Monday, March 12, 2012

HL7 RIM has done its job on HL7 V3. Now it’s time to undermine the V2 standard

I am noticing changes introduced in V2.7 of the HL7 standard – described by one Asian HL7 expert as ‘subtle, insidious and dangerous’ – which consist in the insertion of failed RIM strategies into the newer versions of V2.x. Simple, usable standards are thereby becoming progressively more complex. Mood Codes, for example, the source of so much of what is impenetrable in HL7 V3, are now being reverse-engineered into V2.7, even while the V2.7 documentation acknowledges that At this time, there are no documented use cases for this field. And the CWE ('coded with exceptions') data type, which in V2.6 had 9 components, has 22 components in V2.7 along with multiple new subcomponents.
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:

XML4Pharma said...

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.