Stream: implementers
Topic: How to index document entries vs. index documents?
David Riddle (Feb 03 2021 at 21:24):
It is my understanding that the FHIR DocumentReference resource is the recommended way to represent (and index) C-CDA documents in FHIR. i.e., If the use case is to provide a means to index documents in their native C-CDA format, the FHIR DocumentReference resource should be used to convey the metadata about the document and the DocumentReference.content.attachement.data to convey the actual C-CDA XML document.
With the above use of the FHIR DocumentReference in mind, is there any existing FHIR resource that could be used to discretely index specific entries within a C-CDA document vs. only indexing content at the document grain?
See below for a more detailed description of this use case and related concerns...
Is there a mechanism to expose the metadata about specific document entries via. a FHIR resource? e.g., the metadata found in a C-CDA Note Activity entry - 2.16.840.1.113883.10.20.22.4.202. I do not believe that the DocumentReference resource can be used for this purpose because the cardinality of DocumentReference.content is 1..* and in this use case, the C-CDA content (CDA narrative chunk) being indexed would be embedded inside the attachment to the DocumentReference instance that provides metadata for the full parent C-CDA document (document that contains the Note Activity entry). Is there some other mechanism that would allow the metadata associated with discrete C-CDA entries to be exposed via. a FHIR resource, A) without recreating the entire C-CDA document as a FHIR Bundle and corresponding FHIR Composition and B)without separating the C-CDA narrative content from the parent document it may have dependencies on?
John Moehrke (Feb 03 2021 at 21:35):
Not that I am aware of . There are some IHE uses of DocumentReference.context.event, DocumentReference.context.related to expose some of the additional purposes the document might be also useful for. However your observation is indeed a ramification of overly inclusive Medical-Summary documents of huge size. Where more well defined document types are more friendly like encounter summary, discharge summary, etc.
Note that DocmentReference.content.attachment.url -> Binary might be a far more friendly approach, as this enables your server to return the native C-CDA XML on retrieve of the Binary and where http negotiation allows CDA XML.
Last updated: Apr 12 2022 at 19:14 UTC
