Editor’s note: This blog was originally published in 2010. To view more recent content, please see:
The prospects of a fully integrated healthcare system are truly exciting. While patients’ expectations and HIE capabilities may truly never completely align, the exchange of a patient’s health data within a health organization, or regionally, among aligned providers, have tremendous potential to improve patient care and satisfaction.
Health Information Exchange: What’s the Motivation?
Now that the majority of innovative healthcare organizations have invested the capital, time and effort to install electronic medical records, many are looking to fully leverage the technology and meet Meaningful Use requirements by connecting to an HIE. According to eHealth Initiative’s 2011 Report on Health Information Exchange: FAQs, there were 255 HIEs in 2011, an increase of 9% from 2010. A majority (70%) of existing HIEs are private, yet just 24 claimed to be sustainable.
There are several reasons why HIEs are a logical next step for health providers who have implemented EMR systems, including qualifying for Meaningful Use or serving as a precursor or test case for connecting to a future Accountable Care Organization (ACO). Whatever the motivation, both examples can mean significant revenue for the organization, in addition to improved efficiency of patient care:
- The earlier a health care organization qualifies for Meaningful Use Stage 1 requirements, the more financial benefit the provider or health organization will receive as part of the Medicare Electronic Health Records (EHR) incentive program. For Medicare-eligible hospital systems, qualifying for Meaningful Use in 2011 means receiving millions of government dollars earlier than if they qualify at a later date.
- Care providers who are members of an ACO, as defined in the Affordable Care Act, can potentially earn significant Medicare rewards for the realized cost savings from bundled payments and meeting pre-defined quality of care benchmarks. While EMRs are not required of all ACO providers, they are required to perform an analysis of the ACO’s overall patient care metrics against the 32 benchmarks set by the U.S. Department of Health and Human Services. HIEs also have the potential to provide cost savings to connected organizations in the forms of increased productivity, avoidance of duplicate medical procedures, and the resulting shared savings as a result of payment by episode of care.
While a positive return on investment is always the key motivator for organizations to make costly business moves such as installing EMRs or paying to connect to HIEs, the good news for patients is that both Meaningful Use requirements and ACOs share a common end result – improving the quality of patient care.
Regardless of personal beliefs on the merits of a connected health care industry, the reality for health IT professionals is that HIEs are forming in every state. There is, however, uncertainty about the different forms of HIEs and what challenges health organizations likely will face when trying to exchange data within a HIE.
Architecture Types
This section provides an overview of three common public HIE architecture types: centralized, federated and hybrid models. Additionally, many larger health organizations have built private HIEs to effectively share patient data between member hospitals, labs and their referring physicians.
First, a quick snapshot that displays an example of how data might flow within the three types of public HIEs, starting at the local level (Centralized), moving to the state level (Federated) and ending at the national level (Hybrid), or NwHIN (Nationwide Health Information Network). The Centralized Model is the most common architecture for private HIEs.
Centralized Model
Centralized HIEs have a single Clinical Data Repository (CDR) that is maintained by the HIE authority, which is usually governed by representatives from each member hospital. The centralized architecture can be utilized on a regional basis, for example, by hospital systems located in the same metro area.
Each member hospital electronically transmits agreed upon patient health information to the CDR, where it is securely stored and continually updated via interfaces that are connected directly to each hospital’s patient data repository, or health information system (HIS). Through these interfaces, patient data flows to the central authority, updating the appropriate records, and also back to each member hospital when the data is requested, which is usually done upon patient admit using a pre-defined set of unique patient identifiers, such as social security number or last name.
The most interoperable HIE architecture, the centralized model is also the most expensive to establish and maintain because it requires a large upfront investment in technology in the form of servers, which need to be monitored and stored in a secure, separate location.
Additionally, each organization must have a fully functional EHR and utilize CCD documents.
Federated Model
A Federated HIE model consists of a collection of clinical data repositories that are remotely located. In this example, Centralized HIEs agree to provide the overreaching state or central authority with their unique patient identifier information, which is stored in the statewide HIE patient registry, or record locator service. In a Federated HIE (as opposed to Centralized HIEs) patient data is not stored in a centralized, accessible location. Patient information continues to be stored locally with the Regional Central Authority in this example.
To retrieve patient data, member organizations send query messages to the HIE patient registry. The patient registry contains a “virtual roadmap” of where patient health records are located, searchable by a combination of unique patient identifiers such as a combination of name, social security number, and others.
When a record is located in the registry, the state central authority transmits the record’s physical location back to the requesting organization. The requesting organization then must request the patient information from the facility where it is located. The facility storing the information can transmit the data to the requesting organization via secure e-mail, secure web services, or through a VPN connection.
The Federated HIE model is considered less interoperable than the Centralized HIE because it does not allow a simple exchange of information between facilities’ EHR systems. The requirement that a central record locator service track numerous, duplicate health records at multiple remote locations increases the complexity of locating a patient’s complete health history and determining which information is the most up to date.
Hybrid HIEs
This national HIE architecture type could represent a combination of HIEs participating in the EHR/HIE Interoperability Workgroup, a federally backed initiative to develop and test the standards and processes needed to create a national exchange of health information. In addition, the Nationwide Health Information Network, typically referred to as NwHIN, is working to lay the foundation for our national health system.
In this example Hybrid Architecture model, Federated HIEs request data similar to regional HIEs, but the location of records across states would be performed at a national level. In this example, a national authority, such as the NwHIN, is storing a limited amount of information at the national level possibly for population health reasons. This example assumes that all participating state HIEs are structured using the Federated model.
Several hospital systems across the country have created a private HIE system that includes internal databases and referring physicians. Many ACO structures are supported with private HIEs. Most likely a private HIE will utilize the Centralized HIE model since there is a single, private governing organization. A private HIE is a good way for health systems to create internal interoperability that will allow them to easily connect to HIEs, state databases and, later, the NwHIN.
HIE Communication Methods
Although not a complete list, there are four common methods health organizations use to send and receive Continuity of Care Documents (CCD) within an HIE:
TCP/IP over VPN
TCP = Transmission Control Protocol
This model allows computers to communicate over a secure private network and provides end-to-end connectivity with specifications on how data should be formatted, addressed, transmitted, routed and received at the destination. This method is the most-connected (interoperable) way to exchange health data in an HIE.
When using this communication method, CCD documents are immediately transmitted to the HIE based on trigger events at the point of care, such as a patient discharge. This consecutive updating of a patient’s data gives all HIE members access to a patient’s current health record.
At Corepoint Health, we believe that health organizations can most effectively connect to a public HIE over VPN using an integration engine. Integration engines eliminate the need for extensive point-to-point scripting and programming to configure messages containing CCD documents for exchange within an HIE.
Secured Web Services
This communication method allows HIE members to send and receive patient data via secure communications over the internet. Secured web services is also very interoperable because the HIE data is updated in real time based on trigger events.
Once a patient’s health data is updated by a provider and the trigger is set, that patient record is published to the HIE using industry standard methods, such as IHE profiles. The CCD will be wrapped with metadata that will be stored in the HIE registry, and the document itself will be stored in the HIE repository.
Organizations can use an interface engine or a custom HIS interface to configure and send/receive CCD data to the HIE using web services.
Secured Ftp
FTP = File Transfer Protocol
Organizations connecting to an HIE via secured FTP can send patient data in batches, or one document at a time. Batches are typically sent once each day. This obviously is not a real-time HIE solution, but it does enable the sharing of patient data, thus meeting Meaningful Use electronic data exchange requirements as specified in Stage 1.
Secure E-Mail
Utilized as an entry-level communication method for HIE involvement, secure e-mail is the direct transmission of one provider’s patient data to another requesting HIE provider via secure e-mail. Frequently called the “push” method of HIE data exchange because the owner of the information “pushes” the data to another location.
The Direct Project initiative provides specifications for the use of secure e-mail in transporting patient health information. The primary Direct Project specification, the Applicability Statement for Secure Health Transport, is a required communication method for Meaningful Use Stage 2.
Typically, this is how the exchange works: Provider A contacts the HIE requesting to find information about a specific patient. The HIE might have a portal that returns locations (i.e., other HIE providers) that have information on the specific patient. Provider A will then request that patient’s information directly from the providers identified by the HIE. Once the request is received by the other providers, they will securely email the data to Provider A.
Physician and Patient Portals
HIE architecture types and communication methods typically only involve IT staff. Physician and patient portals bring the HIE end result to individuals, both physicians and patients.
Merriam-Webster defines portal in different ways, but this definition is most applicable to an HIE: “A site serving as a guide or point of entry to the World Wide Web [HIE] and usually including a search engine or a collection of links to other sites arranged especially by topic.”
So, what exactly do portals have to do with HIEs?
Not all physicians will be able to connect to a regional HIE for various reasons, such as lack of an advanced EMR or he or she may be a specialist not involved with routine or emergency care. These physicians will have the ability to access their regional HIE’s physician portal to view a specific patient’s treatment history, providing valuable health data that may be useful prior to performing a procedure.
For patients, portals link them to the process of health data exchange. In the future, the patient’s total health record – regardless of where the care was received – will be viewable in a patient portal. This is extremely valuable because patients will have the ability to correct errors in the health record if they exist and be reminded of previous care they have received.
A portal is also an access point for both patients and health providers to a convenient communication platform, which differs among portal vendors. Some portals allow only basic communication in the form of offering patients the ability to schedule or reschedule appointments, request a prescription refill and complete paperwork prior to their next appointment.
Other, more robust portals – especially those built to meet Meaningful Use Sections 170.304(h) and 170.306(d) – allow patients to access clinical summaries and electronic copies of their health information. In terms of offering a true communication method between patient and physician, some portals give the patient the option to send a text (SMS) message or an email directly to his or her physician.
Portals represent tremendous advances in opening the doors of communication between patients and our caregivers. Giving patients the ability to bypass the patient calling tree and to directly communicate with the provider about billing questions or simple prescription refills will likely improve patient satisfaction. The portal will also give the provider better access to the patient, with the ability to send email reminders that it is time to schedule an annual physical or information about valuable health resources for specific chronic diseases.
An accurate patient health record is vital for quality care because it can prevent repeat examinations and provide caregivers with knowledge of pre-existing medical conditions that may actually save a patient’s life. Portals truly have the potential to directly connect patients to their care, which is the true reason behind health information exchange.
Despite Momentum, HIE Sustainability a Concern
Few in healthcare argue that exchanging patient health records electronically is a bad idea. HIEs around the country are already touting the benefits of their services, namely a reduction in unnecessary patient trauma and unnecessary costs.
In 2011, there were 255 HIE organizations in the U.S., yet only 24 reported that they were financially sustainable. In other words, there are 231 HIEs that are currently not making enough revenue to cover operating expenses.
Many of these HIEs are able to continue operation due to HHS grants and because member healthcare organizations are willing to risk a short-term financial loss because they believe the HIE will gain widespread provider acceptance, which will eventually help them recoup early losses through several cost savings measures and future government reimbursement incentives (e.g., bundled payments, quality of care benchmarks).
Local physician practices are slow to adopt EMR systems due to significant costs that can outpace Meaningful Use reimbursements and, some would argue, because they have no financial incentive to enthusiastically adopt a new healthcare system that moves away from the fee-for-service model they have successfully used for generations. From strictly a business sense, it’s logical for them to ask “What’s in it for me?” before investing hundreds of thousands of dollars on an EMR system just so they can connect with the local HIE.
HIE directors must prove to the referring physician community that patients overwhelmingly want a system that securely exchanges their medical data, and that belonging to such a system will provide the physicians a return on their investment of an EMR system with external connectivity, HIE fees, and all the additional technology and staff required to make it functional.
Through Meaningful Use and HHS, the government is also playing a major role in pushing all providers toward a modern, electronic medical system. However, time is of the essence for HIE sustainability and there are no government mandates that require participation in an HIE, regardless of the obvious benefits it has for patient care. Meaningful Use Stage 2 objectives may push eligible professionals to utilize an HIE, but those rules are not effective until 2014.
Obstacle: Patient Education
An HIE can have 100% provider participation, but it is worthless if it doesn’t have patient data to exchange. It’s imperative that HIEs receive patients’ consent to exchange their health data with other HIE provider members. HIEs currently employ two different models: the patient opt-in model or the patient opt-out model.
It’s pretty simple. When visiting their provider, patients are given two options about their patient data, usually in the form of a check box on paperwork that is completed during check in, which sounds similar to the following simplified examples:
Example 1: Check here if you approve Memorial Hospital to share your electronic health record with local health providers who are members of the State Health Information Exchange. (Opt-in Model)
Example 2: Check here if you DO NOT want Memorial Hospital to share your electronic health record with the State Health Information Exchange. (Opt-out Model)
HIEs have found that the Opt-out Model has a higher success rate because the patient must take the extra action to exclude their record. The Opt-in Model requires an extra educational component about the benefit of HIEs for the patient, either in the form of printed materials or by verbal communication from the office staff.
The Opt-in Model also has other obstacles to gain patient consent because there is an inherent distrust by many Americans to allow their information to be used for any purpose because it only reminds them of junk e-mails, identify theft, and telemarketing phone calls.
So, despite great interest in HIEs, they have many obstacles to overcome before they can claim to be successful. However, numbers never lie – if operating HIEs continue to report progress on cost savings and patient safety, then it is unlikely provider organizations will want to be on the outside looking in. Patients realize the health system is rapidly changing and soon they’ll have the choice to go to a provider who has invested in modern technology in an effort to provide better patient care.
The Building Blocks of HIEs: A Glossary of Terms
One thing to keep in mind when reading about HIEs and how they operate is that the terminology is not consistently used by health IT professionals, which only complicates the learning process. For example, you’ll notice below that the definitions for Document Registry and Record Locator Service are very similar, and you’ll often find they are used interchangeably in discussions and in publication. Hopefully these terms provide a foundation to help you better understand the complicated, and always changing, world of health information exchange.
Clinical Data Repository (CDR): The database in which patient data is stored. Regardless of the HIE architecture type, each member organization maintains their own CDR. Centralized HIEs have a CDR that houses a redacted version of the complete patient medical record, which is easily accessible by all member organizations.
Communication Backbone: The method by which data is transmitted within an HIE. Communication methods include secured email, secured FTP, secured Web services, and TCP/IP via VPN connection. HIE components that need to be regularly updated may include: Master Person Index, Record Locator Service, CDR, and Portals.
Direct Project: The Direct Project was launched by the ONC within Health and Human Services (HHS) on March 1, 2010. It was initially called NHIN Direct. The object of the Direct Project is to replace the use of faxes, phones, and paper transactions with a simple and secure point-to-point communication over the Internet. The Applicability Statement for Secure Health Transport is the primary Direct Project specification and uses the SMTP e-mail protocol with secure S/MIME attachments and x509 certificates.
Document Registry: A document registry is best described as the “patient index” of each patient who has health information accessible by the HIE and contains information where that information is stored. The health standards organization Integrating the Healthcare Enterprise (IHE) has worked at defining document registries, which are available in evolving Web-services technology.
Master Person Index (MPI): Stores, and cross references, the unique ID for every patient in the HIE.
Portal: Provides independent, personal access to the HIE for the treating physician or for the patient to view and access information, which can include hospital paperwork, appointment information and personal health information.
HIE Participant Identity Management: HIE member providers and networks are verified by node level identity management, as defined by IHE Audit Trail and Node Authentication standards. Node level identity management establishes security measures that, together with the HIE’s security policy and procedures, provide patient information confidentiality, data integrity, and user accountability.
Record Locator Service (RLS): Keeps track of all records for a single patient. The location of the RLS varies depending on the HIE architecture type. Centralized HIEs have a common CDR that houses basic patient demographic information. Typically, a centralized HIE member issues a patient query to the RLS, which locates the correct patient’s data and sends the location back to the requesting organization – all within the centralized HIE.
In Federated and Hybrid HIEs, all patient data is maintained by and “lives” in the member’s CDR (not in a centralized location). When the RLS receives a patient query, it must relay all participant organizations, rank the responses, and then return the information to the original requester.
Ready to talk to an interoperability expert? Contact us.
