Background
Healthcare facilities often use complex software systems provided by various independent vendors. Typically these can be classified into
• Hospital Information System • Radiology Information System
• Laboratory Information System
• Electronic Medical Record
• Electronic Healthcare Record
Synchronization of information among these systems will improve overall efficiency of the systems and save time of data entry into multiple applications. This need for data exchange between multiple systems requires interfaces to be build that can communicate with other systems when new information is entered into any of them. Interfaces can be build either point-to-point or by using an integration engine.
Problem
The point-to-point communications model has each pair of applications communicating independently of the other applications. The point to point interfacing is best when the number of applications that need interfacing is very less. When many applications need to communicate, point to point face the following issues:
• It is very expensive to initially implement communications.
• It is expensive and time consuming to add new or replace existing applications
• Require considerable time and money to monitor and maintain the connections over the life of the applications.
This necessitates an Interface engine that can act as an intermediary between the disparate systems. The paper details on how an interface engine provides more control of the information being passed in a multi-application healthcare environment while saving time and effort.
Solution
A good interface engine gives the healthcare organization the ability to get data from wherever it is, do whatever data manipulation is required and deliver that data to whatever destination, repository, or device they wish, and do all of this invisibly.
An interface engine is designed to simplify connecting, maintaining, monitoring, and sharing data between applications. An interface engine can take data from a sending application and filter it or change the format of the data to match destination application’s needs.
Basically it is a software program designed to simplify the creation and management of interfaces between separate applications and systems, either within the organization or with other affiliated organizations. Interface engines undertake messaging between systems, and normally manage any mapping, translation and data modification necessary to ensure the effective exchange of data around the organization.
This feature greatly reduces the number of individual endpoints required to communicate between applications, which in turn, saves on the price of implementing an integrated system. We can define an Interface engine as:
A healthcare organization’s “communications exchange” for clinical and business data, ensuring that information passes smoothly and quickly from one healthcare organization’s computer system to another.
Generally two types of interfaces are used to transmit information across applications.
1. The Master Patient Information: This data provides the data for the Admit, Discharge, or Transfer of a patient.
2. Observation Results. This is data from one or more clinical systems such as Hematology, Radiology, Pathology, and the Transcription services for such clinical systems. The observation data is further separated into two sub-categories:
a. Static data. For the end user, these are view-only reports.
b. Dynamic data: The end user can update these reports.
There is a synchronization dependency between Master Patient Information and Observation results. The ADT data associated with a patient’s visit must be acquired before the observation data for any clinical work associated with the visit. The MPI data must be received and accepted by the receiving application before any associated observation results is forwarded to the receiver.
The Master Patient Information
ADT data is associated with patient Admission, Discharge, and Transfer events. ADT data is used to form the Master Patient Index (MPI). ADT data contains all the information necessary to create a Master Patient Index. They do not contain data that is entered into a report. The ADT records form the basis for checks performed at the receiving application when observation results are received.
ADT data is sent from an HIS or EMR system to the Integration Engine. The Integration Engine may respond with an acknowledgement to verify the data was received successfully, but it never initiates the transfer. After processing the ADT data, the Integration Engine copies the processed data (also referred to as “filtered” data) to the receiving application. This could be a database of the receiving system, a web service used by the application to update information or any other receiving methodologies.
The entry of ADT data does not generate a report. However all subsequent reports related to clinical observation results will be checked against the MPI derived from the ADT data.
Observation results
The logical content of clinical observation results is different than MPI data. Observation results include enough information to perform a look up in the Master Patient Index and also whatever clinical information is necessary to generate a complete report. The data flow for clinical observation results is similar to that for MPI data, but differs in that two logical data sets are produced from the input:
• Metadata including event and patient information.
• The electronic document(s) that will be viewed through the receiving application.
The input data for a document includes metadata that specifies patient and event information. The metadata is used to map the document to the appropriate patient. An error may be logged if the patient MPI information does not exist in the receiving application.
The processing inside the Integration Engine and the data flow after processing is significantly different for clinical observation. The input data format for MPI is usually HL7, whereas the input data for clinical observation varies in format (HL7, PDF, RTF). Even if the data for a given clinical observation happens to be HL7, the processing is different than the processing for MPI because the required output is different. The formatted output documents are generally placed in a file server.
If the input is an HL7 message, it is formatted into a PDF/HTML report using XSLT. This report is sent to the image server. Patient metadata is extracted from predetermined HL7 fields. This metadata is passed along with the report to the receiving application to be mapped with existing patient information.
For PDF inputs, X-Y coordinates along with the height and length of required fields are used to extract metadata. The predetermined fields need to be at the exact location for each document that comes through the interface. The minimum fields required to map a document with the MPI information available in the receiving application are the Medical Record Number (MRN), Episode/Visit Number and the document type.
Available Interface Engines
• InterSystems, the leading provider of application development and database technology (Cache’) behind the most widely used applications in healthcare, released Ensemble in November 2003.
• Orion Health’s Rhapsody easy-to-use suite of applications and tools integrate and enhance existing healthcare information systems and deliver secure, universal access to information. Orion delivers an end-to-end IT integration platform that brings together clinical content to improve clinician effectiveness and the quality of patient care. Rhapsody was released in January 2002.
• Cloverleaf Integration Services by Quovadx provides enterprise-wide system integration within a Services Oriented Integration Architecture (SOIA). Cloverleaf Integration Services is a proven, reliable integration technology specifically tailored for the healthcare industry. The first major product was installed in 1992.
• Siemens OPENLink provides a configurable tool, usable by business and systems analysts without requiring a computer programming background. It was released to the market as an interface engine with the “SMS OPENLink” branding in 1990.
• Sun Microsystems SeeBeyond began development of the first commercial EAI broker back in 1989 with the first sale and deployment of eGate Integrator (formerly "DataGate") occurring in 1991. It is currently renamed to JCAPS by Sun.
• Microsoft BizTalk Server is a business process management (BPM) server. Through the use of "adapters" which are tailored to communicate with different software systems used in a large enterprise, it enables companies to automate and integrate business processes. The first version was the BizTalk Server 2000.
0 comments:
Post a Comment