Documents and Messages, a Guest Blog

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.