Open Control Act Issues

MCAI Known Issues

• Use-case for nullification of controlAct, add status to controlAct ?
• 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.
• Procedural: how to deal with proposals that suggest changes to artefacts, or introduce new artefacts, with a reason that is related to the ITS ("the XML messages are too big unless we simplify the model") or Messaging Infrastructure. Are these proposals "unrelated" by their very nature?
• 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.
• Make ControlAct.id mandatory ?.
  • It is currently an optional attribute. The ControlAct is the key thing in every message, so for it to not be identified makes little sense. We can set an expectation that responses to requests must echo back the ControlAct.id. This makes good modeling sense. What you're responding to is not the payload, but the request about the payload. If I send you 20 request for modification messages, and your response just includes the id of the thing to be modified (which is contained in the payload of the application response), I have no idea which request you're responding to. If you send me the ControlAct.id, I know *exactly* what you're responding to. I might not have a prescription.id or an annotation.id, but I will always have a ControlAct.id, and that id will be unique to the request.
  • Using ControlAct.id is a little better than Transmission.id, because ControlAct.id is probably an end-to-end concept, whereas Transmission.id is peer-to-peer (or hop-to-hop).
• (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 MUST 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.
• Create a RIM harmonization proposal to change the cardinality to 0..1 of the RIM attributes ParameterItem.value and AttentionLine.value. This to bring them in line with they way they're actually used - a correction similar to Observation.value which has already been fixed.
  • Lloyd McKenzie has brought forward a proposal (as a technical correction) for the March 2006 harmonization meeting. If accepted the models and walkthrus need to be updated. This technical correction has been approved by INM on its Feb 20 Telcon.
• (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.
• Nullification of control acts. Lloyd Mckenzie has brought forward a proposal (proposal 963) related to this to INM. The principles behind the proposal are being discussed by MnM, INM will await a recommendation from MnM before deciding how to move forward.

Business-Level Receiver Resonsibilities

The question pharmacy and lab are faced with seems to boil down to this example use-case: how do I send (1) "here's an order, please perfom" v. (2) "FYI: here's an order, please keep on record, do not perform".

• Let's assume the receiver responsabilities (from a pure communications standpoint) are the same, and that both interactions (1) and (2) are notifications that DO NOT have receiver responsabilities. (i.e. no application-level accepts or rejects)
• In that case interaction (1) has the same structure, trigger event, and (communication-level) receiver responsabilities as interaction (2). So currently in v3 modeling terms they are exactly the same.
• So we have a use-case for wishing to explicitely include some of the "business level receiver responsabilities" of the receiver into the interaction, e.g. "this is an order I want you to act upon" v. "FYI, do nothing".

(Tom de Jong): The example use-case states that the interactions do not have receiver responsibilities, but that's not entirely true. Receiver Responsibilities have two (potential) elements:

1. the required response interactions (communication responsibilities) and/or
2. the required resulting trigger events (processing responsibilities). Of course the trigger event and the interaction will often go hand in hand, but in this example we assumed there were no communication responsibilities.

So the first question is: can the difference between the two interactions be determined by the fact that one will result in a trigger at the receiver (the request for fulfilment) and the other will not (the notification)? So in this example, without a response interaction, what is the resulting trigger event (so, on the receiver side) for the fulfilment request?

(Rene) One of the problems when discussing this is that the definition of Receiver Responsibilities has never been formally agreed upon. There is a working definition, but it contains a definition of Trigger Event that is purely communication oriented, not business process oriented.

(Lloyd)We need to discuss within MnM whether introducing a level of standardization above the existing level of "receiver responsibilities" is desirable. Effectively what we'd be doing is defining part of the 'internal' state machine of the various application roles and showing how a complete flow might occur. This gets into the area of application behavior, which is an area where HL7 has traditionally tread very lightly. (Rene) This additional level is currently labeled Interaction Pattern on this Wiki.