Stream: implementers
Topic: Preserving provenance of a FHIR resource
Raheel Sayeed (Nov 09 2021 at 19:19):
What would be the recommended way we could preserve the source URI (full) within the resource? There are potentially two ways: using resource.meta.source
and/or Provenance
We're implementing an app fetches FHIR data from one source and submitting it to another FHIR server (entirely different entity). To avoid any potential collision, all submissions are through POST
-which means: remove existing resource.id
(prior to POST)
Probably its resource.meta.source
? ( @Josh Mandel , @Dan Gottlieb )
From the docs:
Only one nominated source is allowed; for additional provenance details, a full Provenance resource should be used. On the RESTful API: On receiving a write operation, the server SHOULD generally leave this unchanged, unless applicable business rules, along with available provenance, dictate otherwise
However, its unclear if its okay to replace resource.meta.source
, if in the event its already filled in?
Josh Mandel (Nov 09 2021 at 22:37):
I think we might want a common pattern to replace Meta.source for new implementations, given the limitations around its use. Something like a standardized tag of the form:
{
"system": "http://hl7.org/fhir/tags/source-fullUrl",
"code": "https://ehr.example.org/fhir/Observation/123"
}
And maybe also one like the following for cases where the full details are not known or needed:
{
"system": "http://hl7.org/fhir/tags/source-baseUrl",
"code": "https://ehr.example.org/fhir"
}
Josh Mandel (Nov 09 2021 at 22:38):
The idea would be
1) allow for multiple values, where meta.source purpose only one value
2) assign specific semantics for different flavors of sources, where meta.source leaves things wide open
Joel Schneider (Nov 10 2021 at 06:19):
To reference the source of a replicated FHIR resource, instead of using meta.source, we've been adding an "urn:ietf:rfc:3986" identifier, e.g.
"identifier": [ {
"system": "urn:ietf:rfc:3986",
"value": "https://ehr.example.org/fhir/Observation/123"
},
...
Derek Ritz (Nov 17 2021 at 15:28):
This thread seems related to this thread: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Uniqueness.20of.20resource.20id.20in.20FHIR
Across a federation of FHIR servers it can be important to know which resources are "copies" of the same underlying "base" resource.
Lloyd McKenzie (Nov 18 2021 at 16:21):
There is a Linkage resource that can allow tracking that multiple resources are representations of the same underlying clinical/business fact.
Last updated: Apr 12 2022 at 19:14 UTC