As we head into 2012, the “hot topic” in EHR / Health IT circles is connectivity. A doctor’s EHR in the office is supposed to be able to connect with outside sources of patient data – reference laboratories, other clinicians using the same or different EHRs, immunization and public health registries, and the like. Of most urgency, though, is the desire to connect a clinician with the local hospital. And, of all of the integrations, this one is the most difficult.
Myth 1: hospitals are a single system
To help understand this question, we should look a bit deeper at what a “hospital EHR” actually is. Hospitals, historically, have had a collection of systems, installed in their different departments, each one likely having been sold as a stand-alone best suited for that department. So, modern hospitals will have one system for Medical Records (which often involves transcriptionists), another one for the pharmacy, a different one for the in-house lab, another one for their radiology imaging systems, and another one for billing. Emergency Departments may have a system separate from the main inpatient Medical Records systems. Computerized Physician Order Entry (CPOE) systems, often installed in Intensive Care Units or on medical/surgical floors, are usually separate systems tightly connected with billing, and are put into place after-the-fact of other software already in use.
By the time that the federal EHR Incentive Program (Meaningful Use) came along, and encouraged hospitals to demonstrate a set of capabilities and performances in order to access money (Meaningful Use money often is in the range of $1 million per hospital), hospitals faced a big challenge. There was already a legacy of local installation of department-oriented systems, which may not connect together very well. The big challenge has been knitting these separate installations together into something that behaves cohesively. Most hospitals, not surprisingly, did not get to Meaningful Use via a single overall piece of software – usually, it was a collection of elements that, together, could achieve the needed performance. Even large institutions with robust IT infrastructure needed to do that.
This is why so many anecdotes of failed EHR installations are seen in the hospital realm – HIMSS, the trade group for Health IT, is mostly comprised of hospital-focused IT professionals, and has been a forum for discussions on how to overcome these challenges and knit it all together. It takes planning, resources, upgrades from multiple software vendors (usually), and a prolonged learning curve for each of the different departments in the complex in-hospital ecosystem.
Many of the systems that need to be pulled together into a cohesive hospital EHR are stiff and unchanged since they were created in the 1990s, and ask the user (clinicians, hospital personnel) to change their work to fit the product; rather than creating product to fit the work. It is a far cry from the kinds of interfaces seen in ambulatory web-based EHRs, or other elements of modern web-based technology generally.
Myth 2: integration with a hospital is a one-to-one connection
Given that hospitals are focused on trying to tie their internal legacy systems together, or rip-and-replace them with something far-reaching and new (like a multi-million dollar, or even billion-dollar Epic-type system), connection with outside clinician EHRs has not been much of a priority.
Small wonder that many hospitals are willing to “integrate” by simply extending their in-house system to closely-allied (or owned) community physicians, but are not willing to create interfaces with multiple other systems. At best, a hospital may simply want to set up (or subsidize) an HIE hub for remote connection by others – however, the connectivity to each community doc still needs to be built, tested, and will result in substantial integration cost (often borne by the outside physician) – in the range of a few thousand dollars per integration. And it will take time to create. This is not a scalable solution.
It may well be better to think of a hospital as a collection of data systems, and attempt connectivity with some of them one-at-a-time. What kinds of data does a community doc need from the hospital? Mainly, it is Emergency Department encounter reports, and Medical Records documents (admitting history and physicals, discharge summaries, operative reports, dictated consult reports). This is one integration.
If lab tests are needed from the hospital, then this is another, different integration. If discrete data is desired from the hospital, then the integration is more like an integration with an outside reference lab, and hopefully the vocabulary used to identify tests by the hospital lab conforms to standards (LOINC codes) – maybe only 50% of labs are on this standard, however. More likely, simply sending hospital lab reports as a scanned PDF document is a quicker means to the data-exchange end.
Looking at imaging, or cardiac-diagnostic test data, requires different kinds of integrations. If the ambulatory EHR has the ability to connect to, and display medical images (using the DICOM standard), then such integration is possible. Usually, when looking at the actual images is important, a separate window into the hospital’s PACS systems can be set up, outside the EHR.
The bottom line is that “hospital connectivity” is really a bit of a myth – each kind of connection, whether it be medical records, labs, imaging, or pharmacy, is really a separate integration, using different standards and methods.
What is the best way forward?
Given the complexity of “connecting to my local hospital,” it is likely to be a long time before a systematic way of tying it all together is seen in this country. Each hospital has its own unique internal integration issues, and is unlikely to be able to connect externally very well. And there are over 5,700 hospitals in the U.S. A scalable, universal solution is not likely to be achieved in the near future. “Tower of Babel” is a term that comes to mind.
However, we can start building connectivity now. It involves different and innovative approaches to data exchange. It is based on not relying on a “universal HIE” structure to be built.
What we are building in the near-term is a way of “sharing the platform” of ambulatory EHR data, based on a single widely-held web-based platform. Since our EHR platform is free, and new, valid users can be on-boarded very quickly (within minutes, actually), there is the potential to share one’s ambulatory patient record with an outside practice – this capability has not been deployed yet, but is on the near-term roadmap.
Though Chart Share will have many use-cases, and will have a profound impact on the industry, one can envision a specific use-case of getting one’s ambulatory records to the hospital (e.g. a surgeon creating pre-op records from the office, and having them available at the hospital).
In such a use-case, one can set up two “practices” – a “My Ambulatory Practice,” with all one’s EHR data in it, and a separate “My Hospital Practice,” which is initially empty. Then, one can Chart Share a given patient from the Ambulatory Practice to the Hospital Practice, so that the Hospital Practice now contains the one shared chart. I have login ability to My Hospital Practice, as do specific identified other personnel in the hospital, so that the records created in the Ambulatory Practice can be accessed from the Hospital Practice (without exposing any other of My Ambulatory Practice’s patients to view from hospital personnel).
This is a simple case-study of a particular implementation of Chart Share which allows connectivity to the hospital without having to create and rely upon a yet-to-be-built HIE integration.
As this capability becomes more mature, with trust verification of recipients, and a way of securely messaging between connected practices in order to “pull” chart requests upon patient permission, this kind of connectivity will actually get to the goal of sharing health data much sooner than might otherwise be possible. And – it is widely scalable, something that traditional HIE build-outs are sorely challenged to become.