Within the realm of Health IT, 2009 has been a year of unprecedented change, high expectations, and significant frustrations. As a result of ARRA and its HITECH section, which earmarked $19.2 billion intended to increase the use of Electronic Health Records (EHR) systems by physicians and hospitals, unprecedented attention has been focused on EHR systems.
The “hook” to try to incentivize physicians to adopt EHRs (given that the adoption rate as reported in the New England Journal of Medicine was 4% for fully-functional EHRs and 13% for basic systems) revolved around offering bonus incentives through Medicare and Medicaid payments for demonstrating “meaningful use” of “certified” EHRs. Such payments would begin in 2011 and extend through 2015, and thereafter the “stick” of payment reductions for failure to adopt EHRs would start to kick in.
As a result, the topic of EHR adoption has been on the minds and lips of physicians all year. And the state of things might best be summed up by an anecdotal comment I heard recently: “we finally adopted an EHR in our clinic, and it’s ok I guess, but the real problem is that they all need to talk to each other.”
The difficulty in making that happen – in getting EHR systems to talk to each other – has been a much harder nut to crack than one might have imagined. While the Office of the National Coordinator (ONC) has been working furiously all year developing a framework for defining “meaningful use” and is still detailing how to define “certification”, one of the big areas of attention has been on exactly this concern – interoperability between systems.
To illustrate the challenges in interoperability – in getting different systems to talk to each other – we can do a quick “year in review” for some of the various domains where EHR systems should be able to interoperate easily.
Laboratory results – Getting lab test values from hospital or commercial laboratories into one’s EHR would seem like a straightforward task. Many EHRs have a linkage with a local laboratory, but trying to combine linkages with multiple labs runs up against a roadblock: few labs use a standardized way of referring to tests. To put it more simply, an LDL Cholesterol might be referred to using one test code for Quest, a different one for the local hospital lab, and a different one from LabCorp. Yet, in your EHR you want to aggregate all these values, from all these sources, into a single bucket, so you can trend the results for a patient in a unified way.
The ONC has recommended that a particular standardized coding system, called LOINC, be used by all lab vendors so that multiple-lab connectivity can take place. Unfortunately, according to testimony at the Implementation Workgroup of the Health IT Standards Committee, the use of LOINC is still low, even by large commercial lab vendors – less than 25% of lab results generated across the country use the LOINC standard. In fact, some large laboratory IS systems don’t even have a placeholder for LOINC values for their tests, so implementing this standard will be difficult for them. Given this gap, there has even been the emergence of companies whose business is to match non-standardized lab values, and create LOINC codes on-the-fly from hospitals, reference labs and even in-house office labs. Such a patchwork may be the avenue for resolving this apparent impasse.
Electronic prescribing – e-prescribing is a key feature of EHR systems that is specifically desired in HITECH language. To date, Surescripts has emerged as an intermediary organization that came from pharmacy and prescription benefit managers, with which EHR systems can interact. Because of HITECH, every EHR vendor in the market has gotten in line for becoming certified with Surescripts – not surprisingly, the queue is long, and integration is burdensome and slow.
One of the challenges for physicians, however, is limitation in what kinds of prescriptions can go through Surescripts. Non-scheduled drugs, such as blood pressure and diabetes meds, can be prescribed and refilled without problem. But scheduled substances of any kind – even things like codeine-containing cough syrups (schedules III, IV and V) – cannot traffic through Surescripts. This is a new, more restrictive change brought about by DEA rules in 2009. Depending on the specialty, a significant percentage of prescriptions generated by a physician office may be scheduled drugs, and this represents a limitation. Computer-to-fax, phoned, printed or handwritten prescriptions remain the alternatives, and it is a challenge for creators of EHR systems to accommodate these restrictions.
Immunizations – One might think that sharing immunization records would be quite straightforward. After all, every vaccine is linked with a CPT code used for billing, and so CPT coding could serve as a standard for data exchange.
There is no national data repository for immunization records – the CDC offers support for states to create statewide immunization registries (a narrow-scope Health Information Exchange), but each state functions independently in this regard. EHR vendors, like Practice Fusion, are working with various states to enable connectivity to statewide immunization registries (so that a physician can upload or download all immunization information into the EHR) – however this is a state-by-state process.
Allergies – A list of medication or food allergies is important when checking for medications to avoid. Allergy cross-checking is part of e-prescribing, and is one of the kinds of data intended for upload into regional or national Health Information Exchanges. Again, one would think this a straightforward task, but the issue is lack of adoption of coding.
The ONC has recommended using a Unique Ingredient Identifier (UNII) code to track allergies. This is a good start – however, medication databases used for e-prescribing do not necessarily track UNII codes for medications (the databases may use other, internal and local ways of coding medications, without an easy cross-walk to UNII codes). This represents another example of “good intentions, but lack of adoption of any standards.”
Bigger things – The examples above have been some of the “easy” interoperability challenges facing EHR developers in 2009, as they try to get their systems to talk to each other. The bigger things, much more complex, are the sharing of actual chart notes. The problem here is that no two EHR systems handle a “chart note” the same way – every one has a different, and incompatible data structure for handling a “chart.” Some are tightly structured around templates, others have a text-assist flexible templating system (like Practice Fusion’s Smart Charting), while others are free-form Word-like documents.
One way of getting data around is to use a standardized transport document that everyone can write to and read from – the onus is then on each EHR vendor to build the capacity to create such records and read from them, irrespective of how that system handles its data internally. Easy? Not really. There are two competing schools of thought as to what that transport document should be – many of the larger, institution-oriented EHR vendors have favored the more burdensome Continuity of Care Document (CCD), while many of the smaller and more ambulatory-oriented EHR vendors have favored the more web-oriented Continuity of Care Record (CCR). The market, probably more than the ONC, will likely be where the controversy is resolved as to which kind of chart-transport becomes more widely adopted, or in what circumstances one vs. the other should be used.
Given this huge hurdle – regardless of the fact that the Kaiser system and the Mayo Clinic system and many integrated hospital systems “are certified” to use CCD – a Kaiser record will still not appear in a Mayo Clinic record, and neither of these will appear in the chart of rank-and-file Ambulatory Doc’s EHR. This may be the big hurdle of 2010. And beyond.
One approach around all this has been Practice Fusion’s introduction of Chart Sharing. Since Practice Fusion is web-based (no servers need to be installed, no setup needs to take place), and is free, and can be deployed in just a few minutes (“Live in Five”), then sharing charts is mainly a matter of complex permission management. Packaged chart data (in CCR format, or CCD format) does not need to leave a local EHR instance, be uploaded to a Health Information Exchange, and then downloaded into a recipient (and hopefully interpreted correctly). Instead, the recipient is given permission, and the shared chart is now visible to both clinicians. True – the Practice Fusion chart can only be seen by other Practice Fusion clinicians, but there is no real barrier to such viewing. Regardless of what system (if any) the recipient has, the view to the Practice Fusion ChartShare is at hand. No, it will not include the Kaiser records in the same chart’s view (but then, no one’s can). But it moves us all along the path toward the vision of interconnected health that is at the core of the guiding principles elaborated by the ONC and the emerging national health IT policy.
2010 should be an exciting time in the health IT space. By next-year’s end, maybe different EHR systems will actually start to talk to each other, even if it’s with limited vocabularies.
Robert Rowley, MD
Chief Medical Officer, Practice Fusion, Inc.
