I've recently been asked to provide a list of the data elements of an EHR which might be used as part of the ARRA mandate to exchange data as part of meaningful use. There are a nearly infinite number of actors, actions and events for data exchange, but in the interest of getting "data liquidity" in healthcare, here are the elements that are most commonly used and represent a great starting point for healthcare information exchange. I always strive for parsimony of standards - the fewest that we need for the purpose. Below you'll see that I've included the standards that support the systems we have in place today as well as the XML/Web-based standards that support newer web-centric systems and healthcare information exchanges.
Demographics
Content: HL7 2.x for messaging, CCD for document summaries
Vocabulary: HITSP Harmonized codesets for gender, marital status
Problem List
Content: HL7 2.x for messaging, CCD for document summaries
Vocabulary: SNOMED-CT
Medications
Content: NCPDP script for messaging, CCD for document summaries
Vocabulary: RxNorm and Structured SIG
Allergies
Content: HL7 2.x for messaging, CCD for document summaries
Vocabulary: UNII for foods and substances, NDF-RT for medication class, RxNorm for Medications
Progress Notes and Other Narrative Documents (History and Physical, Operative Notes, Discharge Summary)
Content: HL7 2.x for messaging, CCD for document summaries
Vocabulary: CDA Templates
Departmental Reports (Pathology/Cytology, GI, Pulmonary, Cardiology etc.)
Content: HL7 2.x for messaging, CCD for document summaries
Vocabulary: SNOMED-CT
Laboratory Results
Content: HL7 2.x for messaging, CCD for document summaries
Vocabulary: LOINC for lab name, UCUM for units of measure, SNOMED-CT for test ordering reason
Microbiology
Content: HL7 2.x for messaging, CCD for document summaries
Vocabulary: LOINC for lab name/observation
Images
Content: DICOM
Administrative Transactions (Benefits/Eligibility, Referral/Authorization, Claims/Remittance)
Content: X12
Vocabulary: X12, CAQH CORE
Quality Measures
Content: Derived from all the data elements above
Vocabulary: Derived from all the data elements above
Privacy and Security
Transport: HTTPS, SOAP/REST
Transport Orchestration: WS*
Authorization/Access Control: XACML
Given that meaningful use needs to be achieved by 2011-2012, it's clear that we cannot rip and replace existing hospital information systems and EHRs. We need to leverage them, upgrade them over time, and install new systems in an incremental fashion. This is really true of any change in healthcare. If we had a greenfield, we would design healthcare delivery, payment, and infrastructure entirely differently. Unfortunately, we do not have a greenfield, we have limited resources, and limited time to achieve healthcare reform, so we need to leverage what we have and evolve it in phases.
HITSP will be reformatting and streamlining its previous work over the next 90 days to support ARRA, the HIT Standards and Policies Committees, and ONC. I hope you agree that the list of EHR data elements above is practical, achievable now, and reasonable.
I've heard quite a few issues around Structured SIG. It didn't make it into the first round of CMS ePrescribing standards because of implementation challenges, and most of the systems I've looked at in the last year (including at major Boston hospitals) don't support it. Any insight?
ReplyDeleteThe NCPDP-facilitated Industry Sig Task Group completed their version 1.0 guide, which was made official by NCPDP and ANSI in May 2008. A request was brought forward by eprescribing entities to incorporate the Sig guidance into the NCPDP SCRIPT Standard. Version 10.4 of SCRIPT was made official by NCPDP and ANSI also in May 2008. A pilot underway by AHRQ/CMS is testing the use of Sig and RxNorm to provide more feedback for the standard use. Also, the eprescribing industry has requested from NCVHS and CMS to move from SCRIPT version 8.1 to SCRIPT version 10.6 by January 2010. While the request has been met with approval, the recommendation and regulatory process has moved very very slow with all the changes occurring in DC.
ReplyDeleteHi John,
ReplyDeletePerhaps it would be good to put in a plug for HITSP C80 as a consolidated "one stop shopping" source of info on the clinical vocabularies, since it contains further details. Also, I noticed a typo under allergies, where it should say NDF-RT instead of NDC-RT for medication class. Thanks for your continued efforts to inform and educate.
Hello John,
ReplyDeleteI'm curious as to why you'd select HL7 v2, with its delimiter-based syntax, versus v3 which has an XML-based syntax? Having messages consumed and manipulated by both freely available XML processing APIs (Xerces, JAXB, DOM, SAX, etc.) and proprietary hardware-based appliances (like the Datapower XML Gateway) has advantages. Your thoughts?
Per the questions about HL7 2.x and HL7 3.x
ReplyDeleteThe Continuity of Care Document is the HL7 3.x/CDA standard that I'm recommending.
I've included HL7 2.x messaging for existing systems that use point to point messaging for data exchange such as Lab to EHR transactions. To my knowledge no Lab in the country is using HL7 3.x messaging to EHRs at this time.
In the interest of getting all this implemented in the 2011 timeframe, leveraging HL7 2.x where it exists today plus using HL 7 3.x for new functionality seems like the right answer.
I'm a Medical Officer in the Office of Clinical Standards and Quality at CMS and we (CMS) started a project last year (pre-ARRA) working with ONC and HITSP to create the beginnings of a quality measure dataset for use in EHRs which will hope will be a key component for "meaningful use"....
ReplyDeleteHi John
ReplyDeleteHealth IT is always consumed with the present difficulties. We have 1000s of vendors who work in our space largely because it is so highly fragmented: your recommendations illustrate how fragmented. The work of a community of clinicians and IT experts (see openEHR.org) has been developing a massive and collaborative simplification of this space and now has working systems going into production. These promise EHR services independent of clinical applications with collaborative development of display, integration and other transformations. The very recommendations you are making can be formally expressed within the openEHR Framework. It does require an evolutionary approach, but the possibility of consolidation of all information within a single framework seems the right place to start.
John,
ReplyDeleteDo you agree that extraction and combination of the data necessary for quality would require at the very least some decision support services features in the HER? The data would need to be extracted as a report and then reformatted for submission to the proper quality authority such as CMS. Do you agree?
This makes up an interesting proposition for an EHR users as well as for the vendors. The data elements really pose a different challenge than what healthcare industry is already facing.
ReplyDeleteHealth IT is always consumed with the present difficulties. We have 1000s of vendors who work in our space largely because it is so highly fragmented: your recommendations illustrate how fragmented. The work of a community of clinicians and IT experts (see openEHR.org) has been developing a massive and collaborative simplification of this space and now has working systems going into production. These promise EHR services independent of clinical applications with collaborative development of display, integration and other transformations.
ReplyDeleteRecep Deniz MD
DoktorTR.Net