Yesterday on a call of the HIT Standards Committee Privacy and Security Workgroup, we had a great discussion about Common Data Transport and Health Information Exchange. This is a guest blog describing that conversation by David McCallie at Cerner, a member of the Committee.
"These are some principles that we try to follow in our work.
*Be aware of the difference between a document and a message
*A document should ideally contain data that is assembled to represent a specific clinical context – the data in the document should cohere in some meaningful way. For example, a document (e.g., a CCD) could represent a summary of an encounter, or a response to a query for a current_medication_profile, or you could have a CDA representing a radiology report with structured findings, etc.
*A message communicates some kind of discrete change in state, and is capable of standing in isolation from other messages. For example, a reference lab sends a test result back to the ordering physician via messages. Messages should have sufficient metadata to allow for idempotency (timestamps to avoid duplicate data errors on replay) and to allow for transactional updates to the discrete content of the message (externally-valid identifiers that can be used to send corrections or amendments, etc.) Documents do not need to contain idempotency or transactional information about the discrete structures contained within. The arrival of a document does not imply that all of the contained structures have been updated, whereas the arrival of a discrete message usually does indicate a change in state of the discrete.
*Of course, a message could be used to send a document, in which case the message will have metadata about the overall document (though that does not imply that the metadata is relevant to each discrete element within the document.)
*However, in general, a document should not be used to send a message. For example, a document (like a CCD) should not be used to update discrete information such as specific problems in an external problem list. If a provider chooses to (manually) extract discrete data from the document into his EMR, he should be aware of the context of the overall document to determine the validity of making the extraction. (He may reject the extraction because he is already aware of the discrete information, or his EMR already contains more accurate or more refined knowledge than what is contained in the document.)
*Discrete information should not be automatically extracted from a structured document (except under carefully controlled circumstances.)
*It is tempting to consider a structured document to be the same thing as a structured message, but the semantics are different and trouble will follow
*An HIE that allows only for document submission will be unable to accommodate capture of messages (unless some of the above principles are violated.)
*Yet messages are far more common in HIT transactions today than are documents (labs, claims, eRx, etc.)
Ideally, an HIE should be able to utilize both documents and messages to capture and share patient clinical state."
I thought that these ideas were important to share with the Health Information Exchange and Standards stakeholders who read my blog.
Subscribe to:
Post Comments (Atom)
6 comments:
I support the majority of the statements, but feel the need to sharpen them a bit. Messages are today and will be in the future critical to healthcare. They have properties beyond what is listed that make this so. They are very efficient at conveying time-critical things like orders, results, etc. They are the engine that is used to trigger episodic workflows. There is no need to re-invent this in the form of documents.
So I would agree with the statement that “a document should not be used to send a message”, with one important distinction, “within a workflow”. Messages are the right tool to enable a workflow, but as is pointed out a Message “communicates some kind of discrete change in state”, which only works if both parties have the same current state. This is not a problem within a well lubricated workflow, but does not work well when the connection between parties is unknown, such as over the lifecycle of a patient (e.g. patient moves from one region to another).
Thus the automatic conversion from a Lab-Order+Lab-Message into a Lab-Document is a very good way to combine the context of the setting with the results of the lab test in an object (document) that can persist for decades and still be fully understandable.
The point of documents, as defined by HL7, is that they have five key characteristics:
1) Persistence
2) Stewardship
3) Wholeness
4) Human Readability
5) Potential for Authentication
I would disagree with the statements that “discrete information should not be automatically extracted from a structured document”. This is done with ease. The context that the document provides makes it all the more understandable as to what the meaning of any discrete value is and what its relationship to the other values are.
So, I agree with the majority of the statements. Messages are the backbone of today’s healthcare workflow and will surely stay around for many years to come. I simply would caution that a Message does not carry the entire context of its existence, and therefore is “LESS” useful many years in the future.
The Document vs. Message debate has been a religious war raging back for some 10 to 20 years in the software feild. It crops up in HL7 about once every quarter. I have a permanent folder that I use to store these discussions, but haven't seen much new in that time. John's comments above are pretty much in the middle of the road and is also where I stand.
To clarify one point that John M. raised. When I suggested that structured data should not be automatically extracted into the legal record, I did not mean to imply that it couldn't be imported by provider choice. EMR tools should make it easy to import structured content from CCD - that's the point of having the data be structured! But it should be provider-choice as to what gets imported to the legal record. (Thanks to John M. for pointing out the confusion.)
In some cases though where the documents are being shared within the same legal entity (as in a large IDN) you would already be legally bound to have had access to the information in a document sourced from another "owned entity" and therefor an automated import into the EMR makes sense. I completely agree that with disparate legal entities (unless bound by some contractual agreement) that the documents should be reviewed before the import of any clinical information occurs.
One of the easiest ways to decide whether to use a document or a message to communicate information is to ask, "Am I simply publishing information or am I negotiating an agreement?" If I am simply publishing information, then using a document-based methodology is the most efficient (less overhead than a message-based methodology). If I'm negotiating an agreement, such as asking for a promise to fulfill an order request, then a message is required (although, potentially a document could be used in the payload of the message, e.g. a prescription). Upon this distinction, one can build policy and procedure regarding data import business processes to establish the rules of business. For example, for what will the data imported be used? What kind of data lineage reporting and integrity is required? And is human intervention required to assure that these business needs are met? One gets the answer to these kinds of questions by modeling the business processes; not by first making empiric decisions about the technologies to be used.
Wow! Thank you! I always wanted to write in my site something like that. Can I take part of your post to my blog?
Please come visit my site Homegrown when you got time.
Post a Comment