This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Harmonization: add priorTransmission to support Transmission Sequencing"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| (12 intermediate revisions by 2 users not shown) | |||
| Line 5: | Line 5: | ||
|- | |- | ||
|| Sponsored by: INM | || Sponsored by: INM | ||
| − | || Approval date by committee: | + | || Approval date by committee: 20061016 (INM TelCon). See also [[Sequence Number Protocol]]. |
|- | |- | ||
| − | || Revision (# and date): | + | || Revision (# and date): 20061016 |
|| Date submitted: | || Date submitted: | ||
|- | |- | ||
| Line 26: | Line 26: | ||
|- | |- | ||
|| INM | || INM | ||
| − | || | + | || Approved |
|| S | || S | ||
|- | |- | ||
| Line 32: | Line 32: | ||
== Issue == | == 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 have a | + | 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) == | == Recommendation(s) == | ||
| Line 41: | Line 42: | ||
See image on right: | 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. | *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. | + | **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: | + | *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) === | === RIM Recommendation(s) === | ||
| Line 51: | Line 52: | ||
== Rationale == | == 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|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 == | == Recommended Action Items == | ||
| Line 59: | Line 62: | ||
==Discussion== | ==Discussion== | ||
| + | |||
| + | #(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. | ||
| + | #(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. | ||
| + | #(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 == | == 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. | ||
| + | |||
---- | ---- | ||
| − | {{INM Workitem}} | + | {{INM Finalized Workitem}} |
| − | [[Category:Harmonization Proposal]] | + | {{INM Approval|20061016|Motion to forward the proposal for harmonization (Doug/Sandy, 3-0-0)}} |
| + | [[Category:Discussed Harmonization Proposal]] | ||
Latest revision as of 13:58, 6 December 2006
| 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 |
Contents
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)
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
- (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.
- (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.
- (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.
This page documents an INM Finalized Workitem, i.e. an issue within scope of the INM Committee that has been finalized, and which (if applicable) has been included in an INM ballot.
