HIEs, security, and cloud EHRs

Health Information Exchanges (HIEs) have received increasing attention in recent months. They are part of the agenda of the Office of the National Coordinator (ONC) for Healthcare IT, as they take steps to create a Nationwide Health Information Network (NHIN). What is the purpose of such things? What data security risks are raised by such networks? How does this relate to already-connected Internet “cloud”-based EHRs? We will attempt to address these questions in this article.

One of the problems with a health IT landscape characterized by legacy, locally-installed Electronic Health Record (EHR) systems is that medical data is segregated into practice-centered data silos, much like medical data in a paper environment – every doctor has his/her own “chart rack” (or EHR database), and a given patient may have segments of his/her medical information scattered among many different places. There is no one, coherent place where all the information about a patient is kept, and so copying of needed health information and sending to others is how data from outside the practice is updated. Things like lab data, hospital reports, consultation from colleagues, x-ray and imaging reports – all these things make their way into some of the physician’s charts, often in a hit-and-miss fashion.

Many observers of healthcare delivery, including the ONC itself, note that care coordination is hampered by such a chaotic system, and that needless duplication of services is among the results. Improving care coordination, and reducing the risks from medical errors (such as from making a medical decision in the absence of “known” data not available to the clinician at the time and point of care) are some of the issues behind establishing HIEs.

So why don’t EHRs simply “exchange charts?” Traditionally, each EHR vendor has created its own proprietary data structure – it handles a “chart” in its own unique way. Some template-centered EHRs (and several of the “big vendor” EHRs are like this) are so structured as to make “chart” exchange impossible even between clinicians using the same vendor, but using different sets of templates (e.g. a cardiologist and an oncologist practices may not be able to simply “exchange charts”).

The solution? To extract specific elements from a chart (like patient demographics, medications lists, diagnosis lists, allergies, immunizations, etc.) and present them in a standardized format for import and export. Two such formats have been proposed: the Continuity of Care Document (CCD), more favored by large legacy and hospital systems, and Continuity of Care Records (CCR), more favored by smaller, ambulatory systems.

HIEs have been based on the ability of EHRs to create and export CCDs or CCRs, and download and import them. Because the presumption is that a locally-housed EHR may not always be “on,” the HIE serves as a repository for CCD/CCRs for asynchronous uploading and downloading. Even though there is currently a lot of activity around creating regional and local HIEs (either the traditional RHIOs, or other e-Health Collaboratives), and then linking them together into the NHIN (which is supposed to serve as a “network of networks”), there has not been much real-time use of these networks to date. Most data exchange between offices – some on EHRs and some on paper – is still ad-hoc and fax-based. With the national attention on building such an infrastructure, however, it is still a matter of speculation as to whether these networks will, in fact, fill up with significant data.

A feature of HIEs, besides being standards-based places where different EHR systems can go to upload and download health information from outside sources (like lab data, medications data, and CCD/CCRs from other EHRs who elect to participate), is the fact that they are repositories of data. The ONC’s documentation supports a set of “use cases” (recommended by the American Health Information Community, or AHIC) for this aggregated data: (1) emergency responder/EHR; (2) EHR/lab results; (3) Medication management; (4) consumer empowerment/consumer access to clinical information; (5) consumer empowerment/registration and medication history; (6) quality; and (7) biosurveillance.

These uses of HIE/NHIN data are laudable, yet it remains to be established exactly how privacy and security will be maintained in such a system. By definition, the shared HIE data has “left” the confines of a physician’s clinical system, and is therefore outside the reach of traditional HIPAA Privacy relationships – it is no longer data about a patient created by a physician, whose confidentiality is protected by law; instead it is data uploaded by a physician, with permission from the patient, for use in a regional or national reference data service. The precise methods by which legal protection will be carried out to avoid violation of HIPAA privacy are on the ONC’s plate and are awaited eagerly.

As noted previously in this blog, HIE’s are really a “bridge technology” that is needed to link together medical data segregated into data islands. This is the consequence of a legacy where EHRs have been locally installed, with the “universe” being that local practice. Newer technologies – specifically “cloud”-based EHR solutions, such as Practice Fusion – raise the question about HIEs and whether they will be able to deliver on their vision. A “cloud”-based EHR has, by definition, a standardized way of handling a “chart” across all specialties and subscribed practices – chart sharing (real full-chart sharing, not just a CCR or CCD abstract of that chart) across different practices in different specialties sharing in the care of a given patient, becomes possible. Linkage with outside data sources, like laboratories and medication-management systems (e-prescribing) are handled as a single-point-of-integration – once established, such integration becomes immediately available to all participants. When combined with chart sharing, lab test sharing (real time, not awaiting asynchronous upload and download from an HIE) becomes possible across multiple practices. To put it more concretely, the labs ordered by the family practitioner and the cardiologist are visible to each other as they share the chart, and needless duplication is avoided.

With web-based EHR services (the way that “cloud” solutions function), there is already a network in place – the Internet – and a new network of HIEs feeding as nodes into a NHIN loses relevance. Time and experience will tell, but our speculation is that, while laudable and worthwhile effort is appropriately spent building HIEs that (maybe) a good number of legacy systems will connect to, web-based EHRs like Practice Fusion will grow in usage anyway, and the amount of data contained, shared, and actually used by meaningfully-large numbers of clinicians will achieve the desired result more quickly. The government has even acknowledged that “cloud” technology should be used by themselves more widely. We share the same goal – to make an EHR network that will improve care coordination, share relevant clinical information in appropriate settings, enhance quality, reduce errors, and (through all of this) reduce costs. Our belief is that this will be achieved faster by the path pioneered by Practice Fusion than by building “a thousand bridges” to interconnect legacy systems.

Robert Rowley, MD – Chief Medical Officer, Practice Fusion, Inc.