General Principles of a Universal Exchange Language

I've written several posts about the President's Council of Advisors on Science and Technology (PCAST) report on Health Information Technology.

Between January and April, the PCAST Workgroup will think about the high level concepts in the report, which I believe can be distilled into 3 major themes

1. Increase the priority of interoperability to facilitate coordination of care and to enhance research capabilities.
2. Establish a Universal Exchange Language based upon an XML-style approach for exchanging individual data elements.
3. Create a supporting exchange infrastructure that includes a data-element/record locator service along with appropriate privacy and security controls.

I've recently thought a great deal about #2 - the Universal Exchange Language.    I've posted Sean Nolan's examples and provided a briefing about existing approaches to data exchange used on the web.

Before jumping into XML formats and comparisons of existing healthcare standards, I believe we should first define the general characteristics of the ideal Universal Exchange Language.

We should be guided by the HIT Standards Committee's Implementation Workgroup principles for evaluating all future standards work:

Keep it simple.
Don’t let “perfect be the enemy of “good enough.”
Keep the implementation cost as low as possible.
Design for the little guy.
Do not try to create a one-size-fits-all standard.
Separate content and transmission standards.
Create publicly available vocabularies & code sets.
Leverage the web for transport (“health internet”).
Position quality measures so they  motivate standards adoption.
Support implementers.

If I were to invent a Universal Exchange Language using nothing but these guiding principles and my intuition as a doctor and CIO,  I would include the following:

1.  High signal to noise ratio  (some existing standards have significant overhead for every clinically relevant data element).

2.  Easily human readable (by a developer, not necessarily an end user) and computable.

3.  Easy to create, easy to parse.

4.  It should be trivial and clearly understandable how to implement basic exchange such as sending and receiving a medication list, a problem list and an allergy list.

5.  There could be multiple sources of ontology/concept information as long as the receiver of the information understands how the sender packaged and defined the data elements.

6.  To the extent that ontologies are used, they should be viewed as pure notation by developers.  Developers should not need to even understand what an ontology is to be able to understand the content.  As with #5, developers should only need to be able to write code that will consume the metadata that links the content with the context defined in the ontology.

7.  It should be trivial to add additional metadata or additional data without impeding the ability to send and receive the basics.

8.  Data elements should be separable from the document, but we have to be realistic about this, since Problem Start Date really needs to be associated with a Problem Name to be useful.   We could define "data atomic" as the smallest unit of data that makes sense within the context defined by the associated metadata.

9.  An implementation guide should completely define the required and optional data and metadata elements for a given purpose.  Implementers should not have to open a dozen different Standards Development Organization products and implementation guides to understand how to create a message.

10.  Innovators should be free to think about optimal ways to solve this problem without being overly constrained by existing implementations.  Since health information exchange is in its infancy, strict compatibility with previous approaches is not our highest priority.

The PCAST report is likely to be a catalyst for rich discussion.   I look forward to the work ahead to offer ONC options for including PCAST principles in its existing programs and strategies.