Stream: C-CDA
Topic: Life and Death in C-CDA
Natasha Kreisle (Jul 29 2020 at 14:08):
Life and Death in C-CDA (specifically documentation of death, death reason and birth/pregnancy, but not at the same time for the same patient :blush: ) by John D'Amore is the first topic for discussion. https://www.linkedin.com/in/jdamore/
Lisa Nelson (Jul 31 2020 at 12:02):
John's topic brought up a lot of questions about interoperability from the Consumer side of the information exchange interaction. He showed an xml file that had information in it which indicated some pretty clinically relevant data. This person was deceased as of a certain date. He then showed that information rendered in 4 different style sheets. Each showed very different information. Some didn't show the person was deceased. Others did, but in a variety of ways. This strikes me as a VERY MAJOR Interoperability problem. I know, historically, standards developers weren't allowed to suggest that standards would have any say in how the received data would be presented, but I'm here to challenge that prior belief based. I am coming solely from the point of view of interoperability.
The goal is for one actor to be able to share information that can be consistently and reliably be understood at the receiving system WITH THE SAME MEANING as it had at the sending system.
For this reason, I would argue that the visual representation of the information AFFECTS ITS MEANING, and therefore the sender of the information must have some ability to control (and responsibility to control) the rendered "output" of the information that arrives at the recipient information.
Without that, there is not guarantee that the receiver will really appreciate the information in the same and intended way as what was originally created.
Throughout history, things that were taboo at one time become an adopted custom at a later time. (Hopefully taking us in a better direction.)
I'm involved in so many projects these days, where I can see that if the sending system does not specify how the receiving system is intended to present the information, we are not going to have legitimate interoperability. There will be a lot of room for misunderstanding what the information means if the sender doesn't specify its layout (the information's relationship to each other visually which reinforces how it is related conceptually in the data model).
We need to embrace taking this previously forbidden step. BTW - There are no rules, which I am aware of, which prohibit us from taking this step. There just are no rules that require us to take this step. THUS we are FREE TO CHOOSE to do something that makes sense and would produce better, more consistent, and more interoperable results.
I'm sure there are lots of people who will want to speak out against this type of progress, but I am hoping there are others who would be supportive of this idea. I would like to find out who might also be thinking about this need and this possibility.
BTW - Within the IHE Community there is a long history of 4 basic requirements for a Content Consumer: 1. View, 2 Import the document as a whole, 3. Import a section of information, 4. Import discrete data elements. I think we could look at what this "View" requirement currently expects and perhaps suggest an expectation to "present the information as it was intended to be viewed by the source system".
Last updated: Apr 12 2022 at 19:14 UTC
