Stream: cda to fhir
Topic: NON XML Body
Richard Kavanagh (Aug 07 2016 at 20:47):
Is C-CDA on FHIR going to allow for the "non-XML Body" (Level 1) style of CDA? If so how?
Grahame Grieve (Aug 07 2016 at 21:15):
I don't think it should; in CDA land, that made sense, but in FHIR, that would be a DocumentReference
Richard Kavanagh (Aug 07 2016 at 22:00):
Yes - I see some logic in that. But if a DocumentReference is used on its own, then all the other information from the "CDA Header" is lost.
Grahame Grieve (Aug 07 2016 at 23:10):
what information are you concerned about? infomration that you usually have for a nonXmlBody? I've not seen it have more information than a DocumentReference anyway (in fact, a lot less)
Richard Kavanagh (Aug 08 2016 at 07:03):
It is very close but has differences around "event", "confidentiality", "attester" etc
Furthermore it makes the recipient have to deal with two different content patterns.
That said - I'm still interested to see how (if) C-CDA are going to cater for this.
Richard Kavanagh (Mar 21 2017 at 10:13):
So this question has raised its head again in one of our projects. In the scenario where we have a non-FHIR document (e.g. PDF, PNG etc) we are using the DocumentReference resource. The questions which still remains unclear as to where we actually put the document being referenced.
Our use case does not involve any RESTful interfaces and the "document" will manifest itself as a "Bundle" containing all the necessary resources required to describe the document
There seem to be two options:
1) Place it directly within the DocumentReference at DocumentReference.content.attachment.data
2) Place it externally to DocumentReference using DocumentReference.content.attachment.url to point to the actual document
Option (1) seems to be easier to implement in that there are less resources required as the actual document can be Base64 encoded directly in the DocumentReference resource
Option (2) allows the reference and the "document" to be separated from each other which is potentially closer to XDS patterns. In our solution we'd place the document in a Binary resource and reference it within the bundle.
I haven't been able to find any other IGs that are looking in this area to see what others are doing. I'm also not sure whether IHE are doing anything in this areas (@John Moehrke ?). Anyone have any thoughts?
John Moehrke (Mar 21 2017 at 11:38):
Both are enabled by FHIR. IHE in the MHD profile chose to use attachment.url. As you point out this is more consistent with XDS. But it also has other advantages. Accessibility, no need to un base64 encode; just access it. More reasonable size of either, allowing a consuming system to choose based on the DocumentReference metadata, if it wants to retrieve the document. etc.
Richard Kavanagh (Mar 21 2017 at 12:00):
Thanks @John Moehrke we are progressing with option 2 from above in our solution. We're currently constrained to a FHIR Messaging mode of operation but this approach gives up flexibility to adapt at a later stage if required.
John Moehrke (Mar 21 2017 at 12:03):
In a messaging model you still gain space and more easy access with ( 2 ). You also had a ( 3 ) option to use Contained... but with a messaging model you have that advantage without the drawbacks of contained.
Lloyd McKenzie (Mar 21 2017 at 15:18):
Option 2 enables you to retrieve and pass around the metadata (including things like the hash) without passing around the Binary itself. Having the separated also allows control over the data independent of control of the indexing information and potentially lets you have a systems that's "tuned" to dealing with large data handle the binary calls separate from the FHIR calls. Also, when looking at instances as a developer/debugger, it's a bit easier to "collapse" the Binary data if it's sitting in its own resource, though that's a minor thing.
Richard Kavanagh (Mar 21 2017 at 15:35):
Thanks @Lloyd McKenzie I concur with your comments. In our scenario there are no "calls" as the whole payload travels as one bundle in a single message, but it provides options for the future.
Lloyd McKenzie (Mar 21 2017 at 15:37):
Right. When it's all in the message, it really doesn't matter so much. The design considerations are more about how you might want to access or manipulate the data in the future.
Brian Postlethwaite (Mar 21 2017 at 21:10):
And with the size in the header, a mobile app (or bandwidth constrained env) can choose when to grab the content, and how long it might expect it to take.
Last updated: Apr 12 2022 at 19:14 UTC
