OO CR198-855 - Update REL Field Definitions

Return to OO Change Requests page.

Submitted by: Riki Merrick	Revision date: <<Revision Date>>
Submitted date: 14-Dec-2016	Change request ID: OO CR-855
Standard/IG: v2.10 Standard	Artifact ID, Name: <<Artifact ID, Name>>

Issue

See dB document: http://www.hl7.org/memonly/dbtracker/display_detail.cfm?trackerid=855

Discussion

From OO call 12/15/2016:  Will have to forward to PC WG, who owns the REL segment for final approval and execution  Cannot use the option 1 must maintain the backwards compatibility  OBR-2, OBR-3 and OBX-21 all are EI datatype – need to be sure that can still be covered as part of the CX datatype, but in different locations, so might need to re-organize where the data is mapped from, so adds some complexity  Original intent of the REL was to link events to clinical diagnosis, PC will review with that in mind  Motion to adjust the proposal and submit to PC with the note that option 1 was discussed, but is no longer supported, OO has preference for option2, but also send option 3 along for consideration - Riki Merrick, Jim Harrison, further discussion: I adjusted the discussion about the LCC in the front of the proposal, against: 0, abstain: 3, in favor: 12

Tony Julian 20170815

1. In looking at this, there is a fundamental backward-compatibility problem with changing an EI to a CX.
2. 2.8 VERSION COMPATIBILITY DEFINITION states:
3. "The keys to understanding version compatibility are the following 2 axioms, plus the processing rules which state that unexpected information should be discarded.
   • Old receivers receiving new messages should be able to continue receiving messages without error.
   • New receivers should be able to understand old messages.
4. Changing EI to CX would violate both rules which OO identified.
5. HOWEVER: The REL segment was introduced in V2.6 but added to no message structure. I was unable to find the original change request or minutes for establishing the REL segment.
6. Therefore, if the segment is not specified in any message structure, or implementation guide, then I would be in favor of making the change specified in Option 1 as voted on by PC.