Stream: implementers
Topic: FHIR Document Example Request
Richard Kavanagh (Jan 16 2017 at 03:00):
Does anyone have an example Bundle that represents a "Level 1 CDA". We need to create a profile and want to ensure we are doing the same as others. As far as I can make out this is not within scope of "CCDA on FHIR"
Grahame Grieve (Jan 16 2017 at 10:47):
got an example CDA level 1 document, and I'll convert it?
Richard Kavanagh (Jan 16 2017 at 15:01):
I've placed one here https://gist.github.com/InteropAdmin/b0a586d02f72a2004cd8515ed8554616
Kevin Mayfield (Mar 14 2017 at 09:15):
Would FHIR CDA level 1 equivalent use FHIR Composition/Patient/.../DocumentReference/Binary in a document bundle with the text sections of the Composition blank? Or would you use FHIR DocumentReference/Patient/.../Binary bundle, no Composition.
John Moehrke (Mar 14 2017 at 15:07):
that depends on if you are converting the encoding from CDA/XML encoding. In the case of CDA/XML encoding that would be stored in a Binary, and pointed to by DocumentReference with the mimetype of text/x-hl7-text+xml; but if you are going to 'import' and 'decompose' that CDA into a CDA-on-FHIR or simply a FHIR Document; then you would have a Composition in a Bundle with other stuff as necessary; all pointed to by a DocumentReference with mimetype of application/fhir+xml; of course you might have both, for which you would have two DocumentReference with a transform relationship
John Moehrke (Mar 14 2017 at 15:07):
see my blog article on this topic https://healthcaresecprivacy.blogspot.com/2017/03/multiple-formats-of-same-document.html
Kevin Mayfield (Mar 16 2017 at 12:40):
Cheers. So CDA 1->3 equivalent Bundles would have DocumentReference and may not have Composition for Level 1
Richard Kavanagh (Mar 17 2017 at 08:13):
@Kevin Mayfield Our Level 1 documents dont have a composition. They are essentially a Bundle containing a DocumentReference pointing to a Binary. Our DRAFT profiles are here https://nhsconnect.github.io/NHS-FHIR-CDA-DOCREF/Generated/
John Moehrke (Mar 17 2017 at 13:32):
The use of DocumentReference to point at a ~document~ is a great start (full disclosure, I am the author of DocumentReference and the IHE-MHD profile). I would however not call this a "FHIR Document". It is a FHIR DocumentReference. A FHIR DocumentReference can point at a FHIR Document, but that FHIR Document needs to qualify as a "FHIR Document". A "FHIR Document" must be composed from a Composition. --- I support making highlevel evaluations of levels of documents that include DocumentReference as a legitimate thing, as being able to manage and find ~documents~ using DocumentReference is very helpful and supports all types of documents, not just FHIR Documents.
John Moehrke (Mar 17 2017 at 13:35):
I would like ALL documents to have a DocumentReference, even FHIR Documents that contain almost exactly the same elements in Composition. That is to say that DocumentReference and Composition are known to be very very similar; but they have different scope and function. That does not mean that all pointers to FHIR Documents must be pointers to DocumentReference, that is unnecessary overhead. I just think that a DocumentReference should exist for all. THIS will be the topic of discussion in the coming weeks/months, post STU3 publication.
Kevin Mayfield (Mar 17 2017 at 13:51):
@Richard Kavanagh thanks. That's quite to good match to what we we're doing internally with NHS Digital NRLS project.
Grahame Grieve (Apr 19 2017 at 06:13):
I have a note in my todo list to do something about this topic - but looking it, I don't remember what
John Moehrke (Apr 19 2017 at 11:31):
@Grahame Grieve was it to show an example of a CDA Level 1 example decomposed into a FHIR Document (level 1)? as discussed above with @Richard Kavanagh
Grahame Grieve (Apr 19 2017 at 12:17):
hm does someone want to provide a CDA level 1 document?
John Moehrke (Apr 19 2017 at 12:28):
Richard did provide https://gist.github.com/InteropAdmin/b0a586d02f72a2004cd8515ed8554616
Last updated: Apr 12 2022 at 19:14 UTC