Stream: implementers
Topic: How to save external resource's ID
Yunwei Wang (Aug 22 2019 at 14:10):
Here is the use case: Hospital A send a resource (e.g. Condition to Hospital B. Hospital B create its own Condition resource with internal id. Hospital B also wants to keep track of Hospital A's id so that it can avoid creating duplicated record when Hospital A send an update of this Condition. Where, in FHIR resource, can external id be saved? I am thinking using identifier field. Is that correct?
Michel Rutten (Aug 22 2019 at 14:17):
Maybe you can leverage the common Meta.source field?
http://hl7.org/fhir/resource-definitions.html#Meta.source
Michele Mottini (Aug 22 2019 at 14:29):
We do use Identifier for that purpose - value = remote id, system = 'synthetic' URI identifying the remote
Yunwei Wang (Aug 22 2019 at 14:31):
@Michel Rutten That is a good idea but I forgot to mention that I am using STU3. Meta.source was introduced in R4.
Yunwei Wang (Aug 22 2019 at 14:33):
@Michele Mottini Do you also populate Identifier.use and Identifier.type? If so, what the value should be?
Stefan Lang (Aug 22 2019 at 14:34):
Requiring an identifier seems reasonable in that case.
Ideally this would be set by Hospital A, so they can do a Conditional Update using it (assuming you are using the RESTful API).
Michele Mottini (Aug 22 2019 at 14:37):
No, we do not populate use or type
Michel Rutten (Aug 22 2019 at 14:39):
Please keep in mind that many, but not all resources define an .identifier field.
Stefan Lang (Aug 22 2019 at 14:39):
Regarding the value:
You could either have identifier.system like 'http://hospital-a.com/fhir/identifiers/condition' with identifier.value simply being identical to the id of the resource in hospital A.
Or just use UUIDs
Paul Church (Aug 22 2019 at 14:41):
This came up in the $import discussion. In the May 2019 connectathon doc ("Guidance for servers -- preserving Resource ids") it is proposed to preserve them in an extension to Resource.meta. However, this is just a proposal specific to import.
Stefan Lang (Aug 22 2019 at 14:41):
@Michel Rutten true. So this might not be the global solution, but a 80% solution fulfilling 100% of the need in case of Condition ;-)
Stefan Lang (Aug 22 2019 at 14:52):
@Paul Church If it's useful elsewhere, maybe it shouldn't be specific to $import ?
Paul Church (Aug 22 2019 at 14:59):
Yes - since $import is meant to be a core part of how bulk data is synced between such systems, it will create conventions that can be used in general. I'm just saying this specific proposal is at an early stage.
Lloyd McKenzie (Aug 22 2019 at 15:32):
My recommendation has been to capture the full URL for the original identifer as Identifier.value and set the Identifier.system to urn:ietf:rfc:3986. That way you're not creating 'fake' identifier.systems.
Last updated: Apr 12 2022 at 19:14 UTC
