The Different Flavors of Healthcare Integration
Why do ESBs and Integration Engines provide different solution approaches for Healthcare scenarios? Both are application integration solutions.
In the development of an integration platform, hospitals are faced with various scenarios of data interactions and information integration, and often do not know what kind of data exchange middleware technology should be used to optimally achieve data transmission between systems. Such as:
- There are many integration types and protocols, such as Web Services, database, HTTP, HL7, etc. How to choose?
- Under what circumstances do calls between systems need to be synchronised, and under what circumstances do they need to be processed asynchronously?
- If a notification involves multiple systems, how will the messages be distributed?
- A query may involve different business systems or databases. In what way?
- If an external system exception causes a message flow to fail. How do you deal with these exception messages?
Problems of this nature are frequently encountered in project practice. In order to solve these problems appropriately, it is necessary to have an understanding of the data exchange technology of the integration platforms.
ESB (Enterprise Service Bus) and Integration Engines (IE for short) are both core middleware solutions used to realise data transmission and the information interactions of an integration platform. After analysing your actual application scenarios, you must choose or combine these two solutions.
These kinds of technology solutions can deal very well with the problems articulated above. However, sometimes the application of ESB and IE solutions will be rather vague, and inappropriate use will often occur.
What are the key differences between ESB and IE? What are the technical priorities and advantages and disadvantages of each?
This article will specifically reference some application scenarios from Taizhou Hospital Information Center, based south of Shanghai in China.
What is ESB
ESB is a good general solution for API service coordination and orchestration . During data integration, applications can directly call services in the ESB, which can greatly reduce the complexity and workload of interface access, and significantly reduce the difficulty and cost of implementation.
1. Features of ESB
Provided services: provides routing, data conversion and translation according to a customer’s requests and events.
Fast parallel processing of messages: Without guaranteeing the order of messages or service requests, different requests can be processed at the same time to achieve a high-performance request response mode.
Focus on synchronous message processing: After receiving an external system call service request, you must wait for the connected application system to process the request, and then return the result to the external system after the processing is completed. If the external system fails to call the service, the external system is responsible for retrying the service again.
2. The advantages and disadvantages of ESB
Advantages: It can support different access systems and transmission modes, has high transmission efficiency, is easy to implement in a cluster architecture, improves the flexibility of the information system architecture, and reduces the cost of internal information sharing.
Disadvantages: A lack of support for Healthcare standards means, significant secondary development is required for the particularities of the Healthcare industry, resulting in high implementation and maintenance costs.
What is IE
Compared with the versatility of ESB, the Integration Engine is a data exchange integration tool designed specifically for the Healthcare industry. It is focused on applications in medical scenarios. Its main purpose is to achieve interoperability between different systems or applications and to enable business processes. The data interactions are typically message oriented integrations.
1. Features of IE
Guaranteed message transmission: They record the entire message processing process and the messages of each node. The contents are stored for a set period of time for users to view or reprocess after any corrections.
Focused on asynchronous processing of messages: After receiving a request from an external system, the Integration Engine can immediately respond to an external system, and the external system will complete the work. The Integration Engine is responsible for the subsequent processing of the message. If subsequent processing of the message fails, the Integration Engine will be responsible for retrying to transmit the message to the recipient of the message.
Ensures the order of message transmission: In the Healthcare sector, the order of messages is often extremely important. When guaranteeing the order of message transmission, a single thread is required to process the received messages one by one.
Supported medical standards: The traditional Integration Engines designed for the Healthcare industry, support more comprehensive medical standards, such as HL7, CDA, FHIR, etc.
Ease of use: Some Integration Engine products are simply configured products with industry standard characteristics and embedded common functions in healthcare scenarios, eliminating the need for further coding and shortening project cycles.
2. The advantages and disadvantages of IE
Advantages: HL7 message-based integration between different internal departments can be achieved. Integration Engines are designed for Healthcare data exchange and are easy to implement and use.
Disadvantages: Traditional Integration Engines struggle to implement cluster architectures, and they have a single point of failure. Therefore, functional bottlenecks often occur with high concurrency and large traffic environments, and even downtime in severe cases. In hospitals that only use Integration Engines, the IT department engineers will often be troubled by the stability and usability of the platform.
Application scenarios of ESB and IE in hospitals
1. Outpatient appointment business process
(a) Scenario business analysis
Appointment capacity query: This determines the number of people who can be registered for a medical consultation during a day. It is the number of people that the hospital can accept for appointments. It is based on the number of doctors on duty in each department and the average speed of diagnosis and treatment.
A unified appointment information query interface is used for this. It provides source query services for in-hospital kiosks and service desks, patient mobile apps, and external appointment platforms.
Outpatient appointment service: Patients and their families can make online appointment registrations across 4 hospitals under the group through this hospital or a third-party appointment platform, and return the appointment results.
Outpatient appointment cancellation service: Patients and family members can cancel appointments that have been booked.
(b) Scenario technical analysis
The Appointment capacity query requires a fast response speed, synchronisation processing, and its response time cannot exceed 3 seconds. The content of the query can be flexibly adjusted according to business changes.
Outpatient appointment and cancellation services have low response requirements, but need to ensure the transmission of messages and the order of transmission. Therefore, the appointment and cancellation of appointments on the application side are processed asynchronously, and the reception of result information can be queried by sending text messages or refreshing.
Therefore, in this scenario, the appointment capacity query service is suitable for implementation through ESB, and the outpatient appointment and cancellation services are suitable for implementation through IE. When processing all requests for an external input, it is necessary to continuously adjust according to the requirements of the data transmission mode in the specific business.
2. Laboratory test business process
(a) Scenario business analysis
This process includes the notification of the ordering of a laboratory test request, the notification of billing confirmation for the request, the notification of the specimen collection, the notification of the specimen submission, the notification of the specimen acceptance, the notification of specimen return, the notification of the laboratory report review, and any corresponding cancellation notifications.
In this scenario, the process and message paths are determined by the keywords in the message header, and the HIS and LIS databases are asynchronously interacted with through a service number.
(b) Scenario technical analysis
In the business scenario of the laboratory test order, it is very important to ensure the transmission of the message and the transmission sequence of the inspection related stages.
IE is a more suitable integrated middleware for the laboratory test order scenario.
3. Internal data exchange business process
(a) Scenario business analysis
Different systems in a hospital will have external interfaces that can be called. These interface clients are from various systems, including Electronic Medical Record (EMR), diagnostic machine and other systems and clients. The interface types called are also diverse. It is necessary to manage and distribute these through a unified internal system, so that the internal interfaces can be managed more effectively and the interactions can be monitored and standardised.
(b) Scenario technical analysis
Since these data requests may come from multiple sources, to multiple services, and the data throughput is large with high concurrency, the requirement is for query distribution and management.
ESB is more suitable for the data transmission mode in this scenario. Realising parallel processing and a fast response.
Scenario based determination of technology
It can be seen that ESB and IE have their own focus and are suitable for different application scenarios in hospitals. ESB is suitable for scenarios that require fast response, synchronous processing of messages, high concurrency, and high data throughput. IE is more suitable for scenarios where the response speed of message requests is not high, but message transmission and transmission order need to be guaranteed, and messages are processed asynchronously.
At present, the development of regional Healthcare, Healthcare groups, and Community Healthcare continues to advance, and hospitals are playing more and new roles.
The emergence of new technologies and environments, such as 5G, hybrid cloud, Internet of Things, and containerisation, has made application updates and iterations faster and faster. Data exchange within hospitals or between multiple hospitals will continue to increase, and online and offline services will be more convenient. What follows is that hospitals will face more complex and diverse scenarios.
Therefore, when a hospital builds an Integration Platform, the appropriate data exchange technologies should be selected. It should not be limited to one technical solution, but should be based on scenario requirements, practical application impacts, combined with the current situation and the hospital’s future information direction.
Flexible use of the various technologies enables the possibility to better exploit the full value of an integrated platform, and empower clinical business development.
Eric van der Sluis
Odin Health
Source: http://www.odinhealth.co.nz/en/resources/whitepaper-DiffFlavours.html