EHR Patterns -Advantages and Challenges

This is an extract from a presentation which i gave recently where i have been asked to present the different EHR architecturial patterns and the advantages and challenges associated with each of the patterns

There are three types of EHR Models/Patterns which are in wide use

Ø Central Repository Model
Ø Federated Model
Ø Hybrid Model

Central Repository

Features

Ø Health record is stored at point of care systems as well as a common repository
Ø Patients record is identified by a unique identifier which may be allocated by the central repository or a national organization
Ø Local record may be a detailed record and the shared record a summary record
Ø Thin EHR

Advantages

Ø Easy and Quicker access to the data
Ø Security controls easy to implement compared to federated model
Ø Better price/performance ratio
Ø Data can be entered into the local systems or directly
Ø Allows data to be cleansed and its terminology standardized by reference to a canonical controlled vocabulary
Ø Consistent interpretation of data by different clinical settings


Challenges

Ø Determining ownership of data between organizations
Ø Infrastructure and scalability issues
Ø Decoupling and Business continuity issues
Ø Resolving conflicting data issues between central and local e.g. allergies information
Ø Governance and funding issues between different organizations

Federated Model

Features

Ø Health record is stored at their places of origin- point of care systems
Ø Patients unified record is fetched from different systems using patient indexes and record locator services
Ø The fetched record will usually be a agreed subset of data in the point-of-care systems
Ø Thick EHR

Advantages

Ø Avoids the infrastructure and ownership issues that are barriers to information sharing.
Ø Decentralized data approach safeguards privacy and security by affording a pathway that facilitates information exchange while leaving appropriate controls in place.
Ø Infrastructure can be relatively small and requires less capital and ongoing operating expense.
Ø Data can be managed locally
e.g. deletions without considering the impact on data sharing.


Challenges

Ø Appealing in theory but has many implementation and performance difficulties in practice, particularly for large systems with many records and many different federated EHR sources (or EHR nodes).

Ø Rely on a number of factors such as efficient distributed queries, short latencies, and compatible security models and are only as good as the weakest link in the chain.

Hybrid

Features

Ø Combination of the two architecture types
Ø Patients record are identified by a combination of identifiers – national and local
Ø Central record has only demographics and limited clinical data with access control and record locators for detailed data
Ø Thin and Thick EHR

Advantages

Ø Provides all of the advantages of a centralized data architecture for the most relevant clinical data required for care.
Ø Provides benefits of the federated architecture with access to detailed record
Ø Local systems still retain control of their data with access to relevant patient
data from other organizations


Challenges

Ø Deciding the scope of shared data and unshared data
Ø Different access controls required locally and centrally for similar data of a patient.

Message Sequencing in HL7V2.x

Maintaining message sequencing when clinical systems are integrated with in an enterprise using middleware approach and HL7V2.x message specifications is crucial from two perspectives

• Delivering messages in the order is crucial for HL7 messaging; for example an A03-Discharge message cannot arrive before an A04-register a patient or A01- Admit notification. In case of orders a Modify Order cannot reach before a Create New Order is sent
• If a sender needs to send an extremely large message to a receiver, typically containing multiple OBX segments it is impractical to send all the segments into a single message as it will not fit into a single message. The breaking the message into parts and sending each of the parts as a separate message requires that each message needs to indicate its position in the sequence and indicate the total number of messages to expect.

The obvious solution to maintain the messages in sequence in the order they are received and to keep them in sequence as they travel through the middleware-Integration Engine. The solution may be as simple as sending all HL7 ADT messages from the HIS/PAS system to departmental systems in the hospital in the order that they were generated. This can be done by allowing a single-threaded route from the originating application usually the HIS/PAS to the middleware-integration engine. This usually means implementation of a behavior where messages are sent to a single point (Fixed IP address and Port number) and a receipt of acknowledgement message for the previously sent message before the next message is sent.

However for large organizations with huge volumes of messages it is not feasable to maintain a single thread and implementation of multi-threading might disrupt the delivery of messages in the order which they arrive.


One way to solve the problem associated with message sequencing for multi-threaded solutions is to keep messages in sequence that contain information related to the same entity which can be the patient identifier and allow the middleware to route all the messages related to a particular patient or a rane of patinets based on the patient identifier range over the same thread.

Approach – A – Single Threaded Solution

Messages must be delivered by the sending system in sequence using a single communication channel with the integration engine. Messages are received from HIS/PAS through TCP/IP Socket Listener and are allocated a sequence number. The sequence number, and message control id (MSH-10) are persisted either onto the disk or to the database associated with the integration engine. Each of the message that is sent are checked against the stored sequence number and message control id to verify if messages are sent in sequence.

Approach – B – Multi Threaded Solution

When a message is received by the middleware it is allocated a sequence number and the number along with the patient id taken from message are persisted to the disk or database. In case of multi-threaded solution the messages can be processed in parallel by any of the thread which subscribes to the publisher of the message. The thread which picked up the message for processing checks to see if a message has been is delivered through that thread for the patient in the message by looking at the patient id. If it is established messages for that patient in fact have been sent through that thread then a check is made to see if the sequence number of the current message is greater or lower than previously sent stored message. On confirmation of the value of sequence number value the message is delivered to the destination system. The delivery status of the message can be stored in the system so that in case of non-delivery suitable rehydration mechanism can be established before delivering the next message with the same patient id.