Question: Australian PCEHR HPI-I in XCN

Sep 27, 2012

Question:

In a previous post (http://www. ), you recommend this representation for an HPI-I (Australian Health Provider Identifier / Individual):8003610537409456^[surname]^[given]^[etc]^^[title]^^^AUSHIC^^^^NPI8003610537409456^[surname]^[given]^[etc]^^[title]^^^AUSHIC^^^^NPIHowever the PCEHR specification for the XCN data type is:^Dolittle^John^^^Dr^^^&1.2.36. ^Dolittle^John^^^Dr^^^&1.2.36. **Whereas I am presently using:800361xxxxxxxxxx^Dolittle^ 800361xxxxxxxxxx^Dolittle^ **How should an HPI-O be represented in a HL7 v2 XCN data type?

Background:

The XCN data type has the following fields related to identification in HL7 v2.4:

ID Name Definition
1 ID number (ST) This string refers to the coded ID according to a user-defined table, defined by the 9thcomponent. If the first component is present, either the source table or the assigning authority must be valued
8 source table Used to delineate the first component (User defined values)
9 assigning authority a unique identifier of the system (or organization or agency of department) that creates the data
13 identifier type code (IS) A code corresponding to the type of identifier. In some cases, this code may be used as a qualifier to the component
14 assigning facility The place or location identifier where the identifier was first assigned to the person. This component is not an inherent part of the identifier but rather part of the history of the identifier

On this basis, the recommendation I made for representing a patient’s IHI was:

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

8003610537409456 is the identifier, AUSHIC is the Assigning Authority (a code defined as part of HL7 v2 itself), and the identifier type is “National Health Identifier”.

XDS uses the same type for the Patient Identifier. Concerning this (XCN) the documentation says:

This data type describes a person along with the identifier by which he is known in some domain (either the source domain or the XDS affinity domain), using the HL7 v2.5 XCN data type. This data type contains, amongst others,

  • Identifier
  • Last Name
  • First Name
  • Second and Further Given Names
  • Suffix
  • Prefix
  • Assigning Authority All of the HL7 v2.5 fields may be specified as optional components with the following restrictions:
  • Either name or an identifier shall be present. Inclusion of other components is optional provided the slot value length restrictions imposed by ebXML3.0, 256 bytes, is not exceeded.
  • If component 1 (ID Number) is specified, component 9 (Assigning Authority) shall be present if available.
  • The XDS XCN Component 9 is subject to the same the restrictions as defined for the XDS CX data type component 4. Thus: the first subcomponent shall be empty, the second subcomponent must be an ISO OID (e.g., 1.2.840.113619.6.197), and the third subcomponent shall read ‘ISO’.
  • Any empty component shall be treated by the Document Registry as not specified. This is in compliance with HL7 v2.5.
  • Trailing delimiters are recommended to be trimmed off. Document Registries shall ignore trailing delimiters. This is in compliance with HL7 v2.5. An example of person name with ID number using this data type is as follows:

11375^Welby^Marcus^J^Jr. MD^Dr^^^&1.2.840.113619.6.197&ISO

Issue

The XCN is the same datatype, but IHE add a specific extra restriction: that the assigning authority must be identified by an OID rather than a code. This is because the XDS eco-system makes extensive use of OIDs, and so this is a natural restriction to make. However this runs into a problem, which is the way that the OID for the HPI-I is defined.

An HPI-I is a 16 digit number starting with 800361, such as 8003610537409456. When it is represented as an OID, it is represented as 1.2.36.1.2001.1003.0.8003610537409456. This is the recommended representation for a HPI-I in a CDA document, and is enforced throughout the pcEHR.

This means that the scoping OID for the HI service identifiers is 1.2.36.1.2001.1003.0. Technically, this is not the same as the assigning authority – it’s not actually a number that identifies the HI Service assigning authority, though it kind of does, since no one can use it for anything else than to refer to the space of the HI Service – which kind of implies the HI Service. So from that perspective, these 2 representations are nearly the same:

800361xxxxxxxxxx^[surname]^[given]^[etc]^^[title]^^^AUSHIC^^^^NPI

8003610537409456^Dolittle^

However, the system designers of the PCEHR had a problem: it had previously been decreed that the OID form of the HI service identifiers is 1.2.36.1.2001.1003.0.800361xxxxxxxxxx. Now this representation works in any place where you have a single identifier – and these are common – but doesn’t work in any place where an identifier is a scoped identifier – and these are common too. XCN is one of those. You can see some discussion around this issue in the comments on my original post (http://www. ).

Given the constraint that the assigning authority is an OID, and the constraint that the HPI-I is represented as a single OID, this leads naturally to this representation:

^Dolittle^John^^^Dr^^^&1.2.36.

Where the HPI-I OID goes in component 9. Even though this is not really valid use of the XCN data type by either HL7 or IHE rules, in that the HPI-I is not actually the assigning authority.

Resolution

I don’t know how this should be resolved. You could do it properly (per the forthcoming Australian identifiers handbook, whichever form it recommends) in the v2 message and differently in the pcEHR XDS metadata, or you could do it both the same – I’m not sure what should be done. The one thing you can sure of is that the PCEHR isn’t going to change for this now.

The comments thread on this post might be interesting (or empty – I’ve given up trying to guess what’s going to generate comments).