What kind of middleware can help hospitals achieve deep autonomous control over the integrated platform?

One of the most important concerns for hospitals in the construction of an integrated platform is how to achieve autonomous control over the platform. While the integrated platform is considered the "main artery" of the hospital, deep autonomous control becomes more and more crucial. The core middleware of the integrated platform is an important factor in helping hospitals achieve this level of autonomous control.

For the vast majority of hospitals, the integrated platform is seen as the "foundation" for realizing their information construction ideas. The openness and ease-of-use of the core middleware of the platform determines whether this tool is "handy" enough to achieve shallow-level autonomous control over the integrated platform. However, for hospitals to take full control of the platform and use it as the "main artery", both management and technical capabilities are necessary. Many hospital information directors believe that the key to achieving deep-level autonomous control over the integrated platform lies in whether the technology of the platform middleware can be integrated into the hospital's business and management philosophy, and even guide the hospital to form a set of integrated platform operation and management models to optimize business processes.

Ease-of-use and openness: key factors in achieving shallow-level autonomous control over the integrated platform.

After the integrated platform is built, it often becomes a“black box”. Hospitals may have difficulty performing secondary development and controlling the platform as a result. Therefore, the usability and openness of the core middleware of the integrated platform are important factors for hospitals to achieve preliminary autonomous control.

To achieve this, the core component of the integrated platform (middleware) needs to integrate various data integration and exchange technologies, such as integration engines, ESB, ETL, APIs and so on, to greatly enhance the coverage of the integrated platform for hospital business. At the same time, a lot of development work is required to meet the localization needs of hospitals and increase the ease-of-use features that are commonly used in China but not provided by internationally renowned brands, such as built-in API gateways, authentication management, various standard definitions, data processing and conversion tools, PDF export components, etc. The platform also needs to be compatible with domestic servers and operating systems for plug-and-play capability.

Additionally, the usability of the platform can be demonstrated through Chinese language interfaces, pure web-based operational interfaces, and visual tools, making operations and maintenance more straightforward and reducing the learning curve. In terms of openness, features such as 90% API openness and graphical low-code development interfaces can also help hospital technicians quickly and easily use and perform secondary development without the need for third-party intervention.

Case Study: Rapid Launch of "Health Code" Application

During the outbreak of COVID-19 in China, hospitals across the country needed to quickly respond to the promotion of the national "health code". Zhejiang Taizhou Hospital used a user-friendly and open integration platform, which allowed a skilled technician in the hospital's information department to complete all service deployments independently within one hour. In contrast, the traditional interface model would have taken 2-3 days of development work. If the platform had been less user-friendly (with a high development threshold), the hospital would have had to wait for professional support. If the platform had been less open, even hospitals with independent development capabilities would have needed to go through the vendor's authorization process before proceeding.

Deep-level implementation of autonomous and controllable integrated platform

Quickly respond to fragmented demands and ensure stable delivery of each integrated business

Due to the complexity and diversity of hospital business requirements, the integrated platform sometimes needs to face various "tomorrow's" demands, which require a small amount of work but are more complicated, and at the same time, the quality of such integrated business needs to be guaranteed. How to quickly respond to these fragmented demands through the cluster middleware architecture, avoid "mistakes in busyness", and even form a set of solidified processes and concepts with the help of the integrated platform to ensure the quality and quantity of delivery for each integrated business is one of the main challenges faced by hospitals.

Facing the challenge of fragmented demands in hospitals, the core component (integration middleware) of the integrated platform should break through the traditional "giving fish" approach of piling up functions, and instead, form a set of DevOps-standardized management methodology through "teaching fishing", and build a solid environmental foundation for this management process, such as the isolation of production / development dual environments, separation of development/testing/audit/management personnel with different permissions. By skillfully using the above environments for development, it can naturally guide the hospital to form a standardized management process, help the hospital cope with fragmented demands, and ensure stable delivery of each integrated business.

API gateway and microservices

With the continuous increase of demands, more and more projects are connected to the integrated platform. In terms of business, hospitals have concerns about the use and management of a large number of interfaces. In terms of architecture, some hospitals are also trying microservices architecture but are struggling with the cumbersome and complex communication process of microservices architecture.

Therefore, the middleware of the integrated platform needs to embed API gateway service applications, which have API management functions such as authentication management, traffic control, black and white list, and access control. This not only solves the hospital's concerns about interface management and monitoring, improves user experience but also simplifies the communication process of the entire microservices architecture, which is an important part of implementing the microservices architecture.

Various risk investigations in operation and maintenance

In the daily operation and maintenance process of hospitals, sometimes they may receive complaints from various departments that the system is very slow or even not working. There may be various reasons behind it, such as data exchange issues in the integrated platform and message abnormalities in the integration. Due to queue compression, it may lead to access-side faults and abnormal exceptions of the server. How to quickly locate and solve these problems, reduce the risks brought by the problems, is also something that hospitals need to consider.

Therefore, the monitoring interface of the integrated platform usually integrates scattered interfaces through a unified entry point for analysis and viewing. If the information is not effectively integrated, it is not conducive to daily fault handling and analysis. The core component (integration middleware) of the integrated platform should realize interface integration, including unified development, testing, management, operation and maintenance, and monitoring interfaces. It can not only troubleshoot problems in the first time when problems occur but also combine with situational awareness functions to advance warning on some abnormal values in data exchange and integration processes (such as message volume in the queue, processing delay of the published service), prompting operation and maintenance personnel to check and control the problem at the source, and take preventive measures.

Conclusion

In previous communications, the director of the hospital information center believed that it is necessary to select the most suitable integrated platform and corresponding solutions based on the actual situation of hospital information construction.

(1) For hospitals that use integrated platforms as "lubricants", they need to achieve shallow-level autonomy and control of the integrated platform. At this time, the integrated platform should have:

• Openness and ease of use, to help hospitals achieve daily operation and development of the integrated platform;

(2) For large tertiary hospitals that use integrated platforms as "arteries", deep-level autonomy and control need to be achieved. They can choose the middleware of cluster architecture integrated platform:

• Unified development, testing, management, operation, and monitoring interfaces, which can perform risk control and prevention in advance through functions such as situational awareness;
• Embedded API gateways, supporting the construction of microservices architecture, or even the integrated middleware itself is a microservices architecture;
• Providing an environment foundation for standardized DevOps management.