The Language of HealthIT

Yesterday I summarized my thoughts on the Health IT report from the Presidential Council of Advisors on Science and Technology (PCAST).  The advisors made several recommendations, one of which was to "develop" a language for healthcare that could be used in web services and which could be used to access disagregated healthcare data.

I propose such a standards based language already exists, and will explain in more detail.  It's clear that the PCAST has looked into Health IT standards to some degree.  But its also clear that they aren't experts on the topic.

I've gone through the report again to pull out their suggested requirements for such a language:

1. A robust platform for creating user interfaces, decision support, storage and archiving. (p38, item #2)
2. Support for cross-organization data exchange (p38, item #3)
3. Support for strong privacy protection (p38, item #4)
4. Health IT systems must have the ability to communicate and aggregate health information in the ways needed to serve patients, doctors, and researchers. (p39, 1st para, 1st sent.).
5. Enable communication of clinical data. (p39, 2nd sent.)
6. Enable innovators to develop new tools to use healthcare information. (p39, 3rd sent.)
7. * Support policy and governance models to drive innovation. (p39, 4th sent.)
8. * Support appropriate access to information (p39, 2nd para, 1st sent.)
9. * Service Oriented Architecture (p39, last para)
10. Use XML (p41, 2nd para).
11. Support attachment of metadata on data (p41, 4th para) elements including:
1. Identifying information about the patient
2. * Privacy protection information
3. The provenance of the data—the date, time, type of equipment used, personnel
12. * Availability of a national infrastructure for finding health data, and for controlling access to it (p41, last para).
13. Services to include: services would include those associated with crawling, indexing, security, identity, authentication, authorization, and privacy (p42, 1st sent.)
14. * Support patient (or agent) ability to restrict access to the data. (p42, 1st para)
15. Support dynamic aggregation from multiple systems (p42, 2nd para)
16. Interoperable and intercommunicating in conformance to a single Federal standard (p43, 2nd para)
17. * Auditable for compliance with privacy and security policies (p43, 2nd para)
18. Extensible langauge for tagged data elements (p43, 5th para).

John Halamka summarizes these requirements thus (and check his blog tomorrow for details) as follows:

1. Content for Health Information Exchange should be expressed in XML using structured data with controlled vocabularies/code sets in a format that is infinitely extensible
2. Data elements should be separable and not confined to a specific collection of elements forming a document.
3. Metadata included as attributes of data elements should include at least person name/date of birth/data element name
4. Privacy controls should restrict query of data elements per patient preference. Data elements should be queryable using search engine technology (with privacy filters)
5. De-identified data should be available for population health, research, surveillance etc.

So, let's see how where HL7, IHE and HITSP have already addressed the issues:

Architecture and Standards
The PCAST report talks about different kinds of things.  It does not separate requirements for trasport, content, security and privacy, et cetera.  It does not address application requirements vs. interface requirements.  Applications provide services.  Services have interfaces.  Not all applications will support the same set of services.  Some of the "complaints" PCAST makes about existing standards aren't really appropriate, because they have an application requirement in mind that isn't met by one of the services they are looking at.

Now, privacy and security information need to be separately maintained and stored from clinical data.  About the only thing that needs to be stored with the clinical data is PERHAPS the privacy/security classification of it.  One reason for separating this is that they can change independently from the clinical information (new laws/regulation, new or altered patient preferences, et cetera).  The same is true for more specific access control and audit information.  So there isn't "one row" or set of XML elements that would necessarily appear together in an exchange that includes all of the privacy/security information with the clinical data.  I won't address the privacy/security or infrastructure requirements (marked with a *) from the above in this part of the post.  I will say that these have been addressed to some degree in the existing IHE and HITSP specifications and that more work has been done in HL7 on access controls.

One set of standards (CDA/CCD) are currently used under HITECH/Meaningful Use to send/recieve collections of discrete data in documents.  Now, a document is an aggregation of information for a single visit.  The CDA standard is designed for sending aggregations of data specific to a visit.  To complain that it doesn't support other forms of aggregation fails to acknowledge what it was designed to do.

CDA supports many of the requirements from above, including: #1, #2, #4-6, #10-11, #13, #15, #16 and #18

#1:  CDA is a robust way to store the clinical data and metadata, and can support UI and decision support through other application behaviors.  Some implementors have developed decision support services already based on exchange of CDA and CCD, and there are other interfaces to access the clinical data contained within the CDA document, e.g., the IHE QED profile (pdf).

#2:  This is already being done with CDA at Partners, South Shore Hospital, MA Share to the SSA, in the Vermont HIE, between the VA and DOD, and in other HIEs across the country.  It appears as a requirement in the current Meaningful use Regulations (45 CFR 170.205(a)(1)).

#4:  CDA/CCD is a way to aggregate this information for the collection of data about a SINGLE VISIT.  Other specifications, such as IHE QED profile mentioned above, can access the same data across visits using nearly the same XML.  Work is under way in HL7 on CDA Release 3, and on a new ITS that could uuse the SAME XML for all uses.

#5:  CDA enables exchange of clinical data for a visit.  Other profiles of HL7 RIM based standards support other ways to aggregate the data across visits.

#6:  I mentioned the Clinical Decision Support example under #1 above.  You can use CDA and QED to create a patient specific report based on content in a clinical data repository.  QED becomes the method to aggregate and CDA the way to report the aggregation in human readable narrative.

#10:  Yep, CDA uses XML.

#11:  All of the requested data appears in the CDA header and can also be attached to sections or entries in the CDA document.

#13:  CDA is a document format that can be crawled and indexed at a fine grained level.  In fact, the IHE QED profile anticipates that use and further tells how the two work together.

#15: The IHE QED profile is designed to support query and aggregation of data from multiple sources using almost the same markup found in CDA.  That profile can be used for research, gathering data to generate quality metrics, population surveillance, et cetera.

#16:  CDA can be part of that.  There really isn't ONE single standard, but a collection of them that work together (e.g., CDA/CCD, LOINC, SNOMED, et cetera).  See #18 below as well.

#18:  CDA, like all HL7 Version 3 based standards supports extensibility by binding the content with vocabulary standards that contain the detailed medical knowledge about problems (e.g. ICD or SNOMED), dianostic results (LOINC), procedures (CPT, ICD or SNOMED), medications (RxNORM)

The architecture that PCAST asks for already exists, and CDA is one part of it.  The other parts include the HL7 RIM, the HL7 Care Record, and HL7 Care Record Query standards.

More work is needed.  One of the work items is to make easier to use implementation guides.  HL7, IHE, Health Story and ONC are on it.  Another issue to to address transport.  NHIN Direct is a simple model, but isn't the robust exchange that is needed for other use cases like access to longitudinal data.

As a platform, the HL7 CDA and Care Record standards, as profiled by IHE, and applying the additional rules and vocabulary selected by ANSI/HITSP build the healthcare langauge that PCAST wants.

The language is just one part of the platform.  We need transport and we need security and privacy controls on that information.

NOTE:  The PCAST report speaks to the state of healthcare IT as deployed in the majority of institutions today, but DOES NOT speak to the capability of current healthcare IT solutions that are being deployed now. Much of what is currently available from Healthcare IT products supports the language that I just described.
Innovators are already using this langauge, based on the HL7 RIM, to do very interesting things. You can aggregate the data in multiple CDA documents into a CDR (via services that Crawl, index and identify using the existing profiles like XDS and QED). Then you can query that CDR to get data for a variety of uses (QED). Then you can apply clinical decision suppport (IHE CM and RCG -- also using HL7 Care Record), definitions about quality metrics (HL7 QDS), produce reports on quality (HL7 QRDA), or generate an immunization report for a patient (using HL7 QED and HL7 IC as demonstrated by IHE two years ago). It's all there. We just have to use it, instead of spending time trying to reinvent it.
There's a huge difference between what is available and what has been deployed. Advances in the development of these standards have taken some time to reach the healthcare marketplace, but they are getting there. The reasons for that are NOT a technology problem, but rather related to how Health IT infrastructure is invested in, updated, and deployed in the US.   The problem is not in developing the architecture and specifications, because believe it or not, we've been there and done that. 
 
The challenge is in getting it deployed.  There are several theories on why it hasn't been deployed.

1. Some fault the standards or the ease in which they can be understood and used. 
   Ease of understanding is perhaps reasonable argument but NOT a complete one because I know that a significant share of vendors in the market DO understand them and have implemented them.  HL7, IHE, Health Story, ONC, and others are working on the ease of use problem. 
2. Others explain that there's no incentive to deploy them. 
   That is also reasonable argument.  One part of that has to do with who benefits from use of them, and that's NOT a technology issue, but a policy one that I won't even attempt to address.  There are incenctives through ARRA/HITECH and Meaningful Use which are pushing forward, starting with exchange of data about visits and aggregated data about quality, but over the longer term (e.g., beyond 2015), more will be needed.  We need to think about how to accomplish that long term investment in healthcare IT, and make it worth the investment of healthcare providers. 

Ripping and replacing existing work won't solve either problem, it will just set us back to where we were 5-10 years ago, without addressing the fundamental issues.  Our healthcare system, and the IT it uses, is large, complex and emergent in its behaviors.  We need to figure out how to take the work that has already been done and use it to guide it towards the behaviors we want to see: use of the healthcare language.  That evolution will enable the revolution that PCAST is looking for.