Stream: implementers
Topic: FHIR inside CDA
Jens Villadsen (Jan 10 2017 at 10:49):
Has anyone bothered to try out how FHIR could be fitted inside a CDA document? I'm sitting with an infrastructure where the lowest common denominator regarding the wireformat is CDA, but FHIR inside the CDA document is a valid approach. I'm guessing it should go inside the NonXMLBody somehow, but that forces me to use json. While I'm agnostic towards this inner format, the infrastructure is not. Is there somehow a way to put FHIR inside a CDA without it being too nasty?
Grahame Grieve (Jan 10 2017 at 11:54):
why does it force you to use json? you could use xml in nonXmlBody
Grahame Grieve (Jan 10 2017 at 11:54):
but it's a bit weird wrap fhir inside cda - why do you need to do that? I would have thought that the question would be stated differently, like 'how do we use FHIR inside XDS"
John Moehrke (Jan 10 2017 at 12:07):
The answer to Grahames question, how do we use FHIR inside XDS, is easy... XDS is content agnostic. So first set the DocumentEntry.mimeType appropriately http://build.fhir.org/http.html#mime-type
John Moehrke (Jan 10 2017 at 12:10):
The question of FHIR inside CDA... is as a nonXmlBody, encoded to contain it... right? Just like XDS-SD content-profile encapsulates PDF or TEXT. (also known as C62)
Jens Villadsen (Jan 10 2017 at 12:11):
I agree its a bit weird - but that part is politics - the wrapping FHIR inside CDA
Jens Villadsen (Jan 10 2017 at 12:12):
I know XDS/XDR is an agnostic format
Jens Villadsen (Jan 10 2017 at 12:12):
its just the name "NonXMLBody" ... does that not imply that xml is kinda forbidden right there?
Grahame Grieve (Jan 10 2017 at 12:13):
it implies that it's not part of this xml
Grahame Grieve (Jan 10 2017 at 12:13):
there's no rule that it can't be some other xml.
John Moehrke (Jan 10 2017 at 12:13):
No, it just means it is not part of the CDA xml schema... And from CDA perspective it is a blob, and thus must be encoded as a blob.
Jens Villadsen (Jan 10 2017 at 12:14):
so the name should rather be noncdastructuredbody?
John Moehrke (Jan 10 2017 at 12:15):
it is a sign of maturity, that good decisions back then, look odd today.
Jens Villadsen (Jan 10 2017 at 12:16):
so the name should have been different
Jens Villadsen (Jan 10 2017 at 12:16):
?
Grahame Grieve (Jan 10 2017 at 12:17):
names are hard. Perhaps your longer name would have been clearer. But the rules are clear: it's an ed of some content
Jens Villadsen (Jan 10 2017 at 12:17):
right
Grahame Grieve (Jan 10 2017 at 12:18):
actually, what nonXmlBody means is that it's not CDA narrative XML
Jens Villadsen (Jan 10 2017 at 12:18):
that name keeps on givin'
Grahame Grieve (Jan 10 2017 at 12:18):
but it is expected that the content is narrative - so the fhir would have to be a composition with narrative
Grahame Grieve (Jan 10 2017 at 12:19):
at least, that's what's intended
Jens Villadsen (Jan 10 2017 at 12:19):
okay ... so back to the issue: an amount of time have been invested into understanding CDA
Jens Villadsen (Jan 10 2017 at 12:19):
and even some profiles have been developed
Jens Villadsen (Jan 10 2017 at 12:19):
an infrastructure has also been established
Jens Villadsen (Jan 10 2017 at 12:19):
based on XDS / XDR
Jens Villadsen (Jan 10 2017 at 12:20):
now, given that the XDS/XDR part is kinda frozen ... untouchable
Jens Villadsen (Jan 10 2017 at 12:20):
and the header part of the CDA is also kinda frozen ...
Grahame Grieve (Jan 10 2017 at 12:20):
right. and the short path is, re-use the CDA as much as possible. While the long path is , just go to FHIR directly. The short path is more expensive in the end, but politics often involves choosing a cheapaper option in the short term
Grahame Grieve (Jan 10 2017 at 12:21):
we have the same dsicussion in Australia, and it's not resolved yet
Jens Villadsen (Jan 10 2017 at 12:21):
right
Jens Villadsen (Jan 10 2017 at 12:21):
i know my politics :) - which means that I've might been given a change to make a hybrid solution
John Moehrke (Jan 10 2017 at 12:22):
And learn from history... any standard can be improved by making one-more-standard...
Jens Villadsen (Jan 10 2017 at 12:22):
reuse as much of the existing infrastructure as possible (read: no more money here) ... and use FHIR where it could actually make sense
Grahame Grieve (Jan 10 2017 at 12:23):
well, what I've found so far in Australia is that as long as the back end is hard cda/xds, and you can't develop it, the amount of usefulness that can derived by hacking a FHIR interface over it (lipstick on a pig) is limited.
Jens Villadsen (Jan 10 2017 at 12:24):
the case is here that only the XDS part and the CDA header is frozen
Jens Villadsen (Jan 10 2017 at 12:24):
the rest is up for discussion
Grahame Grieve (Jan 10 2017 at 12:24):
you can fhir-ise the xds part itself directly, and that's ok, but a small-ish benefit. once you start putting an API on top of a CDA based repository, you'll find all these rules about what you can't do with the API, and the benefit starts to get somewhat limited
John Moehrke (Jan 10 2017 at 12:25):
I would recommend to pushback on some of the inflexibility you perceive. As I indicated the XD* metadata model intends to be content agnostic, with CDA vs FHIR being addressed fundimentally with the broadest metadata entry -- mimeType... I do expect that the inflexibility might be true, caused by poorly implemented solutions that hard-coded too many things.
Grahame Grieve (Jan 10 2017 at 12:25):
still, so how do you support put and post when each granular put or post is a single act entry in a whole CDA document
Jens Villadsen (Jan 10 2017 at 12:26):
XDS is not the problem
Grahame Grieve (Jan 10 2017 at 12:26):
I'm encouraging consideration of a different model: a native FHIR interface, and throwing summary documents to the xds/cda repositroy
John Moehrke (Jan 10 2017 at 12:26):
Grahame, If what you want is a http/REST api, then I very much agree with you... but if you want Document Sharing, and FHIR has a Document model; then XDS works great.
Jens Villadsen (Jan 10 2017 at 12:26):
its actually not XDS
Jens Villadsen (Jan 10 2017 at 12:26):
its XDR
John Moehrke (Jan 10 2017 at 12:27):
XDR has mimeType metadata element too.
Jens Villadsen (Jan 10 2017 at 12:27):
there is no need for retrieving documents
Jens Villadsen (Jan 10 2017 at 12:28):
i only need XDR for transport basically
Jens Villadsen (Jan 10 2017 at 12:28):
and I need to support the CDA headers
Jens Villadsen (Jan 10 2017 at 12:28):
political reasons
John Moehrke (Jan 10 2017 at 12:28):
Grahame, I agree... I just also see a Document Sharing as a needed thing. Documents, CDA and FHIR, have a characteristic not found in an API... that doesn't mean Docment is better than API, it doesn't mean API is better than Document... it is just two models.
John Moehrke (Jan 10 2017 at 12:30):
Jens, you have made it clear that you will need to encapsulate a FHIR Bundle inside the CDA transported in XDR... where in your case the XDR can only carry CDA...
Jens Villadsen (Jan 10 2017 at 12:30):
and CDA can carry FHIR
Jens Villadsen (Jan 10 2017 at 12:31):
the question is: is it insane?
John Moehrke (Jan 10 2017 at 12:31):
Jens, then what will your FHIR object look like, that is carried inside CDA? Will it be just a FHIR Document Bundle?
Jens Villadsen (Jan 10 2017 at 12:31):
probably
John Moehrke (Jan 10 2017 at 12:31):
CDA can carry anything... it is 'turtles all the way down'
John Moehrke (Jan 10 2017 at 12:32):
all the containers we are talking about can describe the contained content with a mimeType... thus they can contain anything.
Jens Villadsen (Jan 10 2017 at 12:32):
i know
Jens Villadsen (Jan 10 2017 at 12:32):
i know it is technically possible
Jens Villadsen (Jan 10 2017 at 12:32):
all the way down
John Moehrke (Jan 10 2017 at 12:32):
and the FHIR object you have contained in the CDA, can contain CDA...
Jens Villadsen (Jan 10 2017 at 12:32):
hehe
Jens Villadsen (Jan 10 2017 at 12:32):
okay ... lets not take it there ...
Jens Villadsen (Jan 10 2017 at 12:32):
but is it insane?
Jens Villadsen (Jan 10 2017 at 12:33):
fhir inside cda
Jens Villadsen (Jan 10 2017 at 12:33):
(not fhir inside cda inside fhir inside cda insiden .....)
John Moehrke (Jan 10 2017 at 12:34):
I would say not insane... because there is precedent in CDA containing TEXT or PDF or JPEG content... so processing of a received CDA is already looking for something mimeType described in the nonXmlBody
John Moehrke (Jan 10 2017 at 12:35):
the only thing is that it is schizophrenic
Jens Villadsen (Jan 10 2017 at 12:37):
the alternative is to go all the way down CDA - which i would consider sadistic given that CDA has not been used at all among the vendors so far
Jens Villadsen (Jan 10 2017 at 12:38):
they have all used proprietary standards until now
Jens Villadsen (Jan 10 2017 at 12:40):
@Grahame Grieve a native FHIR interface is not an option - politically
Grahame Grieve (Jan 10 2017 at 12:41):
it's not... quite... insane
Jens Villadsen (Jan 10 2017 at 12:42):
thank you!
Grahame Grieve (Jan 10 2017 at 12:42):
but if your only political option is insance, then it's not actually insane
Jens Villadsen (Jan 10 2017 at 12:42):
you're right
Jens Villadsen (Jan 10 2017 at 12:44):
thank you guys! - you gave me the anwers I needed
Jens Villadsen (Jan 10 2017 at 12:44):
I'll let you know what it all ends up with
Jens Villadsen (Jan 10 2017 at 12:45):
(its only a national matter that's going to have high impact the next couple of years ;) )
Last updated: Apr 12 2022 at 19:14 UTC
