To improve the quality of our health care while lowering its cost, we will make the immediate investments necessary to ensure that, within five years, all of America's medical records are computerized.
Yet, recent studies have raised some concerns about the effectiveness of Electronic Health Records (EHRs). A recent survey of 4000 hospitals conducted by Dr. David Himmelstein and his team of researchers at Harvard Medical School and published in the American Journal of Medicine concluded that the adoption of EHRs have had little impact on administrative costs and quality of care.
Another study published in the Milbank Quaterly raised some questions about the effectiveness of EHRs (as compared to paper records) in primary clinical work.
In the US, the American Recovery and Reinvestment Act (ARRA) of 2009 (also known as the "economic stimulus package") contains a portion called the Health Information Technology for Economic and Clinical Health Act (HITECH Act) which provides $19.2 billions of incentives to physicians and hospitals for the adoption of EHRs. No matter where you stand in the political spectrum, ARRA, the HITECH Act, and Health Care Reform are now realities to contend with in the US health care sector.
What can be done to ensure that these massive investments in HIT and EHRs live up to their expectations? A research paper entitled "Use of Electronic Health Records in US Hospitals" and published in April 2009 in The New England Journal of Medicine reveals:
On the basis of responses from 63.1% of hospitals surveyed, only 1.5% of U.S. hospitals have a comprehensive electronic-records system (i.e., present in all clinical units), and an additional 7.6% have a basic system (i.e., present in at least one clinical unit). Computerized provider-order entry for medications has been implemented in only 17% of hospitals.
The EHR is the cornerstone of the emerging Nationwide Health Information Network (NHIN). Software developers can do all sorts of interesting things (in the spirit of "meaningful use") with patient health data once it becomes available in electronic form. In 2010, EHRs will be a top priority for providers because of the incentives available under the HITECH Act. The ECRI Institute puts EHRs on the number two spot on its list of Top 7 Technologies for Health Plans in 2010.
The following factors will be key to unlocking the full potential of HIT:
- Open Source
- Training the HIT Workforce
Standards are important for the seamless exchange of data between the different stakeholders (hospitals, physicians, payers, lab companies, etc.) in the health care industry. Furthermore, due to the complexity of the health care domain, organizations adopting HIT cannot afford to reinvent the wheel when deciding on key issues such as:
- A data model for representing EHR data and quality measure reporting content.
- Coding systems for representing patient health information in a machine-processable format.
- A language for expressing clinical practice guidelines for their automated execution in clinical decision support systems (CDSS) as a "meaningful use" of EHRs.
- A protocol for cross-organization exchange of patient data.
- Technologies for privacy, security, audit trails, and patient consents.
Fortunately, some of these standards exist today and should be adopted. Organizations such as the Health Information Technology Standards Panel (HITSP) and Integrating the Health Enterprise (IHE) in the US and Canada's Health Infoway's Standards Collaborative are working on harmonizing standards for data exchange as well as security and privacy in the health care domain.
EHR Data and Quality Reporting
The HL7 Reference Information Model (RIM) expressed as a set of UML class diagrams is the foundation model for health care and clinical data. The HL7 Clinical Document Architecture (CDA) which is derived from the HL7 RIM has been widely adopted around the world for EHR implementation projects. The HL7 Continuity of Care Documents (CCD) is a constraint on the CDA driven by the requirements of the ATSM Continuity of Care Record (CCR) specification. The HITSP C32 specification which is a further constraint on the HL7 CCD is emerging as the standard for the exchange of EHR data in the US realm.
On the CCR vs. CCD debate, I have come to appreciate and respect the exhaustive metadata provided by the CCD which is important for medico-legal reasons, but also for building software applications such as clinical decision support systems (CDSS) that rely heavily on the availability of such metadata. However, I also realize that some patient-facing web applications for managing personal health records (PHRs) can benefit from the simplicity of the CCR.
For collecting and reporting performance measure data to improve the quality of care, the Physician Quality Reporting Initiative (PQRI) Registry XML Specification and the HL7 Quality Reporting Document Architecture (QRDA) are available.
Laboratory content can be exchanged in HL7 2.5.1 messages or HITSP CCD documents. Digital Images and Communications in Medecine (DICOM), DICOM Structured Reporting (SR), and Web Access to DICOM objects (WADO) are used for medical imaging.
The HITSP C80 Clinical Document and Message Terminology Component specification defines the vocabularies and terminologies used by various HITSP specifications. HITSP C80 recommends Logical Observation Identifiers Names and Codes (LOINC) for laboratory observations, RxNorm for standard names of clinical drugs, Unique Ingredient Identifier (UNII) for allergies, SNOMED CT for Problem Lists, and Unified Code for Units of Measure (UCUM) for units of measure.
Integrating terminologies is a big challenge in Health IT. An example is the mapping from SNOMED-CT to ICD-10 or Current Procedural Terminology (CPT). Semantic web technologies such as RDF, OWL2, SWRL, SPARQL, and SWASDL have proven their usefulness in semantic mediation across coding systems as well as in building Clinical Decision Support Systems (CDSS).
Administrative Transactions and E-Prescribing
Relevant standards include X12 4010 and 5010 for administrative transactions, Council for Affordable Quality Healthcare (CAQH) Core for online patient eligibility and benefits inquiries, and NCPDP SCRIPT 10.6 for electronic prescriptions (e-prescribing). Conversion from 4010 to 5010 and ICD-9 to ICD-10 will be a priority on the agenda in the next three years (details on final compliance dates can be found on this HHS web page). XQuery, XQuery Update, and XSLT2 are likely to play an important role in that conversion effort.
An Expression and Query Language for Clinical Decision Support Systems (CDSS)
There is currently no consensus on a single standard for expressing clinical practice guidelines for their automated execution in CDSS. Existing specifications include the Arden Syntax, the Guideline Interchange Format (GLIF), and GELLO (roughly Guideline Expression Language Object-Oriented). Some wonder if a standard is needed in this space at all. My position is that a standard with an open source reference implementation with support for some publicly available and approved clinical guidelines can be useful in speeding up adoption.
In addition, since EHR data is one of the primary inputs into a CDSS, the CDSS expression language should at least share the same underlying data model with the EHR data input. That model is the HL7 Reference Information Model (RIM). The "virtual medical record" (or vMR) specified by GELLO is defined as a view of the HL7 RIM. It would be a great help if HITSP could step in and harmonize standards in the CDSS space.
Cross-Enterprise Document Sharing
The Integrating the Health Enterprise (IHE) Cross-Enterprise Document Sharing (XDS) Integration Profile specifies a protocol for the sharing and access to EHRs across health enterprises. XDS defines concepts such as an "Affinity Domain" (a group of collaborating health enterprises), the "Document Source", the "Document Repository", and the "Document Registry". It also specifies transactions such as "Provide and Register Document", "Query Document" and "Retrieve document".
Other relevant IHE Integration Profiles include the Cross Community Access profile (XCA), the Cross Enterprise Document Reliable Interchange (XDR), and the Cross Enterprise Document Media Interchange (XDM).
Privacy and Security
On the privacy and security front, the following publicly available standards can be used to comply with ARRA and HIPAA requirements:
- Transport Layer Security (TLS)
- Advanced Encryption Standard (AES)
- Secure Hash Algorithm (SHA)
- OASIS eXtensible Access Control Markup Language (XACML)
- OASIS Security Assertion Markup Language (SAML)
- OASIS WS-Security
- OASIS WS-Trust
- OASIS WS-Policy.
The following IHE Profiles provide specific security guidelines for health enterprises and Health Information Exchanges (HIEs):
- Audit Trail and Node Authentication (ATNA)
- Consistent Time (CT)
- Basic Patient Privacy Consents (BPPC)
- Enterprise User Authentication (EUA)
- Cross-Enterprise User Assertion (XUA)
- Patient Demographics Query (PDQ)
- Patient Identifier Cross-Referencing (PIX)
- Digital Signatures (DSG).
For the de-identification and re-identification of content which are important for privacy as well as public health research and epidemiology, the following specifications are available:
- 45 CFR Parts 160 and 164. Standards for Privacy of Individually Identifiable Health Information; Final Rule. August 14, 2002. Section 164.514(a-b) Deidentification of protected health information. (Deidentification)
- 46 CFR Parts 160 and 164. Standards for Privacy of Individually Identifiable Health Information; Final Rule. August 14, 2002. Section 164.514(c) Reidentification (Pseudonymization)
- ISO/TS 25237:2008 Health Informatics --Pseudonymisation, Unpublished Technical Specification (Pseudonymization).
High costs, total failure, disappointing return on investment (ROI), and adverse impact on end-users productivity are always risk factors to deal with in any large scale software implementation project. HIT projects are no exception. Driving costs out of health care will be a top priority for all stakeholders in 2010. So, companies will look for viable alternatives to insane software licensing and maintenance fees.
Open source implementations of some of the HIT standards mentioned above can be leveraged to reduce such risks. In addition to lowering costs and risk, open source can provide the transparency that is needed to ensure that HIT software provides adequate privacy and security protections. Examples of these tools include:
- The Open eHealth Integration Platform which is based on Apache Camel and implements HIT standards such as HL7 2.x, HL7 CDA/CCD, and IHE XDS.
- The Open Health Tools Project provides tooling for developing HIT applications.
- The Connect Gateway allows health enterprises to easily connect their HIT systems to health information exchanges (HIE). It implements key components such as a Master Patient Index (MPI), XDS.b Document Registry and Repository, Authorization Policy Engine, Consumer Preferences Manager, and a HIPAA-compliant Audit Log.
- The WorldVistA EHR open source EHR system which is based on the U.S. Department of Veterans Affairs (VA) sponsored VistA software. Work is underway to add CCR and CCD support to WorldVistA.
Training the HIT workforce
Finally, the potential of HIT will not be fully realized without the availability of a fully trained and competent workforce. All stakeholders in the health care industry should commit the necessary investments to educating the future HIT workforce through college and university programs as well as corporate training.
Lastly, the usability of EHRs in clinical settings deserves more attention and additional research.