While, therefore, it is being widely acknowledged on the one hand that HL7 V3 has failed, V3's defenders are on the other hand injecting into V2.x some of the very components of the V3 approach which had made it non-viable for messaging.
On Mood Codes in V2.7
For examples of insertions of Mood Codes in V2.7, see chapter 2, section 2.8.1 and Table 0725, and chapter 7, section 7.4.2 (OBX - component 22 - CNE - Mood code):
Definition: This field identifies the actuality of the observation (e.g., intent, request, promise, event). Refer to HL7 Table 0725 - Mood Codes for valid values. This field may only be used with new trigger events and new messages from v2.6 onward.
Note: OBX-22 Mood Code was introduced in v2.6 to support Patient Care messaging concepts and constructs. At this time, there are no documented use cases for this field in the context messages as described in this chapter. This statement does not preclude the use of OBX-22, but implementers should exercise caution in using this field outside of the Patient Care context until appropriate use cases are established. While a similar note exists for OBX-21 Observation Instance Identifier, particular care should be taken with OBX-22 as this could modify the intent of the segment/message and create backward compatibility problems.
5. V 2.7 - Chap 11.2.1.3 "The use of HL7 Version 2.x in clinical messaging has involved the use of segments in ways for which they were not originally intended, as well as the development of the REL segment to express important relationships between clinical data components. Such use has also necessitated the introduction of mood codes to allow for the richer representation of intent, purpose, timing, and other event contingencies that such concepts required.On CWE (coded with exceptions) in V2.6 and V2.7
In V2.6, CWE had 9 components as follows:
SEQ | LEN | DT | OPT | TBL# | COMPONENT NAME | SEC.REF. |
1 | 20 | ST | O | Identifier | 2.A.74 | |
2 | 199 | ST | O | Text | 2.A.74 | |
3 | 20 | ID | O | 0396 | Name of Coding System | 2.A.35 |
4 | 20 | ST | O | Alternate Identifier | 2.A.74 | |
5 | 199 | ST | O | Alternate Text | 2.A.74 | |
6 | 20 | ID | O | 0396 | Name of Alternate Coding System | 2.A.35 |
7 | 10 | ST | C | Coding System Version ID | 2.A.74 | |
8 | 10 | ST | O | Alternate Coding System Version ID | 2.A.74 | |
9 | 199 | ST | O | Original Text | 2.A.74 |
In V2.7, however, this has been expanded to 22 components, which are made even more complicated by the introduction of Value Sets and OIDs (unique object identifiers).
As of v2.7 a third tuple, formerly known as triplet, has been added to the CWE data type. Additionally, 3 new components were added to each tuple such that each tuple now has a total of 7 components.
So each set in V2.6 receives an additional OID (SEQ 14) and a value set OID (SEQ 15) . And this set of 6 is repeated 3 times.
HL7 Component Table - CWE – Coded with Exceptions
SEQ | LEN | C.LEN | DT | OPT | TBL# | COMPONENT NAME |
1 | 20= | ST | O | Identifier | ||
2 | 199# | ST | O | Text | ||
3 | 1..12 | ID | C | Name of Coding System | ||
4 | 20= | ST | O | Alternate Identifier | ||
5 | 199# | ST | O | Alternate Text | ||
6 | 1..12 | ID | C | Name of Alternate Coding System | ||
7 | 10= | ST | C | Coding System Version ID | ||
8 | 10= | ST | O | Alternate Coding System Version ID | ||
9 | 199# | ST | O | Original Text | ||
10 | 20= | ST | O | Second Alternate Identifier | ||
11 | 199# | ST | O | Second Alternate Text | ||
12 | 1..12 | ID | C | Name of Second Alternate Coding System | ||
13 | 10= | ST | O | Second Alternate Coding System Version ID | ||
14 | 199= | ST | C | Coding System OID | ||
15 | 199= | ST | O | Value Set OID | ||
16 | 8= | DTM | C | Value Set Version ID | ||
17 | 199= | ST | C | Alternate Coding System OID | ||
18 | 199= | ST | O | Alternate Value Set OID | ||
19 | 8= | DTM | C | Alternate Value Set Version ID | ||
20 | 199= | ST | C | Second Alternate Coding System OID | ||
21 | 199= | ST | O | Second Alternate Value Set OID | ||
22 | 8= | DTM | C | Second Alternate Value Set Version ID |
1 comment:
We have recently seen something similar in the CDISC SDTM standard (a standard for electronic submissions for new drug applications to the FDA).
In the recently published "Trial Summary Update to the SDTM Implementation Guide: Human Clinical Trials" they introduced null flavors which are (suspiciously) very similar to those of the HL7 RIM.
These "flavors are null" have been introduced for some cases in which bad choices were made before when designing/developing the standard. For example, for the study parameter "AGEMAX" (maximum age of the subjects in the study), the data type has been set to ISO-8601 "duration" (e.g. P65Y for max 65 years old) in an attempt to unite numbers with units! If there is no age limitation however, the value should be set to null, and the "nullflavor" to PINF (positive infinite).
Oh my God! What a bad design!
And this in a standard that has nothing to do with HL7! SDTM still uses the ancient SAS Transport 5 format (.xpt) which does not allow for having "infinite" as a number (XML does).
My impression was that they just added flavors of null to overcome the (severe) limitations of SAS Transport 5 together with some bad design decisions made before.
Post a Comment