Harmonization: add priorTransmission to support Transmission Sequencing

Recommendation for HL7 RIM Change	RECOMMENDATION ID:
Sponsored by: INM	Approval date by committee: 20061016 (INM TelCon). See also Sequence Number Protocol.
Revision (# and date): 20061016	Date submitted:
Editor/Author: Rene Spronk
PROPOSALNAME: add priorTransmission to support Transmission Sequencing

Stewards Position

TC	RECOMMENDATION APPROVAL STATUS	AFFECTED ENTITIES OF INTEREST TO TC (responsibility level: S=Steward; I=Interested)
INM	Approved	S

Issue

In order to provide a sequencing mechanism, this proposal seeks to add a new "blue class" to the RIM that allows the identification of the "prior transmission". If one has the ability to identify a Transmission and its preceding Transmission, then we effectively have introduced a sequencing mechanism.

See the "Rationale" section for the relationship with the Sequence Number Protocol.

Recommendation(s)

Proposed new RIM class

See image on right:

• Add a new TransmissionRelationship class to the RIM, with 2 relationships with the Transmission RIM class. A Transmission (entry point) has 0..n TransmissionRelationships, each of those transmissionRelationships is related to 1..n Transmissions.
  • Effectively what this tries to accomplish is shown in the top half of the image, if Transmission were an Act (which it currently isn't).
• The TransmissionRelationship class has 1 attribute: typeCode (description: A code specifying the meaning and purpose of every TransmissionRelationship instance. Each of its values implies specific constraints to what kinds of Transmission objects can be related and in which way), with values taken from the TransmissionRelationshipTypeCode vocabulary (description: A code specifying the meaning and purpose of every TransmissionRelationship instance. Each of its values implies specific constraints to what kinds of Transmission objects can be related and in which way). The initial value for the vocabulary is SEQL (description: A transmission relationship indicating that the source transmission follows the target transmission).

RIM Recommendation(s)

• Add a new TransmissionRelationship class with a typeCode attribute as described above.

Vocabulary Recommendation(s)

• Add a new TransmissionRelationshipTypeCode vocabulary with 1 value: SEQL and descriptions as shown above.

Rationale

• Use of the Sequence Number Protocol requires that all interactions have an immediate response interaction. The Sequence Number Protocol therefore forces the sender to request accept acknowledgements for some interactions (those that don't have receiver responsibilities which result in an immediate response), but not in others. In order to separate the use of accept Acks from the use of a sequencing mechanism INM has decided to drop the sequence number protocol from the v3 standard (see the "Sequence Number Protocol" page on the HL7 Wiki for details). This proposal supports sequencing without relying on accept acknowledgements and immediate application responses.
• An alternative is to altogether remove support for sequencing in HL7 v3, which is counter to the v3 statement of principles, which states that all v2 functionality will be supported in v3.
• The original intent of the proposal was to create a new priorTransmission class, a more generic approach does however seem advisable given that next to SEQL other TransmissionRelation types may be useful (e.g. COMP, ACK_OF).
• Note: as long as the decision hasn't been made to use the top-half-of-the-RIM classes for Transmission purposes, INM will bring forward harmonization proposals that extend the "blue classes".

Recommended Action Items

• Implement the proposed solution

Discussion

1. (Woody) Why not add a self-association??
   • (Rene) those don't seem to be used anywhere in the RIM, only associations between a class and one of its specialisations. But that's not a reason why it couldn't be used. The associations between the blue classes don't show up in the XML instance, so there is no way to distinguish between a self-association of one type vs. a self-association of another type. (e.g. SEQL vs COMP).
   • (Woody) Self associations are "legitimate" in the RIM, but are not currently part of the RIM. A self-association would ONLY work for ONE type of relationship, but then again, the only type code you have asked for is SEQL. If there is a further type later on, the self-association could be extended to your "TransmissionRelationship" class. BTW, if you had proposed "COMP", I would have raised the concern of how does a component transmission differ from a transmission within a Batch? Can we be absolutely clear about the distinction for users?
   • (Rene) The concept of Batch would be deprecated if&when we introduce COMP. See Composite Message Type (new wrapper mechanism) for where this may be heading.
2. (Woody) Modeling error (should be fixed during Harmonization discussion).
   • Your cardinality on the lower of the two associations in your digram is reversed. (See the RIM ActRelationship model).
   • Your text now reads "A Transmission (entry point) has 0..n TransmissionRelationships, each of those transmissionRelationships is related to 1..n Transmissions."
   • It should read "A Transmission (entry point) has 0..n TransmissionRelationships, each of those transmissionRelationships is related to 1..1 Transmissions."
   • I would also suggest using the SAME naming (source/target and inboundRelationship/outboundRelationship) as used in ActRelationship and RoleLink.
     • (Rene) The above may be proper suggestions to RIM model the intent of the proposal. I'm not a RIM modeler, so these details may well be wrong.
   • BUT, if you do this for JUST SEQL, as I read your proposal, each Transmission should point to its ONE preceding or following Transmission, not all of them. In that case, the cardinality to TransmissionRelationship would be 0..1. (This might be added as a design constraint when choosing SEQL.)
     • (Rene) True. I don't know of a use-case where one would want/have to identify multiple transmission that one is a SEQL to. A design constraint seems to be called for.
3. (Woody) Further question -- Does this mean you intend to deprecate "sequenceNumber" within Message and expectedSequenceNumber within Acknowledgement? If so, we should add OpenIssues to be sure that such changes are proposed.
   • (Rene) That is the intent regardless of whether this proposal is accepted or not. The sequence number related attributes will be removed from all MCCI DMIM/RMIMs. It's not on INMs list (yet) to have them declared "deprecated" in the RIM itself, so that probably should be captured as an OpenIssue.

Resolution

Approved, As amended, 8-0-4. November 2006 Harmonization meeting.

"Motion to accept the proposal as it will be amended by Woody": (Norman/Kathleen 8:0:4)

Amendments are shown on this page.

---