Approaches to assiging/creating FHIR resource.Id on non-FHIR data

Ok so I have an allergy record ini a legacy system which I want to expose as a FHIR resource and need to assign some kind of FHIR compatible Id.

Assuming that my internal representation does not handle identification in the same way as FHIR, or my internal representation handles ID at a different level of granularity, are there any documents or code examples showing how others have approached the problem (esp. when versioning gets involved).

I have found a few articles explaining the issue but not offering potential solutions.

Ian

Couple of links to paragraphs on the main FHIR site:

https://www.hl7.org/fhir/managing.html
https://www.hl7.org/fhir/resource.html#id

The Resource.id field is a 64 character length string so unless you have very long identifiers in your local system they should be compatible.

An identifier only needs to be unique within the context (FHIR base URL) it is published - e.g. http://example.com/fhir/Patient/1234.

However, we (Endeavour) have almost always been fortunate enough to have a GUID/UUID against the source data item, so will always use GUIDs/UUIDs where possible, allowing unique resource identity across multiple contexts.

I expect HSCIC will provide guidance in this area for GP Connect shortly.

Do you have anything that uniquely identifies the data?

I have had problems with the length of the id field (the only unique item I could find was filename and path)

Thanks Jonny,

and @mayfield.g.kev. That makes sense, and what I suspected. Works nicely if a uniqueID exists and if there is a 1:1 correspondence to the granularity of that id to the FHIR resource.

I can see how 64 bytes might be limiting for some systems. Should only be tricky for a few openEHR->FHIR mappings.

Ian

Hi Ian,

FHIR ids are just unique strings (https://www.hl7.org/fhir/datatypes.html#id)

Can you find a unique set of fields from within your internal representation plus context that uniquely identifies the allergy record? If so, then you could have an algorithm that takes these fields, converts them to a single string (e.g. by concatenation) and then hash the field (say MD5). This is repeatable and doesn’t require storage of any additional data.

FHIR versioning is part of the resource metadata (https://www.hl7.org/fhir/resource.html#Meta). VersionId isn’t numeric - it just requires a different versionId for each version - so the same strategy could apply.

We’ve used this strategy previously to produce repeatable unique identifiers for entities within data extractions. Would this work for your case?

Thanks Dunmail,

Very helpful. I (think I) understood the principles, just wondered about some of the practical approaches to creating a resource identifier where there was not an nice, easy fit from legacy data.

I now have 3 concrete suggestions, so job done!! Bear in my mind my hacker status :slight_smile:

Ian

Legendary hacker status :wink: