Element-Centric or Document-Centric Interoperability

A recent Chilmark blog post on national healthcare interoperability mentioned two approaches to healthcare interoperability: element-centric interoperability and document-centric exchange.

As I think back on the thousands of discussions I’ve had on interoperability, these two phrases do a great job describing the different approaches to interoperability. Unfortunately, what I’ve seen is that many people get these two approaches to interoperability mixed up. In fact, I think it’s fair to say that meaningful use’s CDA requirement is an attempt to mix these two concepts into one. It’s one part element data and one part document.

Personally, I think we should be attacking one approach or the other. Trying to mix the two causes issues and confusion for those involved. The biggest problem with mixing the two is managing people’s perception. Once doctors get a small slice of cake, they want the rest of it too. So, it’s very unsatisfying to only get part of it.

Document-Centric Exchange
The argument for document-centric exchange of healthcare data is a good one. There are many parts of the patient record that can’t really be slimmed down into a nice element-centric format. Plus, there’s a wide variation in how and what various doctors document. So, the document format provides the ultimate in flexibility when it comes to outputting and sharing this data with another provider.

Those who are against document-centric exchange highlight that this is really just a modernization of the fax machine. If all we’re doing is exchanging documents, then that’s basically replicating what we’ve been doing for years with the fax machine. Plus, they highlight the fact that you can’t incorporate any of the granular data elements from the documents into the chart for any sort of clinical decision support. It might say your allergies on the document, but the EHR won’t know about those allergies if it’s stored on a document you received from another system.

While certainly not ideal, document-centric exchange can still be a nice improvement over the fax machine. In the fax world, there was still a lot of people required to get the documents faxed over to another provider. In the document-centric exchange world this could happen in real time with little to no interaction from the provider or their staff. The fact that this is possible is exciting and worrisome to many people. However, it would facilitate getting the right information (even if in document form) to the right people at the right time.

Element-Centric Exchange
We all know that the nirvana of health information exchange is element-centric exchange. In this exchange, your entire health record is available along with a series of meta data which tells the receiving system what each data element represents. This solves the allergy problem mentioned above since in an element-centric exchange the allergy would be stored in a specific field which notes it as an allergy and the receiving system could process that element and include it in their system as if it was entered natively.

This last line scares many people when it comes to element-centric exchange. Their fear is that the information coming from an external system will not be trustworthy enough for them to include in their system. What if they receive the data from an external system and it’s wrong. This could cause them to make an incorrect decision. This fear is important to understand and we need our systems to take this into account. There are a lot of ways to solve this problem starting with special notation about where the information was obtained so that the provider can evaluate that information based on the trustworthiness of the source. As doctors often do today with outside information about a patient, they have to trust but verify the information. If it says No Known Drug Allergy, the doctor or other medical staff can verify that information with the patient.

The other major challenge with element-centric exchange is that medical information is really complex. Trying to narrow a record down to specific elements is a real challenge. It’s taken us this long to get element-centric exchange of prescription information. We’re getting pretty close there and prescriptions are relatively easy in the healthcare information world. We’re still working on labs and lab results and anyone whose worked on those interfaces understand why it’s so hard to do element-centric exchange of health information.

This doesn’t even address the challenge of processing these elements and inputting them into a new system. It’s one thing to export the data out of the source system in an element-centric format. It’s an even bigger challenge to take that outputted document and make sure it imports properly into the destination system. Now we’re talking about not only knowing which element should go where, but also the integrity and format of the data in that field. Take something as simple as a date and see the various formats which all say the same thing: 2/17/15, 2/17/2015, 02/17/2015, February 17 2015, Feb 17 2015, 17/2/2015 etc.

Where Is This Heading?
As I look into the future of interoperability, I think we’ll see both types of exchange. Document-centric exchange will continue with things like Direct Project. I also love these initiatives, because they’re connecting the end points. Regardless of what type of exchange you do, you need to trust and verify who is who in the system so that you’re sending the information to the right place. Even if document exchange using Direct isn’t the end all be all, it’s a step in a good direction. Plus, once you’re able to send your documents using direct, why couldn’t an HIE of sorts receive all of your documents? We’re still very early in the process of what Direct could become in the document-centric exchange world.

I think we have a long ways to go to really do element-centric exchange well. One challenge I see in the current marketplace is that companies, organization, and our government are trying to bite off more than they can chew. They are trying to make the entire patient chart available for an element-centric exchange. Given the current environment, I believe this is a failed strategy as is illustrated by the hundreds of millions of dollars that the government has spent on this goal.

I look forward to the day when I see some more reasonable approaches to element-centric exchange which understand the realities and complexities associated with the challenge. This reminds me of many organizations’ approach to big data. So many organizations have spent millions on these massive enterprise data warehouses which have yet to provide any value to the organization. However, lately we’ve seen a move towards small data that’s tied directly to results. I’d like to see a similar move in the element-centric exchange world. Stop trying to do element based exchange with the entire health record. Instead, let’s focus our efforts on a smaller set of meaningful elements that we can reasonable exchange.

While the idea of document-centric exchange and element-centric exchange simplify the challenge, I think it’s a great framework for understanding healthcare interoperability. Both have their pros and cons so it’s important to understand which approach you want to take. Mixing the two often leaves you with the problems of both worlds.

About the author

John Lynn

John Lynn

John Lynn is the Founder of the HealthcareScene.com, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference, EXPO.health, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.


  • I like your summary of the pros and cons of these two methods of data exchange. Governments and industries are moving wholesale to APIs that allow the exchange of single elements. Why should health care once again be dinosaurs? Certainly there are quality issues, but if bad data gets into a structured data field, bad data can also get into a narrative. Let’s train clinicians and patients to follow standards and enter data correctly. Big Data strategies also contain tricks to correct for outlier data; they should know when a man is diagnosed as pregnant (which in these days of transgender empowerment, can actually happen).

  • Andy,
    I was trying to think how FHIR and it’s API approach fit into the above discussion. I think you captured it well. Although, I still think we have to be careful with FHIR that we don’t try and bite off more than we can chew like I mention in the article. If they try to do too much with it, then it will fail. If they start off with something reasonable, they can grow it from there.

    Let me round out the discussion with a reminder that APIs are Hard: http://www.hospitalemrandehr.com/2015/01/22/ehr-apis-are-hard/

Click here to post a comment