Eating an Elephant -- How to approach IHE documentation on Health Information Exchange (HIE)

Any standard is not easy to approach. This is especially problematic when that standard is so central to a concept that affects so many. The
Health Information Exchange as a mechanism to Exchange Health Information under some Organization or Federation of Organizations.

HIE Background and Introduction

Most high level document from IHE is the white paper on what an HIE is and the various methods of communications that are profiled in IHE
Health Information Exchange: Enabling Document Sharing Using IHE Profiles - Published 2012-01-24

Second most high is the Volume 1 material on the different profiles. The format of an IHE profile very specifically has volume one material targeting the users and product management. Volume 1 (ITI TF-1): Integration Profiles (rev 10.1 added 2013-10-25)
This is where one will find XDS, XDR, XCA and the other profiles explained in terms of their benefit. This explanation in the context of the ITI committee is rather abstract, as ITI doesn't deal with any specific domain of healthcare. Thus it is all about the IT Infrastructure.

Third most high is the section 4.1 of Volume 3, that outlines specifically the high-level concepts behind the Document Sharing metadata.  Volume 3 (ITI TF-3):

This metadata description has been re-documented as IHE came to understand how hard it was to read. It historically was written over 10 years little by little. So it was time to take a step back and document it more formally. So it now contains an abstract/conceptual definition, and platform specific definition. This will likely be further refined as IHE approaches RESTful

HIE Profile details

The fourth most deep is best to get from the other IHE domains. The reason is that these other domains focus on actual workflows, not just the infrastructure to support workflows. So you will find better explanations of how to translate a clinical need into detailed encoding of documents. Each of these have a Document Content profile, a profile of some document standard (DICOM SR, HL7 CDA, PDF) and how it maps into the HIE framework

• Cardiology
• Dental
• Endoscopy
• Eye Care
• IT Infrastructure
• Laboratory
• Patient Care Coordination
• Patient Care Device
• Pharmacy
• Quality, Research and Public Health
• Radiation Oncology
• Radiology

The Deepest that IHE goes is found in Volumes 2 and 3. Specifically in the ITI Technical Framework this is where XDS and family are documented in detail.

• Volume 2a (ITI TF-2a): Transactions for the following profiles CT, PSA, EUA, PIX, RID, XDS, ATNA, PDQ, PWP, NAV
• Volume 2b: (ITI TF-2b): Transactions for the following profiles PAM, XDM, XUA, XDS, XCA, PIX V3, MPQ
• Volume 3 (ITI TF-3): Contains Section 4 Cross-Transaction Specifications and Section 5 on the ITI Content Specifications
• Volume 3 (ITI TF-3): Detailed descriptions in the section 4.2 and 4.3 of Volume 3 is very specifically targeting the programmer or one picking the specifics of the technologies and vocabularies. These are the deepest detail we have on the metadata.
• There are also supplements that are not yet in "Final" state. Specifically the Mobile Healthcare Documents, the RESTful API to XDS/XDR/XCA

Deployment Guides

Detailed descriptions of what those that are deploying an HIE would need to consider is found in a ‘handbook’. This is useful to others, but is specifically focused on those responsible for deployment, policy, vocabulary management, and those long term concepts. It is rather focused on XDS, but the concepts are useful for any of the document sharing exchange methods
Template for XDS Affinity Domain Deployment Planning - Revised 2008-12-02

Detailed descriptions of Privacy and Security concepts are in the other ‘handbook’. This is useful to the programmer, but is more useful to the security and privacy developers and those deploying.
Access Control - Published 2009-09-28

I cover many ways to bringing this Access Controls to life including using the newest concepts of data tagging to enable federation of access control enforcement.

 

I also have plenty of other blog articles covering all the various "Topics" that I cover.

There are various levels of complexity found in the IHE IT Infrastructure Technical Framework Appendix found in Volume 1 and Volume 2(x). The volume 1 should be less technical but this isn't always as well done. Volume 2x is mostly completely for the programmer or software architect.
Volume 2x (ITI TF-2x): Appendices A through W and Glossary

IHE and HIE Webinars

I could say that higher than any of this is our Webinars… but I think that is stretching to be called documentation.
http://www.ihe.net/Webinars/

Conclusion

So, like eating an elephant, one must take it one bite at a time. There are many more resources too. I have liked what some of the HIE vendors have done.

On Infuence

My methods of Influence are quiet and patient. Keith wrote on his blog "On Influence" about the ways that he influences. All really good and classic methods of leading and influencing. I agree with everything said, but do things slightly different, some might say totally different. Keith likes to be seen and likes to socialize with the influential. This is shown with his Klout score of 61 today. Yeah, Klout is not that important, but it is recognized by those that like to recognize it.

I however have a Klout score of 47, which is rather high for me. I usually only have a score in the 30s. The difference is that I am less interested in being seen and recognized. I guess I am simply more of a classic geeky engineer. I prefer to act more like Larry Niven's Pierson's Puppeteers, lead from behind the scene. That is not to say that I don't speak with people that do like to be visible. I like to feed those who take on a visible role with information.

The most useful "Influencing" tool that I have, I learned from my Grandfather. My Grandpa Jake was a construction engineer and architect. He was the Superintendent on the Frank Lloyd Wright designed Johnson's Wax Building. One day when my brother-in-law asked "How come you are so quiet Grandpa?" He said "I never learned anything while I was talking." I take this to heart. I do know things about Healthcare Interoperability, Medical Device Safety, Privacy, Security, etc. But I don't know everything, so I try to do more listening than talking. I hope this comes through as better informed opinions when I do speak. I don't mind speaking, and will when asked. I just don't use it as a primary way of influencing.

I do agree with Keith on the importance of associating yourself with activities that will succeed, and also the importance of being willing to fail early. I too use my blog to throw ideas against the open world to see if they are possibly useful or good. It is always good to get positive reinforcement, but more useful to me to hear when I am wrong.

I will add that a very important aspect of Influence in Open Healthcare and Open Standards is a willingness to wait a long time for success. This is not a place for those that want results tomorrow or even this-year. If you are not willing to wait a very minimum of 5 years, and more likely 8 or 10 years; then you should not get excited about this line of work. The things I am working on this year are not likely to be successful for at best 5 years, and I am willing to see it through. During those 5 years lessons will be learned and tweaks will be made. Very little survives this 5 year 'trial implementation' phase unchanged. This goes back to the listening principle. One of the first blog posts I did in 2009 was on the IHE Access Control white paper that I helped write, the fundamentals of this are still being 'discovered' by people and organizations such as the HL7 Healthcare Classification System (HCS) and Data Segmentation for Privacy (DS4P)

I do hold a co-chair position in HL7 Security WG. Politically one must have a co-chair position to be seen as authoritative. Many people think that I am a co-chair in IHE, but I keep avoiding it.

Enough about me:

• Bloginar on Security and Privacy Profiles
• Blog - Table of Contents by Topic

Policy needs to get out of the way of good Patient Identity management

I am reviewing the materials that are being presented to the ONC Patient Matching Meeting on Monday December 16th. These materials are fantastic. There is much work that has gone into the current investigation. Detailed and constructive research. There is research on why patient matching isn't working, what technical issues are in the way.

THE PROBLEM IS NOT TECHNICAL. The problem is Policy. This is not to say there are not technical issues, there certainly are problems with current technology. No matter what the policy solution is, technology will need to change. We need to get the policy out of our way so that we can apply technology to that solution. Right now Policy is in the way!

Here is a quote from the report that illuminates the problem

The research questions did not include any specific questions on unique patient identifiers; however, many of the environmental scan participants indicated that their organizations support the study and development of a universal patient identifier (either mandated or voluntary). At the same time, there was acknowledgement that it would not eliminate the need for patient matching methods/programs and would take a number of years to have an impact.

The problem is that in the USA there are rules and prevailing-wind against a universal patient identifier. I understand why this is, it is for good privacy reasons. BUT the result is a far worse privacy issue, and one that also causes Safety issues and Financial issues.

Healthcare needs a high-quality universal identity. I say this not just because it would solve the 'patient matching' problem, but also because I truly believe that it will solve PRIVACY issues, Safety, and Financial issues. I assert that Universal Health ID Enables Privacy

It solves privacy issues because we STOP needing to push so much demographics data around to everyone under the hope that that 'everyone' would be able to do a Patient Match and provide relevant healthcare information. This Privacy violation is 'not seeing the forest for the trees', or 'cutting off your noise to spite your face', or 'throwing out the baby with the bathwater'. How can we not see this?

With a high-quality universal patient identity we will need to only communicate that opaque identity when requesting information. It works just as well in push use-cases. A Patient can express their Privacy preferences/consent using this high-quality universal patient identifier and it will be applicable for ALL uses of that identifier. Indeed the Accounting of Disclosures or even the Access Log is much easier to implement.

The problem with universal patient identifier: I recognize the privacy worry about a universal patient identifier, but this problem is far better solved in the POLICY space. Solved through simple rules. The universal patient identifier MUST NOT be used for any purpose other than the provision of healthcare or payment of such. I am sure there are other parts of this 'simple rule', but I am sure it is more approachable in Policy than anywhere else.

Who should provide this high-quality universal patient identifier? Very good question that I wish I had a good answer for. In most of Europe they are the national identifier, we should look to Europe for both the solution and how they handle the privacy issues.  I am also willing to say that the identifier could be a patient selected identifier, ala Voluntary Patient Identifier. I just want it to be high-quality, which means it needs to be backed by good solid identity proofing.  One can only outsource your identity proofing if you trust everyone that you  are outsourcing your identity proofing to. In healthcare we are outsourcing our identity proofing to everyone, yet no-one.

If you as a human opt-out of getting a universal patient identifier, then you can't be covered by insurance, no deferred billing available, and your historic information can't be used. You are allowed to do this, but you will need to pay up-front for any healthcare and you will need to pay for extra tests each time you are seen since no historic knowledge can be brought forward. Further your data will be marked with your demographics, not an opaque universal identifier. YES, there is a price to your behavior, but it is your choice.

Conclusion:
We need to drop this archaic policy against a universal patient identifier. Move the policy to where it can be effective, and issue high-quality patient identifier.

Patient Identity

• HIE Patient Identity problem
• Identity Proofing and Authentication -- Patient vs Provider
• Patient Identity Matching
• Universal Health ID -- Enable Privacy
• The Basics of Cross-Community Patient Discovery (XCPD)
• NwHIN-Exchange use of XCPD for Patient Discovery
• Direct addresses- Trusted vs Trustable
• Identity Proofing and Authentication -- Patient vs Provider
• Level setting on Level of Assurance 

If you don't understand, Please ASK!

I really like it when someone asks a question. Especially when that question uncovers something that seems obvious but clearly isn't. There have been quite a few of them in the past few weeks. I am sure there will be far more in the future. I like investigating questions in the same way that I liked to debug code. A question where it seems obvious is not unlike a bug in code where the programmer thought they did it right. I recognize that I might be special, as most people I talk to hate to debug code.

I must give credit to the one asking the questions lately. Mostly the questions are coming from Grahame. big effort to rewrite Volume 3 documentation on the metadata we didn't fix many of them, I am not sure if we fixed any of them. So there will be a pile of Change Proposals queued up this winter/spring.

When I ask him why he is just now asking questions about XDS when I know he has worked with XDS for many years. He responded that now that he is doing the work to incorporate XDS into FHIR he knows that he will be answering questions, therefore he needs to feel very strong about the details. Grahame has uncovered many issues with XDS documentation that I am sure most of us on the core of IHE-ITI simply figured were properly documented. Clearly even with the

This kind of questioning should have happened during the IHE Process,

specifically "Public Comment" and/or "Trial Implementation". This is the time when changes are expected. This is the time when it is expected that the documentation is incomplete or even that the chosen solution is wrong. This is the time when those that are developing their solutions to their read of the Supplement, and bringing their solution to Connectathon. This is why IHE requires three independently developed solutions before a Profile can become "Final Text". But this is NOT the only time that something can be wrong, and why IHE has a "Change Proposal" system.

The influx of questions is from a new set of people, that come with different perspectives. Please feel free to ask questions. This is not to say you won't be told to "Read The Friendly Manual". So, when you ask your question please tell us that you have already RTFM and found it confusing or wrong.

Safety vs Innovation - not just a 23andMe or mHealth problem.

I am a longstanding customer of 23andMe, and am very disappointed at the current behavior. 23andMe have decided to stop offering a healthcare service rather than work with the FDA to achieve safe offering. This approach to questions of patient safety from the FDA seems to be very typical of new product groups. This is not unique to 32andMe. From my read of the 23andMe blog, they are not done but seem they might be working toward a peaceful solution.

I am not upset at FDA, I am an advocate of Safety. I was introduced to the FDA mechanisms 16 years ago. Maybe I was lucky and had good teachers, but I think it was also the fact that I understand the basics of “Risk Assessment and Management”. When one learns of concept domains that are fundamental risk domains, one learns that there is no shortcuts to addressing that concept domain. I am often explaining that there are many risk domains that must be managed: Safety, Security, Privacy, and Effectiveness. There are frameworks, like for security/privacy there is NIST 800-53, but these just try to get the bulk of concerns out of the way using standards based solutions. These frameworks always are backfilled with risk assessment and management frameworks, such as NIST 800-30 for security.

23andMe was approached by FDA many years ago, 23andMe had plenty of time to learn the proper way to address the Safety risk domain. My experience as a customer of 23andMe is very positive. I am very confident that everything that 23andMe have told me about my health has been done in a very respectful and cautious way. I have spoken to others that are 23andMe customers and gotten the same feedback from them. As an example there are some new studies that they are very careful to walk you through a cautious page that is very clear about the sureness or lack of sureness. As a more visible proof, go to the 23andMe web site right now and see an example of their insistence on informed consent.

Given my experience with 23andMe, and my 16 years of working for a company that is FDA regulated, I struggle with understanding what the current problem is. That said, in my 16 years working for a company that is FDA regulated, I also know that the ‘confidential’ letters that come from the FDA are very detailed and require very specific and auditable actions. Thus there must be one of these letters that 23andMe needs to respond to. We don't know the content, and it can take time to resolve all the issues. I am hopeful that 23andMe will come out of this stronger and with the FDA approval. I certainly hope so.

mHealth innovation vs Safety

There is much concern that FDA will quash innovation in mHealth. If one only looks at the negative that FDA brings, that of process rigor and paperwork, I can understand the worry. BUT one must look at what this process rigor and paperwork brings relative to protecting patient safety. Safety really must be a high priority. There is much anger about the NY train crash, much press questions asking why there was not automated safety systems, yet a year ago had someone brought up the question of extra money to outfit the trains with automated control systems there would have been outrage.

I just started Bruce Schneier’s latest book “Carry On: Sound Advice from Schneier on Security”. In the first chapter he covers the paradox of how humans when faced with a loss situation will choose large loss with high-risk over a sure small risk. This is referred to as the Prospect Theory. It is not the typical logical approach, but does seem to be proven out as a human approach. It shows why it is hard to use a 'security' feature as a reason to buy one product over another. It is also why it is hard to use a 'safety' feature as a reason. Too often this means fear is used, which is an equally noneffective approach.

mHealth developers should be allowed to develop applications, but they should not be allowed to cause patient harm through negligence. This is all that FDA regulates. One can follow FDA with little overhead. The alternative is to wait for the FDA to force a visible issue like 23andMe; or for a train wreck to happen for which blood is on your hands.

What is a Connectathon?

Connectathon has two very important purposes and one very important principle. A Connectathon is an event that is centered on an open consensus built Interoperability (Connection) specification. The purpose of a Connectathon is both to prove that the specification is complete as well as to prove that implementations written to that specification can ‘connect’. The most important principle of a Connectathon is that it is a safe place for failure in these endeavors. That is that it is free of negative consequences of a mistake in someone’s implementation and that the specification might need to be refined.

In healthcare today many people might view that IHE invented the concept of Connectathon, this is not true. It was invented back in 1986 by those that had written the Internet specification and those struggling to implement it. In 1986 there was also "Interop" which focused more on the infrastructure standards of TCP/IP, and DNS, while "Connectathon" focused more on the application standards such as NFS, FTP, Telnet, and e-Mail. This quote is pulled from the Internet Archive WaybackMachine describing Connectathon as first introduced by Sun Microsystems in 1986:

“Connectathon is an excellent opportunity for vendors to verify that their distributed computing software interoperates with a wide range of client/server implementations on different operating systems. Everything from laptops to supercomputers can be linked together under one roof, encouraging interaction among vendors, engineers and developers in a confidential atmosphere. Implementations are tested and debugged at Connectathon. There are panel discussions as well as open sessions on the latest developments in technologies and solutions by Connectathon participants. Connectathon is a place where engineers can gather without marketing hype and can exchange ideas and information.”

You can see in this quote the purpose and principle that make a Connectathon successful.

Up to this point most networking protocols were proprietary. This meant that they were designed, specified, and implemented within the confines of the vendor that invented the protocol. Thus that vendor knew exactly what they intended the specification to say. That vendor knew exactly what other implementations (none) they needed to work against. That vendor could fully test their implementation in simulated deployment all safely within that vendors walls. Any bugs found during this pre-release testing were only the concern of that vendor. Actually any bugs found at a customer site were also only truly known by that vendor.

So it was considered critical to the success of the Internet that we know and love today that with open consensus ‘standards’ for connectivity have a similar but clearly different mechanism. Thus the Connectathon.

Connectathon is a Safe place to Fail

This simple principle has many dimensions that are worthy of exploring. The alternative to using a Connectathon as a safe place to fail, is to first try connecting to others at the customer site. One can see very quickly that this is not an optimal situation. The customer is expecting to use the product, not participate in debugging. The customer has likely paid money for the honor of having the systems fail to communicate. The customer will hold the two (or more) parties against each-other. But the customer really can’t tell which party is the one with the broken implementation. Thus finger pointing happens, and likely the most powerful vendor wins. This win means that the smaller vendor creates a custom implementation just for connecting to that powerful vendor. This means that the powerful vendor doesn't ever fix their implementation. This situation repeats with all the various vendors, great and small. Each time two vendors are integrated, they need to debug their various differences. Thus no-one is actually implementing the standard, thus there really is no ‘standard’ there is just a specification that hints at some concepts that might or might-not be implemented.

This situation is not good for the customers, they must each push their vendors hard to solve problems that simply shouldn't be. This causes delays in deployments. These deployments are also very fragile to changes. This is very expensive.

This situation is not good for the vendors, unless you have an alternative proprietary solution that you want to succeed. Vendors are pitted against each other in a very hostile environment under the watchful eye of the customer. Time is short, tools to debug are few. It is very hard to reproduce that specific environment. The software was written months ago, possibly years ago. The software developer has likely been working on something else in the last few months, so is not thinking about their implementation.

A Connectathon is a purely testing environment, so no worry about exposing real patient data or creating real patient safety risks.

Connectathon provides a Referee

At Connectathon there are others besides the vendor peers, including those that wrote the specification itself. There is often a set of people who have taken the specification and written test tools. Test tools are a form of implementation as well. As a test tool, it is not expected to be used at a customer production environment. Those that wrote the test tool are not a vendor and are thus not bias in a debugging dispute. Thus the test tool tends to be a non-biased implementation. Those that wrote the test tool are seen as the referee. Those that wrote the specification are also often consulted when a dispute comes up.

The whole purpose for a ‘standard’ is to have a single specification that is highly reusable. The fact that an implementation can be re-used at many deployments drives down the time and costs and drives up quality.

Connectathon is about Cooperation not Competition

As a “Safe Place” a Connectathon is an environment where those that are close to the implementation can come and be blunt. The participants of a Connectathon agree that they will not speak negative of their peers. One is allowed to speak of their successes, and they are encouraged at Showcases. But everyone must agree that the most important Principle of a Connectathon is that it is safe to fail, and one aspect of this is that one can fail without their competition blabbing about it. This principle is typically part of the agreement to participate, but most of the time is just socially encouraged. It is in the best interest of all parties.

The main reason why failure must be allowed, is that it must be encouraged. Everyone wants to get through Connectathon having cross-tested with all possible peers. This because by testing in a Connectathon means that they will likely not have problems at a customer site. Thus the more testing that can be considered ‘successful’ the better for yourself. The best case is that you can walk away from Connectathon with a huge list of your peers that you have successfully tested with. These successes can be spoken of, and are often included in a press release by your marketing department after the event.

The fact that Connectathon is a safe place to fail, means that vendors are more likely to send the developer that implemented the specification in their code. In fact it is useless for a vendor to send marketing or sales, there are no customers to speak to. Developers really want their code to succeed too. Thus the developer is much more likely to work with their peer to get the systems working. Often times the developers from competing vendors will be sitting right next to each other at Connectathon, often times reviewing source code. Yes, they are sharing their source code so that another can help them debug it. This concept is totally foreign to most vendor-to-vendor interactions, but it happens often on the Connectathon floor.

This does not mean that a Connectathon eliminates Competition, far be it. There is plenty of aspects of the software that are kept very well hidden during Connectathon. Some social networking is built, but the vendor organizations are clearly direct competitors.

Connectathon is not a Showcase

This because there are no customers present at a Connectathon. Sometimes customers are allowed on the Connectathon floor but this needs to be highly orchestrated and announced in advance. It is not uncommon for there to be a very detectable atmosphere change during these customer visits, the room gets more quiet, the participants do tests that they know from previous testing will work. During these customer visits everyone is on their best behavior, essentially the Connectathon event stops for a dog-and-pony show. The participants do want to show-off for their customers, they want to be seen at these events by their customers. This is because there is a common good that both vendors and customers see in the event. However one must recognize that Connectathon is not happening while customers are in the room.

Connectathon might fix the Specification

A less visible but just as important aspect of a Connectathon is that the Interoperabilty Specification is also open for discussion. Specifications that are early in their maturity are more open for debate. When two vendors find that they had to fix something in their code, one must ask the question of the specification. Was the specification at fault? Presumably both vendors wrote their implementations from the same specification, and came to different solutions. This could be because one of them simply didn't read the specification correctly, but it could also mean that the specification was not complete enough. Thus the specification is often improved during Connectathon too.

This is so fundamental that IHE requires that their Profiles go through a ‘Trial Implementation’ state. A Profile can’t move to “Final Text” state until three independently implemented systems prove that they can interoperate at a Connectathon event. This governance is there to show that at least three different development groups were able to read the same specification and end up with the same interoperability implementation. There are other governance measures for IHE “Final Text”, but that is a different topic.

Connectathon principles and purpose are critical

A Connectathon is not the only event where developers gather, some other concepts that are related but are different:

• Hackathon – More focused on the development of code to implement some goal. A Hackathon, or Hackfest, or Codeathon, has a targeted solution as the goal. Those that come to the hackathon are cooperating to achieve a goal. There might be more than one independent solution, but generally the goal is the writing of code. A Hackathon might not be focused on an Interoperability Specification, it might be a functional need. A Hackathon is a cooperative environment, again where it is safe to fail. A Hackathon succeeds when it builds buzz, educates the developers, and proves out alternative designs
• Plugfest – This is similar to a Connectathon, but typically focuses on a physical ‘plug’. That is that it is a Connectathon plus it tests physical and electrical interoperability too.
• Bake-off -- This is an event where different technical solutions to a problem are brought together to be compared to the goal. This is used to evaluate each potential solution so that the best solution can be picked. This is a form of implementation first consensus system. In healthcare this is how the "Direct Project" selected secure e-mail as the solution to the problem of 'replacing the FAX'.
• Showcase – To build awareness, educate, and display success. A showcase has been a follow-on event going back to the original Connectathons that were followed by a Telecommunications tradeshow. For much of the  IHE profiles the showcase is part of HIMSS Interoperability Showcase, or RSNA Demonstration
• Certification – Organized testing to prove a system conforms to a specification. Needed when the customer is incapable or unable to prove conformance to the specification. Automobile example. Crash safety is based on certification. Engine oil ratings are based on certification. Style, interior, features, handling, etc. are not subject to certification. An automobile buyer is genuinely unable to evaluate engine oil or crash capabilities of their purchases. They are able to decide what kind of car they want. There is no such thing as a complete automobile certification. Certification is limited to those items that the purchaser is unable to evaluate.

A Connectathon must be a safe place to fail, and be focused around an interoperability specification. If these are not true then you are not at a Connectathon, and you will not be benefiting from the Connectathon concept.

Distinction between Documents and Messages

While Keith was presenting an introduction to CDA training, the topic of Documents vs Messages comes up. After he presented his material, I asserted a more important distinction between Document and Messaging is that of state-less vs state-full.

Keith presents that Messages are: Real-time / temporary, system-to-system, not linked to creative process of the caregiver, not typically sign-able or legally attest-able, and often customized for the usecase. While contrasting with Document as  persistent, human-to-human, core to training of caregivers, legally recognized, and defined by precedent (the paper world). These might be true, but seem more argumentative than factual.

If we agree to look to HL7 to help us define the difference, this is documented in HL7. However we also must recognize that this is documented in the Structured Documents section. The HL7 standard for Structured Documents Section 1.2 describes the document vs. message distinction as follows 

“A document is designed to be persistent for long periods of time, whereas messages are more often expected to be transient. There is a place for both of these constructs in healthcare.” 

Messages are

A Message is sent in a context of a conversation between the sender and the recipient. These are typically system level transactions, I just don't think that is an important characteristic. The context of the transaction is an important factor to understanding the message by the recipient. Messages tend to be used in a STATEFUL world. A good example is the NAK message, it is totally dependent on knowledge of the message that is being negatively acknowledged. An order message is expecting that it is starting the state of something being done. It is true that there are some messages that don't fit this. I am not trying to setup absolutism, but rather setting general observations.

Health messages are not expected to be persistent, but represent a unit of information at a moment in time. The content is not always whole, where context may exist in the messaging environment rather than inside the message itself. Another example is that messages sometimes just use a vocabulary value without including the textual description or even include the code system identifier. Given that the sender and recipient know that they are using the  same value-set, they don't feel compelled to be complete.

Documents are

The HL7 standard for Structured Documents Section 1.2 describes the document vs. message distinction as follows “A document is designed to be persistent for long periods of time, whereas messages are more often expected to be transient. There is a place for both of these constructs in healthcare.” HL7 characterizes a document by the following properties:

• Persistence – Documents are persistent over time. The content of the document does not change from one moment to another. A document represents information stored at a single instance in time. 
• Wholeness - A document is a whole unit of information. Parts of the document may be created or edited separately, or may also be authenticated or legally authenticated, but the entire document is still to be treated as a whole unit. 
• Stewardship –A document is maintained over its lifetime by a custodian, either an organization or a person entrusted with its care. 
• Context - A clinical document establishes the default context for its contents 
• Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated. 

So what?

The distinction between message and documents can get blurry at times, as messages sometimes can be persisted and can contain all necessary context. Documents too can be incomplete, and rely on external content through links. In fact, messages can be converted to documents and can carry documents within their content. But documents are expected to be persistent, relevant over time and having the same meaning regardless of environment. And messages need not be any of those things.

What is more important to me is the relationship of these two in the context of a long-term, longitudinal, record. In that context the wholeness of documents is more useful than the benefits that messages bring. This is especially true in Cross-Enterprise Health Information Exchanges.

See  Critical aspects of Documents vs Messages or Elements