How does one put a FHIR Document into XDS?
How does one find a FHIR Document in XDS?
Both questions are asking very similar things. The key is the XDS fundamental metadata element mimeType. Let me explain...
XDS, more broadly the whole Document Sharing family, including XDS, XCA, XDR, XDM, and MHD. With a set of more narrow IHE Profiles in DSUB, MPQ, SeR, and MU.
To learn more on Document Sharing, start here: Eating an Elephant -- How to approach IHE documentation on Health Information Exchange (HIE)
Initially Document Sharing was about 'historic' documents. That is a document is published, and in the future it can be discovered and retrieved. Thus the Document is "Shared". Later it gained support for "On-Demand" documents. That is a document that is created when it is retrieved. An On-Demand document is still a document, it is just created a the time it is retrieved, and thus contains the current knowledge about that patient at the time. Both of these might still be needed for FHIR Documents.
How does one find a FHIR Document in XDS?
Both questions are asking very similar things. The key is the XDS fundamental metadata element mimeType. Let me explain...
XDS, more broadly the whole Document Sharing family, including XDS, XCA, XDR, XDM, and MHD. With a set of more narrow IHE Profiles in DSUB, MPQ, SeR, and MU.
To learn more on Document Sharing, start here: Eating an Elephant -- How to approach IHE documentation on Health Information Exchange (HIE)
So the Document Sharing family is a Content Agnostic mechanism for sharing Patient specific Documents. Where the only thing that fixed is that this is an exchange for
- Patient Specific content -- so all the documents must be about a specified patient
- Document format -- so it is not a REST server.
Initially Document Sharing was about 'historic' documents. That is a document is published, and in the future it can be discovered and retrieved. Thus the Document is "Shared". Later it gained support for "On-Demand" documents. That is a document that is created when it is retrieved. An On-Demand document is still a document, it is just created a the time it is retrieved, and thus contains the current knowledge about that patient at the time. Both of these might still be needed for FHIR Documents.
FHIR is more popularly known for the access model using http REST. That is where there is a server that holds current version of the knowledge. Systems can "Create", "Read", "Update", and "Delete" (CRUD) the knowledge using the https protocol.
FHIR has a Document model. It is abstractly very similar to CDA, but uses all the more simple Resources and Encoding that FHIR has to offer. A FHIR Document is contained in a Bundle, and has a Composition, and all kinds of other stuff. There is also a workgroup creating transforms from/to CDA -- CDA on FHIR. I am not here t give a tutorial on FHIR Documents, but need it clear that FHIR has the Document concept.
This is where the question comes from... If I have a FHIR Document, how would I publish that into XDS? If I want FHIR Document, how would I find them in my XDS system? -- or more broadly any of the Document Sharing, because this applies to XDM (Direct Secure Messaging), and other...
This is where the question comes from... If I have a FHIR Document, how would I publish that into XDS? If I want FHIR Document, how would I find them in my XDS system? -- or more broadly any of the Document Sharing, because this applies to XDM (Direct Secure Messaging), and other...
So the FHIR Document, is Patient specific... so it should be clear how the Patient identity is related.
Key to FHIR Documents in XDS
The key is that XDS has a metadata element "mimeType". It is this that is the differentiates CDA from FHIR. So for a FHIR document the mimeType is either going to be:
- XML:
application/fhir+xml - JSON:
application/fhir+json
FormatCode might be more powerful
The XDS formatCode holds the indicator of the technical format that the document follows. This is most of the time a URN that is defined in an IHE Profile, or other external body. This is very possible with FHIR Documents too.
I expect a set of FHIR specific "Implementation Guide", which is FHIR concept of an IHE Profile. of FHIR Documents to happen, these 'profiles' would have FHIR 'StructureDefinition' based constraints. The unique identifier for that StructureDefinition would go into the formatCode.
All the other metadata simply explain the content.
All the other metadata is just as applicable to a FHIR Document is it is to CDA, PDF, DICOM, or any other format. Note that XDS is happy to carry proprietary formats like WORD too.
- IHE #FHIR profiles - MHD, PDQm, and PIXm
- MHD - Why use of FHIR Contained?
- IHE FormatCodes are mandatory
- In Wisconsin we have Interoperability
- What is MHD beyond XDS-on-FHIR?
- Health Information Exchange: Centralized, Federated, or Distributed
- Define Atom -- Too many definitions in use today
- Eating an Elephant -- How to approach IHE documentation on Health Information Exchange (HIE)
- Distinction between Documents and Messages
- Understanding XDS metadata - IHE re-documentation effort
- XDS Notifications
- HIE Patient Identity problem
- Healthcare Metadata
- Minimal Metadata
- What is the benefit of an HIE
- Karen's Cross or just Minimal Metadata
- HIE using IHE
No comments:
Post a Comment