Stream: fhir-messages
Topic: metadata for different purposes
Ole Vilstrup (Apr 01 2020 at 08:44):
In Denmark we are looking into a new national infrastructure where fhir messaging will happen in an eDelivery setup, which basically means that there will be needs for extracting metadata from the fhir messages to a non-fhir envelope. Furthermore the fhir messages will be placed together with other non-fhir messages in a fhir repository for use in an xds infrastructure.
My thoughts around this is:
- to handle fhir messaging using the Bundle as a message type
- to handle the message stored in the fhir repository together with non-fhir messages in a profiled Communication resource
- to use DocumentReference as the metadata carrier across the different "platforms" and to pull metadata from this to the messaging non-fhir envelope and later to be part of the Communication resource and be the source for registration in the XDS Registry
It will of course complicate the fhir message with doubled metadata information as these data also will be part of other resources in the fhir message, but it will ease the automation of extracting metadata across different needs.
Your thoughts?
John Moehrke (Apr 01 2020 at 12:17):
yes DocumentReference <--> XDS DocumentEntry
This is as designed as the FHIR equivalent. It is also documented this way in the IHE MHD profile (I am the author)
Storing a FHIR Message like this is not a problem. As long as your community understands what it is they are finding. Recommend you define a FormatCode. Some environments have done this, less so with full messages, more so with purpose specific bundles (a bundle of current medications).
In this way, when a new FHIR Message of the same purpose is received, will you 'replace' (XDS replace) the previous so as to limit unnecessary duplication?
I would like to see this promoted as a document content type in IHE...
If this is the target, then why store them as Communication resources? Why not just go direct to DocumentReference? What do you expect to get out of the communication resource?
Vassil Peytchev (Apr 01 2020 at 13:04):
It is likely that your interpretation of the use of the Communication Resource does not match its intent. In general, this sounds like adding too many layers on top of FHIR... Are other mechanisms out of the question? The FHIR Workflow group is currently discussing a Guidance for Data Exchange using FHIR, and while it is still work in progress, there might be some useful information.
Link
Last updated: Apr 12 2022 at 19:14 UTC
