Open Control Act Issues

Known issues

MCAI:

• 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).
• 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 DetrectedIssue class. What if one of the pyalodas of the originating interaction is problematic, but the others are fine ? Should the intire interaction be rejected ?
• 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)
• Add to D-MIM walkthru: use 2.16.840.1.113883.1.18 as the codeSystem OID for the TriggerEvent attribute.

QUQI:

• Deprecate query response mode after MCCI R2 has been published
• Add fuzzy search parameter description
  • Names - work with PA TC, proposal 926.
  • Codes: can one use a "*" code if the query contains a coded value parameter, and one wants to convey that the serach is for any code contained in a specified codeSystem. This as a generilzed version of a query for 1 specific code in a specified codeSystem.
• 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.
• 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 ?
  • 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.
• Change queryByParameter class and queryId.attribute to mandatory in QUQI RMIMs. This has already been voted upon by INM.
• 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 ?

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.