This wiki has undergone a migration to Confluence found Here
Difference between revisions of "V2 flavors of null"
Jump to navigation
Jump to search
m |
|||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
'''V2 flavors of Null''' | '''V2 flavors of Null''' | ||
| − | A proposal | + | A proposal #608) has been received to add flavors of Null to V2 using escape sequences. |
| + | |||
| + | [[MEDIA:HL7_V2_Proposal_607.doc|Proposal 608.doc]] | ||
| + | |||
| + | |||
== V2 Flavors of Null questions == | == V2 Flavors of Null questions == | ||
*The first question that comes to mind is | *The first question that comes to mind is | ||
| Line 8: | Line 12: | ||
# how bad to they want it - bad enough to furnish resources? | # how bad to they want it - bad enough to furnish resources? | ||
| + | |||
| + | ---- | ||
| + | # Before proceeding with a project it would help if someone could describe specific real-world use cases involving sending and receiving systems (beyond just interface engines). | ||
| + | # HL7 had previously been adding significant new features to V2 messaging because V3 messaging was very immature and hardly used in the US. However, now that a significant number of vendors have implemented IHE integration profiles which use V3 messaging we may finally be approaching a tipping point where using V3 messaging for new applications becomes practical. If that is the case then we may want to refrain from adding any significant new features to V2. | ||
| + | # Dave Shaver and I had similar ideas for an alternative implementation of null flavors that would involve adding an additional "Null Flavor" (ID) component to every data type. Under that design, instead of |\-NI\| you would send |^NI|. This would preserve backward compatibility better than introducing a new escape code because conforming legacy applications would see a blank first component and ignore the extra second component. The downside is that it would be impossible to send NULL values for subcomponents in the ER7 encoding because there are no sub-subcomponents, but that might be an acceptable limitation. | ||
| + | |||
| + | --22:37, 4 August 2009 (UTC) [[User:Nradov|Nick Radov]] | ||
| + | == Comments == | ||
| + | # The document link above actually contains three different flavors of null: O for Other, U for Unknown, and N for Not Applicable, cooresponding to the HL7 Version 3 concepts of OTH (Other), UNK (Unknown) and NA (Not Applicable). What this seems to indicate is that HL7 Version 2 already addresses "Flavors of Null" using special codes for that purpose. While the this use of special codes in HL7 Version 2 does not follow currently accepted practice in HL7 Version 3, I see no reason to change Version 2 to support flavors of null. The capability is demonstrably present in the example given, adding a new syntax to support it is not required, and doing so would cause substantive change to a large number of existing HL7 vocabulary tables in the HL7 Version 2 standard in order to ensure consistent use of this concept. -- [[User:Kboone|Kboone]] 13:36, 5 August 2009 (UTC) | ||
== Related action items == | == Related action items == | ||
[[V2_flavors_of_null_canada]] | [[V2_flavors_of_null_canada]] | ||
[[V2flavors_of_null_project|Questions about proposal 607]] | [[V2flavors_of_null_project|Questions about proposal 607]] | ||
Latest revision as of 13:36, 5 August 2009
V2 flavors of Null A proposal #608) has been received to add flavors of Null to V2 using escape sequences.
V2 Flavors of Null questions
- The first question that comes to mind is
- do we want to do the work to add flavors of null to V2
- who wants it
- when do they want it
- how bad to they want it - bad enough to furnish resources?
- Before proceeding with a project it would help if someone could describe specific real-world use cases involving sending and receiving systems (beyond just interface engines).
- HL7 had previously been adding significant new features to V2 messaging because V3 messaging was very immature and hardly used in the US. However, now that a significant number of vendors have implemented IHE integration profiles which use V3 messaging we may finally be approaching a tipping point where using V3 messaging for new applications becomes practical. If that is the case then we may want to refrain from adding any significant new features to V2.
- Dave Shaver and I had similar ideas for an alternative implementation of null flavors that would involve adding an additional "Null Flavor" (ID) component to every data type. Under that design, instead of |\-NI\| you would send |^NI|. This would preserve backward compatibility better than introducing a new escape code because conforming legacy applications would see a blank first component and ignore the extra second component. The downside is that it would be impossible to send NULL values for subcomponents in the ER7 encoding because there are no sub-subcomponents, but that might be an acceptable limitation.
--22:37, 4 August 2009 (UTC) Nick Radov
Comments
- The document link above actually contains three different flavors of null: O for Other, U for Unknown, and N for Not Applicable, cooresponding to the HL7 Version 3 concepts of OTH (Other), UNK (Unknown) and NA (Not Applicable). What this seems to indicate is that HL7 Version 2 already addresses "Flavors of Null" using special codes for that purpose. While the this use of special codes in HL7 Version 2 does not follow currently accepted practice in HL7 Version 3, I see no reason to change Version 2 to support flavors of null. The capability is demonstrably present in the example given, adding a new syntax to support it is not required, and doing so would cause substantive change to a large number of existing HL7 vocabulary tables in the HL7 Version 2 standard in order to ensure consistent use of this concept. -- Kboone 13:36, 5 August 2009 (UTC)
