Creating Regional and National Electronic Health Records
with InterSystems HealthShare™
The Fast Path to Connected Healthcare
Contents
I. National and Regional Sharing of Clinical Information
II. HealthShare Architecture
- HealthShare Architecture Overview
- The HealthShare EPR
- The HealthShare Hub
- The HealthShare Edge Cache Repository
- The HealthShare Gateway
III. Advanced Features
- Terminology Services
- Enhancing Functionality
- Connectivity
- Standards
- Privacy and Security
- Consent Management
- Security
IV. Operating a HealthShare System
V. Conclusion
I. National and Regional Sharing of Clinical Information
InterSystems HealthShare Overview
Around the world, healthcare delivery systems are increasingly focused on creating regional and national Electronic Health Records (EHR). The sharing of clinical information increases the accessibility of important health information, can reduce costs through elimination of duplicate tests and prescriptions, and most importantly, improves the quality of care. The availability of such information in emergency situations can literally save lives.
In many cases, these solutions are being approached as ad hoc projects. However, the complexity of healthcare systems makes the development of such sophisticated clinical applications on a custom-programming basis impractical as well as uneconomical. Effective aggregation and sharing of information stored in disparate existing systems requires a product-based approach that incorporates proven components. At the same time, the differing needs of various regions and nations make it essential to use a product that can be easily and rapidly extended to provide additional capabilities.
Any such product must meet the following requirements:
- Clinician access to the EHR must be based upon a proven application used in demanding healthcare environments – and not just a “viewer” or “portal” written specifically for this purpose.
- The database structure of the patient record must be based upon a proven product with an information model that has been clinically proven in a wide variety of hospitals, clinics, and community settings – preferably in multiple countries – to ensure that it supports the complex needs of diverse organizations and is capable of supporting additional needs as requirements inevitably grow.
- A powerful integration platform is required for rapid integration of clinical and demographic information from a variety of sources, with a particular emphasis upon HL7 Versions 2 and 3. Since it is not practical to assume that existing systems support (or will support in a reasonable time) a common format, the ability to rapidly develop support for other formats is critical.
- The core database and integration technologies must support rapid development, rapid customization, and massive scalability.
- A strong standards-based approach is required.
InterSystems HealthShare™ is an innovative software product that meets these requirements. It provides aggregation and sharing of clinical data among multiple provider organizations on a regional or national basis – up to, and including, a full EHR. It can be easily extended to provide additional functionality such as e-prescribing or order communications through the addition of business rules and business processes, composite applications, and additional applications provided by InterSystems’ partners.
HealthShare includes four logical parts:
- The HealthShare EPR is a sophisticated browser-based Electronic Patient Record (EPR) that doctors and other clinicians use to access patient data.
- The HealthShare Edge Cache Repository is a clinical database. Typically, each provider organization has an Edge Cache that holds all the clinical data that a provider is willing to share.
- The HealthShare Gateway is a health integration platform optimized for connecting multiple provider organizations. Each provider has a Gateway that connects the existing systems of that provider to their Edge Cache. Gateways also connect users of the EPR to other Edge Caches and the Hub.
- The HealthShare Hub is a central index of patients and providers. The Hub is used to uniquely identify a patient, and it specifies which Edge Caches maintain data for that patient. The Hub does not store clinical data.
HealthShare is based upon InterSystems technology, which is in use at thousands of hospitals around the world, including InterSystems Caché®, InterSystems Ensemble®, and TrakCare™.
Caché is the predominant database for clinical healthcare applications around the world, and it is the core database technology for all U.S. Department of Veterans Affairs and U.S. Department of Defense hospitals, as well as the Kaiser Permanente network. Caché is used at all of the top 10 hospitals in the U.S. (as ranked by U.S. News and World Report).
Ensemble is a rapid integration platform that is widely used in healthcare projects. It was named by KLAS as the highest-rated interface engine for healthcare in 2006, and has been positioned in the “Leaders Quadrant” of Gartner Inc.’s Magic Quadrant for Application Infrastructure for Composite-Application Projects, 2Q07, report.
TrakCare is a full Web-based hospital information system built around a sophisticated patient-centric electronic record. It is used in hospitals around the world, ranging from small clinics to statewide systems with millions of patients.
In this document, EPR refers to a computer version of the patient’s medical record in use at a single provider organization. At times, it is also used to refer to software products that are used to access and interact with patient records – such as the HealthShare EPR. EHR denotes a composite view of the patient’s medical records that integrates information shared by multiple providers.
Evolving Clinical Information Systems
Over the last 30 years, the evolution of clinical applications has generally proceeded through the development of increasingly sophisticated departmental applications, such as lab, radiology, etc. More recently, a great deal of effort has been expended – often at each site – to get these systems to talk to each other and provide a more integrated view of the patient to the physician.
However, the more modern approach to building a hospital information system is quite different; it is a more patient-centric view that starts with the patient’s medical record as the core of the system. Departmental applications are then built around that core, directly accessing and storing their information in the medical record. Clinicians access the data through a comprehensive EPR rather than through a variety of independent departmental applications with inconsistent user interfaces. The emphasis on the EPR results in a more holistic view of the patient, enables additional functionality, and provides a more sophisticated (and often faster) interaction with the clinician. Clearly, this approach puts demanding requirements upon the quality, sophistication, and ease of use of the EPR.
In much the same way, different regions have adopted varied approaches to the sharing of clinical information, with each emphasizing some particular functionality and seeking to design and build a network to provide just that functionality. For example, a region may choose to start by sharing information from a lab or pharmacy.
In this sense, it is like the older approach of building departmental applications. The question is, how well will that foundation work as the scope of the system expands, or does it even provide a foundation?
We believe that the best way to approach any regional or national system is to take the more modern patient-centric approach and start with a foundation technology capable of supporting a rich, full EHR. It may still make sense to start with a project that is less ambitious than a full EHR, but at least the foundation is present so that future requirements can be met more easily. Plus, the use of the EPR interface by the clinicians from the very start makes the introduction of new capabilities much easier and more natural. Around this structure other clinical functionality, such as e-prescribing or orders, can be added.
IDNs and Hospital Chains
Integrated Delivery Networks (IDNs) and hospital chains increasingly face similar needs for aggregating and sharing clinical data – needs resulting from these factors:
- Often these groups have grown as a result of acquisitions and now have several different systems that are not well integrated. A great deal of effort has been expended using messaging systems, but clinicians often do not have any simple way of accessing a complete medical record – which is at odds with the goal of providing integrated care.
- These organizations can increase their connection with physicians in the community by offering them access to a sophisticated EPR and by sharing clinical information.
- Tracking and treating patients that require ongoing treatment over an extended period of time – such as cancer or HIV patients – is greatly aided by sharing information among facilities.
The requirements of these organizations are fundamentally the same as regional and national systems, but there are often a few additional requirements. For example, an IDN might wish to “push” results out to a primary care office, or at least notify physicians that there is new information regarding their patients. The evolving nature of these needs highlights why it is important for the chosen technology to have a strong clinical foundation based upon proven healthcare products as well as the ability to rapidly develop new functionality with composite applications.
II. HealthShare Architecture
HealthShare Architecture Overview
Design Principles
The HealthShare architecture is based upon these premises:
- The health record is at the core of the system even though other functionality may also be provided.
- While having all of the medical terminology normalized is highly desirable, often that will not occur – at least initially. The system must be capable of aggregating and displaying data from multiple sources with differing terminology.
- Consent policies (for patient confidentiality) will vary between countries.
- Sometimes an existing EPR at a provider organization can provide a medical record electronically on demand. However, more commonly, the information must be accumulated from messages produced by departmental systems as transactions occur (e.g., as lab tests are performed) and retained in a new database.
- Communications and message protocols within the system must be strongly standards-based to enable future connections with other regional or national systems and to enable interoperability with other emerging electronic medical records systems.
- Despite attempts to standardize message formats, a variety of legacy formats need to be supported to integrate existing systems, and often they will be unique to a particular departmental system.
HealthShare Components
The HealthShare Hub is a central computer that maintains an index of all patients and keeps track of which HealthShare Gateways contain information about each patient. The Hub either has an Electronic Master Patient Index (EMPI) or uses an existing one. It does not store clinical data.
Each HealthShare Edge Cache Repository is a sophisticated EPR database that retains the information the provider organization is willing to share. Usually there is one for each large provider, while smaller providers may share an Edge Cache. With this approach, clinical data remains under control of the facilities that collect it.
The HealthShare Gateway connects a provider organization’s existing systems with its Edge Cache. As messages flow from departmental systems (lab results, etc.), the Gateway will transform the messages and insert the patient data into the organization’s Edge Cache. In addition, when a clinician requests information, a Gateway connects the clinician with the Hub to identify the patient and determine where the patient’s data is located. It then communicates with the other Gateways and Edge Caches to obtain the patient’s data and return it to the clinician’s EPR.
The HealthShare EPR is a rich browser-based medical record application that provides the user interface for the clinician. Patient data returned by the Gateway is aggregated and stored locally in the clinician’s EPR. That data is then available through the EPR until the clinician requests it be deleted.
HealthShare Configurations
HealthShare supports a variety of configurations. Normally, there is only one HealthShare Hub, but each provider organization (or in some cases, a group of provider organizations) has its own HealthShare Edge Cache Repository and HealthShare Gateway. Usually the Gateway and associated Edge Cache are at the provider’s site or at a common facility for a group of small providers, but other configurations are possible. Some communities may prefer a central database rather than separate Edge Caches, and others may prefer a mixture.
The graphic on the following page (Figure 1) illustrates a HealthShare deployment in a simple configuration – two provider organizations and a medical laboratory sharing clinical data with each other.
Figure 1. HealthShare architecture. In this example, data flows from clinical and lab systems to Edge Cache Repositories as updates occur in those departmental systems. As new patients are added at the participating organizations, they are entered into the EMPI at the Hub, which keeps track of which Gateways contain information for each patient. Physicians at the group practice (and elsewhere) use the HealthShare EPR to see a consolidated, organized, episode-of-care-based picture of their patients’ medical history.
Using HealthShare
The role of each HealthShare component is best shown through a simple example. Suppose a doctor at the group practice wants to obtain a patient’s clinical data. Fundamentally, there are three steps: (a) identifying the patient and determining the locations of the patient’s clinical information, (b) obtaining the patient’s information from the various sites and putting it into the clinician’s local EPR, and (c) displaying and interacting with the patient’s data. Often, an assistant will have performed the first two steps – either the night before or as the patient enters the office.
To identify the patient and the locations of the patient’s data, a query is sent to the HealthShare Hub (through the provider’s Gateway), and the Hub returns a message that specifies which Gateways have information about the patient. The provider’s Gateway then sends a message to each of those other Gateways. Those messages might request all of the patient’s data, or they might include a filter to only return a more limited amount. Each of those Gateways then retrieves the requested information from its Edge Cache Repository and sends it back to the clinician’s Gateway. The clinician’s Gateway then passes those messages to the clinician’s HealthShare EPR (or such other EPR the physician might have that is capable of reading the messages), which stores them in its local database. Once obtained, that data remains locally in the EPR for reuse until the clinician deletes the record (or until some preassigned period of time elapses).
The HealthShare EPR
The clinician’s use of the system is all through the HealthShare EPR, which is based upon TrakCare – a sophisticated Web-based EPR application proven through extensive use in hundreds of hospitals worldwide. However, organizations also have the option of using their own medical record system – as long as that system supports the same standards and protocols used by HealthShare and, if necessary, can support unnormalized terminology.
To perform a community-wide patient search, the HealthShare EPR connects through the provider’s Gateway to the Hub and to the other Gateways that have data for that patient. It then assembles the data it receives from multiple sites and multiple clinical episodes, providing a rich, comprehensive, patient-centric view.
The EPR provides an intuitive display of a wide variety of information types, 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. Data is organized in clinical categories as a series of tabs (see Figure 2). The timeline above the tabs displays each episode and its associated time period, which can be used to quickly select a particular episode to examine. In Figure 3, the doctor has chosen to view the patient’s current medications.
Figure 2. HealthShare EPR displaying a patient’s recent encounters at several facilities.
Figure 3. HealthShare EPR displaying the patient’s medications.
Because HealthShare is highly configurable, the actual steps/screens used can vary significantly to reflect local requirements and multiple languages. The clinician can also export detailed information from the EPR as a Clinical Document Architecture (CDA) document for use in other applications.
HealthShare EPR utilizes self-documenting data technology, so it is capable of receiving and displaying unnormalized terminology from multiple sources.
As a Web-based technology, the HealthShare EPR is extremely easy to deploy and support. It only requires a Web browser, and there are no client-side components to install.
The HealthShare Hub
The HealthShare Hub is based upon Ensemble, and it provides three functions:
- Identity management determines whether two records at different providers are for the same or different patients
- Clinical patient index determines which providers have information for a given patient
- Administrative information, such as an authorized list of users, Gateway addresses, and security and privacy information
Because data is gathered by several different organizations, for any regional or national system to work, there must be a way to uniquely identify a patient and determine which data at different providers belongs to the same patient. There may be a national identification number, which makes the problem simpler, but that is not always the case.
When there is no national identification number, identify management is typically provided by an EMPI, which is already widely used by IDNs and hospital chains.
For organizations that already have an EMPI, the HealthShare Hub will use that EMPI. For those that don’t, HealthShare includes built-in support for several leading identity management products, and it can be adapted to support others.
What is stored in the EMPI is very minimal. No clinical data is stored – just summary patient demographic information along with the identifiers used by each provider to identify that patient. Information in the patient index is bulk loaded when a provider joins the program. Thereafter, it is continually updated as changes occur at care sites – for instance, as new patients are added, existing patients’ data is updated, or two patient records are discovered to belong to the same person, requiring that the existing records be merged.
EMPIs provide sophisticated matching technology that can perform searches with a variety of demographic data. However, the use of an EMPI still requires a manual review of some new patients.
The HealthShare Edge Cache Repository
When a request is made to obtain the clinical data for a patient for a particular provider, there are three possible sources for the data:
- All clinical data could be stored in and retrieved from a central database (e.g., located at the HealthShare Hub)
- A request could be made to an electronic medical records system of the provider, or even to the source systems of the provider
- A request could be made to an Edge Cache – a database that contains all the clinical data the provider is willing to share
HealthShare supports all three strategies, although the Edge Cache approach is generally the most practical. A central database is often too unwieldy, and providers no longer have control over their information. Passing requests to a provider’s source systems has several problems: (a) many source systems do not have a service-oriented architecture (SOA) that can respond to requests – instead they simply have the ability to pass transactional data such as lab results to other systems as they occur, (b) there may be serious response time problems with having to query multiple source systems, and (c) there may be times when particular source systems are unavailable. Passing requests to an electronic medical records system of the provider is more practical, but may still suffer from the same problems, and for security reasons, many providers may not believe it to be a good approach. For primary care and small group practices, the systems may not even be available 24-hours a day.
Another significant advantage to having an Edge Cache is that it can be queried using business intelligence or SQL reporting tools to derive utilization, public health, research, and other useful information. Terminology throughout the region or nation may not be normalized, but it is likely to be within a single Edge Cache, which makes queries more useful.
The HealthShare Edge Cache Repository is a sophisticated health database using the TrakCare technology – the same technology used in the HealthShare EPR – and the Caché object database. As transactions containing clinical data occur, the source systems send messages to the provider’s Gateway, which transforms the messages and passes them to the provider’s Edge Cache where they are stored.
Typically, each Gateway has its own Edge Cache, and each large provider has its own Gateway and associated Edge Cache. Small providers (e.g., primary care physicians and small group practices) often share a single computer for their Gateway and Edge Caches. Each Edge Cache only stores the clinical information of the provider(s) sharing the same Gateway. However, other configurations are possible, and in an extreme case, the Edge Caches are all in a centralized database.
Because the data in source systems (such as a practice management system in a physician’s office or a hospital’s EPR) could become unavailable, the Edge Cache is important to maintaining data availability through any disruption. The Edge Cache is designed to operate 24-hours a day, every day of the year.
The HealthShare Gateway
The HealthShare Gateway is based upon Ensemble – a rapid integration platform widely used in healthcare as an interface engine and for building and running composite applications.
The HealthShare Gateway is responsible for all communications between:
- A clinical site and its associated Edge Cache
- A clinical site and the Hub
- Gateway-to-Gateway communications between clinical sites
Each Gateway also provides:
- A consent management framework that is used to record patient consent declarations and to enforce those declarations
- Data normalization and terminology services, if any are available and required
- Message protocol transformations
When a provider’s system generates information that can be shared, it sends a message to the Gateway (e.g., when the lab completes a test, the lab result is sent to the Gateway). The Gateway examines that message to determine the nature of the information and its suitability for being cached. If suitable, it then transforms the message into one using a standard HealthShare protocol and transmits it to the Edge Cache for storage.
When a clinician requests information about a patient – typically through the HealthShare EPR – the EPR sends a message to the clinician’s Gateway, which then communicates with the HealthShare Hub. Once the Hub identifies which other Gateways need to be contacted, the clinician’s Gateway contacts those Gateways and requests the patient’s data from those sites. Those Gateways query their associated Edge Cache, and return the resulting data in an XML document back to the originating Gateway, which then provides all the XML documents it received from various other Gateways back to the requesting EPR.
HealthShare has the flexibility to either have Gateways directly contact other Gateways or to pass all Gateway messages through the Hub. In some cases, a mixture is appropriate.
III. Advanced Features
Terminology Services
Different provider organizations may use different terminology, which makes the sharing of information more difficult. Ideally, provider organizations would either convert to a common terminology or at least agree upon and support a common standard for interchange. However, in many cases, that is not practical, or at least it will take considerable time.
HealthShare does not require a common terminology. The HealthShare EPR and Edge Cache employ self-documenting data technology so they can store and display unnormalized terminology from multiple sources.
For providers that wish to share normalized terminology, HealthShare provides the option of working with several leaders in application-independent terminology services. These services translate between different standard medical vocabularies, including SNOMED, ICD 9/10, CPT, and LOINC, and they can be incorporated into the Gateway. Setup of these translation services is the responsibility of each provider organization.
Enhancing Functionality
Organizations, like people, need to grow to survive, and a connected healthcare system needs to be able to evolve as the needs of the healthcare community and its patients evolve. The initial connection and sharing of information is only the beginning. An important question is, does the system provide the foundations for future growth and rapid adaptation?
The connectivity in HealthShare is provided by Ensemble, which includes support for business processes and workflow management. It also enables a new generation of applications called “composite applications”. Plus HealthShare also incorporates Caché, making it easier to add additional functionality.
Ensemble Business Processes
Different communities often have different requirements. For example, one community may wish to trigger public health alerts upon various events. Furthermore, the nature of the events or the action taken might vary from one patient to another – perhaps for female patients we need to query a maternity system before taking further action.
A powerful technique to accommodate these needs is through using Ensemble’s business processes. Ensemble allows the specification of several business rules and processes unique to the organization and then automatically applies those rules and processes.
Because the business rules and processes are defined at a high level and fully encapsulated, they are easily modified. Thus, application or site-specific differences and evolving needs are rapidly accommodated without modifying HealthShare or its adapters (described below).
Composite Applications
Composite applications are a new generation of applications based upon connected systems. Often such applications have little or no database of their own and instead rely upon the data of connected systems. Composite applications frequently access not just the data, but also the functionality – the application logic – of other applications, often using an SOA. Ensemble includes an advanced development environment for rapidly building rich composite applications.
The HealthShare EPR is an example of a composite application; it relies upon the clinical information stored in a variety of provider sites in formats unknown to the EPR. Another example would be the introduction of community-wide clinical orders or e-prescribing without the ordering application being aware of how the various provider applications actually process the orders. It simply utilizes a common object-oriented interface that accesses the functionality of those various applications.
It is easy to see how once a healthcare organization’s applications are connected, composite applications become a very powerful mechanism for addressing evolving functionality.
Connectivity
To succeed, a national system must enable connecting reliably and with minimal cost and effort to a large number of existing clinical applications. HealthShare accomplishes this by using Ensemble technologies that are particularly powerful for this purpose, including adapters, data transformations, and advanced programming capabilities for unusual requirements.
Ensemble Adapters
Ensemble Adapters are reusable software components that provide connectivity to applications and that isolate all application-specific logic from the rest of the system through an object interface. Ensemble includes an extensive library of prebuilt adapters that will meet the needs of many systems. Where the source or target applications do not permit the use of standard adapters, custom adapters can be rapidly created – usually by simply extending (“subclassing”) an existing adapter.
In most cases, some “flavor” of HL7 v2 will be employed to connect to existing clinical applications. With built-in support for HL7 v2 and v3 schemas, and its powerful virtual document architecture, HealthShare provides the richest and fastest HL7-based connectivity available today.
However, not all applications communicate through HL7. In fact, some applications do not have any standard way to communicate. When an integration technology emphasizes how many adapters it has or the number of applications to which it can connect, there’s a real risk that it doesn’t connect to the one special application you need. That’s why Ensemble’s programming capabilities are critical. They easily support the development of completely unique adapters.
Ensemble Data Transformations
The Ensemble transformation engine performs any required message set translation, other message normalization, or modification tasks. These may be as simple as removing or reordering fields in a message, or might involve complex processing to convert application-specific messages to standard forms. Ensemble includes an extensible transformation class for converting HL7 v2 and v3 responses from participating applications to a standard CDA format. New or existing transformations can be specified graphically or via an XML-based transformation “language”. For especially unusual cases, Ensemble’s programming capabilities can always be used.
Standards
Standards are the key to interoperability. By adopting standards at every phase of data exchange, the system ensures the ability to interface not only with new and existing clinical systems, but also with other regional or national health information solutions.
The HealthShare Gateway is based upon Ensemble. Ensemble supports a wide variety of healthcare data and interoperability standards, as shown below. It supports HL7 v2 and v3, and InterSystems is a member of the HL7 standards body. Ensemble 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 is an active participant in the efforts of the Integrating the Healthcare Enterprise (IHE) to improve the way computer systems in healthcare share information.
When connecting with other technologies, we endeavor to use messaging/data standards wherever available. Gateway-to-Hub and Gateway-to-Gateway communication typically uses standard message formats transmitted via Web services. Gateway-to-Hub communication uses the Record Locator Service (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 standards | |
|---|---|
| HL7 v2 | Health Level 7 version 2 (www.hl7.org) |
| HL7 v3 | Health Level 7 version 3 (www.hl7.org) |
| CDA | Clinical Document Architecture (www.ansi.org) |
| CCD | Clinical Care Record (CCR) encapsulated in CDA (www.astm.org) |
| DICOM | Digital Imaging and Communications in Medicine (medical.nema.org) |
| NCPDP | National Council for Prescription Drug Programs (www.ncpdp.org) |
| RLS | Record Locator Service (www.connectingforhealth.org) |
| Healthcare data exchange standards supported by HealthShare. | |
However, when HealthShare is communicating internally with other HealthShare components, it often switches automatically to a higher-performance proprietary protocol that results in faster response time and higher scalability.
Privacy and Security
Consent Management
HealthShare provides built-in consent management. Consent is enforced in two general ways:
- Patient matching: When the Hub receives a request for matches, the Hub returns only those patients who have agreed to be listed in the EMPI
- Clinical data: When a Gateway receives a request for data for a specific patient, the Gateway returns only those portions of the records that the patient has agreed to share
The system can be configured to either require explicit consent by each patient or to assume consent unless the patient explicitly specifies otherwise.
Security
HealthShare utilizes a range of advanced technologies to enforce strict adherence to privacy and security standards, including encryption, strong authentication, role-based privileges, granular security policies, and tamper-resistant audit logs.
HealthShare’s built-in Caché 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. Connection requests between Gateways and between the Gateways and the Hub are only accepted if the requesting 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 EPR 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 Key Distribution Center (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 are defined for various levels of user access and assigned to users as needed. Additional roles can 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.
IV. Operating a HealthShare System
Performance and Scalability
Unless a system provides immediate response at the point-of-care, physicians will not use it. HealthShare provides rapid access to clinical data, even when serving thousands of simultaneous users in a regional or nation-wide deployment.
Scalability is equally important. Many shared health information programs will start as pilots, with perhaps a few hundred thousand patients, and then grow over time by one or two orders of magnitude or 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 Caché’s unique Enterprise Cache Protocol (ECP), which can connect multiple computers together to access a shared database as if all users were running on the same computer, scalability for healthcare applications has been proven to tens of thousands of concurrent users and millions of patients.
Reliability and High Availability
HealthShare is designed to run 24-hours a day, every day of the year. To ensure such high availability, HealthShare relies on the automatic persistence architecture of Caché and Ensemble, which deliver a full range of high-availability features, including:
- Full and incremental backups while applications are running and databases are changing
- Transaction logging and roll forward recovery, for transaction integrity
- Write image journaling to protect database integrity
- Shadow Servers for rapid failover
- Clustered databases
- ECP with automatic failover to backup data servers
In addition, HealthShare automatically saves the message “state” at each stage of its processing in its built-in Caché database. In the event of a system crash or other failure, this enables rapid and reliable recovery.
Monitoring and Administration
With lots of “moving parts” – often hundreds of Gateways and thousands of clinical systems with constant change on any given day – perhaps the most difficult challenge faced by the operations staff will be to rapidly find, diagnose, and correct any problems.
HealthShare’s use of Ensemble brings two powerful advantages to this battle: automatic logging and a powerful monitoring and administration console designed for remote systems management. Ensemble 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 10 hospital systems. Each of those requests and responses is logged for full traceability.
Message trace (see Figure 4) is just one of the facilities provided by the Ensemble Management Portal. Because the Management Portal is browser-based, an administrator with necessary security privileges can investigate a problem anywhere in the network from any location.
Figure 4. HealthShare leverages the Ensemble Visual Trace facility to easily monitor messages and message content.
V. Conclusion
The HealthShare approach to the sharing of clinical information is to base the system upon proven clinical information technology while incorporating the ability to rapidly extend the functionality to address diverse needs. HealthShare does this by utilizing the EPR and Edge Cache database structure of TrakCare, along with the Caché advanced object database and the Ensemble integration platform. This approach also makes it easy to connect with – or incorporate – any of the many healthcare applications provided by InterSystems’ partners.
HealthShare is highly standards-based with strong security, and is built with the premise that the core of a system sharing health information should be the patient record. With this patient-centric view, systems that may initially only share a minimal amount of data have a solid foundation for expanding as usage and functionality demands grow.
Getting connected is just the first step. With HealthShare, a community is in a position to evolve by introducing – or building – composite applications to provide extended functionality, such as community-wide clinical orders or e-prescribing, and to utilize easily modifiable business rules and processes to adapt to changing needs.
Building on more than three decades of delivering software that supports the main healthcare applications of thousands of healthcare systems worldwide, InterSystems’ track record for providing high-performance, extremely scalable software is recognized throughout the healthcare sector. While the pilot for a shared health information program may only include a limited number of patients, the ability to scale up to support millions of patients and many thousands of users is an absolute requirement for full-scale deployment.
For more information
For more information, visit the InterSystems HealthShare web site at: InterSystems.com/HealthShare.
Magic Quadrant for Application Infrastructure for Composite-Application Projects, 2Q07 Publication Date: 7 June 2007 ID Number: G00147640 Top 20 Year End in KLAS Report. KLAS confidential Information. © 2006 KLAS Enterprises, LLC. All rights reserved. www.healthcomputing.com