Stream: implementers
Topic: CCD/CCDA endpoints?
Abbie Watson (Dec 08 2017 at 17:53):
Are there any proposals or recommendations for which endpoints a CCD/C-CDA document should be served up on? We've gotten enough of the Argonaut/MU2 resources implemented that we're starting to put together entire patient histories now, and are quickly moving into processing CCD/C-CDA documents. I can expose them through custom REST endpoints easily enough; but I'd be just as happy to follow other people's lead and build on community efforts.
John Moehrke (Dec 08 2017 at 18:03):
DocumentReference would point at a Binary which is the CCDA content.
John Moehrke (Dec 08 2017 at 18:04):
the Argonaut and the IHE-MHD specifications are working hard to make the Query/Retrieve side consistent, at least for DocumentReference.
John Moehrke (Dec 08 2017 at 18:04):
See IHE-MHD for an approach to publication side, and use of DocumentManifest, and List.
John Moehrke (Dec 08 2017 at 18:05):
http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)
John Moehrke (Dec 08 2017 at 18:05):
There will be testing at the comming Connectathon on this
John Moehrke (Dec 08 2017 at 18:06):
also, my blog on the topic https://healthcaresecprivacy.blogspot.com/2017/11/hie-future-bright-fhir-api-to-document.html
Abbie Watson (Dec 08 2017 at 18:08):
Huh. Very interesting. Not exactly what I was expecting, but makes sense. I'm glad I asked. Thank you!
Abbie Watson (Dec 08 2017 at 18:09):
Bumping up DocumentReference resource as a priority item to implement.
Eric Haas (Dec 08 2017 at 18:11):
Argonaut DocumentQuery is published here for DSTU2 and will be updated in US Core for December Ballot here
Radu Craioveanu (Jan 04 2018 at 21:00):
I noticed Epic is using a Basic Resource to implement an API to request / generate a CCDA in 2.1 format. We were thinking of using a Composition to create and commit a CCDA to our FHIR stack. We were not sure how to create an actual request mechanism? How does the CCDA WG plan to address the workflow?
Grahame Grieve (Jan 04 2018 at 21:04):
DocumentReference should be used for handling existing CCDA documents. To create one... I don't know. ProcedureRequest. Note that Epic's choice in R2 is much restricted compared to current versions of FHIR
Radu Craioveanu (Jan 04 2018 at 21:49):
DocumentReference should be used for handling existing CCDA documents. To create one... I don't know. ProcedureRequest. Note that Epic's choice in R2 is much restricted compared to current versions of FHIR
Grahame, thank you. I initially thought it would be DocumentReference myself, but then I noticed Composite has the concept of Sections, so I thought maybe it should be used instead. Can you point me to a sample CCDA done via DocumentReference?
Grahame Grieve (Jan 04 2018 at 21:53):
well, this: http://build.fhir.org/xds-example.xml.html (though it refers to a C32 not a CCDA)
Grahame Grieve (Jan 04 2018 at 21:54):
but I think you're looking to actually convert the CCDA content to FHIR directly?
Grahame Grieve (Jan 04 2018 at 21:54):
(not merely refer to it)
Radu Craioveanu (Jan 04 2018 at 22:01):
(not merely refer to it)
indeed, convert CCDA content to FHIR, not merely refering to it. Thanks
Grahame Grieve (Jan 04 2018 at 22:03):
then you should look at this:
Grahame Grieve (Jan 04 2018 at 22:04):
John Moehrke (Jan 05 2018 at 14:54):
Are you looking to produce an equivalent FHIR Document as the source CDA? That is a Document is produced that meets the principles of a Document? Or are you just looking to decompose as much of the CDA into FHIR Resources and make those resources available as FHIR Resources? If so, then see http://wiki.ihe.net/index.php/Mobile_Cross-Enterprise_Document_Data_Element_Extraction. This IHE Profile looks to expose the vast existing CDA documents that are communicated in Document Sharing exchanges as discrete data elements through the core set of FHIR Resources.
Radu Craioveanu (Jan 05 2018 at 15:23):
Yes, I am looking to produce an equivalent FHIR Document as the souce CDA. Tell me what you think, please.
here is our usecase:
- we have James Agnew's HAPI FHIR server running STU3 on top of Siemens Cerner EMR and several other clincal and financial systems. We are standardizing internally for all applications and systems on FHIR, single view first architectural pattern - everything gets written to the FHIR stack first, then mapped / pumped to the back end systems via interceptors, and everything is ready from the FHIR APIs. We call our internal systems, which include the API, the back end routing, cache, security ... FABRIC.
- we want to exchange CCDAs with CommonWell, CareEverywhere and some Point to Point (large hospital or healthcare groups...)
- we are looking initially at outbounding CCDA from our system to some of the above, on demand, first use case is ToC Letters
- Some of these end points support FHIR and some do not. Currently we are anticipating they will accept the HL7 CCDA v2.1 XML version, with sections for Medications, Immunizations, Plan of Care, Allergies, ...
- I want to build a mechanism in FABRIC in which we can support requests for both FHIR native CCDA as well as v2.1 XML files.
- I see a few options of getting there:
a. build a component outside of FHIR which will consume discrete FHIR resources (Alergies, Immunization, MedicationStatement...), take that data, compile it and produce the v2.1 CCDA ToC. This CCDA document can then be saved back into FHIR as an attachment to DocumentReference for future consumption, review, retrieval, ...
b. build a component outside of FHIR will will consume a Composition object in FHIR that can GET a FHIR native CCDA. This may required a POST request first (by CCDA type). Once retrieved, that FHIR Composition CCDA can then be transformed into v2.1 CCDA or other outbound formats
- (a) and (b) above are not mutually exclusive, but I want a separate team to build that and I think (b) would be easier for them.
Lloyd McKenzie (Jan 05 2018 at 15:41):
So you're just wanting to generate the CCDA document, not consume a CCDA. Have you looked at http://hl7.org/fhir/composition-operations.html#2.41.13.1? It needs an additional parameter (in general) to pass a profile or graph definition to better qualify what needs to be generated, but should be a good starting point. I think your usecase is absolutely one that should be supported by the core spec.
Lloyd McKenzie (Jan 05 2018 at 15:45):
Also see GF#14391
John Moehrke (Jan 05 2018 at 15:48):
So the Document Sharing infrastructure can carry a FHIR Document just as well as it carries a CDA document. This is indeed something I have been stressing to those communities. The most critical difference is that within the DocumentEntry (FHIR DocumentReference) the document would be described with a mime type indicating that it is encoded as a FHIR Document (likely two entries because you likely want to make both json and xml avaialble, unfortunate duplication but really not that much overhead). These encoding flavors can indicate that they are following the same content requirement rules through using the same FormatCode (FHIR DocumentReference.content.format). All of these DocumentEntry (FHIR DocumentReference) can be in a relationship indicating they are all transforms of the same document (FHIR DocumentReference.relatesTo)
John Moehrke (Jan 05 2018 at 15:49):
See my blog article on this https://healthcaresecprivacy.blogspot.com/2017/03/multiple-formats-of-same-document.html
John Moehrke (Jan 05 2018 at 15:50):
and an older article https://healthcaresecprivacy.blogspot.com/2017/01/fhir-documents-in-xds.html
Radu Craioveanu (Jan 05 2018 at 15:52):
thanks. will check this out.
John Moehrke (Jan 05 2018 at 15:52):
Lastly, there is a theory that when one does the HTTP GET to retrieve the document (FHIR Binary), that the http negotiate can be inspected by the server and used to pick the prefered and available mime-type. This has only been talked about, not yet have I heard of it being tried.
Radu Craioveanu (Jan 06 2018 at 17:12):
I read the Mobile XDS, your blog on multiple formats as well as teh composition-opearatoins and that is exactly what I want to do.
Do you know if there are converters (open source) from FHIR Composition to C-CDA v2.1 or from FHIR Resources to C-CDA v2.1.
Eric Haas (Jan 06 2018 at 18:14):
@Rick Geimer ?
Last updated: Apr 12 2022 at 19:14 UTC
