Stream: implementers
Topic: FHIR Document with XDS Metadata
Thomas Pellizzari (May 01 2017 at 06:18):
This is my first post in the community, hello to everybody from Austria.
Our company is developing medical archiving solutions, and we have recently started to integrate FHIR capabilities. We would like to archive FHIR documents, which have been mostly converted from other sources by our own tools (e.g. from HL7 ORU). So documents according to the FHIR document paradigm seem a reasonable choice (i.e. "Bundle" with "Composition" + other ressources like DiagnosticReport).
Now, we would like to add some Metadata coming from the XDS domain (XDS DocumentEntry) to the FHIR documents. The "DocumentReference" has the appropriate metadata (i.e. DocumentReference.context). But it seems not like a good idea to mix the two concepts "Composition" and "DocumentReference".
What would be a good way of having both FHIR documents according to the document paradigm AND integrating the DocumentReference.context?
Any help most appreciated!
Sunanda Veeraganti (May 01 2017 at 07:30):
@Thomas Pellizzari it is a good idea. The two concept "Composition" and "DocumentReference" can be used together. And your Document Reference resource can reference the Composition.
John Moehrke (May 01 2017 at 12:03):
DocumentReference is the proper metadata to point at any kind of document. It works just as well for FHIR Documents as it does for CDA documents or even proprietary documents like WORD. See https://healthcaresecprivacy.blogspot.com/2017/03/multiple-formats-of-same-document.html
John Moehrke (May 01 2017 at 12:03):
IHE is even looking to it as a general metadata registry for patients that are not patient centric, like stylesheets. This is unlike XDS, but is differentiated by the fact that there is NOT a Patient indicated... This is a new work item about to be sent out for Public Comment.
Elliot Silver (May 01 2017 at 16:38):
From the original question, I'm not sure that FHIR Documents are actually needed, or if they are a by-product of the architecture investigated so far.
If @Thomas Pellizzari is really trying to store XDS documents and metadata in FHIR, or provide a FHIR interface to XDS, or store ORU reports (of some sort) with XDS metadata, then I would suggest skipping FHIR Compositions totally. Instead look at the IHE MHD profile which standardizeds a FHIR interface for XDS, including mapping XDS metadata to FHIR DocumentReference elements.
Thomas Pellizzari (May 01 2017 at 17:02):
Thank you everybody for your feedback, that helps a lot.
Just for clarification, we are trying to achieve several goals:
1) "Upgrade" ORU reports to a more interchangeable format, with proper code systems etc. Or in other words, we would like to
prefer FHIR over HL7 CDA whenever possible (sometimes it is not, of course).
2) Provide access to documents via MHD (which has a well-defined mapping to DocumentReference)
3) Find a meaningful structure for long-term archiving of these data. As some may know, we in the german speaking countries have an
obsession with long-term archiving.
Last updated: Apr 12 2022 at 19:14 UTC
