Having architected, designed and developed multiple systems – products, services, solutions – in the healthcare domain, I’ve come to realize that the domain is still in a nascent stage of technology innovation. Healthcare Information Systems (HIS) are still running on fairly primitive tools, technologies and systems, and they have few – if any – external interfaces that allow them to integrate with the contemporary world.
HIS’ work in technology and data/information silos; they are designed primarily to keep data – such as Electronic Health Records (EHR) and Electronic Medical Records (EMR) *in* rather than share information with cooperating systems. The arcane nature of these systems results patients, physicians, hospitals and insurance companies being unable to get access to the right information at the critical time to make informed, intelligent and optimal decisions.
First, the legacy data that is EHR/EMR sitting inside millions of silos needs to be available to the right people, at the right time, at the right place – it needs to move. Second, EHRs are a large component of Big Data. The data volume created by EHRs is massively significant, because an EHR represents a lifetime of you or me. If the phrase “actionable information” ever had real importance, it’s in relation to your EHR. That “actionable information” can be used by hospitals to predict patient illnesses or visits and thus improve their efficiency and patient relationships; it can be used by insurance companies to provide optimal premiums and increase their profitability; it can be used by physicians and patients to track patient health records and improve patient health.
The Obamacare Meaningful Use (MU) stages are meant to address some of these issues. There are, however, few comprehensive, coherent and omniscient solutions that address these issues. There are even fewer – if any – technology and process frameworks or templates that allow solution providers and systems integrators to build solutions to these problems.
A technical template or framework of a healthcare information system integration solution that allows EHR/EMR data to be used meaningfully is proposed below.
- EMR Database
- Transport Bridging
- Message Protocol Bridging
- Enterprise Service Bus
- Messaging (CDM)
- Dashboard, Management and Monitoring
- Event Processing
- BPM and Workflow
- Business Rules, Analysis and Intelligence
- Business Services (APIs)
An EMR database may be used to temporarily or permanently hold EMR/EHR/patient records that are extracted from disparate HIS systems. System integration frameworks that store such data must be aware that their database will contain PHI data and may be subject to security audits and certifications. Some frameworks will store data temporarily (as a cache), to be wiped out after the user log out of the framework’s portal. Other frameworks will store data permanently, after resolving conflicts between records across different HIS systems.
When a system integration framework connects to, extracts EHR/EMR/patient data from multiple HIS systems, and stores it permanently, its database is often the “source of truth” or golden record for disparate patient data. That is, the database will hold the master data of a patient across all HIS systems, and will need to be kept updated at regular intervals.
Such a database is typically the electronic data warehouse (EDW) for multiple HIS systems, and both physicians (including hospital administrators) and patients may have secured access to the data in that database. The data in the database may also be used for analytics, both for marketing and clinical needs.
EMR databases may be either RDBMS-based or NoSQL-Document-based, but rarely both (because of the overhead involved in synchronizing databases). Databases that hold master/ consolidated EMR/EHR/patient data will need to be replicated to be fault tolerant.
A set of adapters or a system integration framework as a whole will need to be configuration driven, thereby minimizing the number and amount of code changes needed to modify the behavior of the framework. This means that almost everything within the framework – from look and feel (user interface), to language, to HIS connectivity, to locating endpoints, to data transformations, validations and enrichment, to workflow orchestration, to management and monitoring – will need to be configurable.
System integration frameworks may choose to adopt database-driven or file driven configuration, or a combination of both. Frameworks that use database-driven configuration may use RDBMS or NoSQL-based databases depending on their requirements. Frameworks that have a lot of user data or are extremely modular or componentized often use NoSQL, document databases like MongoDB because each user’s preferences or the configuration of each module or component can be isolated within its own document in the database. Often, file or document-driven configurations will be used in version controlled environments to allow end users to safely modify the configurations without fear of catastrophically and irreversibly modifying them.
Other frameworks that are more functional or workflow oriented will prefer RDBMS-based configurations, since functions and workflows are often dependent on multiple, related components/users/modules.
The nature of 3rd party HIS systems is to communicate with the external world using transport choices that are either the most prevalent at the time or the most efficient in the context of the usage of the HIS systems. HIS systems have their own transport systems, ranging from the traditional TCP/IP to the non-traditional UDP, to the common ones such as HTTP, SMTP or FTP.
The system integration framework needs to “understand” the transport protocol(s) used by the HIS systems both for sending and receiving data. For example, when reading data from a Cerner system’s database, the framework needs to send and receive JDBC or ODBC messages over TCP/IP. But, when invoking Cerner Millennium Objects APIs, the the framework needs to send and receive REST messages over HTTPS.
A robust system integration framework will have templatized classes or objects that represent various transport protocols. At runtime, when attempting to communicate with an HIS system, the framework will use the factory design pattern to instantiate an object of the specific transport protocol that is needed to communicate with the HIS system. In this way, both transport bridging code and functionality can be reused across HIS systems and across sessions.
Message Protocol Bridging
Messaging protocols represent the most wide variety of differences amongst HIS systems. A messaging protocol is the internal (and external) representation of an EMR/EHR/patient record. Typically, most legacy HIS systems implement and use their own, custom messaging protocols. Some systems like Cerner and Meditech use primitive, inaccessible protocols like JDBC/ODBC, that offer direct, SQL-based access to their RDBMS-based data sets. Others, like Cerner MO and Epic offer web service API-based messaging protocols, such as SOAP and REST. Yet others expose data externally using CCDAs, HL7 or proprietary XMLs.
As with transport bridging, the system integration framework needs to “understand” the message protocol(s) used by the HIS systems both for sending and receiving data.
A robust system integration framework will have templatized classes or objects that represent various message protocols. At runtime, when attempting to understand the data/messages sent by an HIS system, the framework will use the factory design pattern to instantiate an object of the specific message protocol that is needed to interpret the data in the HIS system. In this way, both message bridging code and functionality can be reused across HIS systems and across sessions.
Enterprise Service Bus (ESB)
This is the heart of the HIS integration framework. It is responsible for coordinating amongst various services, resolving data conflicts, routing data from one location/service to another, enabling transformation/ validation/ enrichment, orchestrating healthcare workflows, filtering and intercepting messages and requests and enforcing business rules both on the workflows and on the data.
While most ESBs are based on queueing systems (JMS, MQ) and follow the publish-subscribe paradigm, there are several ESBs that are based on point-to-point, request-reply systems (Web Services, RMI). Services such as data transformation, data enrichment, data validation, data conflict resolution, business rules enforcement, workflow orchestration and event processing are deployed as plug-and-play components on the ESB; the ESB routes messages (in a common format or CDM) from one service/ component to another.
Such an ESB-driven system integration adheres to Service Oriented Architecture (SOA) paradigms. In an SOA environment, both integration components and 3rd party HIS systems are viewed as services on the bus, in such a way that they offer a single view of a patient (through business service APIs). Additionally, a Healthcare ESB (a.k.a. HSB) offers interoperability between components – the ability of heterogeneous HIS systems and software applications to communicate, to exchange data accurately, effectively, and consistently, and to use the information that has been exchanged.
This includes the creation and use of a common data model or format that holds a “superset” of the EMR data that is retrieved from, or sent to various HIS systems. Most CDMs are proprietary to the solution and customer, and are typically either text-based (XML/JSON) or object based (Java or C# objects).
Object-based CDMs are first serialized to make them suitable for over-the-wire transmission. XML and JSON-based CDMs are often wrapped inside an envelope – such as a SOAP envelope – before transmission. This allows the sender to transmit, and receiver to receive various forms of content such as Laboratory, Pathology, Radiology, Blood Bank, etc., in the same envelope, without breaking the ESB.
CDMs normally have a one-to-one relationship with the database. That is, if the database is meant to hold EHR/EMR/patient records, the database schema will closely mirror the CDM’s model. This allows ORM tools such as Hibernate (Java) and ADO.NET (C#) to effectively and quickly store and retrieve EMR data to/from the database.
Some solutions may use CCDAs or HL7s as the CDM. Others may prefer to use their own CDMs to improve storage efficiency and processing speed.
Dashboard, Management and Monitoring
An HIS system integration framework is tasked with dealing with critical, human data that affects the quality of life of patients. Consequently, it’s mandatory for the system to be functioning smoothly (accurately, quickly and efficiently) and notifying its authorized administrators of its own health, status and issues.
Each service and component in the system needs to report its current health to a dashboard, be open to status queries from a central monitoring service, and be able to start up or shut down remotely, on command from a management service. Consequently, every service needs to be built with “hooks” or callouts in it for monitoring and management.
A monitoring service will typically query other services about their CPU usage, memory usage, processing time/ performance/ load and audit/log trails. A management service will typically request services to start up, shut down, pause or resume. A dashboard will typically present the findings of the management and monitoring services in a single page, along with the abilities for system administrators to send commands to the management service.
Additionally, the framework will contain the ability to notify system administrators and users (hospital administrators, physicians and patients) of issues, status updates and news (most of which are generated by the management and monitoring services).
The system integration framework will receive and process everything in the form of events. This includes receiving events and requests for reads, writes, updates and deletes, and processing them through filters and interceptors.
For example, when physician uses a secure app to view a patient’s Lab records, that “request” is sent to the framework, which receives it as an event. An event is something that triggers an action in the system. In this example, the request for patient Lab data triggers a set of “chained” (sequential) actions called interceptors that authenticate and authorize the user and the request event, and then validate, enrich and transform it into a CDM before pushing that event on the ESB.
Subsequent actions are triggered in the ESB, such as routing the request event to multiple adapters (transport, protocol and messaging bridges) for data extraction from HIS systems. Alternatively, the ESB may route the request event to a BPM workflow that may orchestrate a set of actions or transactions.
When data is being sent out of the framework, such as Radiology or Lab returns for a patient are being sent back to the user after a request was issued, the adapter first sends the data to the ESB – which, once again, treats it as an event (a response event). The response event or data is passed through a set of filters for processing (the filters, for example, filter out irrelevant, empty or null data), or may be sent to a rules engine for consolidation (combining data from HIS1, 2, and 3 into a single record), or may be sent to a different workflow in the BPM engine for more detailed processing.
BPM and Workflow Orchestration
When data and events are flowing within the system integration framework (from one service/ component to another) and externally (to and from HIS systems and users), they typically need to be modified and/or analyzed, because, let’s face it, raw patient data is typically meaningless to most systems and users.
In most cases, data and events don’t undergo just one level or instance of modification or analysis. Instead, they are subjected to multiple levels of scrutiny (authentication, authorization, validation), modification (enrichment, bridging, transformation), consolidation (conflict resolution, application of rules) and transmission (storage into the Master Database – MDB, sent to physicians, alerts sent to hospitals and insurance companies).
All these instances of modification and analysis are parts of one or more business processes or parts of a larger workflow. That is where Business Process Management and Workflow Orchestration are used. The HIS system integration framework must contain a BPM or workflow orchestration engine that can execute these tasks and business processes in the right sequence, with the right parameters and in the right environment.
For example, a hospital administrator may issue a request to the HIS system integration framework to “ask” it if a patient’s disease and health is worsening. The HIS system integration framework, upon receiving the request event, may trigger a “SeachPatientHistory” workflow, that could in turn trigger requests to multiple adapters to retrieve patient data from multiple HIS systems, then trigger requests to a filter to eliminate unnecessary data, then trigger a set of business rules to consolidate data, then trigger a analysis engine that examines values of various parameters in the Lab reports, finally returning the patient’s history in chronological order of worsening health conditions.
Business Rules, Analysis and Intelligence
While the main function of the HIS/EMR/EHR system integration framework is to, literally, “integrate” data from multiple HIS systems, the data remains just that – data – and not usable information, until it is analyzed. The business rules engine, combined with optional analytics and business intelligence logic analyzes data that is stored in the EMR’s database for patterns, events and meaningful information.
Note that because the volume of incoming data from multiple HIS systems is very high, a real-time rules engine, real-time analytics engine or real-time BI engine is not recommended, since this will impose an abnormally high processing load on the system integration framework’s database. Instead, these engines operate on clinical data (indeed, non-clinical data too) in an offline, batch mode, normally at times when the users’ load on the system is minimal.
These engines analyze the data in the EMR database and look for patterns, such as worsening health conditions of a patient, increasing visits of a patient to various hospitals, missed or erratic medications, conflicting health reports or allergy information for a patient, and much more. The results of the analysis are useful to physicians and insurance companies in improving their services to patients/customers.
Business Services (APIs)
The business functions of the system integration framework, such as “PullDataFromHIS1” or “GetPatientDataAsCCDA” or “ExportPatientEMRAsHL7” will be consumed by applications (B2B) and users (B2C). Therefore, such functions must be exposed as externally accessible, secure APIs.
The APIs can be based on any open protocol, transport and messaging standards, though the recommended ones are SOAP or JSON protocols traveling over REST or HTTP or JMS, being carried as HL7 or CCDA messages. If the APIs will be consumed or called by internal or intranet applications, then they need not be secure, but if they are meant to be used by external, 3rd party applications and users, then they will need to be secured using SSL.
Such APIs will typically perform functions such as create, start, stop or modify workflows, retrieve data from HIS systems, consolidate data from multiple disparate HIS systems, send messages/data to HIS systems, monitor the health of the framework and HIS systems, and query the HIS systems for business analytics and intelligence information.
It is important to note that typically, the business service APIs are the only interfaces that the framework will publicly expose to the external world. Internal functions, services, workflows and processes of the framework cannot and should not be exposed as APIs because of security and stability concerns.