Representation of Common Australian Identifiers in v2 and CDA

Previous: Indian Covid-19 Telehealth Application (based on #FHIR) »

Representation of Common Australian Identifiers in v2 and CDA

Jul 29, 2020

This is a wrap up of presentations made last week in the Australian HL7 meeting, along with some additional late breaking information: Medicare OIDs have been finalised. This post iterates through a list of common Australian Identifiers, and shows how to represent each of them in both v2 messages, and CDA documents. If there’s any interest, I’ll provide a DICOM mapping later (note interest in comments). Some of what I have to say, I’m a little unsure of (v2 issues) and I’ll make corrections out of the comments if necessary. The CDA representation is based on the common NEHTA extension for identifiers defined through all the NEHTA CDA implementation guides and also clarified here (vendor firewall, sorry, I’m trying to get it into public), and the CDA implementation guides provide the context for understanding where the asEntityIdentifier goes. Note that the asEntityIdentifier extension is expected to be part of any future CDA version

Institution Medical Record Number

This is also commonly referred to as “UR” for Unit Record Number. There’s no differentiation between “MR” and “UR” (or “MRN”), though a patient may have multiple such numbers due to organisational restructures, and at least one hospital uses “MR” and “UR” to refer to different numbers. However in an HL7 message or a CDA document, they are all “MR” numbers and are differentiated by the assigning authority/scope information.

This example is for a UR number at St Vincent’s Hospital, Melbourne

v2:

PID-3: |123456^^^SVH^MR|

CDA:

<ext:asEntityIdentifier classCode="IDENT">
  <ext:id assigningAuthorityName="SVH" root="[OID]" extension="123456"/>
  <ext:code code="MR" codeSystem="2.16.840.1.113883.12.203"/>
</ext:asEntityIdentifier>

Notes:

In the CDA rendering, the value of [OID] has to be filled in with an OID specific to the particular identifier as used by SVH. Generally someone associated with SVH should define the OID andregister it on the HL7 OID registry. The OID allows for unambiguous identifcation of St Vincent’s Hospital Melbourne. Actually, it just identifies the registry record for the identifier, and the usefulness of this partly depends on the quality of the registration record - though at least there’ll be no duplication, unlike with the code “SVH”. As of today (28 Nov 2011), I can find no registered OIDs for any Australian hospitals.
In the CDA rendering, we have “Assigning Authority Name” giving the informal code, but systems are not allowed to take meaning from that, instead it should come from the OID.
The CDA identifier is given a type using the code for the identifying (IDENT) entity, which is “MR” from the v2 identifier type table. The v2 identifier type table is shockingly messy, but still the best source available
In the v2 rendering, all we know is that the identifier “123456” is a medical record number used by the hospital identified by the code “SVH”. It’s assumed that there’ll be local logic to make sense of “SVH” (which St Vincent’s Hospital?). Some times this local logic is dependent on the known source of the message.

Technically, component 4 is an identifier, and you could do something like this:

123456^^^SVH&[OID]&ISO^MR

- this would make the v2 identifier as rigorous as the CDA identifier, though there’s generally no point, since it’s easier and more cost-effective to do local logic. (This might not be true in the case of inter-institutional clinical messaging, and I’ll be proposing something there when I write the MSIA clinical messaging profile)

You’d use different OIDs/assigning authorities for cases where a patient has multiple local identifers due to organisational restructuring.
There’s an additional HL7 identifier type called “LR” (Local Registry). I’m not at all clear on when it would be appropriate to use “LR” instead of “MR”. Perhaps this would be appropriate for an area wide health service identifier that isn’t used locally in the actual institutions - but usually these are in the process of being introduced anyway. The same applies to the HL7 identifier types “PI” and “PE” - these are not well differentiated (comments please…)

National IHI

This is the new nationwide patient identifier being introduced by NEHTA at the moment. They’re starting to be exchanged.

v2:

PID-3: |8003601234512345^^^AUSHIC^NI|

CDA:

<ext:asEntityIdentifier classCode="IDENT">
 <ext:id assigningAuthorityName="IHI"
    root="1.2.36.1.2001.1003.0.8003601234512345"/>
 <ext:assigningGeographicArea classCode="PLC">
  <ext:name>National Identifier</ext:name>
 </ext:assigningGeographicArea>
</ext:asEntityIdentifier>

Notes:

The inclusion of the assigning geographic area is for round tripping information with the HI service interface, and based on AS 5017, and has no practical utility that I know of
The way the IHI is coded in the CDA document - with the IHI in the OID - frustrates people, but isn’t technically wrong. I don’t know why it was chosen
There’s a NEHTA document out that says that this is the correct OID: 1.2.36.1.2001.1003.0.8003.6012.3451.2345. I don’t know what happened here (and no, I’m not going to link to it), but it’s not the right one
There’s been some debate about the v2 representation since AUSHIC (Australian HIC) has been renamed several times since this code was defined. But it’s a logical code, not a name, and it doesn’t get updated as the name of the logical entity changes
There’s no code with the id to specify the type. This is related to legacy requirements inside the NEHTA process. It wouldn’t be wrong to include , and it might become required at some point in the future.

Medicare Card Number

Australian Medicare card number. This is sometimes used as a patient identifier, and sometimes as an account identifier. This describes it’s use as a patient identifier

v2:

PID-3: |2296818481^^^AUSHIC^MC|

CDA:

<ext:asEntityIdentifier classCode="IDENT">
  <ext:id assigningAuthorityName="Medicare Card Number"
    root="1.2.36.1.5001.1.0.7.1" extension="2296818481"/>
  <ext:code code="MC" codeSystem="2.16.840.1.113883.12.203"/>
</ext:asEntityIdentifier>

Notes:

The OID 1.2.36.1.5001.1.0.7.1 is for 10 digit card number. If the actual identifier is 11 digits, because it includes the line number as well, then the OID 1.2.36.1.5001.1.0.7 should be used instead
I don’t think the v2 metadata changes whether you use the 10 or 11 digit identifier
Fur further information about the medicare card number,see here

When the Medicare number is used to identify a patient account, this is how it’s done:

v2:

PID-3: |2296818481^^^AUSHIC^MC|

CDA:

<ext:coverage2 typeCode="COVBY">
  <ext:entitlement classCode="COV" moodCode="EVN">
    <ext:id assigningAuthorityName="Medicare Card Number"
      root="1.2.36.1.5001.1.0.7.1" extension="2296818481"/>
    <ext:code code="1" displayName="Medicare Benefits"
      codeSystem="1.2.36.1.2001.1001.101.104.16047"/>
  </ext:entitlement>
</ext:coverage2>

Notes:

According to AS 4700.1, medicare number goes in PID-3, and not anywhere else

Healthcare Providers - Individual (HPI-I)

New identifier being introduced by NEHTA at the moment.

v2:

PRD-7: |8003610537409456^NPI^AUSHIC|
XCN: |8003610537409456^[surname]^[given]^[etc]^^[title]^^^AUSHIC^^^^NPI|

CDA:

<ext:asEntityIdentifier classCode="IDENT">
  <ext:id assigningAuthorityName="HPI-I"
    root="1.2.36.1.2001.1003.0.8003610537409456"/>
  <ext:assigningGeographicArea classCode="PLC">
    <ext:name>National Identifier</ext:name>
  </ext:assigningGeographicArea>
</ext:asEntityIdentifier>

Notes:

There’s two v2 methods, depending on whether it’s PRD-7 or elsewhere.
In CDA, HPI-I, HPI-O and IHI are differentiated by the first 5 digits of the identifier itself. They all have the same OID root

Medicare Provider Number

Medicare Provider number - location specific identifier conferring right to bill medicare. Commonly used as a healthcare identifier for providers.

v2:

PRD-7: |049960CT^^AUSHICPR|
XCN: |049960CT^[surname]^[given]^[etc]^^[title]^^^AUSHICPR|

CDA:

<ext:asEntityIdentifier classCode="IDENT">
  <ext:id assigningAuthorityName="Medicare Provider number"
   root="1.2.36.174030967.0.2" extension="049960CT"/>
 <ext:code code="PRN" codeSystem="2.16.840.1.113883.12.203"/>
</ext:asEntityIdentifier>

Notes:

For some strange reason, the accepted v2 representation doesn’t include a type

Medicare Prescriber Number

Medicare Prescriber number - location specific identifier conferring right to prescribe using PBS.

v2:

PRD-7: |453221^PRES^AUSHIC|
XCN: |453221^[surname]^[given]^[etc]^^[title]^^^AUSHIC^PRES|

CDA:

<ext:asEntityIdentifier classCode="IDENT">
  <ext:id assigningAuthorityName="Medicare Prescriber number"
   root="1.2.36.174030967.0.3" extension="453221"/>
 <ext:code code="PRES" codeSystem="2.16.840.1.113883.12.203"/>
</ext:asEntityIdentifier>

Notes:

PRES seems to be an Australian extension to table 203 defined in AS 4700.3

Healthcare Providers - Organisation (HPI-O)

New identifier being introduced by NEHTA at the moment.

v2:

XON: |[name]^L^8003621771167888^^^AUSHIC^NOI|

CDA:

<ext:asEntityIdentifier classCode="IDENT">
  <ext:id assigningAuthorityName="HPI-O"
    root="1.2.36.1.2001.1003.0.8003621771167888"/>
  <ext:assigningGeographicArea classCode="PLC">
    <ext:name>National Identifier</ext:name>
  </ext:assigningGeographicArea>
</ext:asEntityIdentifier>

Notes:

NOI is an extension to table 203 defined for this use.

**Laboratory NATA Identifier **

Used to identify pathology services in clinical messages. A typical pathology service may have many identified labs - there seems to be some arbitrariness about which to choose.

v2:

HD (i.e. MSH-5): |QML^2184^AUSNATA|

CDA:

<ext:asEntityIdentifier classCode="IDENT">
  <ext:id assigningAuthorityName="NATA"
    root="1.2.36.1.2001.1005.12" extension="2184"/>
 <ext:code code="XX" codeSystem="2.16.840.1.113883.12.203"/>
</ext:asEntityIdentifier>

Notes:

XX is “organisation identifier”

**Australian registered company **

Every Australian company is assigned an ACN with a matching ABN. (some other entities are assigned only an ABN, but this coding is for ACN).

v2:

XON: |[name]^L^087493897^^^ASIX^XX|

CDA:

<ext:asEntityIdentifier classCode="IDENT">
  <ext:id assigningAuthorityName="ACN"
    root="1.2.36.87493897"/>
 <ext:code code="XX" codeSystem="2.16.840.1.113883.12.203"/>
</ext:asEntityIdentifier>

Notes:

Part of the root Australian OID (1.2.36) registration is that every ACN defines an OID delegated to the company to manage

Pharmacy Approval Number

Once a pharmacy is registered as a business and has approval from the pharmacy board it may ask Medicare (DHS) for an approval number to become a part of PBS - DHS grant the approval number and it is valid so long as the pharmacy ownership and location remain the same. The number allows the pharmacy to do PBS scripts and claim

v2:

Candidate: ORC-17: |123456789^^AUSPAN|

CDA:

<ext:coverage2 typeCode="COVBY">
 <ext:entitlement classCode="COV" moodCode="EVN">
  <ext:id assigningAuthorityName="Pharmacy Approval Number"
    root="1.2.36.174030967.1.3.2.1" extension="123456789"/>
  <ext:code code="11" displayName="Medicare Pharmacy Approval Number"
    codeSystem="1.2.36.1.2001.1001.101.104.16047"/>
 </ext:entitlement>
</ext:coverage2>

Notes:

Candidate v2 mapping is to a CE. v2 is like that - identifiers and codes are somewhat confused. Per ISO 704, codes in a coding system for which there is only one instantiation of code are called “appelations”. The classic case is country codes. These may be either codes or identifiers, and this is what we have here. Note that the v2 mapping here is the only thing I made up for this post (and it’s crap, but what else can you do?)
Note that this approval number is not the same as the authority and approval numbers for a specific prescription

Conclusion

That’s the common identifiers I know of. Suggest new ones to provide examples for in the comments below.

Acknowledgements: The information here is taken first from Vince’s Presentation at the HL7 Australia meeting, and then from the NEHTA implementation guides and Australian standards AS 4700.1, 4700.2, 4700.3 and 4700.6