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

Difference between revisions of "Open Control Act Issues"

From HL7Wiki
Jump to navigation Jump to search
Line 3: Line 3:
 
== MCAI Known Issues ==
 
== MCAI Known Issues ==
 
*Discussion about scope of the controlAct wrapper v Transmission wrapper, [[Add interactionId to ControlAct]]
 
*Discussion about scope of the controlAct wrapper v Transmission wrapper, [[Add interactionId to ControlAct]]
*Create harmonization proposal to drop QueryByparameter.ResponseElementGroupId. Dropping it may have backwards compatibility issues.
+
*Create harmonization proposal to drop QueryByparameter.ResponseElementGroupId. Dropping it may have backwards compatibility issues. See [[Harmonization: Remove ResponseElementGroupId from QueryByparameter class]] (for July2006 harmonization)
 
*(high) Make ControlAct.id mandatory ?.   
 
*(high) 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.  
 
**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.  

Revision as of 11:37, 8 June 2006

Known issues

MCAI Known Issues

  • Discussion about scope of the controlAct wrapper v Transmission wrapper, Add interactionId to ControlAct
  • Create harmonization proposal to drop QueryByparameter.ResponseElementGroupId. Dropping it may have backwards compatibility issues. See Harmonization: Remove ResponseElementGroupId from QueryByparameter class (for July2006 harmonization)
  • (high) 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).
    • MnM will discuss Interaction Patterns during the May2006 WGM. The outcome of that discussion may influence the discussion of this issue.
  • 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.
  • (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

  • ParameterItem.semanticsText: should be mandatory. Can't be changed in QUQI models because clones of this class are defined in MTs by other committees. Make mandatory in RIM. (LLoyd) The rules for backward compatibility is that a receiver expecting the old version must be able to extract and safely interpret the data they would have received from an old instance from the new instance. Obviously that would not be a problem here.
  • QueryByParameter.responseElementGroupId:: SET<II> (0..*) is defined as "The responseElementGroupId identifies the specific message type to be returned in the query response. This message type must be chosen from the set of message types supported by the receiver responsibilities associated with the query interaction."
  • 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.