Communicating for InterOperability
If you’ve been reading along with my other posts, you’ve journeyed through RelayHealth’s implementations of CCD and C-CDA.
And then we were done with CDA!
…said no one, ever.
Even after we had built parsing support for a remarkable number of health summary sections, we still didn’t have an MVP of interoperability. Today, we at RelayHealth are still feeling the CDA growing pains as we argue with other vendors over “Whose implementation is more correct?”
Over the past year that I’ve been working on CDA parsing at RelayHealth, the majority of my time has been spent improving what I’d call our “CDA communication” with other vendors. I choose “communication” over HIE buzz-word “interoperability” because sometimes parsing a different vendor’s CDA is like trying to speak Italian to a Spaniard. The basis of communication is there, but the structural differences can lead to “false friends”-esque interpretations.
One of my recent discussions with another vendor was regarding how to express a medication’s status. This vendor uses the <statusCode> element to send the status, and we parse the Medication Status section as described by the CCD specification (and Keith Boone’s guide here). The statusCode isn’t generally used for this purpose, but the CCD Medication Status section is not included in the C-CDA spec. The C-CDA spec suggests that implementers rely on start and end dates to determine status, and yet, what if a patient doesn’t remember the end date of a medication they are no longer taking?…
Most times, the C-CDA spec cannot resolve these disputes because of its highly flexible nature. Even in a cooperative partnership, vendors will still fall back on their NIST Validation as the authority of truth before considering making changes. The true question is: how can so many differing CDA interpretations receive NIST Validation?
It seems to me that we need a stricter tool to enforce the guidelines put forth by the C-CDA spec. Better CDA communication will only result from clearer requirements and vendor willingness to make changes. As Charles put it the last post, the CDA spec “gets you 95 percent of the way there”…can FHIR take us 5 percent further?
With its open attitude toward standard development and encouragement of early and continued involvement from all implementers, FHIR looks like a great next step. I read a “FHIRSide Chat” post this morning that stated, “Interoperability standards maturity is a journey, not a destination.” Well put.…Another thing I like about the word “communication” over “interoperability” is that it alludes to a conversation, which is nurtured by collaboration and willingness to listen to improve clarity of understanding. We may not be truly interoperable any time soon, but improving the communication is a step down the right path.