hl7-fhirhapi-fhirsmart-on-fhir

Ingesting FHIR resources - Metadata and resource Identifier for Interoperability / data sharing workflows

Are there any best practices or industry standards when ingesting FHIR resources from another system? More specifically - when multiple healthcare entities using FHIR resources begin sharing data (and wanting to store each other's data within their own system), how should a resource's metadata and ID be handled?

Let's consider one organization has a Patient resource for John Doe. A Practitioner in that system orders a lab (ServiceRequest) and sends that resource to a lab. After the lab is performed, that organization receives the results via a DiagnosticReport and Observation from the 3rd party who performed the test. The metadata (version id, profile, etc.) and ID are going to be referring to that 3rd party, which the ingesting system may not care about.

My gut feeling is the system ingesting those two resources for the lab result would:

  1. Replace the metadata and identifier with information pertaining to it's own system.
  2. Transform any attributes based on the profile being used (if different from the 3rd party)
  3. Store off the 3rd party's identifiers and/or metadata (if needed to be kept for later) elsewhere.

For 3, this could be:

  1. Resource.identifier contains both the ingesting system's AND 3rd party system's identifier
  2. Resource.metadata.source moved to an extension indicating the system it originated from.
  3. References to the Patient in the ingested resource updated to the ingesting system's patient identifier.

Is this the "correct" way to handle persisting external FHIR resources? Or are there other solutions?

Solution

    1. metadata isn't monolithic. metadata.version and lastUpdated would absolutely be replaced. profiles would typically be retained (unless data gets stripped that would violate the declared profiles or at least call validity into question). workflow and security tags might be retained or stripped.

    2. In general, store whatever you can. Don't throw away data just because it isn't in your profile, but you can throw it away if you have no way to store it (so long as it's not a modifier element)

    3. Commonly you'll add the 'id' of the source system as a '.identifier' in the new system to aid in mapping new data.