Stream: implementers
Topic: Use of id and identifier
Martin Grundberg (Mar 25 2020 at 08:04):
We are communicating observations between two systems, where both systems will have their unique instance of each observation, each with it's own internal id.
What is the best way of communicating the ids across the systems? Should we only use resource.id, or should we in addition also use observation.identifier? Each system will need to know the other systems internal id for mapping purposes I guess. But is it better to always communicate the internal id also as an identifier so we get the identifier.system so it is possible to know from which system the id comes?
This seems like a common situation, so looking for some general strategy. Any recommendations?
Lloyd McKenzie (Mar 25 2020 at 14:59):
Resource.id is for the RESTful 'key'. If the instance isn't exposed RESTfully, then use [resource].identifier.
Lloyd McKenzie (Mar 25 2020 at 15:00):
Resource.id is only unique in the context of a known base URL - and if you're not using REST, you don't know the base URL.
Michele Mottini (Mar 25 2020 at 15:11):
(deleted)
Paul Church (Mar 25 2020 at 15:12):
The draft $import spec handles this by putting the source system in meta.source, but doesn't have a good place to put the ID so it adds an identifier extension on meta with system=[input source URI] and identifier=[resource type]/[ID on other system].
There are lots of things not yet resolved with this idea, for example should it track multiple sources? How to represent source systems that aren't fhir, like the output of an ETL from a non-fhir source? Do we need a field on meta in R5 and if so should it replace or extend meta.source?
Josh Mandel (Mar 25 2020 at 15:13):
Resource.id is for the RESTful 'key'. If the instance isn't exposed RESTfully, then use [resource].identifier.
@Lloyd McKenzie this advice doesn't match what I would have said. Have we published it as guidance somewhere?
Josh Mandel (Mar 25 2020 at 15:13):
(Er, I'm thinking primarily about reference.value vs reference.identifier when pointing from one resource to another -- the question is closely related)
John Moehrke (Mar 25 2020 at 15:17):
Seems when there are multiple sources, this is a use-case where Provenance should be brought in.
Lloyd McKenzie (Mar 25 2020 at 15:17):
@Josh Mandel I don't know - what would you have said?
John Moehrke (Mar 25 2020 at 15:18):
it would be good to have a consistent way for someone importing original data from somewhere else, so that someone downstream knows that the copy they are looking at is not original and can easily find the original id. Otherwise we will be creating a de-duplication problem
John Moehrke (Mar 25 2020 at 15:19):
This de-duplication problem was one of my thoughts with the proposals from DaVinci for providing a patient copies of the data that the payer has, while the provider is also providing that very same data. The app the patient is using should have a deterministic way to de-duplicate
Josh Mandel (Mar 25 2020 at 15:20):
@Lloyd McKenzie This came up in discussion on the "saner ig" and I wrote: https://github.com/AudaciousInquiry/saner-ig/issues/14 (basically: I think using reference.value is the best, most general practice)
Lloyd McKenzie (Mar 25 2020 at 15:29):
The question wasn't about referencing, it was about the identity of the instance itself. If you're referencing another resource, you can only use reference.value if the resource either has a URL where it can be reached usefully or if it's in the same Bundle as the referencing resource (and if not RESTfully available, you're stuck using urn:uuid:)
Lloyd McKenzie (Mar 25 2020 at 15:30):
(Or you can use Reference.identifier, but in that case, there's no expectation for resolution of the references when querying or performing other operations)
John Moehrke (Mar 25 2020 at 15:32):
Paul Church said:
The draft $import spec handles this by putting the source system in meta.source, but doesn't have a good place to put the ID so it adds an identifier extension on meta with system=[input source URI] and identifier=[resource type]/[ID on other system].
There are lots of things not yet resolved with this idea, for example should it track multiple sources? How to represent source systems that aren't fhir, like the output of an ETL from a non-fhir source? Do we need a field on meta in R5 and if so should it replace or extend meta.source?
I understood the use of meta.source was to put the original root URI here, and keep the same id value within the importing system. If you keep the same id value, then you only need to know the original root URI to be able to re-discover the original. This however means an importing system must be able to use the original id value.
Josh Mandel (Mar 25 2020 at 15:33):
My point here is that any time you're able to populate Reference.identifier you could instead populate Reference.value with a contained resource (that conveys the identifier, and maybe extra details too. So IGs that require Reference.identifier are going to lead to more brittle exchange (since you just have to cross your fingers and assume that the receiving party knows what to do with this thing).
Josh Mandel (Mar 25 2020 at 15:33):
I understood the use of meta.source was to put the original root URI here, and keep the same id value within the importing system.
Unfortunately (in my view) we discussed and decided to leave the meaning/interpretation of Meta.source pretty wide open. Which means different IGs can establish different (and conflicting) conventions.
Michele Mottini (Mar 25 2020 at 15:34):
(It is Reference.reference)
John Moehrke (Mar 25 2020 at 15:34):
yup, hence why I am concerned about the proliferation of de-duplication problem
Josh Mandel (Mar 25 2020 at 15:34):
FHIR#20906 is the context here, for those who didn't follow.
Josh Mandel (Mar 25 2020 at 15:35):
And FHIR#20688.
Lloyd McKenzie (Mar 25 2020 at 15:43):
A contained resource is appropriate if you're dealing with something that's not stand-alone. Otherwise, no reason to make it contained. (There's no expectation that receivers will un-contain on receipt). If you want linkages retained and you don't have REST, you either need to transmit all the linked content in a single bundle or you're relying on non-standard processing to resolve identifiers
Paul Knapp (Mar 25 2020 at 16:35):
.identifier is intended to convey business identifiers (site-independent identifiers) while .id is intended to convey a site-dependent identifier. So for the original question on this thread, if the originating system can also assign a .identifier then both systems would have their own .id and the same .identifier on their resource instances.
.reference.value refers to a .id while .reference.identifier refers to a .identifier.
Lloyd McKenzie (Mar 25 2020 at 17:16):
.reference.value refers to a URI (of which a component is the .id). The URI must either be a RESTful URL or a urn:uuid: in the context of a Bundle
Lloyd McKenzie (Mar 25 2020 at 17:17):
site-dependent identifiers can still be sent using .identifier
Martin Grundberg (Mar 27 2020 at 12:15):
Paul Knapp said:
.identifier is intended to convey business identifiers (site-independent identifiers) while .id is intended to convey a site-dependent identifier. So for the original question on this thread, if the originating system can also assign a .identifier then both systems would have their own .id and the same .identifier on their resource instances.
.reference.value refers to a .id while .reference.identifier refers to a .identifier.
Would you say it is good practice to always include .identifier in addition to the .id, e.g. by having your own system namespace?. Then if it is persisted in another system, they could also persist that .identifier with their instance, and if they expose the same logical resource (their instance), they would include their .id, plus their .identifier and the original systems .identifier? Or is it only the originating system's .identifier that should be populated? The latter comes with the benefit of knowing where the "master" (which I assume could be useful).
Vassil Peytchev (Mar 27 2020 at 13:59):
- It's always good practice to include .identifier in a resource instance.
- If a resource is persisted in another system, it becomes it's own instance. Unless you have some specific business rules that keep the two instances of the resource in sync, they will diverge and are not the same thing. In such cases it is probably better for the "second" instance to use a ".basedOn" or ".partOf" reference to the original resource (when possible).
- using the same .identifier on two different instances of a resource needs to be considered on a case-by-case basis. Using it as an indication of where the original resource originated is overloading the meaning of .identifier, there are probably better ways to indicate that.
Lloyd McKenzie (Mar 27 2020 at 14:26):
"basedOn" and "partOf" would be appropriate if the record represents a distinct business object. If you have 3 different systems tracking a given prescription, they shouldn't use 'basedOn' to point to each other unless one of them is clearly a distinct object (e.g. a pharmacy 'encoded' representation of the original order). If you have multiple copies of an encounter, order, allergy, etc. on different systems they typically won't have any relationships to each other - though Provenance and/or Linkage might be used to indicate derivation relationships or assertions as to which is primary/source-of-truth.
Last updated: Apr 12 2022 at 19:14 UTC
