XCN DataTypes.The “consultant”, “GP”, or “practitioner” entities in our HL7 messaging are encoded in HL7 XCN datatypes.
We use this datatype typically in PV1-7, PV1-8, PV1-9 etc. Whenever we’re handling a clinician code and name.
For an authoritative definition of HL7 structures, we use Caristix
e.g from an HL7 message
C4100760^Groves^Christopher^James^^Dr^^^NHSCONSULTANTNUMBER^PRSNL^^^NONGP^""
In reality, the XCN output from most customers’ HL7 messages is a repeating collection of XCN in the same segment
e.g.
C4100760^Groves^Christopher^James^^Dr^^^NHSCONSULTANTNUMBER^PRSNL^^^NONGP^""~902802735032^Groves^Christopher^James^^Dr^^^DRNBR^PRSNL^^^ORGDR^""
i.e. Chris Groves has a GMC consultant code of C4100760, but also has another (possibly local) code of 902802735032
EMS only processes a single consultant code per field (referrer, requester, performer)
So we’re faced with a choice - which code do we send to EMS?
The consultant code we choose must be recognised by EMS - either by virtue of being a recognised national codeset (e.g. GMC), or by being pre-configured as a local code within EMS.
MOSTLY in England, NHS Trusts use the GMC or GMP National codes - i.e C followed by seven digits. Health organisations in other countries, or in the private health sector may choose to use other identfier types for medical practitioners. Equally, there maybe other common use cases whereby the “referring practitioner” into EMS is actually a registered nurse practitioner, or some other qualified clinical professional. In such cases, the referring clinician may not have a GMC Consultant Code.
Messages sent into EMS are actually sent as HL7 FHIR. Specifically scheduling, referral and order messages are sent into EMS as FHIR ServiceRequest message types.
Consultant, GP, or other clinician details are codified in FHIR messages as PractitionerRole datatypes. This datatype contains both a Practitioner and an Organization. MEDILOGIK have added their own proprietary extensions to the PractitionerRole datatype to:-
ENGLISH,SCOTTISH,LOCAL){
"resourceType": "PractitionerRole",
"id": "2",
"extension": [ {
"url": "http://medilogik.co.uk/fhir/extensions/PractitionerRoleDataSet",
"valueCodeableConcept": {
"coding": [ {
"system": "http://medilogik.co.uk/fhir/coding/PractitionerRoleDataSet",
"code": "E",
"display": "English"
} ]
}
} ],
"identifier": [ {
"type": {
"coding": [ {
"code": "GP"
} ]
}
} ],
"practitioner": {
"reference": "#3"
},
"organization": {
"reference": "#4"
}
}, {
"resourceType": "Practitioner",
"id": "3",
"identifier": [ {
"use": "official",
"type": {
"coding": [ {
"code": "GP"
} ]
},
"system": "https://fhir.hl7.org.uk/Id/gmp-number",
"value": "G6770587"
} ],
"name": [ {
"use": "usual",
"family": "SCOTLAND EML",
"prefix": [ "Dr" ]
} ]
}, {
"resourceType": "Organization",
"id": "4",
"identifier": [ {
"use": "official",
"system": "https://fhir.nhs.uk/Id/ods-organization-code",
"value": "M81067"
} ]
},
We can see from the FHIR snippet above, that the FHIR syntax for encoding a “consultant” is quite precise. For a PractitionerRole, we provide both a Practitioner and an Organization.
The name portion of the Practitioner is relatively uncontentious, there is a close mapping between HL7 v2.4 and FHIR-R4 definitions of a HumanName. The identifier portion in FHIR is more complex. FHIR provides the taxonomy to allow us to be very precise in defining an “identifier”.
"identifier": [ {
"use": "official",
"type": {
"coding": [ {
"code": "GP"
} ]
},
"system": "https://fhir.hl7.org.uk/Id/gmp-number",
"value": "G6770587"
} ],
Firstly, FHIR allows us to send multiple identifiers per Practitioner - EMS however, will only consume one identifier.
The EMS HL7 interface attempts to select the best or rather most appropriate identifier to send to EMS, and then codifying it in such a way that EMS recognises that it is (for example) an ENGLISH code for a GP.
We also need to accommodate other identifiers:-
Local codes - e.g. the site-specific codes that the customer’s PAS uses
Scottish Codes - ISD / NSS in Scotland use a different set of identifiers for GP’s, Practices, etc
Other Nations’ National code sets.
The system attribute attached to the Identifer allows us to be very explicit in defining what codeset the identifier belongs to. EMS itself does not actually process this field, but the interface can use this when trying to select the best identifier from a collection. Where possible, the interface tries to classify the identifier using a FHIR “official” codeset e.g. https://fhir.hl7.org.uk/Id/gmp-number for NHS GP codes or https://fhir.hl7.org.uk/Id/gmc-number for NHS Consultant codes.
The use attribute allows us to specify that an identifier is OFFICIAL, SECONDARY ,OLD, TEMP, or USUAL. Again EMS does not parse this value, but the interface does attach this value to an identifier and this can be used to select the best identifier from a collection.
In addition to the Practitioner identifier, and name, we also need to provide EMS with some additional information to help EMS ingest the information.
Organization - the organisation to which the Practitioner belongs. In the case of a Consultant - this is likely the ODS / NACS code of the Trust that employs the consultant. In the case of a GP referrer however, the GP Practice is the organisation. As we send clinical details to EMS as PractitionerRole datatypes, we can accommodate this Organization requirement.PractitionerRoleDataSet - this an EMS extension (read “kludge”) to the FHIR encoding. This allows the interface to tell EMS which internal lookup table to use to check the code. e.g
Scottish for ISD / NSS Scottish Consultant codesEnglish for GMC / GMP identifiers.Local for OtherIn reality, the system attribute attached to the FHIR identifier does exactly the same thing as this PractitionerRoleDataSet - but EMS doesn’t parse the system attribute it’s provided.
So as we’ve discussed, the interface needs to handle a wide range of inputs for clinician identifiers, and where multiple values are provided, needs to select the best identifier.
There are a number of methods which can be configured to accomplish this:-
The current process by which the interface selects identifiers is a mixture of:-
Qualification - the customer TIE must qualify any identifier they send us. Using subfield XCN.9 (or XCN.10), the customer sends us a qualifier to tell us what type of identifier it is. Most PAS’s already do this. The interface uses this in it’s selection process.
C\d{7} - C foillowed by 7 digits) is likely a GMC consultant code.
G\d{7} (G followed by seven digits) is likely a GMP GP Code.
[A-Z]\d{5} is likely a UK GP practice code.
The EMS HL7 interface is written in in Java with Spring, and we have the ability to “swap out” small chunks of code (“plugins”) via configuration. These allow us to create rules about which identifier should be used. This is a powerful tool, but this degree of customisation can be difficult to manage on a per-customer basis.
The following components currently exist, and can be used to evaluate and select the preferred identifier:-
From the contents of an XCN we attempt to deduce the identifier system e.g. GMC, GMP etc. This is assisted by the customer passing a value in XCN.9 (assigning authority). i.e. the customer explicitly states “GMC”
NOTE although we refer to XCN.9 as the qualifier subfield, this can also be configured at runtime. e.g. we could instead use XCN.8 - Source Table for the same purpose.
We attempt to classify the “use” (e.g. OFFICIAL or SECONDARY) of the identifier based on the values in the XCN. e.g we may specify that a GMC code is OFFICIAL. But some other unrecognised value is SECONDARY. This value is not necessarily used by EMS, but may be used to inform the preferred identifier selection process.
Where the Identifier System Mapper had not been provided with a value in XCN.9 - the Hinter uses regular expressions to “guess” the identifier type. e.g. G\d{7} is a GMP code and C\d{7} is a GMC code.
EMS needs to know whether the identifier provided is a Consultant or GP. This component classifies the identifier based on the contents of the XCN field.
EMS needs to know which code-set or table to lookup the identifier against. This component attaches a flag indicating ENGLISH, SCOTTISH or LOCAL to the Practitioner (via the PractitionerRoleDataSet)
Ultimately after we’ve processed multiple identifiers from the incoming HL7 message, EMS needs exactly one identifier. This component picks the “best” identifier from the collection of identifiers we’ve found. There are currently two flavours of this component.
This component selects the first OFFICIAL identifier it finds in the collection.
This component iterates through the collection of identifiers, and calculates a “score” for each identifier. The identifier with the highest “score” is returned. The weighting or scoring is performed by an IdentifierWeightingScorer.
This component is responsible for generating a “score” for an identifier.
e.g GmcGmpLocalIdentifierWeightingScorer - generates a score based purely on the system, but weights GMP and GMC codes more heavily than “local” codes
public class GmcGmpLocalIdentifierWeightingScorer implements IIdentifierWeightingScorer {
@Override
public Integer GetScore(Identifier identifier) {
//If there's no identifier value - it has no score.
if (!identifier.hasValue()) return 0;
// An unqualified identifier is better than none - return it with a low weighting;
if (!identifier.hasSystem())
return 1;
switch (identifier.getSystem()) {
case GMC_ID:
return 10;
case GMP_ID:
return 9;
case LOCAL_CONSULTANT_PRACTITIONER_ID:
return 5;
case LOCAL_GP_PRACTITIONER_ID:
return 5;
case UNKNOWN_PRACTITIONER_ID:
return 2;
default:
return 1;
}
}
}
For example the following HL7 snippet was taken from PD1-4 of a customer HL7 message.
Caristix tells us that this field is interpreted as an XCN datatype.
G8937601^GARNER A^^^^DR^^^National GP Code^NATGP~GARNERA^GARNER A^^^^DR^^^PAS^LOCAL
We can see that this field contains two repeats which clearly refer to the same practitioner.
The subfield XCN-10 contains the values NATGP and LOCAL respectively. In this case, EMS is configured to give NATGP a better weighting than LOCAL - as such G8937601 will be selected as the value to send into EMS.
If this XCN-10 value were not present - e.g:-
G8937601^GARNER A^^~GARNERA^GARNER A^^
Then in this case, the Identifier Hinter would deduce that G8937601 is a GMP national code (based on the identifier format G+ 7 digits), and would classify it as a GP code.