This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Open Control Act Issues

From HL7Wiki
Jump to navigation Jump to search

Known issues

MCAI Known Issues

  • Discussion about scope of the controlAct wrapper v Transmission wrapper, Add interactionId to ControlAct
  • (high) Make ControlAct.id mandatory ? Related to Interaction Pattern discussion.
  • Improve documentation when multiple payloads can be used in combination with 1 control act.
    • Note that if multiple payloads are used in an interaction which has Receiver Responsibilities then there is a related open issue: interactions have 1 DetectedIssue class. What if one of the payloads of the originating interaction is problematic, but the others are fine ? Should the intire interaction be rejected ?
    • If one sends a notification with multiple payloads, then which payload was the reason for the notification? Interactions based on state-change trigger events should never have more than 1 payload.
  • MnM (and at a later point in time Michael van Campen) has advised that we change contextConduction in the subject act-relationship between the ControlAct wrapper and the payload Act. In most state transitions, the author, reason, data enterer, effective time, etc. of the controlAct are usually different from the focal class. The most common exception to this is the transition from “null” to “active”. MnM 20050109: Motion that we recommend to INM that contextConduction for ControlAct be allowed to be “true” when the data is the same. We would ask that INM ask committees to recommend specific circumstances when it be sent to true. We will also ask the Implementation Committee for their opinion on this matter. Craig/Lee (10:3:5)
    • INM should confirm this by voting upon the motion Allow contextConduction in the subject act-relationship between the ControlAct wrapper and the payload Act to be "true" (in addition to its current value) in the next release of MCAI, and to add basic guidance as to when it would be approriate for it to be "true". The default value will be "false" for backwards compatibility reasons.
  • FM (Kathleen Connor) have announced they will bring forward a proposal to include the sequenceNumber attribute in the subject act-association between the control act and the payload. Issue deferred until receipt of proposal.
    • Discussion within FM is still ongoing whether this is the sequencing option they'd like to go for.
  • (closed issue: reminder for next publication) Freeze Mood Code of current RMIMs to EVN (currently ANY mood). On 20050109 MnM (for different reasons) confirmed this: Motion that for all trigger events the classCode shall be CACT, the moodCode shall be EVN, and negationInd will not be present. This does not constrain classCode or moodCode of ControlActs that are the subject of the trigger event. Woody/Lee (12:0:6).
  • (closed issue: reminder for next publication) The detectedIssue CMET should be moved to the CMET domain, and not be defined locally in MCAI Pharmacy has a use-case for a message that shows all controlActs(+detectedIssue) related to a single order. This can be implemented today as a shared message. If implemented as a wrapper this would require that the tools support stubs with exit points. (This is INM Action item 33)
  • (closed issue: reminder for next publication) Add to D-MIM walkthru: use 2.16.840.1.113883.1.18 as the codeSystem OID for the TriggerEvent attribute.

QUQI Known Issues

  • INM encourages the use of QueryByParameter As Stub (QUQI_MT021001UV01) - as it would at some point in the future like to get rid of the other variant (ParameterList As Stub -QUQI_MT020001UV01) as soon as no comittee is using it anymore. Note that a comittee can change this (even for normative artefacts) as there is no backwards compatibility issue at all when making the switch. This strategy needs formal approval and action item to ask comittees to switch.
  • Add confidence-level matching information (in the form of new attributes in QuerAck or a new class) in all Wrappers that currently contain a QueryAck class. This to have a generic solution for conveying a confidence.level instead of forcing the comittees to define this within the payload model. Disadvantage: at the wrapper level it would apply to all payloads, and would not allow a payload-by-payload confidence level.
  • Query continuation interaction has MT 000300 (which includes a mandatory Message-Acknowledgement class) as its Transmission Wrapper. Shouldn't this be the 000100 wrapper ?
  • When one queries for max. 10 Matching Classes (MC), these could end up being reported in the form of (both extremes) 1 message with 10 payloads, or 10 messages with 1 payload. Is there a rule on how this should be done ? Is the querying system able to influence this ?
  • The sender may indicate a maximum amount of results to be communicated. Likewise the responding system may have its own maximum for the amount of results it can communicate. This may result in responses with a lower number of results than requested. Sending applications have to take this into account.
    • Add statement to standard: the responding application SHALL make an attempt to return a number of results which is as close as possible to the maximum as requested by the query sender. If the responding system decides to "artificially" set its own standard to 1 then this would not follow the intent nor the spirit of the standard.
  • Use of nullFlavors in queryParameter classes. Does the use of a nullFlavor "UNK" identify that the value is unknown, and that the receiver should match it with any value it may have, or should "UNK" be interpreted as "known to be unknown" and match only with a nullFlavor as stored at the receivers end ? See Query Parameters for details.
    • The Dutch use-case behind this is related to a mandatory birthTime paremeter in a query, and the fact that there are persons where both the sender of the query as well as the responding system know that a person has no known birthdate.
  • Add fuzzy (wildcards, phonetic) search parameter description. See Query Parameters for details.
  • Document statusCode usage in QueryByParameter class and QueryAck class, the attribute statusCode - in both cases - uses QueryStatusCode Vocab domain.
  • (closed issue: reminder for next publication) Add description for ControlAct.text in D-MIM walkthrough: it describes the trigger act, which is similar to the description of the message focal act upon its activation, but will be different for something like suspend, abort, or request.
  • (closed issue: reminder for next publication) Deprecate query response mode after MCCI R2 has been published
  • (closed issue: reminder for next publication) Add to QUQI the following statement: UNLESS it has been defined otherwise by the comittee, the following rules apply when it comes to query parameters:
    • between instances of parameterItem classes: AND
    • between multiple values in the value attribute of a single parameterItem: OR.
  • (closed issue: reminder for next publication) Change queryByParameter class and queryId.attribute to mandatory in QUQI RMIMs. This has already been voted upon by INM.
  • (closed issue) Add a new RIM class (associated with QueryByParameter, akin to sortControl) to allow the sender of a query to specify what parts of the response model it would like to receive. No. See Query Parameters for details, and a summary of discussion on the e-mail list.

Control Acts in Domain Payloads

  • Use of control acts in EVN Mood for change tracking or auditing purposes.
    • Proposal 965 (HL7 Canada): the creation of a new cmet, based upon the MasterFile Control Act Wrapper, MFMI_RM700700, for use in payloads.