There is no one-size-fits-all solution to health information exchange. Under the ONC State HIE Cooperative Agreement Program, states must support or implement HIE within their state. They are required to ensure that all eligible providers within their state have at least one option available to meet the HIE requirements of meaningful use in 2011. Consequently, a high priority for a state's pursuit of HIE is an understanding of the elements to consider before initiating any exchange activities. Numerous approaches to statewide exchange exist in the market today, and different models are successful in different environments. There is no known "best approach." However, some are simply better suited to states with certain characteristics. This section discusses many of these elements to consider while building the foundation of health information exchange within and across states and regions.

State Role in HIE

Perhaps the first action taken by a state, as the process of building or facilitating HIE infrastructure is initiated, is a self-evaluation. States must ask themselves, "Where do we stand with health information technology today?" and "What roles and level of involvement are appropriate or best for my State?" Depending upon existing technology infrastructure, HIE and EHR adoption, and culture, different approaches may be better suited to different states. These considerations are very closely tied to governance structure and models, because state role, governance model, and technology infrastructure are all closely intertwined.

As states continue to craft strategic and operational plans for health information exchange and utilize federal funding, the Office of the National Coordinator for Health IT outlined four common models in February 2011¹:

• States with very little existing HIE infrastructure tend to follow the "Elevator Model," a quick push for basic exchange in a space with limited or no current data exchange capabilities. A key component of this model is the use or development of Health Information Service Providers (HISPs) to facilitate directed exchange and support simple interoperability, and identify more robust exchange services to support Stage 2 and Stage 3 of Meaningful Use. (e.g., Illinois, Wisconsin)
  • Initial phase includes promotion of directed exchange services.
  • Includes services such as provider directories or certificate authority, where they may lower cost or improve the services of vendor-supplied directed exchange solutions.
  • Future phase may include more robust, modular state-level shared services;
  • The governance may in time transition to the Public Utility or Orchestrator model.
• A second model adopted by state plans is that of "Capacity-builder." States with developing localized HIE infrastructure but little state-level oversight will ramp up efforts to implement state-wide policy, while also strengthening local exchanges through technical assistance. (e.g., Indiana, Texas)
  • Initial phase focuses on provision of financial assistance and technical assistance to grantees within the state or sub-state "nodes."
  • Future phases may support limited shared services to connect nodes within or across the state.
• The "Orchestrator Model" is prevalent in states with more fully-developed local exchanges but limited ability to share information between nodes. Protected health information (PHI) resides within the local exchanges. State plans following this model tend to focus on bolstering centrally-located shared services, such as provider directories or data translation, to promote statewide exchange. A state-designated entity or state governance entity may be named to lead or manage these centralized services. (e.g., New Hampshire, Washington, Tennessee)
  • Initial implementation focuses on directed exchange across state nodes or networks, supporting functions such as message routing, security services, and provider directories.
  • Future or more advanced phases may include query/retrieve functions (vs. push-based initial phase) such as master patient index (MPI) or record locater service (RLS).
• The "Public Utility Model" refers to states taking on a more robust role in HIE, typically, where a state entity connects each local or regional stakeholder directly and offers a comprehensive and powerful set of tools and services at the state level. (e.g., Delaware, Idaho) Additionally, hospitals and enterprise HIEs as well as regional or local HIEs may connect to the state-level entity
  • Initial implementation connects providers, hospitals, enterprise HIEs, and regional HIEs to the state-level entity and may provide additional services to support Stage 1 of Meaningful Use, such as clinical messaging, lab results delivery, and care summary record exchange.
  • Future phases may support more advanced analytics and population health activities, connecting consumers to their information, and connectivity to other states and federal agencies using NwHIN standards.

Draft Case Studies of the above referenced models were published by ONC in February 2011. Additional information regarding these models for strategic and operational plans for state roles in HIE can be found at:

• Report: State HIE Strategic and Operational Plan Emerging Models (ONC, February 16, 2011)
• PowerPoint Summary: State HIE Emerging and Operational Plan Models (ONC, February 16, 2011)
• Catalog of State HIE Plans and Plan Summaries
  

State Information Models

State-level entities can take a number of different approaches in the delivery of shared services to HIE users. Utilization of existing regional or local HIE infrastructure and a clear understanding of unique statewide challenges to HIT adoption figure greatly into decisions regarding the state information model of HIE. Below, three models are highlighted, ranging from the centralized model with a robust infrastructure for exchange to the decentralized model, with the state-entity bridging the gaps between existing HIEs.
HIEs at the state level will likely take shape with a model that combines aspects of more than one of the following archetypes. These models are representations of popular approaches, but do not necessarily take into account the needs and unique considerations of individual states. As such, variation in these models, as states begin to implement HIE, is to be expected.

Centralized Information Model

In a centralized state information model, one entity is designated as the health information organization for an entire state. Regional Health Information Organizations, providers, public health institutions and the state Medicaid agency can share information by interfacing with the state HIE. A State Designated Entity will deliver all core exchange services from its position in the center of all stakeholder interaction. In some instances, the state HIE is actually run by a public, state-controlled entity.

This centralized entity manages and performs the exchange of clinical and administrative data among all stakeholders in the HIE. This means that master patient indexing and record locator services are located at the HIE level and all matching services are performed by the Exchange. In addition, statewide ePrescribing capability can be enabled through the HIE, as well as service to order labs and deliver results to providers.

Examples of states with centralized HIE models are:

Delaware (DHIN)

Maryland (CRISP)

New Mexico (NMHIC)

Nebraska (NeHII)

Utah (UHIN)

Decentralized Information Model

In a decentralized state information model, the state acts mostly as a coordination and collaboration facilitator for exchange between organizations. The state may develop policies or procedures to help one organization access a patient's data that is stored at another organization, verify that the other facility and provider are correctly identified, and then exchange information between the organizations. No actual exchange of data takes place through any state-level exchange. The state may support a mechanism to connect to other HIEs via NwHIN standards or gateway, but the data flows between stakeholders and exchanges rather than through any single state HIE or central organization.

A state utilizing the decentralized information model may not handle the actual exchange of data, but still serves important functions. The decentralized state HIE ensures that all data shared is accurate and standardized, and all stakeholders properly secure and validated. Building a community of trust is important in a network of organizations sharing proprietary data, and the state HIE serves as the trust-building link in the exchange chain.

Examples of states with decentralized HIE models are:

Texas (THSA)

Indiana (IHIT)

Hybrid Information Model

The hybrid model incorporates elements of both the centralized and decentralized models. Most state information models likely fall along this spectrum, with varied levels of centralized services to benefit stakeholders. Exchange of PHI may or may not be managed solely at the state level as it would in a centralized model, but services like a master patient index (MPI), record locator service (RLS), and consent management are common offerings of HIEs employing the hybrid information model. The HIE will institute policies that dictate data exchange and offer a varying level of robust shared services but may not play as active of a role in the transmission of data as the HIE operating as a centralized state information model. As organizations share data between one another, states employing the hybrid information model often implement technology infrastructure to support exchange between and with enterprise HIEs, regional HIEs, and other health information providers. These state-level services help to support that the correct information is exchanged - with the correct patient record retrieved in response to a query.

Examples of states with hybrid HIE models are:

Tennessee (HIP-TN)

New York (New York eHealth Collaborative)

California (Cal eConnect)

Standards

Without the use of commonly accepted standards, health information exchange would be cumbersome or limited in its clinical and operational value. The use of shared health information across disparate settings is made possible through the use of common language, via use of standards that may be bolstered or supported through shared services at the state-level.

This section provides an overview of the various types of standards the need to be considered by states and HIOs when developing technical infrastructure: terminology standards, messaging standards, and document standards. Following an introduction of standards, an introduction to data translation and mapping services is provided to assist HIE efforts in supporting exchange across entities that employ varying levels of these three categories of standards.

Terminology Standards

Terminology standards ensure that stakeholders across the entire spectrum of a health information exchange are speaking the same language. Medical terms, laboratory results, specific diagnoses, and procedures are shared across the HIE, but without terminology standards, these results remain as internal codes, only useful to those providers who input the data. Terminology standards allow widespread use and understanding of medical results to be utilized in the delivery of care or in outcomes management, and facilitate clinical decision support.

Limitations of widespread terminology standards do exist. One significant challenge is adoption. If certain organizations are slow to adopt the generally accepted terminology standard, their data cannot easily be consumed or shared at the HIE level. Providers may also implement and use standardized terminology at different levels of specificity for documentation and delivery to the HIE. Finally, local variations of the national standard do exist, and some new diagnoses, procedures, or medications may not have an assigned code or term.

Another challenge with terminology standards lies in the details of translation. Who will translate local codes for lab results or diagnoses into the proper standard format? Is this done at the user level, or after information has been sent to the HIE? More information on this is below in the Data Translation and Mapping section.

• LOINC – Codes for medical laboratory observations
• SNOMED – (Systematized Nomenclature of Medicine) Core medical terminology, and the vocabulary used in EHRs
• NDC – (National Drug Codes) Codes for identifying packaged drugs
• RxNorm – normalized names for clinical drugs
• ICD – (International Classification of Diseases) Coding for diagnoses and problem lists.
• CPT – (Current Procedural Terminology) Coding for procedures and services

Messaging Standards

In order to send and receive messages easily and efficiently, HIEs must structure messages in such a way that all stakeholders across an HIE can easily decipher their meaning and content. Messaging standards make it possible for different computer systems to pull out the same messages across the spectrum, regardless of local specification.

Still, limitations exist in the use of messaging standards. These standards continue to develop and evolve, and confusion around exact specifications for some of these standards can still be a challenge. In the case of National Council for Prescription Drug Programs (NCPDP), the lack of adoption of consistent units and standards of measurement has proven to be a challenge.

• HL7 – (Health Level 7) Standards framework for the exchange of health information
• Web Services
• Secure transport protocols such as HTTPS, SFTP, VPN
• XDS – Integrating the Healthcare Enterprise (IHE) Cross-Enterprise Document Sharing specification, for the exchange of healthcare documents across different enterprise stakeholders typically used for storing in a document repository
• PIX/PDQ – IHE interoperability specification for Patient Identifier Cross Reference Manager and Patient Demographics Query, respectively. Use of these standards enables EHRs and other applications to query HIE for patient demographics and patient identifier information

Document Standards and Specifications
Document standards across an HIE ensure that organizations are sharing relevant patient data organized in a useable and readable manner. By standardizing the documents shared across the HIE, providers can be sure they are receiving accurately recorded and organized patient summary data (as with the CCR or CCD), laboratory images and results, or any other formalized communication. Furthermore, by using document standards, electronic health records can accurately extract patient data, interpret the information, and place data into the appropriate location within the user's EHR.

• CCD – The Continuity of Care Document is a patient summary containing pertinent clinical and administrative information
• CCR – Continuity of Care Record is a summary of a patient's health status at a certain point in their continuum of care
• DICOM – Laboratory image sharing and workflow management
• XML - (Extensible Markup Language) An internet standard that supports the ability to represent structured data and hierarchical data as stored in relational databases used for encoding documents and data into a form that can be read by machines
• NCPDP SCRIPT – (National Council on Prescription Drug Programs) Data interchange standard for exchange of prescription data between pharmacies, prescribers, payers, and intermediaries (e.g. Surescripts). NCPCP also leads development of a formulary and benefit standard

IHE PIX/PDQ and XDS-based query for health information

Data Translation and Mapping

As provider organizations deliver care and record diagnoses, medications, and any other medical data into an EHR system, vendor-specific or localized methodologies are used to document the information. For medical data to be shared state or nationwide, data must be converted to the appropriate standard. This conversion can be a resource-intensive undertaking. By prioritizing the most commonly used codes and terms, some of the difficulties inherent in data mapping and translation can be mitigated.

As seen in the Terminology Standards Overview above, there are multiple standards for similar types of information. For example, both NDC and RxNorm codes are used for medications. However, NDC codes support packaged medication and are more often used by dispensing organizations such as pharmacies, while RxNorm codes are used to identify the individual ingredients in a medication. There is a one-to-many relationship between NDC and RxNorm codes. Although there are products and health IT solutions that support mapping between these two codes, there are many more standards in use (and needed for development) in health care. This example describing the potential need for mapping between NDC and RxNorm codes may apply across any and all information exchanged via HIE, as the level of standards adoption and use varies.

Data transformation can occur at numerous levels in the health information exchange process. The HIE can perform the transformation at its centralized location within the exchange community, or organizations can be required to transform and properly map their data prior to being sent to the HIE. As such, data transformation is a value-added service provided by some HIEs. The HIE takes the translation burden off of stakeholder organizations and can accept data in any form, performing the translation centrally. This removes a significant barrier to entry for organizations looking to participate in information exchange.

Data Storage Architecture Models

Many HIEs adopt different approaches to the storage of health data. While it may seem that data storage and state level architecture go hand in hand, the considerations for the two model types differ substantially. Data storage architecture models refer to the locations where clinical data resides and is maintained. HIEs can store all clinical data in one central location, have data live on-site to be maintained by stakeholders within the exchange, or operate with some combination of these two approaches. Although there are technical and data architecture solutions to help mitigate concerns over privacy, security, and power to manage one's own data, these stakeholder concerns and organizational culture are a key factor in determining technical architecture models for HIE.  Three models (Centralized, Federated, and Hybrid) demonstrate the full spectrum of considerations for data storage.

There is often confusion among use of the terms for HIE information models (Centralized, Decentralized, and Hybrid) and HIE data storage architecture (Centralized, Federated, and Hybrid). In many cases, the terms "decentralized" and "federated" are used interchangeably.

For example, New Mexico (NMHIC) is a state-wide HIE that employs a centralized information model as there is a singular exchange that serves the entire state. However, the only centralized data store is the master patient index, as all patient records remain in databases at the original site of patient care. In this case, federated data storage architecture is used for storage of patient health records.

Centralized

Centralized data storage architecture is characterized by health information and data that resides in one central location. In the case of a state HIE, this means that data from hospitals, providers, Regional Health Information Organizations (HIOs), Integrated Delivery Networks (IDNs), and any other source will be routed (usually pushed) to the central HIE, where all available health information will be stored. A centralized HIE will also support shared services such as consent management, master patient indexing and record location services. Registries and repositories will also be handled centrally. Either the HIE can perform the data mapping and transformation after the data has been received, or the HIE can require data-senders to put the information into the correct standard format prior to pushing on the data.

Advantages of this centralized architectural approach mostly lie in the realm of economies of scale. The large, centralized HIE can handle much of the administrative burden that would otherwise be shouldered by the smaller stakeholders in the statewide HIE network. Data backup and user auditing can be done centrally (where all the data resides) rather than at each site where data is stored, as is the case of a federated model. With much of the administrative and technical load carried by the centralized HIE, costs can also be more closely monitored and controlled. The cost to implement and maintain the HIE is more controlled as well.

Disadvantages of the centralized approach mostly concern the issue of data ownership. As in a centralized HIE information architecture, stakeholders sending data to a centralized data store may have greater privacy concerns and want more ownership and control over their own data, rather than their data being pushed to a central hub and comingled with the data of numerous other (and potentially competing) organizations and stakeholders.

The centralized approach for data storage is rare in community based HIEs and is most prevalent in enterprise HIEs, where the enterprise either owns the data within the HIE or is already a trusted partner of the data sharer (such as affiliated ambulatory providers). The centralized data architecture is also common among data stores for advanced analytics, as most data warehouses employ the centralized data storage architecture.

Federated

In a federated data storage model, HIE participants store data in individual databases within their own organizations. Although federated data stores are often easiest to implement, they are more complex to maintain. For example, if the underlying data structure is not consistent across each data store, there is more burden involved in transforming or translating that information when sent in response to a query.

Limitations of the federated approach include the challenge of coordinating many separate stakeholders on the use of set standards and procedures for exchange, and the need for many disparate systems to work together at any given time. With so much disparate infrastructure throughout a given state, it can be a challenge to manage the pieces working together to enable exchange. Additionally, providing real-time point-of-care data to support decision making may be difficult, since the HIE will have to pull data from many disparate systems, which will take some time.

Hybrid

A hybrid model incorporates elements of both the centralized and federated data stores. Often, the hybrid approach takes the form of a central repository of information with "edge servers" utilized for data storage. These edge servers can be located at stakeholder sites or within the central repository, but are notable for the control that providers maintain over their data. Since stakeholders' data is not comingled, each entity can maintain much more control and ownership of their data. HIEs should talk to potential vendors about their use of edge servers and other architecture components to support the hybrid data architecture model.

The hybrid model makes it possible for existing HIE infrastructure to be utilized while still allowing for a more centralized approach to data exchange. Maintaining this central control over the flow of data, while still preserving stakeholder control over their own data, strikes an attractive balance to many prospective participants. Competitive entities, like separate health systems within a state or region, will take ownership of their data, while the HIO manages the sharing of information. Maintenance and coordination may require more work on the part of the HIE, as a result of taking a hybrid approach, as compared to more centralized data storage architectures.