What do you do when you can’t (easily) create a valid resource ID?

This post is rather like ‘peeking over the parapet’ – but here goes!

As most of you will know, one of the fundamental concepts behind FHIR is that resources have an ‘identity’ by which it can be addressed – expressed in the specification as the ‘id’ of the resource. And that id is limited to 64 characters in length.

Once you have this identity, it is then possible for individual resources to reference each other in a ‘web’ of information – for example a Condition resource can reference the Patient resource that represents the person who has the condition.

When you’re developing a ‘green fields’ application, it’s reasonably straightforward to create these identities – or to ensure they exist – but what do you do if you’re creating a FHIR interface to an existing system that simply doesn’t have these concepts?

For example, suppose the source system (holding the data you want to expose) exposes its data by means of a SOAP service. Your proxy application calls that service to get the allergies and all you get back is the list of allergies for that person. Or, suppose that there is a potential Id but it is too long for FHIR – which could well happen if you were aggregating data from v2 messages where the identifiers can be quite long.

One way is to expose the information as a List resource with contained AllergyIntolerance resources, but that affects the search url – you are now querying against a List rather than a Resource Type.

You could require the interface component to manage (and persist) a mapping between the contents of the resource and an id generated by the interface – but this is shifting the problem around rather than solving it. Ideally the problem should be fixed at source, if that is possible.

Is there an argument to say that the resource ID should be optional?

Obviously not having an identity severely affects the usability of the resources:

• They can no longer be the target of a reference from another resource – but in some cases that ability is not actually needed. For example if all we want to do is to display a list of the patients allergies, then not being able to reference those resources isn’t a limitation. (Obviously the Allergy resource needs to reference the Patient resource – but that’s another matter.)
• And it is no longer possible to perform any ‘instance’ operation on a resource – for example you can’t retrieve a specific allergy – you get the whole (unidentified) list or you get nothing.
• And when importing data it becomes harder to determine duplicates

If making the id optional is a step too far (and sends the wrong message to the community), an alternative might be to leave it as required, but allow a generated id with a standard tag that indicates the id is generated and carries no real identity.

None of this is nice, but it does lower the barrier of entry to FHIR and maybe encourage the source systems to add identity to their data.

Of course, it might also be too low.

Now to pop back below the parapet…