Identification

Authors: Alexander Henket/Niek van Galen (Nictiz), Tom de Jong (VZVZ), Henry Mulder (MedMij)
Status: Work-in-Progress

1 Identification

1.1 Intro

Whenever you access information, you always want to know if and how information relates to other information. Identification plays a crucial role in connecting different pieces of information such as a result to an order, and in detecting if two pieces of information as are actually (versions of) the same information.

If a system is unable to detect that one piece of information is actually the same as another piece of information then they will come up as two pieces of information. This could have several consequences, including but not limited to:

• User could start using twice the medication he is supposed to
• User could be burdened with manual deduplication, something he may not be knowledgeable enough for
• System could proliferate duplicate information to other systems
• The same action could be billed multiple times

There are a lot of information objects that are typically identified: observations, images, documents, problems, practitioners, and organizations. The list is not a closed list however, and at time of writing it does not exist as normative list. Over time new information objects will be defined and added to the list of identifiable information objects.

While ‘information’ should have persistent identifiers, also known as business identifiers, there are usually also other ids at play of a more technical or temporal nature. They include message ids on Edifact and HL7 V3 interactions, FHIR Resource.id supporting RESTful communication and more. These temporal ids are a source of confusion because of their overlapping name and sometimes seemingly overlapping function.

1.2 Definitions and Principles for Business Identifiers

To establish a healthcare ecosystem where information is consistently identified across all parties involved in handling the information, we need some definitions and principles.

1.2.1 Definitions

• ‘source system’ - a system that information originates in. Note that in some cases e.g., devices, it could be the system that the device sends the first basic information to.
• ‘secondary system’ - any system that is not the source system for that information.
• ‘business identifier’ - a persistent and globally unique identifier for information regardless of their technical representation.
• ‘logical id’ – a persistent id(entifier) for a specific representation of information, which is guaranteed unique within the context of a given server. Information may have multiple representations, e.g. in various technical carriers.

1.2.2 Principles

ID-1 Source systems SHALL be responsible for assigning a business identifier to every identifiable information object. Source systems SHALL have a methodology in place to guarantee global uniqueness

ID-2 Secondary systems SHALL be responsible for maintaining the business identifier assigned by the source system as they obtained it

ID-3 Source systems and secondary systems SHALL be responsible for applying business identifier as assigned by the source in all forms of electronic distribution, unless the specific use case forbids them to

ID-4 Any system regardless of being the source SHALL maintain persistent logical ids when required for the use cases for the information and unique within that system

1.3 Interoperability

One of the most difficult realities to deal with is the fact that it matters which technical standards you apply when dealing with business identifiers. It also matters for logical ids but the implications are less severe.

Example: lab results. Lab results can have identifiers in many ways. They may be related to a placer order (requester), and a filler order (performer). A result may be sent multiple times as more results become available. It may have a result identifier for the whole and for the individual tests. Some parties may even relate everything to the (derived) specimen. Lab results exist in every technical standard that is in use:

Edifact MEDLAB 1.0	HL7v2	HL7v3 CDA	FHIR Bundle, Observation, Specimen
UNB+5 Interchange Control Reference (alphanumeric string 14 characters)	MSH|10 Message Control ID (string no length)	Interaction Message ID (datatype II – with OID)	Bundle.identifier (datatype Identifier with URI)
IDE+2 Identificatienummer materiaal/aanvraag (alphanumeric string 9 characters)	ORC|2 / OBR|2 Placer Order ID (datatype EI) ORC|3 / OBR|3 Filler Order ID (datatype EI) SPM|2 Specimen ID (datatype EIP)	observation/id (datatype II with OID) specimen/id (datatype II with OID))	Observation.identifier (datatype Identifier with URI) Specimen.identifier (datatype Identifier with URI)
No identification possible at (individual) result level.	3 Observation Identifier is actually the type of test and not an identification of ‘this’ test	Identification possible at all levels	Identification possible at all levels

The table shows that not all levels of identification exist in all different technical standards. If they do exist, they may or may not be interoperable due to differences in the datatype related to length or other properties.

FHIR STU3 and beyond

[FHIR specifies] the following methods for identification of a resource:

There are two different ways to identify a resource:

• By a "Location" URL that identifies where is can be accessed (based on the "Logical ID"). This location will be change as it is copied/moved around
• By some inherent identifier ("Business Identifier" or "Canonical URL") that is part of the resource and remains fixed as it is copied/moved around

Logical ID is based on the Resource.id and the (RESTful) endpoint this resource came from. Any resource SHOULD have an id, except in special cases like create requests where the receiving server is expected to assign the Resource.id. Resource.id SHALL be unique and persistent within the resource type and endpoint. The Resource.id is assigned by each server individually, and MAY even be reassigned when the same server exposes a new endpoint, e.g. because of an upgrade to a new version of FHIR.

For logical ids you SHALL NOT assume that:

• [host A]/Patient/123 and [host B]/Patient/123 are the same patient.
• [host]/stu3/Patient/123 and [host]/r4/Patient/123 are the same patient.
• [host]/Patient/123 and [host]/Patient/456 are not the same patient.

For logical ids you SHALL assume that:

• [base]/Patient/123 will either not resolve or will always point to the same patient

Business identifiers are in Resource.identifier. A business identifier SHOULD be assigned at the source system. A business identifier, if available, SHALL be applied in the relevant resource in FHIR. A secondary system SHALL preserve the original identifier and SHALL reuse the original identifier in any communication/migration of that resource.

If only one identifier exists on a resource without Identifier.use, it SHALL be the primary identifier of that resource as assigned by the source. If multiple identifiers exist, then Identifier.use SHALL be the discriminator (usual | official | temp | secondary | old).

Business identifiers always consist of the identifier itself and the identification system that produced it. The identifier SHALL be unique within the identification system. The identifier is considered case sensitive unless the identification system is known to be case insensitive. This is specifically relevant for uuids which are lower case ‘on output’ (RfC4122) but case insensitive ‘on input’. While HL7 V3 did not enforce any casing on uuids, the expectation in FHIR is a lower-case representation because communication is considered ‘on output’. This could mean that a simple string comparison could fail based on casing.

The basic rule is that systems SHALL preserve the original business identifier. Some implementation aspects have to be taken into account. Most of current information exchanges are based on something other than FHIR. Most of the cross enterprise/realm exchanges are based on HL7 V3/CDA as touched upon above for uuids. All HL7 V3 identifiers can be converted into FHIR. Some FHIR identifiers cannot be converted into HL7 V3 at all. Hence additional requirements apply for identifiers to flow safely across domains and technical implementations:

• FHIR Identifier.system SHALL be of type Object IDentifier (OID), unless a formal 1-to-1 mapping exists between a URL based system and the OID. In this case and only in this case, the system SHALL be the URL
  • Official listing of URLs/OIDs for NL
  • More information OIDs
• FHIR Identifier.system length SHALL be <= 128 characters, exclusive of urn:oid: or urn:uuid:
• FHIR Identifier.value length SHALL be <= 64 characters

1.4 Sources

• Nictiz FHIR IG R4 Usage of the .id, .identifier and .fullUrl elements
• MM-2606 "Uitbreiden mapping Huisartsgegevens <> Ketenzorg met resource.id"
• MM-2695 "Verduidelijken dat identifier bij sturen gewenst is per meting"
• MM-2829 "Hoe om te gaan met FHIR identifiers en Gegevensdienst en MedMij releases?"
• MM-2832 "Verplicht stellen van Resource.identifier bij ingestuurde zelfmetingen"
• FHIR Chat "Resource.id and endpoint STU3/R4"
• Informatiestandaard Basisgegevensset Zorg Medisch Specialistische Zorg (BgZ MSZ)
• FHIR Resource identifiers
• HL7 NL Datatype Instance Identifier (II)

1.5 What is an OID?

An OID (Object Identifier) is a string of integer nodes (without leading zeros), separated by periods, which can be constructed and maintained in a way that guarantees global uniqueness as an identifier. An OID corresponds to a node in the "OID tree" or hierarchy, formally defined using ITU standard X.660. The root of the tree contains the following three arcs:

• 0: ITU-T
• 1: ISO
• 2: joint-iso-itu-t

Each node in the tree is represented by a series of branches that leads to the node, corresponding to the path from the root through the series of ancestor nodes, to the node. Thus, an OID denoting Intel Corporation appears as follows, 1.3.6.1.4.1.343, and corresponds to the following path through the OID tree:

• 1 ISO
• 1.3 identified-organization,
• 1.3.6 DoD,
• 1.3.6.1 internet,
• 1.3.6.1.4 private,
• 1.3.6.1.4.1 IANA enterprise numbers,
• 1.3.6.1.4.1.343 Intel Corporation

A textual representation of the OID paths is also commonly seen; for example,

• iso.identified-organization.dod.internet.private.enterprise.intel

Each node in the tree is controlled by an assigning authority, which may define child nodes under the node and delegate assigning authority for the child nodes. Continuing with the example, the node numbers under root node "1" are assigned by ISO; the nodes under "1.3.6" are assigned by the US Department of Defense; the nodes under "1.3.6.1.4.1" are assigned by IANA; the nodes under "1.3.6.1.4.1.343" are assigned by Intel Corporation, and so forth. Within HL7 (V3 and FHIR) OIDs can be used to identify identification schemes and coding schemes. These schemes are collections of alphanumerical strings that either identify an object (thing or activity) within the identification scheme (e.g. a particular BSN within the list of all valid Burger Service Nummers in the Netherlands) or classify a codable concept within the coding scheme (e.g. a particular LOINC code within the list of all valid LOINC codes).

1.6 Centralized vs. locally defined OIDs

There are two types of schemes that potentially need to be uniquely identified: centrally maintained shared schemes and locally maintained private schemes. Most coding schemes fall into the first category, e.g. ISO country codes, LOINC, SNOMED, NHG table 45, HL7 codes, G-Standaard medication, etc. These code systems are maintained by some central authority and require a common understanding of their semantics by any system that uses them.

Some identification schemes also fall into the centralized category, like BSN, URA number, UZI number and AGB number (even though that is usually called an AGB code). They have a central registry to maintain associated data (like SBV-Z for BSN and Zorg-AB for the others) All these centralized schemes have a commonly used OID, but also a commonly used URL in the case of FHIR interfaces, which can be mapped to each other in case of transformations.

The trickiest category are locally maintained identification schemes, which identify objects (usually activities) that are recorded during the healthcare process or information exchange. Examples of these are identifiers of lab and other observations (ánd associated requests), encounters, medication acts, but also logged messages. These don’t have to be understood by secondary systems, but are simply recorded or matched with previously stored data.

The tricky part is not so much their uniqueness within the source system, but assigning a unique OID for the local ID scheme that contains them. This requires a way that guarantees the principle of delegated authority for OID assignment, without having a central authority. Therefore, there needs to be a base OID node that uniquely identifies the context of the application, IT vendor or healthcare organization that assigns the more specific OIDs.

1.7 Assignment method for locally defined OIDs

Voor al deze identificaties geldt dat ze uniek en persistent moeten zijn. Dit betekent onder andere dat ze ook bestand moeten zijn tegen migraties en fusies van informatiesystemen.

Het is onmogelijk om vanuit HL7 Nederland, of welke instantie dan ook, centraal bij te houden welke OID’s gebruikt worden voor lokaal gegenereerde zorggegevens. Elke applicatie die een uniek nummer bepaalt per ingevoerde order of uitgevoerde activiteit zal daarvoor een eigen unieke en persistente OID moeten hanteren, om te zorgen dat bijvoorbeeld elke medicatieverstrekking te onderscheiden is van elke andere medicatieverstrekking.

Wat daarom nodig is, is een compromis met de volgende kenmerken:

• Forceer OID roots per applicatie, per zorgaanbieder of per softwareleverancier.
• Geef richtlijnen voor het uitdelen van nodes onder deze roots.
• Laat het beheer hiervan over aan de assigning authority (behorend bij de root).

De volgende IDs kunnen in principe als root dienen in de zorg:

• De applicatie, o.b.v. de door het LSP uitgedeelde applicatie ID (dit zou handig zijn, maar er is dan geen vanzelfsprekende assigning authority).
• De zorgaanbieder, o.b.v. het UZI Register Abonnee (URA) nummer (probleem is dat nog niet zeker is of URA 1-op-1 bij zorgaanbieder zal horen).
• Het Goed Beheerd Zorgsysteem, o.b.v. de daaraan uitgedeelde GBZ ID (probleem is dat de juridische definitie van een GBZ nog niet 100% zeker is).
• De IT-leverancier, o.b.v. een nog te bepalen identificatie van de organisatie (het lijkt niet zo handig om leverancier assigning authority te maken, bijvoorbeeld i.v.m. conversie naar een andere leverancier).

Implementatierichtlijnen zijn nodig om duidelijk te maken welke OID-structuur gebruikt moet worden in HL7 versie 3 berichten binnen AORTA.

Ten behoeve van de wereldwijde uniciteit en persistentie van gegevens-identificatie wordt de zorgaanbieder geadviseerd haar URA (UZI Register Abonneenummer) te gebruiken als basis voor de OID root van alle binnen de zorgaanbieder gegenereerde gegevens. Zorgaanbieders die reeds een bestaande OID hanteren, mogen deze blijven gebruiken. Voor goed OID-gebruik moeten de volgende zaken worden meegenomen:

• De inrichting van identificatie is een samenspel tussen zorgaanbieder en systeemleverancier
• Identificatie dient persistent en wereldwijd uniek te zijn
• Zorgaanbieders dienen zich ervan te vergewissen dat systemen in haar organisatie allemaal persistente, unieke identificatie garanderen
• Als meerdere systemen op basis van dezelfde OID (bijvoorbeeld URA) van de zorgaanbieder identificatie toekennen, dan zijn branches onder deze OID onvermijdelijk
• Voorbeeld voor zorgaanbieder met URA 12345678 die deze voor identificatie in zijn lab- en radiologiesysteem wil gebruiken LAB: 2.16.528.1.1007.3.3.12345678.1 RAD: 2.16.528.1.1007.3.3.12345678.2
• Identificatie op basis van URA werkt alleen goed als de zorgaanbieder administratie over toegekende OID's per systeem bijhoudt, zodat er geen ambiguïteit ontstaat
• Als een zorgaanbieder geen OID-administratie per systeem kan of wil voeren, dan kan een leverancier deze service voor zijn systeem bieden door een OID aan te vragen. Op basis hiervan kan de leverancier, branches toekennen aan klanten. Uiteraard dient de leverancier dan de administratie hierop bij te houden.

1.8 OID-related business rules for applications

De volledige ID (dus extensie én OID root) moet altijd reproduceerbaar zijn

• bij opslaan opgevraagde gegevens moet volledige identifier worden bewaard
• bij opnieuw opvragen van gegevens moet dezelfde identifier worden opgeleverd

De volgende praktijksituaties moeten ondersteund worden:

• Gegevens wijzigen van bron
• Er vindt een migratie plaats van gegevens tussen softwareleveranciers, zorgverleners of locaties
• De ID (OID root en extensie) blijft gehandhaafd; er mag dus niet meer omgenummerd worden
• Gegeven wordt afgemeld voor oude bron en aangemeld als onderdeel van nieuwe bron
• Externe gegevens worden opgenomen in eigen dossier
• De ID (OID root en extensie) blijft gehandhaafd; er mag dus geen eigen nummer meer toegekend worden.