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 from CX to II 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, 13606 or CDA either.
[…] Question: v2 CX vs v3/ISO 21090 II « Health Intersections Pty Ltd […]
Well, as the II is unique, you know where it comes from for sure. You just can’t read it ‘in English’ directly. In fact, the way OID are built is giving you more information than just a couple of words. It is almost describing the hospital hierarchy.
Yeah, that’s if it’s built that way, and if you can resolve it. But it might not be built like that, and even if it is, it’s unlikely you’ll be able to access any policies about it so you know what the parts mean – if they mean anything.
Does OID assignment need to be hierarchical with respect to organization hierarchy? If it is, what will happen if there is going to be a reorganization of child organizations?
See comment below. If there’s a re-org, you keep the existing OID you were already using. Because the OID doesn’t have any meaning, except to be unique.
What in the last instance gives the same information than an hospital name. At least knowing the OID you can try to figure what country is it, which organization, etc.
nothing really gives the hospital name. If you can find the OID in a registry, such as the HL7 OID registry, then you can know all about the OID. If you can’t, then you know nothing, and you can’t infer anything from the OID.
Take this common scenario: A hospital department needs an OID. It goes to the hospital, and says “You have an OID. What’s your allocation policy”. The requests ping-pongs around the management because none of them know what an OID is, or why they’d care. Eventually, the department gets an OID from HL7 directly. Later in the year, the hospital is merged with another (M&A in some countries, government rationalisation in others), and it can’t change it’s OID when that happens… We’d be lucky if they even updated the OID registration (which would exist if they got their oid from HL7)
That seems like a problem with the organization workflow, not with the OID itself
oh sure. But it happens all the time. Anyway, the point is, the OID does not reliably tell you anything at all meaningful.
I kind of think of OIDs to be like supermodels. They’re kind of cool to look at (you can’t help it). But they’re really not as useful in practice as they look like they’d be
Point taken that OID should be meaningless, like an uuid. However, the way OID is assigned in hl7 OID registry seems to be systematic. What’s your view on this?
well, there’s no reason not to be systematic. It helps with administration and maintaining uniqueness.