Stream: fhir/documents
Topic: puzzling document mappings
Jens Villadsen (Oct 08 2018 at 21:13):
I'm a bit puzzled about the current mapping between CDA and FHIR documents. On composition the following is stated:
"A composition is a logical construct- its identifier matches to the CDA ClinicalDocument.setId. Composition resources are wrapped into Document structures, for exchange of the whole package (the composition and its parts), and this wrapped, sealed entity is equivalent to a CDA document, where the Bundle.id is equivalent in function to ClinicalDocument.id (but it is not identical when interconverting, since it's a transform between them)."
What does that in bold mean in case where a client needs to send off a FHIR Document to a server? Can FHIR documents that needs to map to CDA only be send as upserts as Bundle.id maps to ClinicalDocument.id, and hence a POST is not an option since the client is then not able to supply the ClinicalDocument.id?
René Spronk (Oct 09 2018 at 12:39):
If you'd wish to preserve the Bundle.id you'd post to /Binary (not a bad idea anyway). If you post to /Bundle, a new Bundle.id will be created server side. If you map any FHIR Document Bundle to a CDA document, you need a new ClinicalDocument.id, although its header could define that it's a XRFM from a FHIR document with a specific Bundle.id, or that it's a transform from a certain /Binary resource.
Lloyd McKenzie (Oct 09 2018 at 14:18):
You can also do a PUT of your Bundle to preserve your Bundle.id - if the server supports that.
Last updated: Apr 12 2022 at 19:14 UTC
