Every day I experience life in the world of healthcare IT, supporting 3000 doctors, 18000 faculty, and 3 million patients. In this blog I record my experiences with infrastructure, applications, policies, management, and governance as well as muse on such topics such as reducing our carbon footprint, standardizing data in healthcare, and living life to its fullest.

Wednesday, January 26, 2011

General Principles of a Universal Exchange Language

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.

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:

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.

John - two comments:1. separating data elements from the context in which the data element was documented can lose the intended meaning. While item 8 allows for some recognition of context, I do not think it fully addresses the loss of meaning.

2. In item 9, you state that An implementation guide should completely define the required and optional data and metadata. As you know, we wanted to accomplish that in HITSP, but did not have a way to address the intellectual property issues. Has that IP issue been resolved?

Thanks for important and concise comments here. Really appreciate the reminder of established Implementation Workgroup guiding principles. Great litmus test for several elements brought forward in the PCAST report. Not sure it's possible to do #9 while abiding by principle 2...but we can still aim high right?