Next Steps for the HIT Standards Committee

Guest author and co-chair of the HIT Standards Committee John Halamka reports on the July 21st meeting of the HIT Standards Committee working groups' progress on Clinical Operations, Clinical Quality and Privacy/Security.

Next Steps for the HIT Standards Committee
by John Halamka

At the July 21 meeting of the HIT Standards, we approved an initial set of standards for quality, clinical operations and security/privacy. We were told to refine these initial efforts by the next meeting of the Committee, August 20, so that ONC and CMS can incorporate the work into the interim final rule. Here's an update on the deliberations of the workgroups.

Privacy and Security
We received several public comments about our selected privacy and security standards - those used for authentication, authorization, auditing, encryption, and secure transmission. It's important to note that the sending and receiving of transactions for healthcare information exchange is part of the scope of the Privacy and Security Workgroup. Clinical Operations specifies the vocabulary/codesets/value sets and the actual message or document to send. Privacy and Security ensures it is sent in a secure fashion, consistent with HIPAA and ARRA. Our recent decisions in response to comments are

*Although the IHE ATNA profile for securing transmission via TLS allows use of Null Cipher (i.e. no encryption) as an option for private networks, we will require all health information exchange transactions between organizations, even those running on private networks to be encrypted via the AES_SHA cipher by 2011.

*SOAP is an approach to data exchange that enables programmers to use the web to call remote servers using the HTTP POST syntax. POST means the URL does not contain any specific information i.e.

I use POST to talk to a server at http://mymedicalrecords.com and request information about my medical record number and the kind of information I want to retrieve using hidden exchanges between the servers, not by embedding the details of my request in the URL.

SOAP has a learning curve and generally requires a toolkit to make the implementation easier. It has been a favored approach in healthcare because it has many standardized security tools.

*REST is an approach to data exchange the enables programmers to use the web to call remote servers using the HTTP GET syntax. It's easy to use without a toolkit. For example, you could use a browser to call a URL like the following to retrieve your allergies

http://mymedicalrecords.com?myMRN=1234567&show=allergies

Although it's simple, there are fewer standardized security tools. REST is increasingly popular and Amazon, Google, and most e-commerce companies have embraced REST, creating their own unique security tools.

*The Security and Privacy Workgroup recognizes that both approaches, SOAP and REST, should be allowable for data exchange. Here's a list of the HITSP Capabilities and Services supporting these transactions

TP13 - Manage Sharing of Documents (XDS.a), SOAP and REST
TP13 - Manage Sharing of Documents (XDS.b), SOAP
TP13 - Cross-Community Access (XCA), SOAP
TP21 - Query for Existing Data, SOAP
T31 - Document Reliable Interchange, SOAP
T42 - Medication Dispensing Status, SOAP
TP49 Sharing Radiology Results, SOAP and REST
TP50 - Retrieve Form for Data Capture, REST
T63 - Emergency Message Distribution Element, SOAP
T66 - Terminology Service, SOAP and REST
T81 - Retrieval of Medical Knowledge, REST
T85 - Administrative Transport to Health Plan, SOAP
TP89 - Sharing Imaging Results, SOAP and REST

For a more detailed discussion of the pros/cons of SOAP and REST, see my blog entry on the topic.

Clinical Quality
Leveraging the completed HITEP report, the Clinical Quality Workgroup has proposed 27 initial quality measures and the data types required to capture each electronically. The challenge is that several quality measures contain exclusionary criteria i.e. when considering HbA1c levels, remove patients on comfort care measures from the denominator. When considering tobacco cessation counseling, remove patients who really like smoking and lack readiness to quit from the denominator. Such exclusionary criteria are really challenging to support with existing EHRs. It is likely that either these exclusions will have to be removed from the measures until EHRs and standards support them, or that self attestation of quality measures rather than electronic measurement be done in the short term until EHRs can capture these more esoteric data elements. The Clinical Quality workgroup is examining every data type for its readiness/adoption and will then make final recommendations on the quality measures and data types to use in 2011.

Clinical Operations
We're refining the matrix of vocabulary, messaging and document standards to respond to comments from HIT Standards Committee members and the public. We've heard such things as

*Allow HL7 2.51 messaging as well as XML-based document formats for transmission of data in HIEs, at least for the next several years

*Although care coordination and patient experience data exchanges may benefit from unstructured documents such as a PDF exchanged electronically along with metadata, quality measurement really requires codified data, even if it is just ICD9. SNOMED-CT is the preferred vocabulary for clinical observations and eventually should be used for all quality measures, but it will take several years for SNOMED-CT to be fully implemented in healthcare information exchanges, so ICD9 and ICD10 will be allowed along the way

*The HIT Standards Committee focuses on healthcare information exchange - from the edge of one organization to another organization. All the vocabularies we are discussing - LOINC, RxNorm, SNOMED-CT and UNII (for allergies) are for exchange, not necessarily required within internal systems of organizations. This is the realistic approach that is needed to give organizations the time they need to implement controlled vocabularies for data exchange.

We'll continue our work for the next two weeks and then present it publicly on August 20. Thanks to all the Committee, Workgroup, and HITSP volunteers who have spent many hours on this effort.