Around the world, healthcare delivery systems are increasingly focused on making large-scale cross-organization exchange of clinical information a reality. It is widely recognized and accepted that this is the essential next step in improving the quality and safety of medical care with efforts occurring at the local, regional, and national levels. Typically, though, these efforts are undertaken as “one of a kind” development projects, with the attendant high costs, long time frames, and significant risk of project failure.

HealthShare takes a different approach. It is an innovative software platform that includes the technology needed to get an electronic health record system up and running quickly, plus a complete development environment for customizing solutions to meet the needs of each system. HealthShare is designed to radically reduce the costs, development time, and risks of building and operating an electronic health record (EHR) system.

HealthShare, which has been specifically designed for Regional Health Information Organizations (RHIOs) and other EHR applications, is a new product built on proven technology within our Ensemble rapid integration platform. Released in 2003, Ensemble is widely used in healthcare projects ranging from integration within a single hospital to the development and deployment of a nationwide electronic health record system, such as the Netherlands national electronic health records implementation.

HealthShare includes three components that, together, address the end-to-end requirements of a multi-organization health information exchange deployment:

• The HealthShare Hub acts as the central index of patients, with “pointers” to the hospital and doctors office systems that contain patients' clinical data.
• The HealthShare Gateway connects participating healthcare sites and users to the exchange.
• The HealthShare Viewer is a sophisticated browser-based portal that doctors and other clinicians use to access patient demographic and clinical data.

The roles of these three components are best shown through a simple example (see figure below). Suppose a doctor wants to obtain a patient's clinical data. The following process is used. First, the doctor queries the Hub to “find” the patient. Second, having identified the patient, the doctor requests data from one or more sites. Requests are sent to the Gateways for those sites, data is retrieved from each site's local applications, and the Gateways assemble responses. Those responses are returned to the originating Gateway for use by the clinician via the Viewer.

One of the biggest challenges faced by a RHIO or any other EHR system is to enable doctors to find a patient's data quickly and reliably. Because this data was gathered by a number of organizations – primary care physicians, specialists, hospitals, and so on – without the benefit of a community-wide identifier, a sophisticated matching engine is required. This enables reliable patient identification despite variations in the data, such as a first name of “Robert” in one system and “Bob” in another, or the day and month portions of a date being swapped. HealthShare includes built-in support for several of the leading identity management products.

HealthShare Hub

The HealthShare Hub provides a central patient index, storing summary patient demographic information along with links to each patient's medical records in the source systems at doctors' offices, hospitals, and other care or testing sites. Information in the patient index is bulk loaded when a site joins the health information exchange. Thereafter, it is continually updated as changes occur at care sites – for instance, as new patients are added, or existing patients' data is updated, or two patient records are discovered to belong to the same person, requiring that the existing records be merged.

HealthShare Gateway

The HealthShare Gateway is responsible for all communications between a clinical site and the Hub as well as for Gateway-to-Gateway communications between clinical sites.

The Gateway also connects to each site's existing application(s) for bidirectional information flows. Specifically, those applications notify the Gateway about events that need to be reflected in the Hub patient index, such as when a new patient is registered or there is an update to an existing patient's demographic information. In the other direction, the Gateway sends requests for clinical information to the site's existing applications. Communication between the Gateway and each site's applications occurs via HealthShare Adapters.

Each Gateway includes a consent management framework that is used to record patient consent declarations and to enforce those declarations. The Gateway also includes sophisticated facilities for local integration. These might be used with an existing clinical application to query the community patient index or to request clinical data from other sites.

HealthShare Viewer

The HealthShare Viewer connects to the Hub to enable community-wide patient search, and it combines data from multiple sites and multiple clinical episodes into a comprehensive patient-centric view. It provides intuitive display of a wide variety of information, including patient demographics, allergies, medication, diagnoses, lab results (in result range, cumulative, and graphical formats), radiology results (text and images), family history, clinical findings, progress notes, and more. As a “pure” Web product, the Viewer is extremely easy to deploy and support. Only a Web browser is required and there are no client-side components to install.

The Power of HealthShare Viewer

To illustrate the power of the HealthShare Viewer, let's look at a sample session. We begin by going to the community EHR Web site and logging in. If desired, the user can be required to reaffirm his or her agreement with privacy rules or other site-specific policies at each log in.

Next the doctor searches for a patient by filling in whatever demographic details are available. In this example, the patient's name and birth date are supplied. Search fields are highly configurable and could, for instance, include other values such as telephone number or mother's maiden name. The search screen is easily configurable to include or exclude additional data fields.

The system returns with a list of possible patient matches, ranked by probability of match. If the doctor is not certain which of the matching patient entries is correct, he or she can click on the last name to see additional demographic details (beyond those stored in the EMPI).

Once the correct matching patient records have been identified (by clicking one or more check boxes in the Select column), the doctor can search for available clinical data by indicating the types of data needed and the timeframe. In this case, (see figure 7) the doctor has selected all five of the patient records (as they represent records from five different data sources for the same patient) and requested allergy and medication data for all years in the records.

Based on this request, HealthShare interrogates the five data sources, retrieves the allergy and medication data stored there, and presents a summary.

At this point, the user can refine his data request (by clicking on View) or export detailed information as a CDA document. Note that the preceding steps are not “cast in stone”. Because HealthShare is highly configurable, the actual steps/screens used could vary significantly, to reflect local needs.

Summary of Design Principles

HealthShare was built with six key design principles in mind.

• Usability : Clinicians want to view “remote” clinical data (that is, data from practices or facilities other than their own) through the same application as “local” data. Unfortunately, most existing electronic medical records systems lack this capability today and enhancing them will take substantial time. Furthermore, we believe that one of the major keys to success for RHIO projects is ensuring that the healthcare professionals using the system derive immediate benefit. The best way to accomplish this is to include a clinical viewer that is sophisticated yet easy to use, highly customizable but simple to configure, rich in functionality but highly intuitive, and available from any device that supports a browser.
• Security and Privacy : The system needs to support strict adherence to privacy and security standards. Strict authentication, role-based access, granular security policies, and tamper-proof logs recording all activity of all users, are key to achieving these goals.
• Performance, Scalability, and Reliability : The system needs to provide near real-time access to clinical data, whether it's serving a few dozen users of a pilot system or many thousands of users in a statewide or nationwide deployment. And it needs to do this twenty-four hours a day, seven days a week.
• Standards-based : Standards are the key to interoperability. By adopting standards at every phase of data exchange – particularly HL7 v2, HL7 v3, Web Services, and CDA – the system ensures the ability to interface not only with new and existing clinical systems, but also with other EHR solutions.
• Flexibility and Rapid Customization : Desired EHR functionality and standards are rapidly evolving, but are still very much in their infancy. In addition, multiple deployment architectures, such as centralized, decentralized, and hybrid configurations, are being considered. The system therefore needs to be highly flexible and adept at rapid change to respond effectively to evolving requirements and user feedback.
• Ease of Management : As a “system of systems”, an EHR presents an enormously challenging environment for system administration and high availability. The system needs to support multiple administrators with different roles, have minimum maintenance requirements, and provide an end-to-end Web-based management portal for managing all components and administrative functions of the system.

Constructing an Electronic Health Record System

Because of the diversity of approaches being tried with EHRs, as well as the rapid evolution of technical standards, packaged application solutions lack the flexibility to meet the unique requirements of each RHIO. As a result, most EHR systems are built as “one of a kind” development projects that combine general purpose technologies – integration engines, databases, portals, and so on – with substantial custom application development. This “technology assembly” approach is prone to long and costly development cycles and large investments in infrastructure which may or may not deliver real value in the ultimate solution.

HealthShare offers a different approach to building EHR systems. By combining a set of comprehensive health information exchange services with rapid development tools for efficiently closing the gap between those services and the unique approach and requirements of each RHIO, HealthShare will dramatically speed the development and deployment of EHR solutions.

Connectivity and Standards

To succeed, an EHR system must connect reliably and with minimum cost and effort to a large number of existing clinical applications. With HealthShare, this is accomplished with a combination of three powerful technologies that are part of the InterSystems Ensemble technology at the heart of HealthShare: adapters, data transformations, and business processes.

Adapters

Adapters are reusable software components that provide connectivity to applications and that isolate all application-specific logic from the rest of the system. HealthShare includes an extensive library of pre-built adapters that will meet the needs of many EHR applications. Where the source or target applications do not permit the use of standard adapters, custom adapters can be rapidly created. Typically, this is done by extending (technically “sub classing”) an existing HealthShare adapter, enabling rapid development and ensuring that all of HealthShare's reliability, manageability, and performance features are realized.

In most cases, some “flavor” of HL7 v2 will be employed to connect to existing clinical applications. With built-in support for all HL7 v2.x schemas and its powerful virtual document architecture, HealthShare provides the richest and fastest HL7-based connectivity available today.

Data Transformations

The data transformation engine performs any required message set translation or other message normalization or modification tasks. These may be as simple as removing or reordering fields in a message, or might involve interactions with external systems or other complex processing in order to convert application-specific messages to standard forms. HealthShare includes an extensible transformation class for converting HL7 v2 responses from participating applications to standard CDA format. New or existing transformations can be specified graphically or via an XML-based transformation “language”.

Business Processes

Differences among the clinical applications may require different processing steps for individual requests. For instance, a request for a patient's clinical information might be satisfied by sending a single request to a single application (which would be typical in a doctor's office) or by sending multiple requests to multiple applications, perhaps on multiple computers (which would be typical in a hospital.) To make things even more interesting, the process might vary from one patient to another – perhaps for female patients we need to query a maternity system. To accommodate this variability, the HealthShare Gateway uses a business process to define the clinical data retrieval process at each site. An example business process is shown below.

Through this mechanism, application- or site- specific differences are rapidly accommodated without modifying HealthShare or its adapters. Rather, these differences are defined at a high level and fully encapsulated in an easily modified business process.

Standards

HealthShare supports a wide variety of healthcare data and interoperability standards, as shown on the next page. It supports HL7 v2 and v3, and InterSystems is a member of the HL7 standards body, helping to guide development and ready to support future versions of the standard. HealthShare also has strong XML support, including a built-in XML parser, bidirectional support for DTD and XML schemas, document querying and transformation via XPATH and XSLT, and transmission of messages using SOAP. Together, these facilities enable HealthShare to deliver high performance support for CDA and other XML document-based standards. InterSystems also is an active participant in the efforts of IHE (Integrating the Healthcare Enterprise) to improve the way computer systems in healthcare share information. Within HealthShare itself, we endeavor to use messaging/data standards wherever available. All Gateway-to-Hub and Gateway-to-Gateway communication uses standard message formats transmitted via Web services. Gateway-to-Hub communication uses the RLS specification from the Connecting for Health Common framework. For Gateway-to-Gateway communication, HL7 v3 messages are used to request clinical data and CDA documents are used to return that data.

Healthcare data exchange standards supported by HealthShare

Identity Management

Identifying patients quickly and accurately is central to the operation of an EHR system. This requires sophisticated matching technology that can perform searches with a variety of demographic data, and InterSystems has partnered with two of the leaders in this field, Initiate Systems (www.initiatesystems.com) and QuadraMed (www.quadramed.com). HealthShare includes adapters for both products and both store their data in HealthShare's built-in high performance database, eliminating the cost, complexity, and performance overhead of the relational database products often required for storing patient index data.

HealthShare provides rapid customization of the identity management system, including:

• What demographic data is indexed. For instance, some EHR systems will collect and index on social security numbers while others (for legal or policy reasons) will not.
• What query fields must be supplied. To prevent “fishing expeditions”, EHR systems may want to specify one or more sets of fields that must be supplied when a search is initiated. For instance, perhaps either a first and last name or a last name and date of birth must be entered.
• What data is returned from a search. To avoid unnecessary disclosure of personal information, EHR systems may also want to limit what data is returned in response to a search. Suppose that our patient index contains social security numbers and that a search is requested for a patient named “John Smith” with social security number “123-45-6789” living at zip code “12345”. Such a search might return a list of candidate patients, none of whom have the indicated social security number. HealthShare enables the EHR system to decide whether or not this list should include social security numbers or other sensitive information.

Consent Management

The HealthShare Gateway includes a consent management framework that is used to record patient consent declarations and to enforce those declarations at the individual site or practice level. By default, this provides a simple opt-in/opt-out policy. That is, for each facility and patient, the system provides either all clinical data or none. For instance, a patient might elect to opt in for data held by her internist but to opt out for data held by a fertility clinic. More sophisticated policies, such as sharing certain types of data but not others, can be enforced by writing a custom consent-checking method.

The system can be configured to assume consent unless the patient explicitly opts out, or to require explicit opt in for each patient. Whichever approach is chosen, every request is automatically checked by the appropriate Gateway for adherence to patient consent policies.

Virtual EHR and Repository Architectures

There is a wide range of thinking about the best architecture for constructing EHR systems. Some advocate a virtual EHR or “keep the data at home” strategy, where all clinical data remains under the control of the source systems at each healthcare institution. Others prefer a repository strategy, where data from multiple sources is collected and stored in a central location – typically at the Hub. HealthShare supports both of these approaches as well as hybrid architectures that combine these two.

For instance, a RHIO might decide to centralize allergy information but leave all other clinical data in the source systems. A system would be constructed as follows:

• The Hub would be used to index patients and their clinical data locations.
• The Gateways at the data provider sites would be used to provide access to the data source systems.
• A repository would be constructed at some location, typically the same site as the Hub. Because HealthShare includes complete database capabilities (based on InterSystems Caché technology, the number one database in clinical applications worldwide) no additional software is needed. Alternatively, any other database or off-the-shelf clinical repository could be used.
• Each time there is an allergy event at a site, an entry is added, updated, or deleted in the repository. Typically, this is implemented by sending an HL7 message from a data source system to a local Gateway, which sends a request (in a standard format) to the Gateway at the repository site.

Note that, with HealthShare, access to data in a repository is no different from any other clinical data access; it is indexed by the Hub and accessed via a Gateway.

For repository-based implementations, HealthShare provides complete flexibility to select the most appropriate healthcare data model. HealthShare's built-in XML-enabled object database can be used for everything from an HL7 v3 RIM model to a pure document repository based on CDA or other XML-based standards.

Terminology

One of the ongoing challenges in healthcare around the world is to employ standardized terminology to facilitate meaningful information exchange. Without a shared understanding of diagnoses, for instance, it's difficult for two physicians to communicate effectively.

To address this key issue, we have partnered with Health Language, Inc. (www.healthlanguage.com), one of the leaders in application-independent terminology services. Health Language supports a wide variety of standard terminology sets including, SNOMED, ICD 9/10, CPT, and LOINC. HealthShare includes built-in support for HLI's Language Engine, including storage of the Language Engine knowledge base in HealthShare's built-in high performance database. This eliminates the cost, complexity, and performance overhead of a separate relational database.

Accessing the EHR Through Existing Systems

While the functions of HealthShare are (from the user's perspective) typically invoked via the Viewer, the Gateway also makes them available programmatically for direct integration with other applications. These might be used with an existing clinical application to query the community patient index or to request clinical data from other sites.

Because the Gateway provides access to these services through a variety of technologies, including SOAP, .NET, Java, ODBC, and JDBC, they are compatible with virtually any development technology.

Portal Development

HealthShare includes powerful portal development tools that can be used to develop and operate specialized Web sites and applications, such as the following home page for a fictitious RHIO.

The Information for Patients link explains the system from the point of view of a patient or other layperson. The Information for Clinicians link enables authorized doctors and other users to gain access to the system. (Experienced users will likely bypass this page and go directly to the log in screen.) It will also provide a clinician's overview of the system, as an introduction for interested parties from outside of the communities. The Participating Hospitals and Practices link provides a list of the participating organizations, with links to their Web sites where applicable.

Operating an Electronic Health Record System

Performance and Scalability

Performance is key to the success of an EHR solution: unless a system provides nearly instantaneous response at the point of care, physicians will not use it. HealthShare shares core technology with InterSystems Caché post-relational database, which has earned a worldwide reputation for high performance especially for demanding healthcare applications.

Scalability is equally important. Many EHR systems will start as pilots, with perhaps a few hundred thousand patients, and then grow over time by one or two orders of magnitude or even more. HealthShare supports cost-effective incremental growth through both the addition of processors within a server as well as the addition of servers within a multi-tier configuration. Using InterSystems' unique Enterprise Cache Protocol, scalability has been proven to tens of thousands of concurrent users and millions of patients.

Deployment Configurations

Remote sites are connected to an EHR system via HealthShare Gateways. For maximum flexibility and simplicity of management, both centralized and distributed Gateways are supported.

In a distributed configuration, the Gateway is located at the remote site. This is generally desirable for large sites, such as hospitals, with local IT staff. Alternatively, in a centralized configuration, the Gateway is co-located with the Hub. This architecture is well suited for connecting doctors' offices and other smaller facilities, where IT staff are not available to manage a local Gateway.

A single EHR system can (and often will) employ both centralized and distributed Gateways.

High Availability

To ensure high availability, HealthShare relies on InterSystems' automatic persistence architecture. At each stage of its processing, HealthShare automatically saves the message “state” in its built-in database. In the event of a system crash or other failure, this enables rapid and reliable recovery. HealthShare delivers a full range of high availability features, including:

• Concurrent full and incremental backup while applications are running and databases are changing.
• Transaction logging and roll forward recovery, for transaction integrity.
• Write image journaling to protect database integrity.
• Local and remote shadowing, for on-site or off-site standby recovery.
• Clustering for scalability and rapid failover.

Security

To ensure security and privacy, HealthShare employs a range of advanced technologies including encryption, strong authentication, role-based privileges, and audit logging and reporting.

HealthShare provides strong encryption for both data at rest and data in motion. HealthShare's built in database encryption technology encrypts the entire contents of the database, including indices. It protects all sensitive data at the Hub and Gateways, including both “real” clinical and demographic information as well as other “system” data, such as audit records and logs.

Database encryption is implemented using the Advanced Encryption Standard (AES) algorithm specified by Federal Information Processing Standard 197. AES is a strong and fast symmetric encryption algorithm, and is used with a 256-bit encryption key. The key is stored outside of HealthShare (e.g. on a memory stick, CD, or a file) and is loaded during start-up of the system. A password is required to access the encryption key. At run time, the key is stored in a protected memory location.

To ensure safe communications between the various HealthShare Hub and Gateway components, HealthShare includes support for SSL (2.0 and 3.0) and TLS. Incoming connections from a Gateway are only accepted if the Gateway presents a valid certificate, and if the identity – contained in the certificate– is known to the server. For a certificate to be valid, it must be issued by a recognized Certificate Authority and must not be expired.

HealthShare supports the underlying authentication technologies needed to enforce a strong authentication policy. Users of the HealthShare Viewer are prompted for a username and password. These credentials are sent (in encrypted form) using an HTTPS connection to the HealthShare Gateway, which verifies the identity of the user by connecting to a Kerberos KDC. The KDC can be configured to enforce strict password policies, such as length and pattern of password and frequency of password change.

HealthShare includes a very flexible and powerful role-based security mechanism. Roles will be defined for Level 1 and Level 2 access and assigned to users as needed. (No role is needed for Level 0 users, as they have no access.) Additional roles will be defined to control other types of access to the system, such as access to audit trail information.

The HealthShare Hub and Gateway provide flexible logging capabilities for all requests using a secure tamper-resistant audit log. This data can be used to monitor usage of the system, to investigate any suspected misuse, and to conduct periodic audits. Because HealthShare provides full SQL support, in addition to built-in online search of the audit log a wide variety of off-the-shelf data access tools may also be used.

Monitoring and Administration

With lots of “moving parts” – often hundreds of Gateways and thousands of clinical systems and constant change on any given day – one of the most difficult challenges faced by RHIOs will be to maintain high availability and to rapidly find, diagnose, and correct any problems.

HealthShare brings two powerful advantages to this battle: automatic logging and a powerful monitoring and administration console designed for remote systems management. HealthShare automatically records each action taken to process a request, at the level of detail needed to accurately diagnose problems. For instance, a Gateway might receive a request to fetch a certain patient's clinical data and, to fulfill it, sends requests to five or ten hospital systems. Each of those requests and responses is logged for full traceability.

To investigate further, an operator or administrator might click on one of the steps in the trace diagram to “drill down”. We might, for instance, inspect an HL7 message, as shown in the following illustration.

Message trace is just one of the facilities provided by the HealthShare Management Portal. Because it is browser-based, it operates identically for both local and remote operations. An administrator with necessary security privileges can investigate a problem anywhere in the network.

For more information

For more information, visit the InterSystems HealthShare web site at: www.InterSystems.com/HealthShare.

InterSystems Corporation
World Headquarters
One Memorial Drive
Cambridge, MA 02142-1356
Tel: +1.617.621.0600
Fax: +1.617.494.1631
InterSystems.com