I was at a dinner sponsored by Canada Health Infoway tonight as the guest speaker. My topic was CDA: An International Perspective. There were no slides for this presentation, but there were a few screen captures from some Infoway Standards, as well as a few clips from this blog. One of the items I spoke on was documents vs. messages. Before I tell you more about this, I want to tell you a bit about some improvements recently made to the ISO 7 layer model. You see, we've realized that there are two more layers beyond the application layer in the ISO model, those are politics and religion. Layer 9 plays an important role in this discussion.
Several years ago, around 2001, I told an employer that I had been working in XML for 9 years. If you get the joke, you realize that a) XML became a standard in 1998, and b) I'd been working in SGML for 6 years before that. SGML has been a standard for about 25 years now. The issue of documents vs. messages has been discussed in SGML and other computational circles for nearly as long. It still hasn't been resolved because we have only just now identified layer 9, and are still working out how to relate to each other at that level, let alone interoperate.
The fundamental difference between a document and a message is that a document is persistent. I don't care how you send it. If you retrieve it and get back the same information every time, it is a document. When you look at the
Ontario specifications for a Discharge summary, you might see a message, but if it doesn't return the same data every time, I'm a fool and so are they. And they weren't fools. To me, that makes it a document. In fact, they even call it a clinical document. You know, we have a standard for that in HL7.
What is interesting about this to me, is that Ontario already has quite a bit of infrastructure in place to store large blobs of data. In fact, Canada has, to the best of my understanding, selected XDS-I for dealing with imaging exchange. So, if you want to store, query and retrieve chuncks of unchanging data, what's a good way to do that? Uhm, XDS of course.
But Canada has already invested quite a bit of development in HL7 Version 3 messaging specifications to exchange documents. It must have seemed like a good idea at the time. While I don't happen to have any off the shelf Version 3 implementations of this technology, if I wanted to build it today I could do so quite easily. Here is how:
- I'd start with an XDS Registry and Repository. I happen to know where you can buy these and also know of a number of high quality open source implementations.
- Next, I'd configure the Affinity domain to deal with appropriate code systems for Ontario.
- But I'd also add configurations for some of the other query parameters that appear in the Ontario specification: Intended Recipient (already in XDS Metadata), Health Condition, Indication and Event Categories (which I would support using tghe XDS Event Code metadata). [Most good XDS implementors can query on metadata other than what's required by the profile -- it's a minimum requirement, not a closed specification]
- Then I'd find an interface technology that would let me map the V3 query into the appropriate XDS query, and away I'd go. I know where those can be purchased as well, and again, there are a number of good open source implementations.
- Of course, I'd also have to map the message storing the document to a provide and register transaction, but that is relatively simply. It's the reverse of what I did in step 3.
- Once I was done, and especially if it was me writing the code, I'd probably rewrite these as XSLT transformations and layer them into the services supported by the XDS Registry I was using. That way I could adjust to minor (or even major) changes to the specifications pretty quickly and using a language that truly is cross platform and not beholden to any single vendor.
Any competent engineering team can have this up and running in less than six weeks, and hardened and ready for service in 3-6 months. Been there. Done that.
Standards are like potato chips (you can never have just one). But they also provide solution that would let me use off-the-shelf, standards based software, so I don't have to reinvent the wheel. And that would let me leverage an existing infrastructure that used different standards.
Ah, but I am not the King of Canada, I'm not in charge, and I don't know who is, and finally, it's not my technology investment. But if you happen to live in Ontario, it is yours. Think about it, and not just for discharge summaries, that was just an example to make a point. There's a lot more to clincial documents than discharge summaries.
P.S. I can pick on Canada a little, because I live in a land that has much richer targets that this little issue, and the Lord knows, my Canadian friends certainly take advantage of that fact.
###
Dennis Giokas, CTO of Infoway, responded via e-mail asking that I post this as a response since it is to large to fit into comments. His response appears below.
Keith, I am not King of Canada either (is there an opening that I’m not aware of?) but I do lead the standards efforts at Canada Health Infoway and would like to comment on your blog.
You indicated in your blog posting, “The fundamental difference between a document and a message is that a document is persistent.” Messages can actually persist in any number of ways. The transaction they convey is often persisted in a database. I can reconstruct the results of those transactions via numerous mechanisms such as a transaction log.
A very key aspect of the agenda in Canada for the interoperable EHR are complete records of key clinical information, patient centric, and longitudinal. Snapshots at a point in time in a document such as a CCD will not support that very important business requirement effectively.
Let’s for example consider medication reconciliation. I would assert using a message on medication dispense to update a reconciled medication list is much more effective than a document. That resulting healthcare event’s information is
persisted as discrete, structured and coded data as a record in a database. In addition, the system can manage and invoke the resulting behaviours behind the transaction. Whether a document or message, the resulting behaviours on the exchange are just as important as the information exchanged. With messages, the two systems can “have a conversation” to ensure the transaction is properly handled, especially if there are exceptions to be handled, corrections or retractions for the dispense. Messages have important transactional semantics that can be enhance the quality of data and thus reliability and accuracy of information in the interoperable electronic health record (EHR).
On a message-based query of medications I will always get the same information back every time. So getting the right information back is not the issue. In addition, there are significant advantages over documents in this scenario because the system that persists that information can be easily queried for lots of other information, such as medications that are no longer current. The system or user does not have to parse a series of documents to assemble that information over time.
To illustrate my point, would our banks use documents to post a loan or credit card payment? No. Would they use a document at the ATM on credits and debits from my checking account? No. Can they get an accurate view of all transactions and compute my balance after each of those transactions? Yes. So why would the healthcare industry strive to be different and feel as though it can be run efficiently and effectively using documents where message-based transactions are most appropriate?
Don’t get me wrong, there are things such as discharge summaries, e-referrals, and clinical notes which should be documents. But types of clinical information that need processing and reconciliation such as medications, allergies, problem lists, condition lists, and lab results should always be written using message-based transactions. This is especially true on the
write of data. The write into a repository of discrete, structured, coded data is key feature of our approach.
In addition, this approach also has the benefit of being very flexible on the
read side of the equation. I can support just functional interoperability on the read. One can query for the current medication list and get that back in many forms, and the same every time. It can be in a final form, such as PDF. A form that has flexibility for display, such as HTML. I can also do the read and achieve semantic interoperability and return a CDA document or a message such that the receiving system has ultimate control over the data for processing purposes. I can then process the medications list in the receiving system and look for issues of compliance or contraindications and alert the clinician. There are numerous options for read and use of the data when I put a lot of rigor on the write/exchange of clinical information.
Dr. John Halamka recently posted a blog on some aspects of this issue. http://geekdoctor.blogspot.com/2011/02/safety-of-hit-assisted-care.html CCD does have significant shortcoming and implications on patient safety. He says:
Safety is improved by ensuring each provider has a complete problem list, medication list, allergy list, and recent results. Such a document is useful for medication reconciliation, drug/drug and drug/allergy decision support, and managing the entire patient by understanding all active problems.
However, summaries exchanged at a point in time are just that - a summary or abstract of the lifetime record that is accurate at a point in time. They do not provide access to the complete record such as inpatient notes, operative notes, history and physicals, and historical data such as discontinued medications or resolved problems. Many clinicians believe that a patient summary at a point in time is good enough for transitions of care, so the risk introduced by abstracting the record into just the salient handoff details may be minimal.
…….
Summary data is an abstract captured at a moment in time. Data corrections/updates are not sent. Thus, data about the patient becomes incomplete and stale over time. However, for the purpose intended, ensuring a transition of care is safe, a point in time summary may be good enough.
I don’t think we can simplify healthcare interoperability and say all can be solved with CDA and XDS, nor with messages. I would encourage architects to look at all of the requirements at hand and identify the most appropriate solution approach.
While it may be true an infrastructure could be up and running in six weeks, one cannot ignore the most critical aspect of interoperability over that infrastructure: the information model (e.g. payload over that infrastructure) and behavioural model on that information at both ends of the wire. That is the tough part and the one that takes time to define and time for the vendors to adopt and implement. Then one has to deploy it, test it, and implement a change management and training program for the end users.
Don’t get me wrong, we support and embrace CDA and XDS where it is appropriate. But it is not the solution to every health information exchange use case.
