CACT R2

CACT an abbreviation for the ControlAct wrapper domains (MCAI,QUQI,MFMT).

• See MCCI/CACT R2 Project for the project plan and scope of MCCI R2, which will be committee balloted in January 2008.

MCAI Open Issues

• Discussion about scope of the controlAct wrapper v Transmission wrapper: Constrain Transmission Wrapper
• 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. Use-case is still there, request is hereby made (20070503).

QUQI Open Issues

• add bolus functionality
• 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, no changes to QUQI) Add confidence-level matching information (in the form of new attributes in QueryAck 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.
  • Michael: Historic CACTs are also related to the focal class. This observation is similarly related to the focal class.
• (closed) When one queries for max. 10 Matching Classes (MC) (in QueryByParameter.InitialQuantity), these could end up being reported in the form of (both extremes) 1 message with 10 payloads, or 10 messages with (each) 1 payload. Is there a rule on how this should be done ? Is the querying system able to influence this ? No.
  • Mark T: query conformance statement by data server defines this.
  • Default rule = Return in as few interactions as possible.
• (closed, add wording as shown in subbullet) 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.

• (closed) Use of nullFlavors in queryParameter classes. Does the use of a nullFlavor "UNK" (just to use an example) 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 parameter 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.
  • Vassil: should not be used as a wilcard (we have a different mechanism to deal with that), so receiver should match with UNK nullFlavor.
  • Motion: If the value of a query parameter is a nullFlavor, the receiving system SHALL not interpret it as a wilcard. The use of nullFlavors in query values needs to be well documented in query conformance statements. (20070502 Q3, Rene/Mark T, 8-0-0)

MCAI closed issues

• (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).

done in DMIM 21/6/07 Charliemccay 10:15, 21 June 2007 (CDT)

• (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)

checking with Dale for CMET admin process Charliemccay 10:15, 21 June 2007 (CDT)

• (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.
• (closed, for documentation in next ballot) 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.
  • 20060915 Motion to change contextConduction on CACT-Payload association not to be a fixed value. This has backwards compatibility issues associated with it. (Rene/Sandy, 16-0-2)

done in dmim Charliemccay 10:15, 21 June 2007 (CDT)

QUQI closed issues

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

Draft MCAI DMIM

Issues

• if we do go for a conversation class, what is its class code and mood code?

dynamic model issues

There has been some progress on the way to diagram the dynamic model. As part of the outcomes we talked about conformance. Conformance will be expressed in terms of profileId (the profile will also define what dynamic pattern, application roles one conforms to). This means that we can toast the concept of Conversation.code (we don't need to convey conversation type for conformance reasons). We probably still have a use-case for Conversation.id (as an optional element), to string together messages at the business-process level.

I have added conversation as an act off controlActProcessChoice -- are you suggesting that ConversationId be an attribute of ControlAct, and that it is effectively an instance identifier for an object typed by ProfileId (ie ProfileId provides the type of the conversation, and conversationId provides a common identifier for all instances that conform to that profile) Charliemccay 09:18, 22 June 2007 (CDT)

My immediate concern is that profileId is a set (and needs to be because a message may be sent as part of multiple care pathways) and the conversation identifier needs to be bound to its type. So this would suggest that we still need the conversation class -- and maybe that profileId is dropped in favour of conversation.code, with tempplateId being used to communicate the static model being used if that is all that matters. Charliemccay 09:18, 22 June 2007 (CDT)

Alternatively profileId is kept for unidentified conversations, and that it is duplicated in the conversation class when an identifier is needed. Charliemccay 09:18, 22 June 2007 (CDT)

The right way to go depends on how often we expect conversations to have identifiers Charliemccay 09:18, 22 June 2007 (CDT)

ControlActGrouper and context conduction

• Is it just the associations of ControlActGrouper that are assumed to provide values for ControlActProcess, or can attribute values be conducted as well.

Draft ballot content

The draft version of the ballot content for the september ballot has been uploaded to the INM documents page [[1]].