advisory note health information exchanges: global lessons...

Advisory Note

Publication Date: 03/06/2014

Publication Date: June 3, 2014 of 43

© 2014 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Health Information Exchanges: Global Lessons Learnt From Implementations and Best Practices

Zafar Chaudry, M.D.

This paper reviews the lessons learnt internationally from health information exchange implementations.

Key Findings

Developing an integrated strategic plan for HIE across a healthcare system requires a redesign of clinical processes, redefined roles for clinicians and the use of integrated healthcare information systems (that adhere to predefined standards) across primary and acute care.

There is a standardised model for the continuity of care record across the USA and UK.

Define and clearly articulate the value of the HIE initiative in specific clinical contexts.

It is important to have stakeholder participation to ensure system usability, participation and adoption.

Know when to involve senior management to gain support and to move the project forward.

Large corporate groups are more likely to embrace HIE-based systems.

At the planning stage, define who is allowed to see what information and when, plus how to win consensus of practicing clinicians on such definitions.

Understand that the trust of patients, above all, rests with their physicians and that clinician engagement is therefore critical. It takes many years of hard work to build trust among participants.

Develop a clear business case for each type of participant.

Publication Date: /ID Number: of 43


The real purpose of the planning exercise should be to define a meaningful pilot that meets the needs of the local stakeholders.

Address security and privacy concerns from the onset of the program’s planning. This means, closely involving clinicians in developing a privacy and security framework and validating that framework in extensive pilot tests.

Organisers must carefully define and continually communicate the many value propositions for different types of participants.

Legal problems must be addressed in the planning stages.

A perfect corollary to the problem of over-strategising the HIE is the tendency of many organisations to define project phases and milestones that are far too ambitious. Execution risks are enormous when there are huge costs that have already been incurred and lavish expenditure of time and users’ engagement. It is far more expedient to get a small HIE project up and running.

Recommendations

Develop a health information exchange policy for the healthcare system.

Organisers must carefully define, and continually communicate, the many value propositions for different types of participants.

Know the political climate of the state.

Ensure clear expectations regarding budget authority.

Involve representative stakeholders to ensure project support and governance. Make sure roles and responsibilities are well understood within a team.

Focus on the clinical use case first - a HIE network will ultimately encompass many functions including reporting, biosurveillance, eligibility checking, claims and administrative data transmission, plus consumer communication. The first and most important focus of the HIE network must be its clinical use. This is the dominant objective of the HIE network; to provide information that leads to better outcomes for patients. Establish value by demonstrating clinical use and viability.

Say no to an Opt-In consent policy - the goal of a HIE is to make pertinent health information available for the good of the patient and to also provide that information only to the right people. How this is managed without infringing on privacy rights is a delicate matter. It is vital to protect the rights of the patient, but it has also been demonstrated that creating an opt-in environment impedes patient participation. Our research indicates that it is impractical to begin a HIE with a consent model that requires express patient consent: opt-in. We strongly recommend the adoption of a clear opt-out model for the HIE. In this case, patients are considered to be in the exchange unless they specifically choose to opt-out of participation. We further recommend patient opt-out be administered through the provider’s office. The logic of this is clear; patients consider their primary care physician their main contact with the healthcare system. If a change needs to be made to their status, they will logically want to handle it through their primary care physician. We caution against allowing patients to restrict access to certain physicians and facilities or to restrict the sharing of certain diagnoses.



A medical office, hospital, or clinic is a world filled with data. Clinicians are already overwhelmed with information. If the HIE deals up an even bigger sea of data, it can seem unmanageable and even discouraging to those it is meant to help. Traditional episode-of-care-based viewers (which include all current EMR and most HIE products) simply divide a summary screen into four to six groups, showing — in reverse chronological order — lists of diagnoses, procedures, medications, providers, lab work, and other entries. This may give an acceptable review of what the patient has experienced in the past week; however, it fails to deliver a continuity-of-care view that highlights the health history of a patient. For the 20 percent of patients with chronic disease who consume 80 percent of healthcare resources, these traditional approaches fall short. The right HIE can solve this problem. HIE has the potential to deliver an enormous amount of data to a clinician. However, unless filtered and organised for easy viewing and use, it is too much, too fast.

Build analytics into the system at start-up - systems designed to simply deliver content from one end to the other do not scale well to perform more sophisticated functions that require analysis. Analytic readiness and data transformation must take place as the data moves through the system, so that each edge system is not required to embed intelligence. It is prohibitively expensive to fix data at the receiving edge.

The HIE system you select should be undergirded with the ability to:

Link clinical and administrative data

Apply data standardisation that enables analytical readiness

Select specific clinical and administrative data fields for centralised decision support

The system needs to have the intelligence to determine what data is pertinent to the patient’s situation at that particular moment. It also requires the capability to deliver rules and alerts that proactively call attention to pieces of critical data that might otherwise be ignored. This will naturally yield better medical treatment decisions and better outcomes.



TABLE OF CONTENTS

Introduction ........................................................................................................................................ 5

Market Definition ................................................................................................................................ 7

Market Direction................................................................................................................................. 7

Market Analysis ............................................................................................................................... 11

Representative Vendors .................................................................................................................. 14 EHR and Megasuite Vendors Offering HIE Services ......................................................... 14

Allscripts, Inc. ........................................................................................................ 14 Cerner, Inc. ............................................................................................................ 14 Epic ........................................................................................................................ 15 Quality Systems, Inc. (NextGen) ........................................................................... 16 Siemens ................................................................................................................. 17

Independent HIE Vendors .................................................................................................. 17 McKesson .............................................................................................................. 19 Optum Health ........................................................................................................ 20 Orion Health .......................................................................................................... 20

Continuity of Care Record .................................................................................................. 21 Decision Points ................................................................................................................... 22

Planning and Sustaining the Initiative ................................................................ 25 Major Issue Management .................................................................................... 27 Governance and Communications ..................................................................... 29 Technology and Interoperability .......................................................................... 30 Implementation ..................................................................................................... 31

Lessons Learnt .................................................................................................................. 32 Stakeholder Engagement .................................................................................... 32 Governance .......................................................................................................... 33 Finance ................................................................................................................. 34 Technical Infrastructure ....................................................................................... 35 Business and Technical Operations ................................................................... 38 Legal and Policy .................................................................................................... 40

Recommended Reading .................................................................................................................. 41



Introduction

All around the world, healthcare services are undergoing significant reforms. Healthcare providers, policy-makers and patients are increasingly expressing concern about fragmentation of care. Rapid advances, new treatments and shifts in care from institutional to outpatient and home settings mean that patients may see an ever expanding array of different types of providers in a variety of organisations and places. Connecting these components into a smooth care trajectory is becoming increasingly difficult. Greater availability of accurate, complete, relevant clinical data allows care providers to deliver higher quality, more efficient and cost -effective care. Studies have shown that initiatives that include electronic medical record (EMR) systems connected to a health information exchange (HIE) , result in a reduction of redundant tests, increased administrative efficiencies, plus improved processing time for referrals, prescriptions, and hospital discharges. These efficiencies can improve patient safety by eliminating transcription mistakes, thereby reducing medication errors and adverse drug events. In addition, the capture and exchange of patient clinical data opens the door to new alternatives to face-to-face care provider visits which are equally effective, less costly and more efficient for patients and providers. Gartner defines "HIE" as the "exchange of clinical information among independent healthcare organisations." The HIE technology market includes software and technological services offered to create and operate a HIE. We do not include systems integrators and other providers of professional services for implementing HIEs except to the extent when these services are available through the vendors of technology, incidental to its implementation.

Two assumptions that underlie most HIEs are that physicians will seek information outside their own medical records while treating a patient; and that information could automatically be imported into the electronic medical record (EMR) system of the healthcare delivery organisation (HDO). Both of these assumptions have been challenged in implementations. Even in emergency departments, simply making the information available, seldom results in substantial usage. In the U.S., many public HIEs were created through $500 million dollars in grants issued pursuant to the Health Information Technology for Economic and Clinical Health (HITECH) Act. In 2010, we predicted that these HIEs would often fail to develop into economically self-sustaining programmes. Since 2012, our inquiries from CFOs and CIOs of healthcare organisations that have taken leadership roles in HIEs confirm this trend. Many are attempting to renegotiate software fees drastically downward, based on the lack of uptake. HIE software vendors are refocusing their sales efforts on privately funded and governed operators of HIEs. Most of the large U.S. HDOs that Gartner talk to are creating self-funded HDO-based HIEs for interactions with their affiliated physicians to assist the physicians in achieving "meaningful use" incentive payments, and as a strategic step toward enlisting them in ‘accountable care’ and patient-centred medical-home efforts.

Globally, progress on HIEs is also variable. Many of the same barriers described above are being encountered. Government-driven HIE programmes are frequently overambitious in scope and time frame, and unclear with respect to the tangible economic value that can be achieved in the first two or three years of implementation. In responding to top-down political imperatives, these HIE programmes tended to neglect the needs of the local organisations and clinicians. These programs did also not take into account the need to maintain and integrate with existing applications and failed to minimise concerns of privacy and data ownership. Most progress to date has occurred in smaller jurisdictions e.g. Singapore, where there is less variability in culture or the health system.

Some specific examples of international HIE efforts include:



Clalit, the largest healthcare provider in Israel, operates a HIE that includes two non-Clalit hospitals.

Scotland's national health service (NHS Scotland) has developed an "Emergency Care Summary" that extracts data from electronic medical record (EMR) systems and then makes it available to clinicians in out-of-hours centres.

The government of Sweden is deploying a "National Patient Overview," which collects summary data from acute care and primary care applications and makes it available through a national portal.

Singapore's national electronic health record is an amalgamation of data sources that contribute summary-structured data to a national repository; and physicians have portal-based access to this information.

Denmark; where there has been a long standing programme of regional information sharing.

Australia's Personally Controlled Electronic Health Record programme became operational in 2012, and has now built a critical mass of patient registrations (over 1.5 million). It envisions patients authorising retrieval of information on a case-by-case basis.

The Canada Health Infoway programme is funding and guiding the development of HIE programmes in Canada's provinces and territories.

The European Patient Smart Open Services (epSOS) programme, aims to develop a common transnational approach to a patient summary record and prescription fulfilment. 23 countries have participated in 2012 and 2013, demonstrating technical interoperability. In April 2012, epSOS began a multinational test with participating patients among 72 points of care in 39 cities in Austria, France, Greece, Italy, Sweden, Luxembourg and Spain.

Some U.S. HDO-based and many public-based operators of HIEs are members of Healtheway (healthewayinc.org), a non-profit corporation that has inherited the charter previously known as the Nationwide Health Information Network (NwHIN). This organisation maintains the Data Use and Reciprocal Support Agreement (DURSA), which describes the obligations of member organisations regarding trust and services. It also selects and adopts standards and specifications, mostly based on HIEs. Healtheway standards are currently limited to queries. It has no agreements or protocols to push data. Most vendors in the U.S. that offer HIE technology also offer Health Information Service Provider (HISP) technology to support pushing health data by direct messaging. However, HIE products generally include patient identity matching and patient data lookup with analytic capabilities that are not part of direct messaging.

To date, the ability to achieve semantic interoperability through HIEs has been limited, and has depended on the HIE implementing mappings that enable the major data sources (such as hospitals and labs), to send data without having to conform to uniform standards for messages and code sets. National and international efforts continue to work to overcome the challenges of interoperability, record linking, insufficient infrastructures, governance, and interorganisational relationships; and have created architectural strategies, oversight agencies, and incentives to foster exchange.



Market Definition

Globally, health information exchange (HIE), the process of electronically moving patient-level information between different organisations, is viewed as a solution to the fragmentation of data in healthcare. Gartner defines "HIE" as the "exchange of clinical information among independent healthcare organisations" (see “Avoid the Pitfalls of HIE Selection by Using New Market Definitions”). Often, patient-specific clinical and other data is shared as well but transaction networks that specialize in clearing claims, payment advice, and other administrative transactions are not included in the HIE category. The HIE technology market, therefore, includes software and technological services offered to create and operate an HIE. Gartner does not include systems integrators and other providers of professional services for implementing HIEs except to the extent that these services are available through the vendors of technology incidental to its implementation. Buyers in this market are often or most commonly individual HDOs that will use the technology internally to interconnect organisational units or clinical systems.

As Gartner discusses in "Global Definitions of EHR, PHR, E-Prescribing and Other Terms for Healthcare Providers," there often is not a single term that is used universally across countries for various systems and services and this is the case here. Fully functioning HIE is not yet a common phenomenon worldwide. Some use variants of electronic health records (EHRs) that imply information exchange or assembly of a record from disparate providers, while other countries use "EHR" to mean an institutional record and decision support system. We have settled on "HIE" because it is self-explanatory and not used to mean something different in any country we have discovered. We also prefer this term because it does not imply that a country or region would replace individual organisational systems with a truly unitary record but instead information is exchanged among organisations' record systems.

We define the participants in an HIE as being the organisations that, by prearrangement, exchange data through the HIE. This prearrangement generally involves a legal agreement designed that among other things provides assurance that the recipient of clinical information will protect the privacy of the patient (as required by law). We define the users of HIEs as the people that create or consume information through the HIE. These people are usually members of the workforce but increasingly software products also allow access by patients themselves.

Market Direction

In recent years there has been a drive in Europe, Canada, Asia Pacific and the United States (U.S.) towards an integrated electronic healthcare record (EHR) at the care provider level as well as toward health information exchanges (HIEs) which facilitate the electronic exchange of patient information between care providers at a provincial, state, regional or national level. HIE efforts in Australia, Canada, Israel, New Zealand, and dozens of European nations rely, or are planning to rely, on unique national identifiers. National and international efforts are focused on trying to overcome the challenges of interoperability, record linking, insufficient infrastructures, governance, and inter-organisational relationships, but have already created architectural strategies, oversight agencies, and incentives to foster exchange.



HIEs require collaboration and trust between 2 or more entities. This includes the users, the technologies and the vendors. HIEs must also have trusted relationships (forms of trust include: DURSA – Data Use and Reciprocal Support Agreement; MPA – Membership Participation Agreement; Electronic Certificates or NDA – Non-Disclosure Agreement). A HIE is placed in 3 different categories (from an interoperability perspective): Send, Discover, Collaborate. HIEs must be able to:

Send - systematic push in real time to notify regarding important information. Responds from an electronic order to deliver results from one EHR system to another (for example, CCD, radiology results, lab results, documents, etc.); deliver immunizations from EHR System to immunization registry; and deliver notifications of a patient registering in a hospital to a primary care physician.

Discover - information pulled from the community at the point of care. Perform multiple queries, for example, on demand query, query for CDA from EHR system to EHR system and leverage standards (such as NwHIN – eHealth Exchange, XCA – Cross Community Access, XDS.b – Cross Document Sharing, HL7 – Health Level 7).

Collaborate - back and forth exchange of ad hoc communication using DIRECT standards with the ability to attach clinical information to the message, integrated in the clinician’s workflow and also satisfy meaningful use Stage 2 (U.S. only).

Generally buyers in the HIE technology market are looking to accomplish some combination of the following use cases (“Use Cases”):

Sharing patient transactional data - transmitting the results of a single event such as a lab test or encounter, as well as referrals.

Patient summary - sharing a compiled summary of information from single events.

Extended EHR - achieving the functions of a full EHR across entities within an organisation or across organisations with no EHRs (an additional potential vendor offering provided by some HIE vendors).

Personal health record (PHR) - patient facing portal containing data from HIE participants and patient-entered or amended data.

The "extended EHR" use case should not be thought of as creating an amalgam of EHRs that interoperate with the same level of precision and consistency as a single EHR. Instead, it is an attempt to share transactional or patient summary data to support multi-institutional care scenarios. In the U.S., the specific goals within these use cases are often framed in a way that enables the participating organisations to conform to the interoperability requirements of the federal programme that offers incentives for meaningful use of electronic health record systems.

SEND DISCOVER COLLABORATE



Buyers in the HIE technology market should evaluate HIE software and technology providers by the functionality that their software provides in support of the above described use cases.

This functionality (“Functionality”) should include:

Event-based routing - routing information among HIE participants is based on an event rather than an overt request to send information to an identified participant.

Workflow - managing multistep multi-institutional workflows.

Direct routing - the ability to transmit information to a third-party that is not a registered participant of the HIE. In the US this includes the direct protocol.

Patient data lookup/record locater service - mediating request to look up and retrieve data for a patient among participants in the HIE.

Functionally federated data storage - clinical data remains on the servers of the source participants in an HDO and is only retrieved for patient-specific requests.

Centralised clinical data storage - clinical data is accumulated in a centralised data storage network to be available for fast inquiry.

Structured data - the ability to do searches, plot trends or create clinical alerts based on the contents of documents or messages.

Aggregated patient records - amalgamating data about a patient from multiple sources to create a patient summary that can be pushed or pulled, and grouped with other patient records to form populations or cohorts for analysis and action.

Physician-facing portal - having portals that provide the ability to access or create data about a patient used to support practices that do not have a connected EHR system.

Patient-facing portal - having portals that provide the ability to access patient data with the ability to view, download or transmit data. May provide options for patient-entered data, disputing provider-sourced data and controlling the subjects' privacy settings.

Inter-HIE routing - using inter-HIE connectivity, locating, routing and sharing information among HIEs. This is a requirement specific to the U.S. that is accomplished



in two ways: use of the Direct protocol or via the protocols promulgated by Healthewayinc.org, a nonprofit organisation created for this purpose.

Heath data aggregation - health information data mining process where data is searched, gathered and presented in a report-based, summarized format to achieve specific business objectives or processes. The ability to create easy access and interoperability of the data regardless of the source application and provide data availability and interoperability long after the source application is retired.

Person identification - cross-matching both patient and healthcare provider IDs based on demographics.

Enterprise master patient index - links identifiers for the same patient from different organisations and facilities with the aggregation of the complete patient record.

Trust ecosystem - providing a security approach and the requisite operational support.

Transmission - transmitting patient information from a source system to receivers.

Privacy - maintaining and enforcing patient-specific preferences on whether their data should be shared through the HIE.

Continuity of care exchange - provides the generation and exchange of CCD and allows these documents to be shared with other organisations.

Semantic normalisation of data - semantic mapping using normalized vocabulary sets allows for standardised descriptions of laboratory results, problems and allergies. Medication and other clinical content information are reliably grouped to create a complete patient record and consistent data set for regional management.

Flexible architecture - a flexible solution architecture that can be tailored to an organisation’s needs.

Flexible privacy and consent - a flexible, rules-based privacy solution allows access based on multiple criteria, including support for Opt-In, Opt-Out, relationship, location- and age-based privacy, as well as regulations surrounding minors and sexual and mental health.



Market Analysis

United States

The anticipated growth in the health information exchange market in the U.S. is in large part due to a greater sense of certainty around the direction of healthcare reform. Other key factors propelling this market include Stage 2 meaningful use requirements calling for more robust HIE participation among providers as well as stronger technical standards to ensure interoperability. In addition, HIE is essential as care settings expand beyond the traditional boundaries of the doctor's office or hospital in response to growing demand. Most healthcare providers realise that, despite the numerous complexities and challenges associated with the exchange of health data, HIE will continue to accelerate. Some of the major trends and issues include:

Increasing efforts to ensure the ongoing viability of public health information exchange

The conflict between information transparency and privacy

A short-term benefit for private HIEs driven by the move to accountable care

An acceleration in cloud and mobile HIE

Vendors trying to differentiate themselves through innovative value-added HIE services

It has been a common belief that HIEs would support gathering clinical data normalized to a data model that supports analytics. Indeed, many vendors and analysts have expressed the thought that such data would be gathered as a byproduct of transactional exchange effectively serving the business requirement for analytics without requiring a specific investment in extracting clinical data from EHRs. As Gartner has predicted the evolution of both exchange and analytics markets, it has become increasingly clear that EHRs do not yet produce data in a sufficiently standard form to allow such aggregation. Furthermore, special-purpose vendors that offer clinical analytics have developed libraries of EHR-specific extraction and normalisation software and provide the segregation independent of the use cases commonly associated with HIE. Accordingly, we have revised our definitions of the HIE market to exclude data-gathering for analytics. It is not that some vendors don't offer such a capability integral to their product suites; it is just that we do not recommend using general HIE software for this purpose.

Because of the different buying patterns, the HIE technology provider targeting the U.S. largely fall into one of three categories: EHR vendors, payer subsidiaries and independent firms. There are viable vendors in each category. To date, EHR vendors are not players in non-US markets for HIEs. The U.S. continues to have the largest market for HIE in the world. However, the adoption rate of HIE in the U.S. continues to lag behind certain countries, for example, in Scandinavia. Some state HIE networks in the U.S. have inefficiencies that may hinder further market development. Many believe that privately governed HIE networks have proven to be more efficient than public HIEs, and the future of the HIE market may be in private HIEs in the U.S. and around the world.

Canada

Canada's approach to HIE is a network of provincial and regional exchange efforts built on the same architecture and standards. Canada's strategy is technology and vendor neutral. Each jurisdiction maintains a fairly centralised technical architecture that relies on select data extracts from local health care and public health organisations’ information systems. These centrally stored data form the patient's EHR, viewable within the system and in a fully mature implementation searchable across jurisdictions.



Japan

Japan's experiences with HIE includes early grant mechanisms which provided one-time funding for hospital-centric or local physician association-led regional HIE organisations. Most of the efforts haven’t transitioned from grant funding to a sustainable business model, faced technological limitations, and interoperability issues. Japan espouses a local control model, but provides national recommendations, such as a preference for software as a service to minimize costs, use of international exchange standards, and privacy assurances. Importantly, Japan has not mandated HIE for HDOs.

China

The state of HIE in China is still in its early stage and not widely adopted, but regional-based information exchange is a priority. The effort is described as a large hospital-centric system with a centralised data repository and centralised records. While concerns exist over general technological capacity, the primary identified barrier to HIE in China appears to be a lack of interoperability. International standards are not widely adopted; instead HDOs utilize self-developed standards for everything from diagnoses, to demographics, to charges. Lastly, as the country with the world's largest population, HIE in China possess a problem of scale not seen elsewhere.

A majority of the population of Israel is included in a single HIE. This HIE provides access to patient information based on a comprehensive clinical database, virtually instantly created at the time and place of care and dissipated immediately at the end of the transaction. This federated model addressed data ownership concerns and supports patient privacy because the system has no means of locally storing information.

Australia

Australia's approach to HIE includes a history of local effort, a move toward centralised technology policy, and the adoption of a very patient-centric technology. During the last decade, Australia funded several state-level HIE pilot projects under HealthConnect, a national programme in cooperation with states and territories supporting locally driven projects, and other local efforts worked toward HIE. These efforts faced challenges of governance, difficulties in record linkage in the absence of national identifiers, a lack of standards, privacy protections, and workforce needs. The National E-Health Transition Authority (NEHTA) was created by the national, state, and territory governments to provide national e-health coordination and policy. NEHTA is responsible for managing the requirements and standards of the nationwide personally controlled electronic health record (PCEHR) system, which has hit 1.5 million patients registered to use the system. The PCEHR is a repository for health information aggregated from numerous sources where the patient decides who can access the information. Usage of the PCEHR is completely voluntary, but is promoted as a means to exchange information between providers.

New Zealand

New Zealand's national strategic health IT plan calls for the use of four regional central data repositories linked into a national network. Patient data is contributed from local organisation's information systems to populate the centralised data repository with a national set of core clinical information. Providers are able to access patient's virtual health records across the country by common patient identifiers.



Singapore

Singapore is making relatively good progress in the HIE area, particularly within and between publicly funded hospitals, but there are concerns about private providers lacking incentives to invest in healthcare IT and falling behind the public system. Singapore’s National Electronic Healthcare Record (NEHR) is the cornerstone of its connected health strategy, and with the first phase completed in 2011, the Singaporean government is on track to deliver on the vision of one Singaporean health record.

Europe

European nations have been the focus of early evaluations of the benefit of electronically sharing patient-level information between providers, mostly using messaging type systems (for example, Scotland, Sweden and the U.K.). Smart Open Services for European Patients, or epSOS, is a 23 nation, international HIE effort. The main focus of epSOS's first stage is the exchange of a shared patient summary record and e-prescriptions with the purpose of improving patient safety during international travel. The patient record summary includes demographic information, allergies, problem lists, medications, vaccinations, social observations, and recent surgical history. EpSOS does not include direct connections between the health care organisations or providers, but instead is a federated network of national health information networks. After more than 3 years of hard work to develop feasible cross-border eHealth services, the efforts of the epSOS project team have culminated in the large scale pilot entering into operational mode. In this phase, which is active since April 2012, the developed solutions are being tested in a real-life environment (Spain, Greece, Italy, Denmark, Sweden and Luxembourg).

Other European countries with functioning HIEs include Scotland and England. The NHS Scotland HIE is the emergency care summary, which is hosted in a national cloud data center. This record comprises demographic, prescribing data, and allergies for 99% of the Scottish population, approximately 5 million people. It is updated twice daily from the family doctors’ clinical systems, and was initially intended for use in emergency situations where the patient was conscious and could provide consent for access. The English national Spine HIE supports a single unique identifier, provides non-clinical reference information for more than 70 million patients and provides a central repository of summary clinical information (the summary care record). The summary care record contains information about medications, allergies and adverse medication reactions.

Currently, buying patterns vary by region. In the U.S., the time when governmental or quasi-governmental organisations were being chartered for the purpose of operating HIE's has largely passed. At the same time, there is growing emphasis on private HIEs organised to support meaningful use requirements or to support the information exchange required for collaborative, accountable care organisations. On the other hand, in most other countries, buyers of HIE technology tend to be government or quasi-governmental organisations attempting to achieve the fundamental ability to share patient summaries across HDOs.



Representative Vendors

The vendors listed in this Market Guide do not imply an exhaustive list. This section is intended to provide more understanding of the market and its offerings.

EHR and Megasuite Vendors Offering HIE Services

Allscripts, Inc.

Pittsburgh, PA

Offerings: dbMotion Platform Description:

Product has the capability to meet the Use Case and Functionality criteria (see “Market Direction” section)

Manages a comprehensive set of technologies involved in the design of an HIE that includes a presentation layer, patient/provider identification, data aggregation, data integration and exchange, information management, identity access management, privacy and consent management, management of semantic vocabularies and development framework

Strengths:

The acquisition of dbMotion will mean a tighter integration between Sunrise, TouchWorks EHR, and the dbMotion community solution as well as a stronger focus on customers outside the Allscripts base

Strong U.S. and international client base

Strong end user perception for product quality, quality of support and interface delivery Caution:

With strong global growth there is a concern that customers risk losing their skilled employees who have dbMotion experience which may result in healthcare organisations competing for skilled staff

Cerner, Inc.

Kansas City, KS

Offerings: Resonance, Clinical Exchange Platform, Hub and HealthDock Description:

Products have the capability to meet the Use Case and Functionality criteria (see “Market Direction” section)


Strengths:

Well integrated with Millennium

Can be hosted in the cloud




Few international HDOs as clients for HIE products

With strong global growth there is a concern that customers risk losing their skilled employees who have Cerner experience which may result in healthcare organisations competing for skilled staff

Epic

Verona, Wisconsin

Offerings: Care Everywhere, Lucy, MyChart Description:

Products have the capability to meet the Use Case and Functionality criteria (see “Market Direction” section)


Strengths:

Strong end user perception for product quality, quality of support and interface delivery

Patient identity management regardless of local patient identifier using Care Everywhere unique identifier

Patient authorisation requirements tracked by each receiving facility

Care Everywhere network participants agree to standardised governance practices globally creating a single network of all participants

Caution:


With strong global growth there is a concern that customers risk losing their skilled employees who have Epic experience which may result in healthcare organisations competing for skilled staff



InterSystems

Cambridge, Massachusetts

Offerings: HealthShare Description:

Product is a healthcare informatics platform that has the capability to meet the Use Case and Functionality criteria (see “Market Direction” section)


Strengths:

Based on InterSystems Cache database and Ensemble integration technology, a familiar technology widely used by self-hosted Epic users as well as users of other EHR solutions


Strong end user perception for product quality, quality of support, interoperability, and interface delivery

Caution:

Cache technology may be perceived as a culture barrier for many IT shops that are not hosting Epic products, although it works seamlessly with all database and EHR technologies

With strong global growth there is a concern that customers risk losing their skilled employees who have InterSystems experience which may result in healthcare organisations competing for skilled staff

(Note: InterSystems is an EHR and Megasuite vendor, though not in the US)

Quality Systems, Inc. (NextGen)

Costa Mesa, California

Offerings: Mirth HIE Description:


Manages a comprehensive set of technologies involved in the design of an HIE that includes a presentation layer, patient/provider identification, data aggregation, data integration and exchange, information management, identity access management, privacy and consent management and development framework

Strengths:

Mixture of open source and proprietary products has provided a moderate price point

Can be hosted in the cloud Caution:



Tied to the fortunes of QSI, best known for the NextGen EHR and clinical products. QSI is in the process of reinventing itself, going from an EHR vendor to a vendor of collaborative, accountable care products

No international HDOs as clients for HIE products

For existing Mirth customers, product licensing could change over the long term due to its acquisition by QSI

Siemens

Malvern, Pennsylvania

Offerings: MobileMD HIE Description:



Strengths:

Relatively strong end user perception for product quality, quality of support and interface delivery

Delivered as a Software as a Service model Caution:


Independent HIE Vendors

Covisint

Detroit, Michigan

Offerings: Covisint HIE Description:



Strengths:

Covisint has always been a cloud vendor with nearly 15 years’ experience Caution:



Although healthcare is not Covisint’s largest vertical (automotive is), healthcare is nonetheless its second-largest and fastest growing

Newly in the international market for HDOs as clients for HIE products

Some Covisint customers can opt to use Mirth tools (for CDR), so it’s possible they may be impacted by Mirth’s acquisition by QSI

Infor, Inc.

New York, New York

Offerings: Cloverleaf hosted HIE Description:



Strengths:

Only available as a hosted, cloud based service and implemented as a managed service

Existing customers can leverage their existing on-premise Cloverleaf interoperability platform investment and technologies as data on-ramps to Infor Cloverleaf Hosted HIE

Caution:


Informatics Corporation of America

Nashville, Tennessee

Offerings: CareAlign Description:


Manages a complex set of technologies involved in the design of an HIE that includes a presentation layer, patient/provider identification, data aggregation, data integration and exchange, information management, identity access management, and development framework

Strengths:

ICA has coveted ties to Vanderbilt University Medical Centre

Delivers its capabilities by taking a biomedical informatics approach rather than a traditional IT data processing approach, developed by Vanderbilt University Medical Centre

Caution:




McKesson

Atlanta, Georgia

Offerings: RelayHealth HIE Description:



Strengths:

Strong end user perception for product quality, quality of support, patient identity mapping and interface delivery

Caution:


Medicity, a Healthagen Business (Aetna, Inc.)

Salt Lake City, Utah

Offerings: Connect, Notify, Exchange, Organise, and Engage Description:

The Medicity product has the capability to meet the Use Case and Functionality criteria (see “Market Direction” section)


Strengths:

Solutions can be hosted by Medicity or self-hosted; acquired independently or as a suite of solutions

Relatively strong end user perception for product quality, quality of support and interface delivery

The Medicity Network is the largest HIE network in the U.S., and powers 9 state designated entities and 12 regional health information exchanges

Medicity is the first vendor to be recognized as an eHealth Exchange validated system by Healtheway

Caution:

Ownership by a healthcare payer creates some reluctance among HDO buyers, however, more are seeing the advantages of partnering to leverage the insights from years of managing population risk along with the back-end office capabilities to support transitions in payment models




Optum Health

Eden Prairie, Minnesota

Offerings: Optum HIE (Axolotl) Description:


Manages a complex set of technologies involved in the design of an HIE that includes a presentation layer, patient/provider identification, data aggregation, data integration and exchange, information management, identity access management, and development framework

Strengths:

Can be hosted in the cloud Caution:

Ownership by a healthcare payer creates some reluctance among HDO buyers


Orion Health

Auckland, New Zealand

Offerings: Orion Health Healthier Populations Description:


Manages a comprehensive set of technologies involved in the design of an HIE (focus is a population health management open platform) that includes a presentation layer, patient/provider identification, data aggregation, data integration and exchange, information management, identity access management, privacy and consent management, management of semantic vocabularies and development framework

Strengths:



With strong global growth there is a concern that customers risk losing their skilled employees who have Orion experience which may result in healthcare organisations competing for skilled staff



Continuity of Care Record

In the USA, the Continuity of Care Record (CCR) is a standard specification developed jointly by five organisations:

1 ASTM International - one of the largest voluntary standards development organisations in the world - a trusted source for technical standards for materials, products, systems, and services.

2 Massachusetts Medical Society (MMS) - the oldest continuously operating medical society in the United States.

3 Health Information Management and Systems Society (HIMSS) - the healthcare industry's membership organisation exclusively focused on providing leadership for the optimal use of healthcare information technology (IT) and management systems for the betterment of healthcare.

4 American Academy of Family Physicians (AAFP) - one of the largest medical organisations in the United States with a mission to improve the health of patients, families, and communities by serving the needs of its members with professionalism and creativity.

5 American Academy of Pediatrics (AAP) – a non-profit organisation reflected the physician's commitment to children and the specialty of pediatrics.

The CCR was created to foster and improve continuity of patient care, reduce medical errors, and assure a standard of health information transportability when a patient is referred or transferred to another provider. The CCR is being developed and enhanced in response to the need to organise and make transportable a set of basic patient information consisting of the most relevant and timely facts about a patient's condition. The CCR is a proposed standard for exchanging basic patient data between one care provider and another to enable this next provider to have ready access to relevant patient information. The CCR is technology-neutral and vendor-neutral. However, it is offered as an XML platform that can stand alone or can be transformed into the Health Level Seven (HL7) Clinical Document Architecture (CDA). Although the CCR can be used without interfacing to an electronic medical record (EMR) on either the sender or receiver side, a compliant EMR or other clinical information system should be able to both import and export CCR data. The CCR contains the following major data categories:

Document identifying information;

Patient identifying information;

Patient insurance/financial information;

Advance directives;

Patient health status;

Diagnosis, problems and conditions;

Family history;

Social history and health risk factors;

Adverse reactions/alerts;



Current medications and relevant history;

Immunisations;

Vital signs and physiological measurements;

Laboratory results;

Procedures/imaging;

Health status assessments;

Care documentation;

Care plan recommendation.

In the UK, the Summary Care Record (SCR) is the standard interoperable transportable record. The SCR contains the following major data categories:

Document identifying information;

Patient identifying information;

Diagnosis, problems and conditions;

Adverse reactions/alerts;

Current medications and relevant history.

The SCR is designed to give access to healthcare staff to help prevent mistakes being made when receiving treatment in an emergency or when the GP practice is closed. SCR data is held on the National data Spine. Clinicians have reported benefits with:

Increased clinical confidence;

Easier mental healthcare, assessments and treatment;

Better prescribing safety;

Reduced referrals to hospital from out of hours services;

Medication reconciliation;

Reduced admin entering patient information.

SCR facts: 41 million patients informed about the scheme, 1.34% opted out. 21 million records created across 3,031 primary care practices.

Decision Points

However, even under the best-case scenarios, HIE initiatives are organisationally, technically and politically complex, and costly, and take years to complete. Electronic capture and storage of health information always brings forth differing, often very strong, opinions about patients’ rights, providers’ needs, and government intervention and responsibilities. Understanding the risks and issues from similar efforts can help avoid making the same mistakes. Fortunately, comparable efforts do exist. European countries tend to be more advanced than the U.S. in implementing large-scale initiatives, starting more than a decade



ago. In countries such as Denmark, the Netherlands and Norway, EMR adoption by general practitioners (GP) is approaching 100 percent, compared to 20 percent, at most, in the U.S. Denmark, Sweden, Norway and the United Kingdom (UK) have had great success implementing HIE solutions that are already demonstrating positive results. These pioneering efforts provide country-wide success stories of routine data exchanges that are now an integral part of care delivery.

Our first-hand experience in Europe (Denmark, the Netherlands and three regions in the UK) and our U.S. healthcare and technology knowledge have enabled us to identify major decision points, best (exemplary) practices and lessons learned that are transferrable to any project (see table 1). While the size of the European efforts is far smaller than the U.S., they are comparable to U.S. state efforts.



Table 1: Decision Points Summary

TOPIC DECISION POINTS BEST PRACTICES, KEY LESSONS LEARNT

PLANNING & SUSTAINING THE INITIATIVE

SETTING EXPECTATIONS

These are healthcare initiatives, supported by technology

VALUE DEFINITION & MEASUREMENT

Build a value programme into the plan with health-based measures calculated before and after installation

DETERMINING IT REQUIREMENTS

Broad scope for setting requirements, periodic review

FUNDING & SUSTAINABILITY

Those who gain from the value need to be willing to pay the cost

MAJOR ISSUE MANAGEMENT

PRIVACY & SECURITY

Early communication regarding options, role-based access-preferred option with ability to break the glass Data sharing — opt in, opt out, opt in with restrictions, assume opt in

PATIENT IDENTIFICATION

Clean PHI data, unique ID number is the preferred approach

GOVERNANCE AND COMMUNICATION

GOVERNANCE Involve all key stakeholders, centralize decision making whenever possible, seek input

COMMUNICATION Comprehensive strategy executed by governance group, communicate to each constituency using the right method, two-way interactions

TECHNOLOGY AND INTEROPERABILITY

TECHNICAL ARCHITECTURE

Fit to meet healthcare reform programme and policy needs, foundation for the future

STANDARDS & CERTIFICATION

Must-haves

IMPLEMENTATION PLANNING Strong link to policy, continuous planning with process and resources to support changes

IMPLEMENTATION & ROLLOUT

Pilot and roll out incrementally, support continuously



Planning and Sustaining the Initiative

Many HIE efforts failed because there was not a clear, specific business reason for forming the exchange. The availability of grant funding and the overall agreement that the access to accurate and complete patient data improves care created many short-lived HIEs that struggled to answer questions on how to set up governance, what data should be exchanged, who should be included in the HIE and how will the solution be architected and maintained. Without a clear focus and healthcare-directed business case, these important questions could not be answered, leaving these pilots to be no more than planning and/or technology connectivity exercises, which ultimately ended after the initial pilot stage.

Setting Expectations

The first critical decision is to define the healthcare purpose for the initiative, starting with a targeted objective (e.g., improve prescription processing efficiency and patient safety through e-prescribing). This allows the stakeholders to set realistic expectations, define success criteria and measure the value for the investment — all in healthcare-directed terms, not technical ones. In Europe the initiatives started or were primarily driven by the Ministers of Health, with the purpose of improving access, care quality and cost efficiency. In the Netherlands, the aging population with a long life expectancy (82 years for women and 77 for men) is putting demands on the healthcare system to do more with less and to offer extramural care. Information access and sharing, and provider communications were identified as critical to providing more efficient and effective healthcare. To that end, the National IT Institute for Healthcare (NICTIZ), a foundation supported by the Ministry of Health, established a national EHR infrastructure.

Denmark’s goal is to allow patients to get the best care wherever they are so data needs to follow patients, not vice versa. Currently, Denmark’s ehealth programme has implemented more than 50 standard messages for data exchanges related to patient referrals, diagnostic test requisitions, test results, prescriptions, hospital discharge information, homecare data and physician notes, allowing important clinical data to be accessible at the point of care. By leading with the health reform requirements instead of the technology ones, stakeholder and end user expectations are focused first on healthcare, and then on using technology to improve efficiency and access.

Even when the overall goal is clearly in support of health reform, initiatives need to be constantly communicated in healthcare terms. When technology appears to lead the effort, there are likely to be issues with stakeholder and end user buy-in and adoption. This was the case with UK’s National Health Service (NHS) program. The fact that the name of the programme was the National Program for Information Technology (NPfIT) and the CIO was the responsible person at each health trust lead to a perception of an IT-centric project, not care-centric initiative.

Value Definition and Measurement

Success criteria and quantifiable benefits must be part of the overall programme to solidify expectations, measure impact and direct the technical requirements. Broad value statements need to be converted into metrics and measured before and after the programme (and technology) implementation to demonstrate the value in terms that stakeholders understand and that support the goals for health reform. Understanding the effort in healthcare-value terms also directs the implementation since the new applications can be configured to maximize these value measures.



In Europe, comprehensive value measurement was not done. “Before” measures, if they exist at all, were often based on targeted research studies such as avoidable hospital admissions due to medication errors and errors in transferring data between GPs and specialists. Intermittent studies were done by individual medical centers or industry associations and extrapolated for the entire area, and do not deal with the full spectrum of patient, provider and government expectations. Most importantly, they did not address the two most cited reasons for implementing a technology-supported health reform programme: improved provider efficiency and patient outcomes.

Benefits and progress were measured in operational terms (time to process a referral, or book an appointment) and technology installation progress and use terms (e.g., number of EHRs installed and volume of exchange messages sent). This does not mean that outcome and provider efficiency improvements are not there — they had not been studied and measured. The UK is taking the next step and has started policy and strategy reviews to analyze costs and benefits but no results are ready to be released. Without pre-implementation metrics, the post measures will not be able to quantify the total impact of the IT solution and the health programme changes on care delivery. The study results however, will provide valuable information on trends, adoption and care delivery improvements.

Determining IT Requirements

The healthcare reform plan and value expectations direct the technology architecture and are the starting points for documenting IT requirements. IT requirements need to cover the broadest scope possible, from the beginning. Furthermore, a change/innovation process is key, leading to a revision cycle of the IT requirements.

These requirement specifications will need to be detailed enough to identify functions and features and data requirements for each type of end user application, functionality, data storage/data access requirements, connectivity and IT resources and support services that are part of the overarching health exchange solution.

IT requirements need to be regularly reviewed and potentially updated when the implementation timeframe spans several years. In the UK, output-based specifications written in 2002 were still required in 2009 although the practice of care delivery had changed. Outdated requirements become a source of debate which takes time and resources to resolve. For each change, there needs to be a decision about whether it is an enhancement (out of scope of the budget) or necessary change (part of the program’s scope).

Clarity of design and detail specifications is particularly critical when implementations are decentralised and managed by different vendors and software solutions. For example, in the UK, there was overall agreement about the goals, but requirements, scope of delivery and expectations were allowed to be determined at the region level. Separate negotiating teams working with at least 12 different shortlisted suppliers bidding for five contracts, led to inconsistencies and end user confusion on what they were getting. In Denmark, allowing requirements to be defined at the county level resulted in a number of failed health record projects due to lack of agreement on requirements and data sharing standards. They have since changed to a more central requirements model under Connected Digital Health in Denmark.

Funding and Sustainability

Most studies in the U.S. have shown that the payers (and patients) are the beneficiaries of the improvements made (e.g., fewer redundant tests, fewer re-admissions and reduced admissions due to medication errors) but the hospitals and physicians are the ones paying



for the implementation and support of clinical applications. For large-scale initiatives to be sustaining there needs to be a financial balance. Specifically, the stakeholders who gain the value from the initiative must be willing to pay for it. In our experiences in Europe, funding was not an issue. The HIE efforts were government funded, whether the countries supported a government-funded (Denmark and the UK) or private (The Netherlands) healthcare system. In Denmark, the government paid for the infrastructure and central services, and sometimes pays for upgrades to end user applications to meet new regulatory requirements. The UK’s Connecting for Health central programme has budget ownership and contract management responsibilities for the national infrastructure and services and the EHR software. UK Trusts are responsible for their own implementation costs, end user training, hardware and local area networks, but their budgets are government funded. The Netherlands also paid for the core national infrastructure system called the Landelijk Schakelpunt (LSP) or National Switch Point. The Ministry of Health was the driving force behind the initiative. It coordinated and funded the implementation and supports it without charging the providers a transaction fee for use. These efforts all considered government funding essential for building the infrastructure, the central services, adding or replacing core clinical systems, and providing some ongoing financial support.

Major Issue Management

Identifying, prioritising and addressing “show-stopping” road blocks are critical for programme momentum and success, especially those requiring regulatory changes. Special work groups and subcommittees may be needed to research, get input; present alternatives and help the programme leadership and constituents come to consensus on the best option. Although these appear to be one-time decisions, we have found that decisions made by consensus have to be continually reaffirmed as leadership and the environment changes. Two decision points that often raise questions, concerns and lengthy debates are pat ient privacy and security and patient identification. Depending on the circumstances (and country/region), these can be simple or very complex policy decisions with equally simple or complex technology requirements. However, even when the path seems clear, the vocal minority can stall progress if not addressed. No matter the approach taken, poor decisions related to policy, communications, adoption or technology solution requirements can delay or derail the project prior to implementation and can have significant consequences for patients, providers and the long-term viability of the initiative after implementation.

Privacy and Security

Privacy and security involves both authorised and unauthorised access to shared data. Authorised access allows authenticated end users to view some or all of the patient’s information, typically based on their role or relationship with the patient. Organisations such as the Patient Privacy Rights advocacy group and HealthDataRights.org have worked to raise public awareness about the rights already protected under U.S. HIPAA rules and also direct debate towards increasing patient access and control over their own health data. Their belief is that patients should have the right to decide who can see and use patient cl inical data and who cannot. Based on our experiences in Europe, their authorised access policies, procedures and associated system requirements are aligned with many of the requirements cited above. Best practices for authorizing access to shared patient data includes role-based and legitimate relationship-based authentication. A frequently used practice for obtaining patient consent for shared data is to automatically include them and have them inform the programme if they want to Opt Out or Opt In with restrictions. A full audit trail to record access and updates needs to be provided, and made accessible for patients.



Getting input and communicating the data capture and collection, and patient consent options for shared data with sufficient time for discussion are crucial for gaining patient adoption. In the UK, the issue of informed consent was addressed by giving patients plenty of advanced notice and allowing them to opt out of the system. In this case, less than 1 percent (0.78 percent) of patients did. Conversely, in the Netherlands, informed consent was not addressed until much of the system was built and was ready for rollout. The decision was made to send everyone a letter asking for permission. Citizens were taken by surprise by the consent letter they received in the mail and consequently 300,000 people sent letters back with incomplete or inaccurate information. Every letter needed to be followed up with to get an answer, resulting in a lengthy delay in rolling out the system. The above procedures and system restrictions address authorised access requirements and help to minimize unauthorised access. Best practices to minimize unauthorised access includes two level end user authentication, hosting the applications and data servers in a secure, 24 by 7 monitored data center, and using architectures that do not store data locally. For hosting data centers, facilities need to develop a well-documented security plan with clear policies and procedures that include an aggressive security awareness programme and compliance monitoring. Data on the servers should be encrypted and servers frequently need to be physically located in the country or state. In addition to monitoring user access, there needs to be a print monitoring service to track printed reports — who is requesting them and what is printed.

Patient Identification

Patients and their clinical data across different care settings can by linked by one of two methods. The first is a unique healthcare number that is used consistently by the patient and care provider. If that is not an option, the second method is to match patient information from different systems by comparing personal data such as name, date of birth, gender and address, and using a record locator service application (RLS) that includes a matching algorithm which assigns a probability to the match. The higher the probability, the more likely the information is for the same person. The matching algorithm software can be fine-tuned based on geographic location, population mix and other user-defined criteria. In the U.S. there are different schools of thought regarding the matching algorithm sophistication and the data elements involved, but most everyone agrees that patient identification will be based on standardised methodologies, but without a mandated national unique health identifier. A unique healthcare number that is actively managed by all participating systems is preferable. Even when using a unique identification scheme there can be issues such as authorised use for healthcare and data quality:

UK: a unique NHS patient number is available but not always used. Eighty (80) percent of the patient records that were converted to the new, updated applications had multiple IDs including hospital medical record numbers. Hospitals were responsible for making sure the identifier and patient data were accurate and complete prior to conversion to the new IT systems, which took time and valuable resources.

Netherlands: every citizen had a Citizen Service Number that is used for several purposes, but not authorised as a healthcare identifier. A new bill, required in order to allow this change, took three years to pass; about two years longer than expected.

Denmark: there were no issues with the identifier since it is assigned by the hospital when a baby is born and used for a variety of purposes, including his/her healthcare identifier.



Regardless of the patient identification method used, best practice is to cleanse the patient identification data and consolidate records within a care facility or region first, institute policies to prevent duplicates before implementation, and maintain this practice so duplicates are not introduced.

Governance and Communications

There is a strong interdependency between decisions made regarding governance and communication. Governing bodies need to involve key stakeholders and solicit input from end users, and communicate constantly on progress. Setting up a strong governance structure is crucial for planning but needs to stay strong and involved throughout the implementation. Governing bodies need to include all major stakeholders and should be centralised whenever possible to speed decision making and progress, especially during the planning and requirements phases. The group also maintains control over scope, budget and timelines. A formal process and a central sub-group needs to be established and charged with the responsibility of addressing issues and unexpected changes to determine their impact to the initiative’s technology, implementation roadmap and use in care delivery, and whether it is in or out of scope. Without a process and resources in place, unplanned changes create tension among the stakeholders, are a source of debate and ultimately stall progress.

Governance can be decentralised, and/or multi-tiered, depending on the size and scope of the initiative. If so, issue management and decisions should be discussed at the highest appropriate level (e.g., national, state, county, region) and communicated to interested parties and end users to be clear about decision-making authority and process at each level. In Denmark, patient data access decisions made at the region level can override the national requirements only in selected areas. For instance, in one region, the nurse can see all patient encounters, as opposed to the national standard of viewing only the inpatient encounter. In the UK, data sharing agreements among facilities are made at the Trust level. The individual care entities agree on what data are appropriate to be shared for specific types of medical problems. Specifically, a cancer patient may receive care at an outpatient clinic, hospital, specialty cancer center and hospice. All facilities must agree on the data each will share and then document and approve the agreement before implementation starts.

The problem with decentralised governance occurs when decision making is by consensus only and there are many constituents. In 2006 when the UK’s Connecting for Health devolved from region to local providers (to 300 individual trusts), all participants felt they could say “no,” which significantly slowed progress of both EHR and inpatient system implementations.

Communications

A comprehensive communication strategy should be part of the program’s overall plan and the responsibility of the governing body to execute the strategy. Each stakeholder and the end users need to receive communication using methods that meet their needs. The information should be balanced including good news, such as implementation successes and setbacks, such as budget issues and delays. Communications needs to be two ways which will be a balancing act. Appropriate consultation is needed to gain buy-in, but too much discussion can stall progress. However, spending the time in the planning stages is particularly important to gain buy-in in order to eliminate the fear and criticism that the technology is being forced onto the end users without their consent and understanding.



The UK’s Connecting for Health set up its communication channels through a number of structured boards (e.g., architecture, governance, infrastructure and development planning). The boards have regularly scheduled meetings that include vendor representatives, who in turn disseminate information to the regions. Unfortunately this strategy does not include direct communication with patients and physicians who are critical of the process and feel unprepared for the upcoming technology and process changes. To close this communicat ion gap at the local level, we found that setting up user groups to involve them in the EHR design, testing, education, local configuration and workflow integration helps for a smooth implementation and improves adoption.

Technology and Interoperability

Determining what functionality and data will be shared and/or centralised (from the planning stage) is important to the overall technical architecture and drives the requirements for application certification, data and network interoperability standards. In addition, the technology design must be able to support all policy, government reporting, privacy and security requirements.

Technical Architecture

In very simplified terms, the technology architecture is based on what data will be stored centrally, what applications and technical services will be centrally provided, the level of interoperability of the end user systems and how all the applications connect (e.g., the infrastructure network and services). Major components of the architecture, therefore, include data messaging services, locator application, secure network infrastructure (private or Internet-based), connectivity services to the end user applications, and potentially a central patient data repository containing summary or encounter data, a patient portal with view and/or update capabilities, and a de-identified data warehouse for public health and research purposes. There is no one best practice for the technology architecture because of the differences in the healthcare systems and country administrations.

However, in large and federal countries, slim infrastructures and public health applications tend to be on the federal level, whereas the majority of the value-adding applications tend to be set up in regions/states or even by stakeholders, where the care process happens. Factors that will impact the final design of the architecture include regulatory requirements, policy decisions, data ownership and sharing requirements, the population’s culture, and most importantly, supporting the needs of the health reform programme.

Standards and Certification

Data and infrastructure standards and application certification, along with central managing organisations are unconditional requirements for success for large-scale initiative interoperability. The Netherlands has established a certification system for EHRs and connection-service providers. Certification is based on three types of requirements: functional (how to register and exchange information), implementation (how to connect and secure the system) and utilization (procedural measures to keep information accurate, timely and secure). They use HL7 Version 3.0 message specifications for data sharing between the health information systems and the National Switch Point.

MedCom, a national public project organisation in Denmark dictates the standards for the National Data Network. Interoperability standards include an open EDI-mail to ensure compatibility with existing VANS-based communications and IP-based networks. EDI communication (XML, EDIFACT, HTML, HL7 and DICOM) is in wide use. Application certification is also a requirement. There are 15 GP systems and a similar number for hospital systems. Standards need to be defined to the version



level too. The UK has similar standards for certification, data coding, messaging and interoperability but had problems with sharing data when different versions of their READ coding scheme were allowed. Version 3 has much more specificity than Version 2. So Version 3 can be mapped to Version 2 but not vice versa. This was a problem when patients changed GPs and their data (coded in Version 2) could not be exported to the new GP’s system if it was using Version 3.29.

Implementation

Implementations take years, involving many resources, and are never problem-free. Implementation planning starts in the early phases of programme development and is ongoing to adjust for necessary changes and unexpected delays.

Planning

Pioneering organisations recommend planning with a strong link to health policy and the health reform plan. Efforts should follow an incremental approach based on building a solid foundation and growing the solution by starting with the highest priority needs of the health reform programme. Although IT requirements development starts with the highest level centralised applications and services in mind, building the solution starts from the foundation up. Core systems at the end user facilities and the connecting infrastructure and services must be in place before centralised applications can be put into production. Since Denmark’s GPs and hospitals already had applications in place, initial efforts were in building the network infrastructure and developing the messaging services and the central databases. The Netherlands had a similar technology starting point since most of the GPs have been using computers for more than 20 years, focusing their efforts on building the national network and the national switch record locator application. With the issue regarding the use of the citizen number for healthcare purposes resolved, connecting the GP systems to the central infrastructure is underway. NHS emphasis had been on implementing the Spine (infrastructure) and installing/upgrading GP systems to meet national requirements and adhere to regionally approved systems. Now the focus is on inpatient systems implementation and populating the summary care record.

All implementations have problems and changes, but few have time and resources built into the plan for analysis and resolution. Improvements in technology, changes in care practice, missing requirements and policy changes are examples of unexpected issues that need to be explored and addressed. For example, in the UK, a wait time goal for “referral to service less than 18 weeks” was decided upon by the NHS during the implementation rollout but there was nothing in the plan to make the system and reporting changes. Since the contracts required the vendors to meet all regulatory requirements, these changes had to be completed within the original budget and timeline.

Implementation Rollout and Support

Pilot first then roll out incrementally is the mantra for large-scale implementations — for several reasons. The technology, especially the infrastructure and central applications, is new. There will be system errors and missing functionality so starting small with a core group of sites willing to invest the time and resources to work through the bugs will prevent major problems as the systems are rolled out. In the Netherlands, the team started with a technical pilot to make sure all of the new technology worked properly before starting the end user pilots. Rollout is underway with more than 1,500 sites connected to the national network. Another important consideration is the impact the technology will have on the end user processes. In physician practices, piloting helps to fine-tune the new or updated application and allows the implementation support team to tailor the training programme to match workflow processes. For hospital system installs that involve large number of people and different IT applications, taking an incremental approach is even more important because software and performance problems can result in loss in revenue and lengthy delays. The NHS’ Early Adopter



programme for hospital installs took the pilot and rollout approach to the next level. In this programme, the team worked closely with a small number of customers (including each type of hospital — e.g., rural, urban, academic medical center) to adapt the system so it would fit for the remaining ones. The install in each early adopter hospital followed a rollout approach: a small number of users were added department by department to make sure performance and interface issues were addressed. The result was applications configured to meet specific hospital needs that met integration and performance requirements. Support for the implemented applications, infrastructure and HIE services must be immediate and easy for end users, with limited downtime. Best practices for support include a central Help Desk to triage all calls, controlled downtime and local expertise to address questions and problems. Healthcare is a 24 hour a day, 7 day a week operation so systems must have high availability and performance. When upgrades and application fixes are implemented that require downtime they must be done during non-peak hours (e.g., 2:00 am on weekends) to minimize disruptions. End user questions and problems need immediate attention. In the UK, we found that super-users at each medical practice and in the hospitals can address 80 to 90 percent of questions and problems. When external assistance is needed, users call one number and the Help Desk analyst triages the problem and is the one responsible for contacting the right service group, either locally or nationally.

Lessons Learnt

The global lessons learned are organised into six categories:

Within these areas, a set of summary statements of the lesson learned is provided. Each summary statement is designed to identify key success factors.

Stakeholder Engagement

There were several lessons learned that highlight the importance of stakeholder engagement in HIE development. The examples provided in this section illustrate the challenges and opportunities in advancing HIE in the face of local stakeholders ’ concerns, which can include privacy and security of personal health information, the possible loss of competitive advantage, lack of empirical evidence of clinical benefits and value of investing in the HIE effort; these have been reported as barriers to HIE elsewhere as well. The following lessons learned on stakeholders highlight some strategies for overcoming these concerns early in the development of HIE.

Engage a broad range of stakeholders. Recruit an advisory group of diverse stakeholders from the State or region, including consumers, physician practices, hospitals, health systems, insurers, health plans, laboratories, pharmacies, employers, public health agencies, long-term care facilities, and local government agencies. Others highlighted the value of engaging safety-net and ambulatory providers on any advisory group. By engaging a diverse set of stakeholders as advisors, there was a balanced set of perspectives and could develop greater investment within communities. Word-of-mouth and positive peer pressure were also viewed as effective strategies for encouraging participation within stakeholder groups in HIE activities; when individuals or organisations knew that their peers were participating, they were more likely to join.

STAKEHOLDER ENGAGEMENT

GOVERNANCE FINANCE TECHNICAL

INFRASTRUCTURE BUSINESS AND

TECHNICAL OPERATIONS LEGAL/POLICY



Provide a convincing argument as to why potential stakeholders should invest time and money. Organisations were more successful in engaging stakeholders when they could articulate the value proposition for HIE for different stakeholders early in the development process. To understand what outcomes stakeholders would consider worth their investment in HIE, some of the organisations conducted stakeholder focus groups. From the focus groups, for example, organisations learned the high value to various stakeholders of exchanging laboratory results. In investigating the value of HIE for nationwide laboratories, one organisation found that these nationwide laboratories are more likely to participate if the HIE becomes the official delivery mechanism for a laboratory or report of record. The report of record is a service-level agreement where a vendor meets certain requirements to be an official delivery mechanism for a laboratory. The value proposition for hospitals was reported as the impact of HIE on hospital admissions, emergency lengths of stay, duplicative laboratories, emergency efficiency, and clinical outcomes.

Understand the requirements of community consensus. The process of convening stakeholders and building consensus takes a considerable amount of time. Many organisations found that broad community input and consensus take at least 1 year. In Rhode Island, engaging stakeholders in a consensus-driven process was a fundamental guiding principle that resulted in an 18-month process to reach consensus on the authorisation policy and technical model for the HIE system. Additional confidentiality protections for the envisioned system were sought through the legislative process and were enacted into law as the Rhode Island Health Information Exchange Act of 2008. Although the consensus process used in Rhode Island may have been more in depth than the process other organisations used, it demonstrates the time and effort required to achieve consensus across a broad range of clinical, technical, administrative, and consumer stakeholders. In addition, organisations found that they needed to guide the consensus-making process among and also within stakeholder organisations. Guiding the consensus process requires strong leadership, a clear vision, and substantial in-kind and financial support. Given the need for buy-in from a large number of organisations and individuals, appropriate time and resources must be directed toward consensus-building processes.

Foster ongoing dialogue among stakeholders. Ongoing dialogue among stakeholders facilitated the development of trusting relationships, which proved necessary for drafting, gaining consensus about, and signing of master data-sharing documents and other legal agreements. Organisations were more successful when they addressed any real or perceived competing organisational interests among stakeholders involved in governance. For example, one organisation observed a conflict between their stakeholders’ own sense of what is best from a competitive perspective and what may be best for increasing the overall quality of patient care in the community. Organisations also needed to resolve competing demands from funders and other stakeholders.

Governance

This section outlines some of the global lessons learned about setting up a governance structure, including activities such as establishing a board of directors and advisory group, and creating committees where stakeholders may volunteer their time to provide input on key issues.

Realise that a board of directors is vital to a good governance structure. A board of directors generally sets strategy, secures funding, and provides oversight. The organisations board should have a strong sense of ownership early on. Organisations found that the following factors are important for establishing a successful board: balanced stakeholder representation, a sufficient number of board members that does not impede the organisation’s ability to reach



consensus, senior leadership with necessary skills and experience to execute the goals of the HIO, and flexibility in board composition and the roles of its members over time.

Establish an advisory board or advisory committees in addition to a board of directors. Because the board of directors is limited in size and probably will not address the needs and issues of all stakeholders, establishing one or more formal advisory group(s) is recommended to represent the employers, payers, and health care community to the board of directors. For example, establish consumer advisory committees to provide expertise, insight, and policy direction; as a side benefit, these members also served as champions for HIE in their respective communities. In addition, establish similar groups to address legal, policy, technical, and provider issues. The structure of advisory groups will vary depending on the scope of the HIE and whether it is a State or a regional/local initiative. Advisory boards or committees are useful in broadening stakeholder representation and can also cultivate future members.

Engage volunteers in development. The in-kind contributions of the community participants on these advisory groups are necessary, and organisations should effectively leverage their expertise. Nevertheless, based on their experience, organisations warned against overextending these volunteers. In addition, overreliance on volunteers may signal that the business plan needs to be revisited. Volunteers’ time and experience can be maximized by providing a clear scope of work for volunteers and defining expectations for outcomes or deliverables.

Allow governance structures to evolve over time. As funding sources and organisational priorities change, governance structures may be updated. For example, governance structures can transition to include more clinical and consumer representation.

Finance

Organisations reported lessons learned in determining how to best finance HIE activities. These include developing a business plan, identifying potential funding sources, and planning for long-term financial viability.

Have a sound business plan. Organisations emphasised the importance of having a sound business plan at the outset of the project. The business plan should carefully delineate the level of funding needed for establishing and maintaining operations, and the sources for those funds. Federal funding, other initial financial support, and other revenue sources (e.g., membership fees, transaction fees, and programme and service fees) should be included in the business plan. Grant funding should not be considered a long-term solution, although it can be very helpful in launching the initiative. The business plan should also incorporate a plan for long-term sustainability. Organisations found that their business and sustainability plans needed updating throughout their contract term.

A working business plan will satisfy the following expectations:

Completeness - does the plan contain all key elements (resources, lines of authority, etc.)?

Level of detail - is a sufficient level of detail provided—that is, is the plan actionable?

General feasibility - is the articulated approach viable? What are additional items for consideration?

Substance - what were the primary methods used to determine the path to sustainability? Does the plan include tools for measuring sustainability (e.g., return on investment, cost analysis)?



Secure funding early in the planning process. Funding is needed for all of the activities. These include costs to purchase and maintain hardware and software, convene stakeholders, set up the governance structure, establish committees and workgroups, develop legal documents and agreements, identify and prioritise transactions to be supported, conduct inventories of data sources, and procure the appropriate technical and professional resources to design and deploy an exchange. To raise the necessary initial and ongoing funds, organisations engaged a variety of public and private sources, including Federal and State funding sources, private foundations, and health care stakeholders.

Keep participation costs low. Organisations and individuals - either data providers or receivers - are more likely to join an HIE effort if the costs of participation are low. Organisations identified a number of strategies to lower costs of participation. For example, accepting data in whatever format the participant provides (creating a low barrier to participation) and then converting the data to the HIE’s messaging and content standards. As another example, providing incentives for participation (e.g., value-added products/services) also works. Lowering costs to participants by developing an interface that is flexible and requires a minimum Health Level 7 (HL7) interface feed and by establishing a low-cost contract with its EMR vendors has also seen success.

Set long-term expectations with HIE beneficiaries to assume financial responsibility.

Organisations found that it was a challenge to encourage organisations and individuals to contribute toward covering the costs of HIE, but in general they set payment rates in proportion to the extent to which various parties benefit from HIE. For example, some organisations raised revenue by charging stakeholders and providers based on their volume of transactions. Others imposed a per-member-per-month fee on health plans and a subscription fee for certain value-added services (e.g., quality reporting and hosting). These mechanisms are examples of how beneficiaries of the HIE system may assume some responsibility for financing the system over time.

Technical Infrastructure

This section describes the lessons learned about the technical infrastructure of HIE systems, including system architecture, services, and data and exchange standards.

Know that each of the three main models for HIE technical architecture has advantages and disadvantages. HIE systems can be classified into one of three types of architectures: centralised, federated (decentralised), and hybrid. Table 2 describes these architectures.

Diagram 2. HIE system architectures



The hybrid model is the most common. In most cases, each data sender has its own data store, which is federated but often centrally managed. Furthermore, a number of organisations report having a central MPI or record locator service (RLS). An MPI is a common medical record number or algorithm that identifies patients across several institutions. An RLS provides authorised users of a regional health information network with pointers to the location of patient health information across the network nodes, i.e. the clinical data sources to enable users to access and integrate patient healthcare information from the distributed sources without national patient identifiers or centralised databases. Although a centralised architecture for an HIE system has some benefits, including reliability and time efficiency of retrieving information from one source, there are some concerns about the security and privacy risks related to storing data in a single centralised repository. Organisations found that by adopting a federated/hybrid architecture, they achieved benefits such as allowing participating provider organisations to maintain control over patient data, and avoiding any concern over the comingling of data across different provider organisations.

Provide services that quickly demonstrate to participants the value of the HIE system. Core services commonly supported by organisations include the provision of laboratory results, radiology results, dictation/transcription data, medication lists, and administrative data (e.g., dates of inpatient, outpatient, or emergency visits) to participating providers. Many organisations have used an incremental approach to making HIE services available. Currently, some organisations are also investigating the feasibility of providing other value-added services, including comprehensive medication histories, patient portals, quality reporting, and medication reconciliation, to increase value for participants.

Use existing and emerging standards and an extensible, scalable platform. Organisations recommend using standards for—common messaging and syntax for exchanging information

to facilitate the exchange of health information. Typical standards include HL7 2.x for messaging; LOINC and SNOMED for laboratories; CPT, ICD-9, and ANSI X12 for administrative transactions; and NCPDP for pharmacy data. As organisations discovered, even though numerous standards are available for data transmission and content, few exchange participants were able to send standardised information. The lesson learned is that 100 percent mapping to standards is not required to have useful information available to users.

Centralised

Patient data is collected and stored in a centralised repository, data warehouse, or other database, with the

organisation having full control over the data and the ability to authenticate,

authorise, and record transactions among

participants.

Federated

(decentralised)

Interconnected independent databases allowing for data

sharing and exchange, while granting users access

to the information; only when needed.

Hybrid

This architectures incorporates variations of

the federated and centralised architecture models to harness the advantages of both.



Understand that there are issues associated with mapping current standards. A number of organisations reported that using LOINC mapping to exchange laboratory results has been laborious and that prioritising the mapping effort can help reduce this barrier to exchange. Furthermore, point-of-care devices are increasingly being used in clinical settings where routine tests (e.g., simple blood chemistries) are done. Many of these results are not LOINC coded, which presents challenges for creating a comprehensive medical record.

Realise that patient identification and matching can be a core challenge for HIE. As an HIE system grows to include more patient records, optimising patient matching and record location becomes increasingly important. Organisations tested various methods for patient identity management and record location. Most utilized an MPI for patient identification; they found that, in order to develop an accurate community MPI, their exchange partners had to clean up their local MPIs before loading records into the community MPI. Algorithms tuned to match patient demographics were used to link records from disparate organisations. Once an MPI was in place, organisations differed in the approach they took to patient matching. Organisations selected a deterministic, probabilistic, or hybrid matching method. In choosing a matching approach, organisations had to balance the rate of false positives (records that appear to match when they do not) and false negatives (records that do not appear to match when they should) and the implications for their users. A high rate of false positives can reduce trust in the system, while a high rate of false negatives may deter users from using the system if it means they frequently cannot locate information. As users gain familiarity with and develop trust in the system, the approach to matching may change. Many organisations reported that they had to work extensively with their exchange partners to agree on a minimum set of identifiers for patient matching. In addition, the process of fine-tuning the patient matching algorithms and setting thresholds for patient matching that would be acceptable to the community is intensive in time and resources, involving the organisations’ vendors or their in-house technical staff.

Know the advantages of buying vs. building HIE software. Organisations stated that, although building their own HIE software products takes a considerable amount of time, effort, skilled resources, and expense, these products can be customised to their needs. Readymade HIE software products, however, have recently become more widely available and have the advantage of being installed and implemented relatively quickly. Several organisations selected commercial off-the-shelf products that they customised to meet their local needs. This customisation process can increase the costs of ongoing maintenance.

Develop a relationship with an HIE system vendor: it is crucial to operations and management. Organisations that outsourced their technology operations to a vendor were highly dependent on their vendor to complete the major functions, such as hardware, software, interface creation and maintenance, and data center. These organisations agree that when selecting a vendor, it is important to seek both a high-quality software product and a team that will be responsive to organisations’ needs.

Realise that technical development is influenced by policy and operational considerations. Several steps in HIE system development took more time than organisations anticipated, delaying technical development in some cases. The timeline for developing the technical solutions for HIE can be affected by the process of developing policies with considerable stakeholder input, establishing data-sharing agreements, negotiating liability insurance, resolving technical issues involving programming, and differences in readiness of user sites to go live.



Business and Technical Operations

The business and technical operations of an HIO are broad and varied. For example, the SRDs were tasked with addressing the organisational needs of an HIO (e.g., staffing and meeting business goals), managing the actual use of the HIE by stakeholders, and evaluating the impact of the HIO’s activities.

Recruit a large user base. Organisations emphasised the need to consider a wide range and large number of organisations as potential participants. A critical mass of data sources and user base must be achieved to obtain buy-in. If there is not enough information in the HIE system, users will not participate because doing so offers only marginal benefits. For example, organisations noted the importance of recruiting as many ambulatory care practitioners as possible, simply because the majority of care was delivered in an ambulatory setting. Other key partners include hospitals, laboratories, and other entities that can provide data that can be used to populate the system. Large self-funded employers are often highly desired partners because of the large potential user base that they bring (i.e., health care plans and affiliated providers that serve their employees). Similarly, self-funded employers have a lot to gain in terms of efficiency because they bear all of their employees’ healthcare costs.

Use creative marketing and recruiting strategies. Along with lowering costs of participation and addressing perceived barriers to participation, organisations found creative ways to recruit participants to the HIEs. They marketed areas of potential benefits to payers and employers (e.g., disease management, obesity reduction, improved management of workers’ compensation claims). Organisations found that hospitals, laboratories, and other data sources were more likely to participate in the HIE when their own physicians requested it. Organisations noted that all participants should have a strong desire to take part in HIE, have resources to dedicate, and maintain a sense of project ownership and commitment.

Demonstrate quick wins. Organisations sought ways to demonstrate quick wins as an important strategy for building momentum and gaining a critical mass of participants. This frequently involved identifying key areas where they could easily provide participants with valuable information.

Identify clinical settings that are expected to have high and rapid impact. Selecting settings and scenarios in which HIE can increase value for providers supports successful recruitment of new HIE participants. Rhode Island (RI), for example, chose four target use cases as initial areas to explore for potential evaluation: adult chest pain unit, management of newborn risk for Group B strep and hepatitis B, pediatric emergency care for fever, and care transitions for nursing home patients. Results derived from this exploratory study revealed challenges in evaluating some use cases (e.g., adult chest pain) while confirming the value proposition of the specific features and implementation timing of the RI HIE system for others (e.g., long-term care). This process of identifying use cases in which HIE could have a positive impact helped to shape some of the strategy for focusing HIE development.

Reduce barriers to participation. Organisations use multiple strategies to reduce the real and perceived barriers to participation. A number of organisations also worked to identify how workflows would be impacted and to ensure that participating organisations were well versed on the impact to providers. Organisations also found it necessary to foster and develop confidence in privacy and security measures and develop appropriate policies and technologies to ensure that information is appropriately protected. This was often accomplished by educating data senders and users about the processes that would be used to secure patient information. To obtain the buy-in of stakeholders, the system must be built to protect consumers’ health information, while at the same time addressing the perception of risk to participating organisations with liability and



business concerns. Organisations also worked to minimize the burden on data providers, as they found that those who hold data are more willing to share information if they are not required to process it before submitting it. Finally, organisations found that they could develop confidence among users and increase acceptance and adoption by involving stakeholders in user acceptance testing and other testing processes.

Demonstrate the value and function to participants. One of the most effective recruiting strategies was to demonstrate the function and value. Participants who were initially skeptical were more easily convinced once the HIE system was up and running. Although it was often assumed that HIE participants would pay in accordance with the benefits received, many healthcare providers and clinicians were uncomfortable with its pricing model. To address these concerns, organisations developed strategies to educate participants about the HIE’s function and value.

Train providers to prepare them for workflow changes. Organisations emphasised the importance of assessing the changes in workflow that will result when the HIE system is operational. During the planning stage, careful consideration should be given to minimizing workflow disruptions and ensuring that users are well trained and prepared for changes in workflow. Organisations caution that the fit of the HIE system into clinical workflow and the training of users are important for promoting ongoing use of the HIE system. If the system is not intuitive and easily integrated into clinical workflows, providers will not use it.

Expect substantial operating costs. Operating costs including legal and intellectual property, liability insurance, policy development, personnel, overhead and indirect costs, data center and hardware, accreditation and certification, marketing and stakeholder management, database setup and maintenance, software, interface creation and maintenance, and training and help desk costs can be significant, and can even exceed the cost of acquiring the HIE system technology and other startup costs. Making estimates and determining a way to cover these operating costs are necessary for building a sound and sustainable model. Organisations incurred higher operating costs than originally projected.

Assume that the cost benefit derived from HIE will not be realised for several years. The cost savings generated from improved efficiencies and health outcomes should not be expected for the first several years of operation. Also, improved health outcomes from preventive care and treatment of chronic conditions may not lead to reduced costs during the early years. For this reason, organisations should ensure that they have adequate capital to maintain the initiative until the cost benefits begin to accrue.

Set realistic expectations for quality and cost metrics. There are multiple factors to consider including the business, market, and financial aspects, and the potential improvements to the quality and efficiency of healthcare. One of the challenges is that quality improvement may not drive economic sustainability. Organisations also noted that over time, preparing for a large and growing number of users requires considerable planning and management. They continue to determine how to sustain user participation both operationally and financially.

Understand that evaluation of HIE can have multiple goals. Organisations used evaluation to understand who uses the HIE system, why they use it, and how well the system works for them; to understand the impact of HIE on the clinical environment; and to understand whether the HIE system has an impact on quality and efficiency of care. Organisations’ evaluation plans measure both process and outcomes. Organisations’ evaluation tools and materials include a survey of users, review of data reports, interviews with clinical staff and participating institutions, and usability testing. Organisations then used their testing and evaluation results to improve their system, substantiate the value they provide, and support quality improvement efforts.



Develop evaluation metrics and data collection processes that are applicable across the entire continuum of care. Evaluation metrics should be designed to measure the care across settings, including inpatient and outpatient settings. In developing the evaluation design, primary and specialty care provider practices and safety-net clinics should also be included. A full evaluation requires the collection of data across the care continuum. Strategies for collecting data include surveys, focus groups, and key informant interviews.

Incorporate flexibility in evaluation approaches. Evaluation activities will likely evolve over the course of the life cycle. Therefore, the evaluation approach requires flexibility with respect to the timing, planning, resources, and analyses that are conducted. Depending on the scope and type of the evaluation selected, an organisation may need to seek approval from its institutional review board. These processes can be quite lengthy. Another consideration is that the operational rollout plan may or may not support data collection for the evaluation (e.g., if the rollout is done quickly, “pre” data may be difficult to collect for some studies). It was suggested that evaluation activities be integrated into the project as early in the process as possible.

Legal and Policy

The legal and policy issues associated with developing HIE on a State or regional level include setting up the legal structure and the policies that guide the technical development and operations of an HIE system. Just as the technology for electronic HIE evolved differently for each organisation - based on their original goals, types of data, and data-sharing partners - so too did their policies. Organisations found that strong dependencies exist between policy and technology development, and many of the lessons learned described in the following sections emphasise the need to begin policy development early on, in order to reflect community and stakeholder requirements and relevant law and regulations, and to inform technology development.

Realise that laws and regulation can impact policies. Although few regulations are specifically written for an HIE system, laws and regulations can impact the exchange of health information. For example, the rules governing when written patient permission is required for the disclosure of protected health information are set forth in the HIPAA Privacy Rule. For example, a review of state mental health law prompted Rhode Island to adopt a definition of disclosure that requires patient authorisation to be obtained prior to data leaving the original source for transmission to the HIE system; this legal interpretation is a key driver of Rhode Island’s HIE system authorisation policy and the technical solution that supports it. In Delaware, promulgated regulations that give authorisation to laboratories to release all data for patients and providers have been introduced.

Understand stakeholder requirements for policies. Law and regulation may put some boundaries around possible direction for HIE policy development but are not the only factors to consider. For example, organisations found that policies regarding health information exchange that would be permitted under law did not always meet consumers or user’s requirements for how health information should be treated in an exchange. Furthermore, through the process of involving other stakeholders in HIE development, organisations found that the interests and focus of advocacy organisations, individual consumers, and providers (as potential users of an HIE system) can conflict with one another and be difficult to resolve.

Know that options for patient authorisation policy (to disclose/exchange health information for treatment purposes) vary. Patient authorisation (or permission) policies are often positioned along a spectrum that is colloquially referred to as ranging between opt-out and opt-in, and policies usually fall somewhere between the two poles. An opt-out policy, which does not require patient authorisation to disclose or exchange health information, allows patient



health information to be automatically included in the HIE system unless the patient requests otherwise. Under an opt-in policy, a consumer must actively authorize the disclosure of health information through an HIE system. Each model for patient authorisation policy has different implications for technical and business operations, and the model chosen by each of the organisations was largely driven by the organisations’ individual community the stakeholders involved, the legal context, existing business practices, etc. Most organisations adopted an opt-out policy. In Rhode Island, a type of opt-in policy was adopted under which consumers must affirm their intent to participate in the HIE system and explicitly authorise the desired level of access to their health information by providers.

Anticipate that policies and procedures will impact technical and business operations. Organisations advise that comprehensive policies be developed early on in the planning process for HIE, then updated based on the lessons learned during the demonstration period and as HIE matures. For example, Rhode Island’s HIE stakeholders developed a specific patient authorisation policy, which required authorisation from patients to allow PHI to (1) be transmitted to the HIE system and (2) be viewed by treating providers. As a result, additional technology development was required to support a two-stage authorisation process that was not available in an off-the-shelf solution, and Rhode Island worked very closely with its vendor to meet stakeholders’ expectations for policy implementation.

Sequence policy development carefully. Some policies and procedures should be completed during the planning phase for HIE, others prior to go-live, and others can be completed in the post-go-live phase. A number of organisations experienced delays in their go-live dates because critical policies or procedures had not yet been finalized.

Conclusions

Establishing electronic health information exchange is highly complex because it demands advancement in multiple challenging areas in a synchronised manner: engaging stakeholders, establishing governance structure and practices, securing financing, designing the system’s technical infrastructure, making the system operational from a business and technical standpoint, and developing policy. Tough decisions regarding standards, patient consent, architecture and patient identification need to be made. Once these decisions are set, enormous coordinated resources will be required to install/upgrade thousands of EMRs and connect them to regional, state and eventually national information networks. Fortunately the work in Europe and other national efforts continue to grow, expanding both functionality and connectivity reach to provide additional guidance and shared experiences.

Recommended Reading

Some documents may not be available as part of your current Gartner subscription.

Hype Cycle for Healthcare Provider Technologies and Standards, 2013

Avoid the Pitfalls of the HIE Selection by Using New Market Definitions

Acronym Key and Glossary Terms

EMR Electronic medical record

GP General practitioner

SCR Summary care record



Evidence

Chapter 5: Regional Health Information Organisations and Health Information Exchange, Healthcare Information Technology in the United States: Where We Stand, 2008. Robert Wood Johnson Foundation, 2008.

Adler-Milstein J., A. McAfee, D.W. Bates, A.K. Jha. “The State of Regional Health Information Organisations in the U.S.: Current Activities and Sources of Funding.” Health Affairs , 27(1): w60-9.

IT Brings the Danish Health Sector Together. The Danish eHealth portal, http://www.sdsd.dk/~/media/Files/WoHIT/2009/WoHit%2005%2001%2009_2.ashx.

Protti, D. and C. Smit. “The Netherlands: Another European Country Where GP’s Have Been Using EMRs for Over Twenty Years.” Healthcare Information Management & Communications, Volume 30, Number 3, October 2006.

DesRoches, C., et al. “Electronic Health Records in Ambulatory Care — A National Survey of Physicians, Special Article.” The New England Journal of Medicine , 359; 1 July 3, 2008.

eHealth strategies and Implementation in European Countries, European Commission, 2007

Protti, D. and C. Smit. “The Netherlands: Another European Country Where GP’s Have Been Using EMRs for Over Twenty Years,” Healthcare Information Management & Communications, Volume 30, Number 3, October 2006.

Cannaby, S. et al. The Cost Benefit of Electronic Patient Referrals in Denmark, published by ACCA and MedCom in collaboration with the European Commission Information Society Directorate — General, 2004.

Supporting Transformation: National Program for Health IT in the NHS, Benefits Statement 2006/2007. NHS Connecting for Hea lth, www.connectingforhealthnhs.uk.

Schoen, C., et al. “On the Front Lines of Care: Primary Care Doctors’ Office Systems, Experiences, and Views in Seven Countries.” Health Affairs, 2006.25(6): p.555-571.

Protti, D. and C. Smit. “The Netherlands: Another European Country Where GP’s Have Been Using EMRs for Over Twenty Years.” Healthcare Information Management & Communications, Volume 30, Number 3, October 2006.

Linder, C., J. Fortin, and F. Turisco. Information Security and Privacy: A Component of the Hospital Risk Management Programme, CSC 2008.

Text of the Health Information Technology for Economic and Clinical Health Act http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_029033.hcsp?dDocName=bok1_029033.

Canada Infoway (2014). About Infoway. https://www.infoway-inforoute.ca/index.php/about-infoway.

Abraham et al (2011). Transforming healthcare with information technology in Japan: A review of policy, people, and progress, International Journal of Medical Informatics, Vol. 80, pp.157-170.

http://www.connectingforhealthnhs.uk/



Liu et al (2011). Beyond regional health information exchange in china: A practical and industrial-strength approach. Proceedings of the American Medical Informatics Association Symposium, pp.824–833.

Frankel et al (2013). Sustainable health information exchanges: the role of institutional factors, Israel Journal of Health Policy Research, Vol 2, pp.21-32.

Morrison et al (2011). Understanding contrasting approaches to nationwide implementations of electronic health record systems: England, the USA and Australia, Journal of Healthcare Engineering, Vol. 2, pp.25-42.

Schoen et al (2012). A survey of primary care doctors in ten countries shows progress in use of health information technology, less in other areas, Health Affairs.

Accenture (2012). Connected health in Singapore.

Stroetmann et al (2011). Developing national eHealth infrastructures – results and lessons from Europe, Proceedings of the American Medical Informatics Association Symposium, pp. 1347-1354.

advisory note health information exchanges: global lessons...

Documents