Question: v2 CX vs v3/ISO 21090 II

Aug 17, 2011

The question is:

I am currently working on interoperability between ISO13606 model and Hl7v2. We are using ISO21090 as the model data type. Currently, we are trying to map Hl7v2 data types to ISO equivalents. From my analysis, hl7v2 CX data type will be mapped to II data type. I would thus like to know how II will map to CX data type, in particular the check digit and check digit scheme sub-component?

The v2 CX data type (v2.6):

“This data type is used for specifying an identifier with its associated administrative detail”

Number The value of the identifier itself
Identifier Check Digit A digit, or digits, exclusive of the identifier in CX.1, usually calculated by applying an algorithm to all or some of the digits in the number, which may be used to test validity of the non-check-digit identifier.
Check Digit Scheme Contains the code identifying the check digit scheme employed
Assigning Authority The assigning authority is a unique name of the system (or organization or agency or department) that creates the data
Identifier Type Code A code corresponding to the type of identifier.  In some cases, this code may be used as a qualifier to the “Assigning authority” component
Assigning Facility The place or location identifier where the identifier was first assigned to the patient
Effective Date The first date, if known, on which the identifier is valid and active
Expiration Date The last date, if known, on which the identifier is valid and active
Assigning Jurisdiction The geo-political body that assigned the identifier “Number”
Assigning Agency or Department The agency or department that assigned the identifier “Number”

The ISO 21090 II data type (which is the v3 II data type):

“An identifier that uniquely identifies a thing or object”

root A unique identifier that guarantees the global uniqueness of the instance identifier.
extension A character string as a unique identifier within the scope of the identifier root
identifierName This is a human-readable name for the namespace represented in the root
displayable If the identifier is intended for human display and data entry (displayable = true) as opposed to pure machine interoperation (displayable = false)
scope The scope in which the identifier applies to the object with which it is associated
reliability The reliability with which this identifier is known. This attribute may be used to assist with identifier matching algorithms.

It’s important to understand that the scope of the CX and II are different, as is clear from their definitions: the CX data type includes the administrative details, and the II type doesn’t. Also the II data type is globally unique, which is not a requirement of the CX data type.

In fact, there’s only one piece of information that is the same in CX and II: the actual identifier. But even then, it might be in the root or the extension of the II data type. (for instance, if the CX.Number is a GUID, then it goes in the II.root all by itself. Otherwise it might be tacked onto an OID root in the II.root, or put in the II.extension with something else as the scoping value in II.root).

CX includes information about the type and assigner of the identifier. II doesn’t – it just includes enough to make it a primary key – to be unique. Sometimes, if you have the information, you can convert from the globally unique key to a type and assigner. But that information isn’t in the II data type. It’s also important to know the somewhat unfortunate fact that there’s nowhere else to put the same information in 13606 (as far as I can tell, unless you have the freedom to add it to an archetype in this context, because you’re out in a leaf.). Nor is this stuff in CDA.

As an example, take a medical record number (from my ex-employer, say) in CX:

  • Value: 555555
  • Type: MRN
  • Assigning Authority: St Vincent’s Hospital, Fitzroy

Inspecting this in an instance, we know who assigned it (sort of), and what kind of role it has in their usage – identifying the test patient “Donald Duck” with a record. One problem is that several major cities in Australia have a St Vincent’s Hospital. Is a “555555” from “St Vincent’s Melbourne” the same as  a “555555” from “St Vincent’s Fitzroy”? They are, but whether you can tell depends on how the Assigning Authority is coded, and this is generally not done well in v2 messages.

Representing the same identifier in II:

  • Root: 2.16.840.1.113883.19.1113.1
  • Extension: 555555

In this case, there’s never any question of which institution it comes from – you don’t know, and you don’t need to know. This identifier is 2.16.840.1.113883.19.1113.1::55555 and it will never be used for anything else but this entity, ever. If you do need to know which institution or type (so you can populate a form, for instance) - well that’s the administrative information that’s not part of II or 13606. (Or CDA either.)

Unfortunately you don’t know whether it’s a medical record number, and account number, or something else. And you don’t know – unless the identifier name is populated, which is optional  - which institution this is from – unless you’ve got a list for OIDs (say, the HL7 OID registry).

Converting v2 identifiers to CDA is not too hard – you just have to “know” how to move the value across, and scope it with an OID or GUID somehow. Inevitably this resolves to a configuration table of some form or other. Migrating from a v2 workflow to a CDA (or in this case, 13606) workflow can be a challenge if the workflow depends on this administrative information that is missing from the II type.

Now, specifically for the check digit. V3 / the II type assume that the sender’s business is to check the identifier and not to send it if it’s not correct. So there’s no need for the recipient to know what the check digit is if they’re simply using the identifier (the scope of II). If there’s some advanced workflow that depends on the values of the check digit and method, then that’s administrative stuff, and it’s not in II or CDA either.