Hospital multi-system data interaction method based on standardized intermediate adaptation layer

Abstract

The embodiment of the invention provides a hospital multi-system data interaction method based on a standardized intermediate adaptation layer, and relates to the field of medical informationization, and the method comprises the steps: system access and protocol adaptation: configuring access parameters of a nursing system and a core system, and selecting manufacturer protocols corresponding to the two systems; analyzing a manufacturer protocol, and converting the manufacturer protocol into an internal standard protocol; standardized conversion of data formats: converting the data formats according to a preset unified medical data model, and correcting abnormal fields; data interaction scheduling and monitoring: pushing the data to a target system in real time or at regular time according to business requirements; the data interaction process is monitored in real time, and abnormal conditions are processed. According to the technical scheme, the problem of'data islands' caused by heterogeneous system interface protocols and data formats of different manufacturers can be solved.

Description

Technical Field

[0001] This application relates to the field of medical information technology, and more specifically, to a method for multi-system data interaction in hospitals based on a standardized intermediate adaptation layer. Background Technology

[0002] With the deepening of informatization in hospital nursing services, the interaction needs between systems such as mobile nursing (bedside medical order execution), intelligent nursing dashboards (real-time monitoring of patient status), and smart bedside (patient information display) and HIS (medical order issuance), LIS (laboratory information system), and PACS (image report viewing) are becoming increasingly frequent. However, the current medical informatization market has significant pain points: Inconsistent interface protocols: Different manufacturers use different protocols for their systems. For example, HIS manufacturers mostly support HL7 v2, LIS manufacturers may use RESTful, and smart bedside device manufacturers may even use proprietary protocols, making it impossible for systems to communicate directly. Data format heterogeneity: The field names and data types of the same business data are inconsistent. For example, the patient ID is "PatID" (string) in vendor A's system and "PatientNo" (number) in vendor B's system, which makes it impossible to directly associate the data. The integration efficiency is extremely low: In the traditional "direct pairing" model, N (N-1) / 2 sets of interfaces need to be developed to integrate with N systems. For example, 6 sets of interfaces are needed to integrate with 4 systems. The development cycle is long and the maintenance cost is high. Business interruption risk: When the vendor's interface is updated, the integration logic needs to be redeveloped and the system restarted, which may cause interruption of nursing services (such as bedside medical order execution); Unreliable data interaction: The lack of unified scheduling and monitoring makes it easy for data loss and delays to occur, affecting nursing decisions (such as failure to obtain critical test values ​​in a timely manner).

[0003] In existing solutions, some hospitals use "data conversion tools" to solve format issues, but these only support single format conversion and lack protocol parsing capabilities; other solutions achieve connection through "interface gateways," but require static configuration of protocol rules and have poor scalability. Therefore, there is an urgent need for a standardized intermediate adaptation layer that integrates "protocol adaptation, format conversion, and interactive scheduling" to achieve efficient and reliable interoperability among multiple systems. Summary of the Invention

[0004] The embodiments of this application provide a hospital multi-system data interaction method based on a standardized intermediate adaptation layer to solve the technical problems existing in the prior art.

[0005] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0006] According to a first aspect of the embodiments of this application, a hospital multi-system data interaction method based on a standardized intermediate adaptation layer is provided, including: System access and protocol adaptation: Configure access parameters for nursing systems and core systems, and select the corresponding vendor protocols for the two systems; parse the vendor protocols and convert them into internal standard protocols; Data format standardization and conversion: Convert data format according to a preset unified medical data model and correct abnormal fields; Data interaction scheduling and monitoring: Choose to push data to the target system in real time or on a schedule according to business needs; monitor the data interaction process in real time and handle abnormal situations.

[0007] In some embodiments of this application, based on the foregoing scheme, the vendor protocol includes: HL7 v2 protocol, RESTful protocol and proprietary protocol.

[0008] In some embodiments of this application, based on the aforementioned scheme, when the vendor's agreement is updated, the system is dynamically updated by adjusting the parsing logic online.

[0009] In some embodiments of this application, based on the foregoing scheme, the parsing of the vendor protocol and conversion into an internal standard protocol includes: Identify the vendor's protocol type and convert non-standard protocols into internal standard protocols.

[0010] In some embodiments of this application, based on the foregoing scheme, the unified medical data model includes: a patient information model and a test result model.

[0011] In some embodiments of this application, based on the foregoing scheme, the correction of the abnormal field includes: Add missing fields and correct incorrect formats through cross-validation.

[0012] In some embodiments of this application, the process of selecting real-time push data according to business needs based on the foregoing scheme includes: When encountering bedside medical order execution scenarios or critical test value push scenarios, a real-time push mode is adopted, with an interaction delay of less than 1 second.

[0013] In some embodiments of this application, based on the foregoing scheme, the process of selecting timed data push according to business needs includes: When encountering scenarios involving nursing smart dashboard data statistics, data can be pushed out in batches at custom intervals.

[0014] In some embodiments of this application, based on the foregoing scheme, the real-time monitoring of the data interaction process and the handling of abnormal situations include: When a data transmission failure is detected, the system will retry N times at a set interval. If the failure still occurs, a log will be logged and an SMS alarm will be triggered, where N is a positive integer greater than or equal to 3. Set an interaction timeout threshold, and mark "interaction error" after the timeout. The system displays the interaction status of each system in real time, including the number of successes / failures and the delay time. Logs can be filtered by system and business type, and the log retention period is greater than or equal to M years, where M is a positive integer greater than or equal to 1.

[0015] The technical solution of this application has the following beneficial effects: Significantly improved integration efficiency: The workload for integrating with N systems is reduced from N(N-1) / 2 to N times. For example, when integrating with 5 systems, the traditional solution requires 10 sets of interfaces, while this invention only requires 5 sets, shortening the development cycle by 60%. Wide compatibility coverage: Compatible with over 95% of mainstream medical system manufacturers (such as Neusoft, Winning, and Wanda Information), supporting HL7 v2 / v3, DICOM, RESTful, SOAP, and 10+ proprietary protocols; Data interaction performance optimization: data conversion latency <1 second, real-time interaction success rate reaches 99.9%, meeting the timeliness requirements of bedside nursing services; Reduced maintenance costs: When vendor interfaces are updated, the adjustment cycle is shortened from 15 days to 3 days, resulting in a 50% reduction in annual maintenance costs; Business continuity assurance: Supports online rule updates and system expansion, with no risk of business interruption, meeting the hospital's 24 / 7 operation requirements.

[0016] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1 A flowchart illustrating a hospital multi-system data interaction method based on a standardized intermediate adapter layer according to an embodiment of this application is shown. Detailed Implementation

[0018] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0019] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0020] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0021] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0023] The following detailed description of some embodiments of this application will be provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0024] See Figure 1 The diagram illustrates a flowchart of a hospital multi-system data interaction method based on a standardized intermediate adapter layer according to an embodiment of this application.

[0025] like Figure 1As shown, a method for data interaction between multiple hospital systems based on a standardized intermediate adaptation layer is presented, specifically including steps S100 to S300.

[0026] refer to Figure 1 Step S100, System Access and Protocol Adaptation: Configure the access parameters for the nursing system and the core system, and select the corresponding vendor protocols for the two systems; parse the vendor protocols and convert them into internal standard protocols.

[0027] It should be noted that, in this embodiment, the nursing system can be a mobile nursing system or a smart bedside nursing system.

[0028] In some feasible embodiments, based on the foregoing scheme, the vendor protocol includes: HL7 v2 protocol, RESTful protocol and proprietary protocol.

[0029] In some feasible embodiments, based on the aforementioned scheme, when the vendor's protocol is updated, the system is dynamically updated by adjusting the parsing logic online.

[0030] For example, the process is as follows: When the vendor protocol is updated, the parsing logic (such as field mapping relationships) can be adjusted online through the "rule management interface" of the adaptation layer without restarting the system, and the update takes effect in less than 5 minutes.

[0031] In some feasible embodiments, based on the foregoing scheme, the parsing of the vendor protocol and its conversion into an internal standard protocol includes: Identify the vendor's protocol type and convert non-standard protocols into internal standard protocols.

[0032] It is understandable that non-standard protocols can refer to proprietary protocols.

[0033] Continue to refer to Figure 1 Step S200, Data format standardization conversion: The data format is converted according to the preset unified medical data model, and abnormal fields are corrected.

[0034] In some feasible embodiments, based on the aforementioned scheme, the unified medical data model includes: a patient information model and a test result model.

[0035] For example, the specific process of data format conversion is as follows: First, define a unified healthcare data model: The adaptation layer pre-defines the core data model for medical business, for example: Patient information model: PatientID (unique patient identifier), Name, Gender, Age, BedNo; Test result model: OrderID (medical order ID), TestItem (test item), Result (result), Reference (reference value), ReportTime (report time); Then, the data is converted using format conversion rules, as follows: The system automatically matches the output format with a unified model, for example, converting "PatientNo (number)" from vendor A to "PatientID (string)" and mapping "Test_Name" from vendor B to "TestItem", with a conversion accuracy of ≥99%.

[0036] In some feasible embodiments, based on the foregoing scheme, the corrected anomaly field includes: Add missing fields and correct incorrect formats through cross-validation.

[0037] For example, when a character-based age is formatted incorrectly, it can be corrected by matching the patient's birth date to calculate the age.

[0038] Continue to refer to Figure 1 Step S300, Data Interaction Scheduling and Monitoring: Choose to push data to the target system in real time or on a schedule according to business needs; monitor the data interaction process in real time and handle abnormal situations.

[0039] In some feasible embodiments, based on the aforementioned scheme, the process of selecting real-time data push according to business needs includes: When encountering bedside medical order execution scenarios or critical test value push scenarios, a real-time push mode is adopted, with an interaction delay of less than 1 second.

[0040] In some feasible embodiments, based on the aforementioned scheme, the process of selecting timed data push according to business needs includes: When encountering scenarios involving nursing smart dashboard data statistics, data can be pushed out in batches at custom intervals.

[0041] It should be noted that in this embodiment, the custom cycle is 5 minutes / time.

[0042] In some feasible embodiments, based on the foregoing scheme, the real-time monitoring of the data interaction process and the handling of abnormal situations include: When a data transmission failure is detected, the system will retry N times at a set interval. If the failure still occurs, a log will be logged and an SMS alarm will be triggered, where N is a positive integer greater than or equal to 3. Set an interaction timeout threshold, and mark "interaction error" after the timeout. The system displays the interaction status of each system in real time, including the number of successes / failures and the delay time. Logs can be filtered by system and business type, and the log retention period is greater than or equal to M years, where M is a positive integer greater than or equal to 1.

[0043] The following example, using the "Nursing Multi-System Interoperability" project of a tertiary hospital, illustrates this method.

[0044] (1) Implementation environment Systems to be integrated: Mobile nursing system (vendor A, proprietary protocol), nursing smart dashboard (vendor B, RESTful protocol), smart bedside device (vendor C, MQTT protocol), HIS system (vendor D, HL7 v2 protocol), LIS system (vendor E, HL7 v3 protocol). Adaptation layer deployment: Adopting a cloud-native architecture, deployed on the hospital's intranet server (CPU: 16 cores, memory: 32GB), supporting horizontal scaling.

[0045] (2) Implementation steps System access configuration (1 day): Configure access parameters for the 5 systems and select the corresponding protocols (e.g., select "Vendor A Proprietary Protocol" for mobile nursing and "HL7 v2" for HIS). The protocol adaptation module loads the protocol parsing rules of each manufacturer and completes the initial adaptation.

[0046] Data model mapping (0.5 days): The unified data model was fine-tuned according to the needs of hospitals (such as adding a "history of allergies" field). Configure format conversion rules, for example, map vendor A's "Bed_Num" to "BedNo", and directly reuse vendor D's "PatientID".

[0047] Scheduling rule settings (0.5 days): The "Medical Order Interaction" between mobile nursing and HIS is set to real-time mode; The nursing dashboard and the LIS's "Laboratory Result Statistics" are set to a 5-minute timer mode; Abnormal threshold: Timeout of 3 seconds, retry 3 times, alarm pushed to nursing department and operation and maintenance team.

[0048] Effect verification (2 days): Functional verification: Mobile nursing successfully retrieves HIS medical orders (response time 0.8 seconds), smart bedside devices synchronize vital signs to HIS (100% success rate), and the nursing dashboard displays LIS test results in real time; Stress test: Simulating 1000 interaction requests per minute, the adaptation layer's processing latency remained stable at <1 second with no packet loss; Dynamic update test: Modify the parsing rules of the "Medical Order Status" field in vendor A's proprietary protocol. The changes take effect online in 3 minutes without any business interruption.

[0049] (3) Implementation effect Integration efficiency: Only 5 sets of interfaces are needed to integrate 5 systems, reducing workload by 50% compared to the traditional solution (10 sets), and shortening the implementation cycle from 15 days to 4 days; Interaction performance: Real-time interaction latency is 0.6-0.9 seconds, and the accuracy of timed interaction data is 99.9%. Ease of maintenance: After one month, the vendor D updates the HL7 v2 protocol, requiring only adjustments to the parsing rules at the adaptation layer (completed in 1 hour), without needing to modify the HIS and mobile care system.

[0050] Other embodiments of this application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. It should be understood that this application is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for multi-system data interaction in hospitals based on a standardized intermediate adaptation layer, characterized in that, include: System access and protocol adaptation: Configure the access parameters for the nursing system and the core system, and select the corresponding vendor protocols for the two systems; Parse the vendor's protocol and convert it into an internal standard protocol; Data format standardization and conversion: Convert data format according to a preset unified medical data model and correct abnormal fields; Data interaction scheduling and monitoring: Based on business needs, data can be pushed to the target system in real time or on a scheduled basis; Monitor the data interaction process in real time and handle any abnormal situations.

2. The method according to claim 1, characterized in that, The vendor protocols include: HL7 v2 protocol, RESTful protocol, and proprietary protocol.

3. The method according to claim 1, characterized in that, When the vendor's protocol is updated, the system is dynamically updated by adjusting the parsing logic online.

4. The method according to claim 1, characterized in that, The parsing of vendor protocols, converted into internal standard protocols, includes: Identify the vendor's protocol type and convert non-standard protocols into internal standard protocols.

5. The method according to claim 1, characterized in that, The unified medical data model includes: a patient information model and a test result model.

6. The method according to claim 1, characterized in that, The corrected exception fields include: Add missing fields and correct incorrect formats through cross-validation.

7. The method according to claim 1, characterized in that, The process of selecting real-time data push based on business needs includes: When encountering bedside medical order execution scenarios or critical test value push scenarios, a real-time push mode is adopted, with an interaction delay of less than 1 second.

8. The method according to claim 1, characterized in that, The process of selecting scheduled data push based on business needs includes: When encountering scenarios involving nursing smart dashboard data statistics, data can be pushed out in batches at custom intervals.

9. The method according to claim 1, characterized in that, The real-time monitoring data interaction process, and the handling of abnormal situations, includes: When a data transmission failure is detected, the system will retry N times at a set interval. If the failure still occurs, a log will be logged and an SMS alarm will be triggered, where N is a positive integer greater than or equal to 3. Set an interaction timeout threshold, and mark "interaction error" after the timeout. The system displays the interaction status of each system in real time, including the number of successes / failures and the delay time. Logs can be filtered by system and business type, and the log retention period is greater than or equal to M years, where M is a positive integer greater than or equal to 1.

Images