Open Control Act Issues

Known issues

MCAI:

• Freeze Mood Code of current RMIMs to EVN (currently ANY mood)
• Use-case for nullification of controlAct, add status to controlAct ?
• Improve documentation when multiple payloads can be used in combination with 1 control act.

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
• query continuation interaction has MT 000300 (which includes a mandatory Message-Acknowledgement class) as its Transmission Wrapper. Shouldn't this be the 000100 wrapper ?

Control Acts in Domain Payloads

• Use of control acts in EVN Mood for change tracking or auditing purposes. Robert Grant (PM) will bring forward a proposal related to this.
• Nullification of control acts. Lloyd Mckenzie has brought forward a proposal 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.