Stream: cda to fhir
Topic: Repating actors
Shamil Nizamov (Dec 13 2019 at 16:28):
I’m still trying to understand what is the best way to handle repeating actors when converting from a CDA instance to a FHIR transaction.
For example, each section may have a practitioner with partially defined elements (e.g., identifier and name only). But the same practitioner may be fully defined in the CDA header. If I decide to defer all logic to the FHIR server and simply convert all CDA appearing practitioners into Practitioners, the latter PUT will likely override the fully defined Practitioner instance. What is the best way to avoid it?
Should I include both –POST (conditional create if none exists) and PATCH (to update only missing parts)? And again, this is about FHIR transaction only, not a FHIR document.
René Spronk (Dec 13 2019 at 16:38):
Mostly this calls for some server side logic. The actor may already exist, and your CDA document could be 5 years old and hence have outdated actor details. A $shred-document operation would be best. But if one doesn't have that option, and you'd go for a translation to a transaction, a conditional PUT would be your best bet. Or even PATCH, but that requires more work on the client, and not all servers will support it.
Keith Boone (Dec 13 2019 at 19:32):
Yeah, I have a deduplication stage after conversion to deal with merging these things... Within a single CDA document, you can generally assume that if IDs are the same, it's just different representations of the same actor.
Shamil Nizamov (Dec 13 2019 at 19:44):
Right, the client may use identifier for conditional create. At the same time it seems the only safe way is when the client app collects all info about an actor based on the identifier and then turns it into a Practitioner. I was hoping there are other ways offloading the client app doing this logic.
@René Spronk Where is $shred-document operation defined? It's not a part of the standard.
René Spronk (Dec 14 2019 at 08:10):
I made up the $shred-document operation to illustrate that this is best done using a server side operation. We do have $process-message for server side processing of messages (as part of the standard), perhaps the standard should mention the $shred operation as well, without specifying exactly as to what it should do, given that each and every implementation will have different logic/business rules as to how to shred documents.
The easy use case is if you have a summary document, which was auto generated by a known and trusted source, 10 seconds ago. Then you're all set to transform into a FHIR transaction. The older the document content, the more unknown its author, the more humans have been involved in the authoring of the document, the harder your transformation work will be.
Lisa Nelson (Mar 07 2020 at 12:56):
@Brett Marquard , @David Riddle This topic seems relevant to our discussions about US Core Provenance and expectations about the processing relationship between authors (person and device authors) and represented organizations in CDA wrt US Core Provenance profile.
@Jean Duteau , @Matt Lord This also seems relevant to the mapping work we are doing (have done) between C-CDA and FHIR. The idea of a $decompose-document operation seems like a good idea. If we were to consider it in conjunction with the existing "$document" operation, which could easily be thought of as the "$compose-document" operation, they would make a powerful pair.
David Riddle (May 08 2020 at 21:10):
Lisa Nelson said:
Brett Marquard , David Riddle This topic seems relevant to our discussions about US Core Provenance and expectations about the processing relationship between authors (person and device authors) and represented organizations in CDA wrt US Core Provenance profile.
@Lisa Nelson, Can you elaborate on how this relates to our expectations about the processing relationship between authors (person and device authors) and represented organizations?
Lisa Nelson (Aug 11 2020 at 14:16):
@David Riddle , @René Spronk wrote: perhaps the standard should mention the $shred operation as well, without specifying exactly as to what it should do, given that each and every implementation will have different logic/business rules as to how to shred documents.
I think we are attempting to make rules that will prevent each and every implementation will have different logic/business rules as to how to shred documents. This would not be good for interoperability. The envisioned behavior of the possible $shred operation needs to move CDA data into FHIR Resources in a CONSISTENT AND PREDICTABLE ways.
We know there are cardinality mismatches that make it difficult to move C-CDA entries into the corresponding FHIR resources. We need to all agree on a transparent, consistent mapping that will be used to move the data from C-CDA to FHIR.
René Spronk (Aug 11 2020 at 17:04):
Well, translating CCDA (based on CDA R2) to a FHIR Document is yet again quite a different beast than $shred/$decompose, which is just about the shredding of a FHIR Document. You may wish to combine these two things into one single operation (that would not be my choice, but you could).
Not being located in the US, I don't care that much about C-CDA specifically (we have to deal with other CDA implementation guides). There are some groups within HL7 that have created mapping specs for CCDA to FHIR, I would imagine that even those can't be entirely standardized because of differences in the implementation of CCDA between systems.
As for $shred/$decompose: one could probably define some guidance/best practices as to what such an operation should do. I don't think one could take it down to the level of an implementable specification, but we'll wait and see.
John Moehrke (Aug 12 2020 at 12:56):
as is being discussed.. this is not something that is likely going to be standardized... In IHE we defined this kind of a service functionally. It is defined in the mXDE profile that fits between a Document Sharing environment (XDS, XCA, etc) and a FHIR resource query service (QEDm). Given the global variation, and the simple fact that even in a highly profiled environment the CDA tends to be sloppy... we just expected that some region would be able to functionally do it. And we did point at CCDA-on-FHIR http://hl7.org/fhir/us/ccda/2016Sep/index.html
John Moehrke (Aug 12 2020 at 12:58):
some webinars https://healthcaresecprivacy.blogspot.com/2018/09/webinars-on-mhd-and-mxde-available-from.html
Last updated: Apr 12 2022 at 19:14 UTC
