FHIR: A question of identity

One thing that comes up frequently for people new to FHIR is the concept of a resource identity – and I have a great deal of sympathy with this as I also had a lot of trouble getting my head around exactly what this is.

The identity of a resource is one of the fundamental concepts in REST – and in FHIR. In fact the way that you refer to a resource is via its URI – the Uniform Resource Identifier. It is a way of unambiguously locating or specifying the resource: if you have the URI then you can find and refer to it – for example being able to state unambiguously to which patient a particular condition refers.

What seems to trip people up in healthcare is the similar business concept of a patient identifier, like a Medical Record Number (MRN) or in New Zealand the National Health Identifier (NHI) and which is often called a patient ID. Despite the similar sounding (identical!) names, they are quite different.

• The resource ID refers to the location of a resource (any resource) on a particular server (or at least the ‘external address’ – it’s up to the server where and how  it’s physically stored, but it does agree to always refer to that resource from that place). Further, the resource ID is unique only on that server – it’s not transportable between servers.
• The MRN is actually an identifier from a registry/system of some sort – and identifies the person/patient for the business purpose of healthcare delivery. In healthcare, this functionality is often supplied by a ‘Master Patient Index’ (MPI) that has all sorts of sophisticated algorithms to help to resolve issues like two identifiers referring to the same person.

So FHIR also has these 2 concepts:

• The resource ID (specific to a server) that every resource MUST have. If a copy of the same ‘thing’ is stored on different servers, then they will have different IDs, but the ID  will never change on a given server. It’s kind of like a primary key in a database – except that the primary key will change if a record is migrated to another database, which means that the location on that server would change, which means that it is no longer the same resource. A sequential counter or GUID that doesn’t change and stays with the record might be a better choice. The resource ID is not a property of the resource – it is held outside of it.
• A specific resource (like Patient) CAN have one or more identifier properties that refer to some external system or registry. FHIR doesn’t have any particular requirements of an identifier, only that you can specify the ‘system’ within which the identifier is unique – eg a passport, or a drivers license are equally valid identifiers. And, an identifier can change for a given resource.

Another way to think of the difference is that the resource ID is a ‘system’ level ID – it locates resources and allows one resource to reference another. Change the ID and it becomes a different resource. An identifier is about how humans categorize things – including other humans – and can change.

When a resource is copied from one server to another (maybe it is in a bundle, and the recipient server wants its own copy), then it will receive a new ID on the new server and so is a different resource (there is a different URI that refers to it). However, if there is an identifier property on the resource, then that will remain the same so a consumer of the resources will know that they are actually pointing to the same real world entity – eg a patient.

There is more discussion on resource identity in the spec here, and about the identifier here. And I’ve talked before in this blog about REST in general, and using the ID to manipulate resources.

In this blog I try to consistently refer to a resource ID as its ‘ID’, and a specific identifier property as ‘identifier’

Makes sense?