Method and system for business interconnection and intercommunication of medical community based on platform and data double bus

Abstract

The present application relates to the technical field of data processing, in particular to a medical community business interconnection method and system based on platform and data double bus, through the double mode of timing and real-time collection and standardization of each institution heterogeneous business data, a unified data resource center is constructed; a double bus architecture of platform service bus and data exchange bus cooperation is established, respectively realizing intelligent scheduling of business service and reliable transmission of data; the core business capability is packaged as a standardized reusable service, and the business request is dynamically distributed through the intelligent routing mechanism; through the unified interface layer, the protocol and semantic double adaptive access with external systems are realized; finally, through full link monitoring and multi-modal intelligent diagnosis, abnormal early warning and root cause positioning are realized. The problems such as low data flow efficiency, slow business response, lack of unified scheduling and intelligent routing mechanism in the existing medical community system are solved, and the overall operation efficiency and service capability of the medical community are improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and system for interconnecting medical consortium services based on a platform and a dual data bus. Background Technology

[0002] In the current construction of medical consortia (medical communities), various medical institutions generally face problems such as heterogeneous information systems, inconsistent data standards, and independent business processes. Traditional integration methods often use point-to-point interfaces, resulting in high system coupling, poor scalability, and maintenance difficulties, making it difficult to achieve efficient collaboration and real-time data sharing within the medical consortium. Although some platforms have attempted to address these issues by establishing unified data exchange platforms, problems such as low data flow efficiency, untimely business response, and a lack of unified scheduling and intelligent routing mechanisms still exist, hindering the improvement of the overall operational efficiency and service capabilities of the medical consortium. Summary of the Invention

[0003] The purpose of this invention is to provide a method and system for interconnecting medical consortium services based on a platform and a dual data bus, thereby improving the overall operational efficiency and service capabilities of the medical consortium.

[0004] To achieve the above objectives, in a first aspect, the present invention provides a method for interconnecting and interoperating medical consortium services based on a platform and a dual data bus, comprising the following steps: Heterogeneous business data is extracted in a timed batch or real-time event-driven manner; the extracted raw data is sent to the data resource center for parsing, cleaning, coding standardization and patient identity merging processing to form a standardized thematic database; the extracted raw data includes core diagnosis and treatment data, drug and material data, resource and management data, public health and health data and business collaboration data; A platform service bus is constructed for registering, discovering, scheduling, and monitoring encapsulated business services within the medical consortium; a data exchange bus is constructed for data transmission between different data producers and consumers; the platform service bus and the data exchange bus coordinate and link through metadata; The core business capabilities of the medical consortium are encapsulated into reusable services with standardized interfaces and registered to the platform service bus; through the intelligent routing of the platform service bus, external business requests are dynamically routed to service instances based on business content, system load and preset strategies. The platform receives business requests from external systems through a unified interface service platform, performs protocol conversion, security verification, and semantic mapping, converts external requests into standard internal service call requests, routes them to the corresponding internal services for execution via the platform service bus, and returns the execution results to the external system after reverse conversion. Collect full-link metrics of infrastructure, platform bus, application services, and data quality; perform multimodal anomaly judgment on the collected metrics, and issue graded warnings and notifications based on the anomaly level.

[0005] This includes encapsulating the core business capabilities of the medical consortium into reusable services with standardized interfaces, including: Identify and classify atomic services and composite services, and define a service contract for each service that includes input and output parameters and a quality of service protocol; when a service instance is executed, it obtains standardized data from the data resource center by calling the unified interface provided by the data exchange bus, thereby decoupling business logic from the data source.

[0006] The intelligent routing process specifically includes: When an external business request carrying a service identifier and business context arrives at the intelligent routing gateway of the platform service bus; After the intelligent routing gateway verifies the security of the request, it queries the service registry to obtain a list of available service instances, and combines real-time load information, business context content, and preset routing policies to dynamically calculate and select the optimal target service instance for request forwarding.

[0007] The intelligent routing gateway, based on the global service-data lineage graph, attaches a data prefetch metadata instruction before forwarding a service request, triggering the data exchange bus to push the associated data to the target service instance in advance.

[0008] The process of the unified interface service platform handling external requests includes: Convert external heterogeneous protocol requests into internal intermediate data structures; Based on predefined mapping rules, key parameters of the external data model are mapped to unified identifiers and data models within the medical consortium; The service routing proxy routes the transformed internal requests to the corresponding internal business service for execution. The service obtains the required data and completes the business logic through the data exchange bus. The execution results of internal services are reverse-engineered and returned as a response message that meets the expectations of the external system.

[0009] The semantic mapping stage relies on a mapping rule base that is associated with the medical consortium master data management platform and the patient master index service to ensure accurate conversion between external encoding and internal unified encoding.

[0010] This includes performing multimodal anomaly detection on the collected indicators and issuing graded early warnings and notifications based on the anomaly level, including: Anomaly detection is performed based on preset static thresholds and trend rules; Establish dynamic behavioral baselines for monitoring metrics and detect abnormal patterns that deviate from these baselines; When multiple alarms occur, correlation analysis is performed based on the system dependency topology to locate the root cause, and graded warnings and notifications are issued according to the anomaly level.

[0011] The system includes tiered early warning and notification based on the level of abnormality, including: Early warnings are categorized based on the breadth and depth of the abnormal impact; a diagnostic snapshot is generated that includes an anomaly summary, the scope of impact, preliminary root cause analysis, and action recommendations. Based on the warning level, duty roster, and personnel skill tags, the notification channels and recipients are determined.

[0012] The data exchange bus adopts a unified message hub architecture based on message queues, and implements conditional routing and distribution of data through a data routing and distribution controller.

[0013] Secondly, the present invention provides a medical consortium business interconnection system based on a platform and data dual bus, applied to a medical consortium business interconnection method based on a platform and data dual bus as provided in the first aspect, comprising: The data resource center is used to store thematic databases that have undergone standardization processes. The platform service bus module includes a service registration and discovery center, an intelligent routing gateway, and a service orchestration engine, which are used to implement service registration, discovery, intelligent routing, and process orchestration. The data exchange bus module, including a unified message hub, a data routing and distribution controller, and a format conversion adapter, is used to achieve secure and reliable data transmission and routing. The unified interface service platform module includes an API gateway, a protocol adapter factory, and a semantic mapping and conversion engine, which are used to realize protocol conversion, secure access, and semantic mapping of external systems. The operation monitoring and early warning center includes probes deployed at each layer, a unified monitoring data lake, and a multimodal diagnostic engine, used to achieve end-to-end monitoring, intelligent anomaly diagnosis, and tiered early warning.

[0014] This invention discloses a method and system for interconnecting medical consortium services based on a platform and data dual-bus architecture. It collects and standardizes heterogeneous business data from various institutions in both timed and real-time modes to construct a unified data resource center. A dual-bus architecture is established, with a platform service bus and a data exchange bus working in tandem to achieve intelligent scheduling of business services and reliable data transmission. Core business capabilities are encapsulated into standardized, reusable services, and business requests are dynamically allocated through an intelligent routing mechanism. A unified interface layer enables dual adaptive access to external systems in terms of protocol and semantics. Finally, end-to-end monitoring and multimodal intelligent diagnosis enable anomaly warning and root cause localization. This addresses the problems of low data flow efficiency, untimely business response, and lack of unified scheduling and intelligent routing mechanisms in existing medical consortium systems, thereby improving the overall operational efficiency and service capabilities of the medical consortium. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0016] Figure 1 This is a schematic diagram illustrating the steps of a medical consortium business interconnection method based on a platform and data dual bus according to the first embodiment of the present invention.

[0017] Figure 2 This is a flowchart illustrating the process from external request to internal processing and then to response provided by the present invention.

[0018] Figure 3 This is a schematic diagram of the monitoring and early warning operation provided by the present invention.

[0019] Figure 4 This is a schematic diagram of the electronic device of the present invention. Detailed Implementation

[0020] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0021] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0022] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0023] The first embodiment of this application is as follows: Please see Figures 1-3 This invention provides a method for interconnecting and interoperating medical consortium services based on a platform and a dual data bus, comprising the following steps: S1. Extract heterogeneous business data in a timed batch or real-time event-driven manner; send the extracted raw data to the data resource center for parsing, cleaning, encoding standardization, and patient identity merging processing to form a standardized thematic database.

[0024] Specifically, for large-volume historical data migrations, daily report data, and archived medical records where real-time requirements are not high, the unified task scheduling center deployed at the headquarters of the medical consortium issues extraction instructions to the data collection agents of each member institution according to a preset cycle (e.g., 2:00 AM daily). Database transaction log capture technology is utilized. Logging is enabled on the source business database (e.g., Oracle for the hospital's HIS), and the collection agent monitors log changes in real time. Once a new outpatient record, test result is generated, or medical order is updated, the agent immediately captures the change event. This is applicable to all business processes requiring real-time collaboration, such as critical value reporting, new prescriptions, and referral requests, ensuring zero-latency business operations.

[0025] The data acquisition agent extracts the following core business data from the information systems of various medical institutions based on a predefined data asset catalog: Core diagnostic and treatment data: outpatient and emergency medical records, inpatient medical record cover sheet, admission record, progress notes, examination reports, laboratory results, surgical records, and nursing records.

[0026] Drug and supplies data: drug catalog, inventory information, purchase orders, prescription details, and high-value consumable usage records.

[0027] Resource and management data: master data of medical staff, department information, equipment files, bed status, and financial cost data.

[0028] Public health and health data: residents' electronic health records, chronic disease follow-up records, immunization information, and maternal and child health information.

[0029] Business collaboration data: referral application form, consultation invitation, remote diagnostic images, and traceability code for disinfection packs.

[0030] The extracted data is encapsulated into a standard data packet, containing metadata (such as data source, type, and timestamp) and the business data body. It is then sent to the data resource center using the following methods: Data packets are encrypted using national cryptographic algorithms and transmitted via the hospital's dedicated network or VPN tunnel. A "response-retry" mechanism is employed. Upon successful reception, the data resource center returns an acknowledgment signal; if the reception fails, the acquisition agent temporarily stores the data in a local cache queue and retryes according to a strategy to ensure no data loss. The transmission rate is dynamically adjusted based on network conditions and data priority to avoid congestion.

[0031] After the data arrives at the data resource center, it enters a standardized processing pipeline, which consists of a series of sequentially executed processing units.

[0032] First, a multi-format parser automatically identifies the data packet format (such as XML, JSON, HL7V2 / V3, DICOM) and converts it into an internally unified intermediate model. For unstructured data processing: for CT images, doctor's handwritten scans, etc., their metadata (patient ID, examination time) is extracted and structured, the original files are stored in a distributed file system, and accessible index links are generated.

[0033] Then, the pre-defined data quality rule base is invoked to perform cleaning, including: Integrity check: Check whether key fields (such as patient ID, treatment time) are empty.

[0034] Format compliance verification: such as ID card number format, telephone number format.

[0035] Logical rationality check: For example, the patient's age cannot be 200 years old, and the drug dosage should not exceed the extreme value.

[0036] Intelligent repair: For missing "gender" fields, it can be intelligently deduced from the associated "ID number"; for obvious outliers, it can be automatically marked and trigger a manual review process.

[0037] The system maintains a master data management platform for the medical consortium, which defines a unified standard terminology system across the entire group (e.g., unified disease coding ICD-10, unified drug coding, unified operation coding). The system automatically maps local codes in the source data to standard terms. For example, the local code for "hypertension" used by Hospital A, GXY01, will be automatically mapped to the standard ICD-10 code I10. When encountering ambiguous or conflicting mappings (e.g., "heart failure" may correspond to multiple specific diagnoses), the system calls upon the medical knowledge graph, combined with the medical record context (e.g., examination and test results "elevated BNP"), to help determine the most accurate standardized code.

[0038] The patient master index service is the cornerstone of interoperability. Algorithms (such as weighted matching based on name, ID number, date of birth, and mobile phone number) determine whether medical records from different institutions belong to the same patient and generate a globally unique medical consortium patient ID for them. Multiple outpatient, inpatient, examination, and medication records of the same patient are linked chronologically using the medical consortium patient ID and a unified medical event ID, forming a complete view of the individual's health record.

[0039] Each data processing stage generates quality metrics (such as the number of received records, successful parsing rate, number of mapping failures, and number of duplicate records). These metrics are displayed in real time on the data governance dashboard and can trigger alarms based on thresholds. For example, if a hospital's "encoding mapping failure rate" continuously exceeds the standard, the system will automatically notify the hospital's information technology department to rectify the data source.

[0040] The "standard data" that has been processed through the pipeline is classified and stored in the corresponding thematic databases within the data resource center according to its business theme.

[0041] The storage strategy is as follows: Hot data and real-time indexing: Frequently accessed data such as recent (e.g., within 3 years) electronic medical records and daily test results are stored in a distributed relational database cluster and a full-text index is built to ensure millisecond-level response for queries and retrieval.

[0042] Warm data and historical archives: Earlier historical data is migrated to columnar storage databases or data lakes for offline analysis, scientific research, and large-screen display.

[0043] Data and database correspondence: The core data flow for patient diagnosis and treatment is as follows: electronic medical record database / examination report database / laboratory result database; Example: standardized outpatient medical records, CT imaging reports, and blood glucose test values ​​are stored in the above databases respectively, and are linked through the medical consortium patient ID and unified medical event ID.

[0044] Resource and operational data flow → Medical resource database / operational database. Example: Unified medical staff information, drug catalog, and equipment files are stored in the medical resource database; revenue, cost, and workload indicators are stored in the operation database.

[0045] Public health data flow → Resident health record database; Example: Integrated chronic disease follow-up records and health check-up summaries are stored in this database.

[0046] S2. Construct a platform service bus for registering, discovering, scheduling, and monitoring encapsulated business services within the medical consortium; construct a data exchange bus for data transmission between different data producers and consumers; the platform service bus and the data exchange bus coordinate and link through metadata.

[0047] Specifically, the dual-bus architecture is located between the data resource center and the business application services (encapsulated in step S3), undertaking the core central scheduling and transmission functions. The platform service bus is the scheduling center for business instructions, responsible for receiving, routing, orchestrating, and monitoring all business service requests. The data exchange bus is the data lifeline network, responsible for ensuring reliable, real-time, and secure data transmission between data producers (such as various business systems and the data resource center in step S1) and consumers (such as various services and regulatory applications). The dual-bus architecture directly relies on the high-quality data assets produced in step S1. The data exchange bus reads standardized data from various thematic databases in the data resource center; simultaneously, new data generated during the execution of business services is also written back to the data resource center via the data exchange bus, forming a data closed loop.

[0048] The platform service bus is a distributed service governance platform built upon microservice architecture and enterprise service bus principles. Core components include: Service Registry and Discovery Center: All services encapsulated by business systems (such as image diagnostic services and drug inventory query services) register their network addresses, service interfaces, performance metrics, and other information with this center upon startup. Service consumers locate the services they need by querying this center, enabling dynamic service discovery and invocation.

[0049] Intelligent Routing Gateway: This is the "traffic control core" of the bus. All external business requests first reach this gateway. The gateway has a built-in routing rule engine that can perform intelligent routing based on various strategies: Content-based routing: Parse the disease type in the request (such as "chest pain") and automatically route it to "Chest Pain Center Collaboration Service".

[0050] Load-based routing: Real-time monitoring of CPU and memory usage of each service node, directing new requests to the node with the lowest load.

[0051] Policy-based routing: Based on the medical consortium management policy, such as "community first consultation", initial diagnosis requests are preferentially routed to primary healthcare service nodes.

[0052] Service orchestration engine: For complex business processes (such as "two-way referral" which involves multiple steps such as application, review, receipt, and feedback), this engine can orchestrate multiple single services according to a predetermined process (workflow), execute them automatically, and provide a complete composite service interface to the outside world.

[0053] Unified Security and Authentication Center: Performs identity authentication, authorization (role-based access control), and auditing on all service calls to ensure secure and compliant business access.

[0054] Operating mechanism: When a request for remote ECG diagnosis is sent by a primary care physician: The request arrives at the intelligent routing gateway. After security verification, the gateway queries the service registry to find a list of all available "ECG Diagnostic Service" instances. The routing engine selects the optimal service instance address based on current load, institutional affiliation (prioritizing the local regional center), and other strategies. The gateway forwards the request to the target service instance for processing. During processing, if the service instance needs to access the patient's historical medical records, it will generate a data request (this process triggers the data exchange bus).

[0055] The data exchange bus is a high-performance, highly reliable data pipeline system built upon message queuing and data streaming technologies. Core components include: Unified Messaging Hub: Employs a distributed message queue cluster (such as the Kafka paradigm) as its core. It defines different "topics" for different types of data, such as Topic_EMR (Electronic Medical Record Stream) and Topic_LIS (Test Results Stream). Data producers send messages to specific topics, and consumers subscribe to topics of interest to receive data.

[0056] Data Format Conversion Adapter: Although the data has been standardized in step S1, a unified, compact format (such as Apache Avro) is used during bus transmission to achieve maximum efficiency. This component is responsible for quickly converting the internal data model to the transmission format.

[0057] Data Routing and Distribution Controller: Monitors traffic in the message hub. It can perform not only simple one-to-many broadcasts (such as simultaneously distributing a critical value to departments, doctors, and monitoring platforms), but also complex conditional routing. For example, a piece of "hypertension patient follow-up data" can be simultaneously routed to the "chronic disease management database" for storage and routed in real-time to the "family doctor workbench" for notification.

[0058] Transport security layer: End-to-end encryption is implemented at the transport layer, and each data stream is signed for integrity to prevent data from being tampered with or stolen during transmission.

[0059] Operating mechanism (example of connecting platform bus): When the ECG diagnostic service requires a patient's historical medical records: the service sends a "data subscription / request" message to the data exchange bus, specifying the required data (e.g., Patient ID=123, Data Item=Past ECG Reports). The data routing and distribution controller receives this request and converts it into a query for Topic_EMR (assuming the ECG is stored in the electronic medical record stream). The controller initiates a real-time query from the corresponding topic in the message hub, or directly to the "Examination Report Repository" in the data resource center (step S1), to obtain the required data. The obtained data is packaged by a format conversion adapter and accurately returned to the requesting "ECG diagnostic service" instance through a secure message hub channel.

[0060] The dual buses do not operate in isolation; they establish a global service – a data lineage graph. This graph records the patient's "historical ECG data" and "basic medication records" that a service like "ECG diagnosis" depends on during execution. When the platform service bus routes an ECG diagnosis service request, it can anticipate the data requirements through this graph and proactively trigger the data exchange bus to prefetch data, pushing potentially needed data to the service node cache in advance, thereby significantly reducing service processing latency. Information such as data flow pressure and latency monitored by the data exchange bus can be fed back to the platform service bus's intelligent routing gateway in real time.

[0061] For example, when the gateway detects a request for the "image retrieval" service, the data bus returns "high image data transmission latency". Based on this, the gateway can dynamically adjust its routing strategy, prioritizing sending the next request to the service instance that is closer to the data storage location on the network, or enabling data compression transmission.

[0062] S3. Encapsulate the core business capabilities of the medical consortium into reusable services with standardized interfaces and register them to the platform service bus; through the intelligent routing of the platform service bus, dynamically route external business requests to service instances based on business content, system load, and preset strategies.

[0063] Specifically, in the traditional construction of medical consortia, the systems of various institutions are like "chimneys," with duplicated functions and heterogeneous interfaces. Service-oriented encapsulation aims to solve this problem. Decoupling and reuse: Core business capabilities such as "image diagnosis" and "drug allocation" are separated from specific systems and transformed into independent standard services that can be repeatedly called by multiple applications.

[0064] Simplified integration: Other systems only need to call the service through a unified and simple interface, without having to worry about its complex internal implementation and data source.

[0065] Enhance agility: New services (such as epidemic monitoring and early warning) can be built by quickly combining existing services (such as patient inquiry, medical record retrieval, and message notification) without having to develop them from scratch.

[0066] The encapsulation process follows the principle of "high cohesion and low coupling" and is completed within the service development framework: Service identification and granularity classification: Based on the business processes of the medical consortium, atomic services and composite services are identified.

[0067] Atomic services: Microservices that perform a single, clearly defined function. For example: Unified patient identity verification service: Input a local ID, return the global patient ID within the medical consortium. Standardized prescription issuance service: Input a diagnosis and medication, return a prescription that conforms to the regional prescription set specifications.

[0068] Composite (composite) services: composed of multiple atomic services arranged in a flow. For example: Two-way referral service = referral indication verification service + receiving institution matching service + electronic medical record synchronization service + notification service.

[0069] Standardized Interface Definition: Each service is defined through a service contract, clearly defining its: Functional Description: What the service does. Input / Output Parameters: Strictly adhering to the data standards defined in Step One (e.g., a unified patient information model, drug coding). Service Quality Agreement: Such as response time commitments and availability requirements.

[0070] Service implementation and data binding: Service developers write business logic within the framework. When a service needs data (such as retrieving a patient's historical medical records), it does not directly connect to the database, but instead obtains it by calling the unified data access interface provided by the data exchange bus in step S2. This ensures decoupling between the service and the underlying data source.

[0071] Service registration: The encapsulated service publishes its service contract and network address information to the service registration and discovery center of the platform service bus, announcing its online readiness.

[0072] The following section uses a typical scenario of a primary care physician initiating a remote electrocardiogram (ECG) diagnosis request to explain in detail how a request flows through the dual bus and completes data processing and return.

[0073] Assumption: Patient Mr. Zhang (Medical Consortium Global ID: P123) visited a community health center. The doctor suspected that he had arrhythmia and needed to apply for diagnosis from the regional electrocardiogram center.

[0074] Phase 1: Business request initiation and platform service bus scheduling.

[0075] Request Initiation and Access: When a community doctor clicks "Request Remote ECG Diagnosis" on the workstation, the system generates a structured business request object. This object contains: Service identifier: ApplyRemoteECGDiagnosis; Business context: Patient ID=P123, Requesting institution=Community Center A, Urgency level=Middle, Clinical symptom description=Palpitation, dizziness; Requested data payload: The raw ECG waveform data file acquired in this session (already temporarily stored).

[0076] Security token: A token for verifying the doctor's identity.

[0077] Platform service bus processing chain: Unified Gateway Access and Security Authentication: The request first arrives at the intelligent routing gateway on the platform service bus. The gateway immediately verifies the validity of the security token and whether the doctor is authorized to request this service.

[0078] Service Discovery and Intelligent Routing: The gateway resolves the service identifier ApplyRemoteECGDiagnosis and queries the service registry for all available instances of the service (e.g., potentially distributed across multiple ECG centers such as the Municipal People's Hospital and the County Central Hospital). The intelligent routing engine then starts, calculating the optimal target based on multi-dimensional strategies: Load balancing: Select the currently idle instance.

[0079] Proximity and Affiliation: Prioritize regional central hospitals that are affiliated with Community Center A.

[0080] Business capability matching: Based on the "clinical symptom description", if the knowledge base suggests that it may be "complex atrial fibrillation", then priority will be given to routing to instances with a team of arrhythmia experts.

[0081] Routing decision: The engine will route the request to "City People's Hospital ECG Diagnosis Service Instance (Address: Svc_ECG_01)".

[0082] Request Enhancement and Forwarding: Before forwarding, the gateway may automatically append metadata instructions to the request based on the service contract and the global service-data lineage graph, such as: Prefetch Data Identifier = [Patient P123's previous ECG reports, basic medication history]. Then, the enhanced request is forwarded to Svc_ECG_01.

[0083] Phase Two: Service execution and data exchange bus linkage.

[0084] Service instance execution and data requirements: The Svc_ECG_01 service instance receives the request and begins executing its diagnostic logic. The first part of the logic is likely: "It is necessary to review the patient's relevant past medical history to assist in the diagnosis."

[0085] Service instances do not query the database automatically. Instead, based on the prefetch data identifier attached to the request or the data requirements they generate themselves, they construct one or more standard data requests and send them to the unified interface of the data exchange bus. For example, a request might be generated as: {"Operation":"query","Subject":"Patient Treatment Data","Condition":{"Patient ID":"P123","Data Category":["ECG Report","Medication Record"]}}.

[0086] Data exchange bus processing and data supply: Request reception and parsing: The data routing and distribution controller of the data exchange bus receives the data request.

[0087] Topic matching and data location: The controller parses the topic and conditions in the request.

[0088] The topic "Patient diagnosis and treatment data" is mapped internally to multiple message streams (Topics) from the data resource center (Step 1), such as Topic_ECG_Report (electrocardiogram report stream) and Topic_Medication (medication record stream).

[0089] The controller initiates a precise query to the corresponding message topic based on the patient ID and data category. If the required data is historical archived data, the controller directly initiates a real-time query to the topic database (such as the examination report database or electronic medical record database) in the data resource center.

[0090] After retrieving raw data from the data source, the bus invokes the data security policy engine. For example, based on the "doctor role" and the "minimum necessity principle," it automatically filters out sensitive fields that are irrelevant to the diagnosis (such as the patient's home address or specific genetic disease information).

[0091] The acquired and filtered data is serialized into an efficient transmission format by the format conversion adapter and accurately transmitted back to the requester Svc_ECG_01 through the encrypted channel established by the unified message hub.

[0092] Svc_ECG_01 receives structured patient history data, such as "had a record of premature ventricular contractions in 2023, and is currently taking metoprolol".

[0093] Svc_ECG_01 combines newly acquired ECG waveforms with the patient's historical data to complete diagnostic analysis and generate a structured diagnostic report (e.g., "Sinus rhythm, occasional premature atrial contractions, regular follow-up recommended"). The service instance returns the diagnostic report as a business response to the platform service bus gateway. The gateway records this service call log and returns the final result to the original requester—the community health center doctor's workstation. Simultaneously, the diagnostic report, as new medical data, is sent by the Svc_ECG_01 service through the data exchange bus back to the examination report repository in the data resource center for persistent storage, completing the data loop.

[0094] Data security is the lifeline throughout the entire process: Transmission security: End-to-end encryption: From request initiation to data transfer between buses and data return, TLS / Chinese cryptographic algorithms are used for encryption throughout the entire process. Message-level signature: Each data packet is accompanied by a digital signature to prevent tampering during transmission.

[0095] Access Security: Identity and Permissions: The platform's unified security center strictly manages the identities of users (doctors) and services (ECG diagnostic services). Every service call and data access requires role-based permission verification. Dynamic Tokens: Access tokens with expiration dates are used to prevent unauthorized use.

[0096] Data Security: Privacy Masking Engine: The built-in masking engine on the data exchange bus automatically masks or replaces sensitive information (such as ID numbers and contact information) according to policies before data flows out of the bus. Auditing and Tracing: The complete chain of all business requests, service calls, and data access (who, when, from where, what service was called, and what data was accessed) is recorded immutably to form an audit log, meeting medical compliance requirements.

[0097] S4. Receive business requests from external systems through the unified interface service platform, perform protocol conversion, security verification and semantic mapping, convert external requests into standard internal service call requests, route them to the corresponding internal services for execution via the platform service bus, and return the execution results to the external system after reverse conversion.

[0098] Specifically, the unified interface service platform built in this step serves as the sole standardized entry and exit point for the medical consortium to interact with the outside world. Internally, it connects the various business services encapsulated in step S3 with the data exchange bus in step S2. Externally, it interfaces with diverse external entities such as county and city-level public health information platforms, medical insurance settlement systems, financial payment platforms, third-party internet hospitals, pharmaceutical supply chain platforms, and wearable device manufacturers.

[0099] The unified interface service platform adopts a layered architecture, mainly including the following core components: API Gateway Cluster: Serving as a unified access point for traffic entry, it is responsible for protocol offloading, route distribution, and global security policy enforcement.

[0100] Protocol Adapter Factory: A pluggable component library containing various protocol converters (such as HL7v2 / v3 to FHIR / internal model, medical insurance 8583 message to JSON, DICOM service access, etc.).

[0101] Semantic Mapping and Transformation Engine: A core innovative component. It is responsible for performing bidirectional intelligent mapping between external data models and the unified data model within the medical consortium (defined in step one).

[0102] Service routing proxy: Deeply integrated with the platform service bus in step two, it is responsible for accurately routing verified and transformed external requests to the corresponding internal services (encapsulated in step three) or obtaining data through the data exchange bus.

[0103] External Service Catalog and Lifecycle Manager: Registers, publishes, manages versions, and monitors the billing of APIs and services exposed by external systems.

[0104] Two-way traffic governance center: monitors and manages internal and external two-way data flows, and implements strategies such as rate limiting, circuit breaking, degradation, and canary release.

[0105] The following example, "Initiating online settlement of inpatient expenses through the medical insurance system," illustrates the complete processing flow of an external request.

[0106] Scenario: Ms. Li, a patient, is discharged from the core hospital of the medical consortium. The medical insurance system needs to obtain a detailed list of her hospitalization expenses in order to complete the online settlement.

[0107] Phase 1: Access Request and Initial Processing Arrival and Protocol Identification: The medical insurance system sends a settlement request message containing "hospitalization number" and "settlement type" to the API gateway via a dedicated line, in accordance with national standards (such as the medical insurance interface specification). The gateway's protocol recognizer automatically identifies the request as "medical insurance protocol 8583 format" and immediately forwards it to the "medical insurance 8583 adapter" in the protocol adapter factory.

[0108] Protocol Conversion and Security Verification: The medical insurance 8583 adapter parses and converts binary or fixed-length messages into an internal intermediate data structure (such as JSON), extracting key business parameters: {"Operation Type":"Fee Settlement","Hospital Number":"ZY20230520001"}. The converted request is then sent back to the API gateway, entering the unified security pipeline. Identity authentication: Verify the digital certificate and signature provided by the medical insurance system to confirm that the user is a legitimate access party.

[0109] Permission verification: Based on the preset policy, confirm that the medical insurance system has the authority to call the "Inpatient Expense Inquiry" interface.

[0110] Request audit: Generate audit logs, recording the source, time, and operation type.

[0111] Phase Two: Semantic Mapping and Internal Routing Semantic mapping and request enhancement: The request, having passed security verification, is sent to the semantic mapping and transformation engine. Based on the "Operation Type: Fee Settlement," the engine invokes a predefined "Medical Insurance Settlement Request Mapping Rule." This rule maps the external parameter "Hospital Number" (ZY20230520001) to a unique unified medical event ID within the medical consortium. This step may require invoking the association query capabilities provided by the patient master index service in step S1. According to the settlement business context, the necessary internal query parameters are automatically appended to the request, such as the required expense details (drug fees, examination fees, material fees, bed fees, etc.). At this point, an external medical insurance request is completely transformed and enhanced into a standard internal service call request, whose target may be an internal service called "Get Hospital Fee Details."

[0112] Internal service routing and execution: The service routing proxy receives a standard internal request, and its role is similar to that of the platform service bus in step S2 in handling internal requests. The proxy queries the service registry built in step S3 and finds the service for retrieving hospitalization fee details. The proxy forwards the request to that service instance. The business logic of that service instance then begins to execute.

[0113] Phase Three: Internal Data Acquisition and Assembly The service calls the internal bus to retrieve data: The service for obtaining hospitalization expense details requires detailed expense data for this hospitalization. It does not directly access the database, but instead initiates a query to the operational database and electronic medical record database of the data resource center (step S1) by calling the data exchange bus in step S2. The query criteria are the converted unified medical event ID and expense items. The data exchange bus securely and efficiently returns standardized, structured expense details.

[0114] Data assembly and internal format generation: The service instance receives the raw cost data and performs business calculations and assembly according to the logic of medical insurance settlement requirements (such as classification and summarization, co-payment ratio calculation, and catalog matching). It generates a cost settlement result object that conforms to the internal data standards of the medical consortium.

[0115] Phase 4: Response Transformation and External Return Internal response inverse transformation: The service returns the internal result object to the service routing proxy, which then passes it to the semantic mapping and transformation engine.

[0116] Based on the "medical insurance settlement response mapping rules", the engine reverse maps the internal data model to the field format and encoding expected by the medical insurance system (such as mapping the internal drug code to the national medical insurance drug catalog code).

[0117] Protocol Reverse Conversion and Security Signature: The converted data is sent to the "Medical Insurance 8583 Adapter" at the protocol adapter factory, where it is repackaged into a standard response message conforming to medical insurance specifications. Before sending the response, the API gateway uses the medical consortium's private key to sign key messages, ensuring that the response is tamper-proof and non-repudiable.

[0118] Response issuance and traffic logging: The final standard message is returned to the medical insurance system via a dedicated line. The two-way traffic governance center records complete metrics (time, data volume, status) for this interaction, which are used for monitoring, analysis, and billing.

[0119] S5 collects full-link metrics of infrastructure, platform bus, application services, and data quality; performs multimodal anomaly judgment on the collected metrics, and provides graded early warnings and notifications based on the anomaly level.

[0120] Specifically, the infrastructure layer monitors the status of hardware resources such as servers, networks, and storage. The platform layer (step S2) monitors core metrics of the platform service bus and data exchange bus. The application and business layer (focusing on steps S1, S3, and S4) monitors the health of business services, data quality, and the execution status of business processes.

[0121] Deploy probes at key nodes of the platform service bus (intelligent routing gateway, service instance container) to collect data. Service call chain tracing data: which service nodes a remote consultation request passed through, and the time consumed at each node.

[0122] Service performance metrics: QPS, average response time, and error code distribution for each service instance.

[0123] Gateway global metrics: total requests, routing decision logs, and security interception events.

[0124] Deploy probes at key nodes of the data exchange bus (unified message hub, data routing controller) to collect data. Data flow throughput and latency: message production / consumption rate and end-to-end transmission latency for each topic.

[0125] Data quality sampling metrics: By sampling at regular intervals, we check the compliance of data format and the fill rate of key fields.

[0126] Resource consumption: CPU and memory usage of the bus processing process.

[0127] Deploy probes in the data resource center (step S1) to collect: Data pipeline health status: data inflow, backlog, and cleaning failure rate from data collection agents at various institutions to the standardized processing pipeline.

[0128] Subject database status: number of connections, slow queries, storage space utilization.

[0129] On the business application side (steps S3 and S4), data is collected through SDK integration: Key business metrics include the time taken for the entire process from "image upload to report issuance" and the success rate of "online registration and payment".

[0130] User behavior logs: Anonymized logs of key operations used to analyze business process bottlenecks.

[0131] All probe data is aggregated in real time to the unified monitoring data lake through a high-throughput "metric collector" cluster. The data lake adopts a hybrid architecture of "hot storage + warm storage": detailed metrics for the past 7 days are stored in a time-series database for real-time querying and alerting; historical data is transferred to low-cost object storage for long-term trend analysis and model training.

[0132] The system abandons simple static threshold alarms and adopts a multimodal diagnostic engine of "rule engine + machine learning + topology association analysis" for intelligent anomaly judgment.

[0133] Rule engine (detection based on explicit rules): Configure static thresholds and trend rules at the business and technical levels. For example: Business rule: An alarm is triggered when the average time for a regional ECG center to issue a report is greater than 30 minutes.

[0134] Technical rules: "The error rate of a certain service instance is consistently >1% within 5 minutes" or "The percentile (P95) of the data exchange bus delay is >2 seconds".

[0135] Machine learning engine (intelligent baseline anomaly detection): The engine learns from historical monitoring data (such as service response time and data inflow) to establish a dynamic "behavioral baseline" for each metric.

[0136] Detection process: Real-time data streams are continuously compared with behavioral baselines. For example, the system learns that "registration service requests typically peak between 9-10 AM on Mondays." If, on a Tuesday afternoon, the service request volume suddenly spikes to Monday's peak level, but CPU utilization does not increase accordingly, the machine learning engine will determine this as an anomaly "deviation from expected patterns," and will generate a low-level warning even if the static threshold is not triggered.

[0137] Topological association and root cause localization engine: This engine is activated when multiple alarms occur simultaneously. It performs correlation analysis based on the "system dependency topology graph" (e.g., service A calls service B, and service B depends on database C).

[0138] Scenario Example: The alerting platform receives two alerts simultaneously: "Slow response of image upload service" and "Backlog of storage topics on data exchange bus". Engine analysis of the topology diagram reveals that the image upload service relies on the bus for data transmission. Therefore, it is inferred that the root cause is likely a "bottleneck in the I / O of the data exchange bus storage node," rather than a problem with the image service's code itself. This allows for precise identification of the alert's root cause and guides operations personnel to quickly address the issue.

[0139] Based on the output of the multimodal diagnostic engine, the system initiates an intelligent early warning process.

[0140] Early warning classification and grading: Based on the breadth and depth of the abnormal impact, the warning is automatically divided into four levels: P0 - Emergency: Core business services are completely unavailable, or there is a risk of patient data breach. Immediate telephone notification is required.

[0141] P1 - Critical: Critical business performance has severely degraded, affecting a large number of users. Notification must be sent within 10 minutes via instant messaging tools (such as WeChat / DingTalk).

[0142] P2 - Warning: Minor business anomalies or metrics consistently deviating from baseline. Send an email to the relevant team.

[0143] P3 - Notification: Potential risk or informational event. Recorded on the operations dashboard; no proactive notification required.

[0144] Context-rich alert notifications: The alert message is not a simple "XX service failure". It will automatically attach a "diagnostic snapshot", which includes: Anomaly Summary: What went wrong?

[0145] Scope of impact: Which institutions, which businesses, and how many users are affected.

[0146] Preliminary root cause analysis: inference results from the multimodal diagnostic engine (e.g., suspected database lock contention).

[0147] Related metrics: Chart links to the current status of related upstream and downstream services.

[0148] Action recommendations: Based on the knowledge base, provide possible emergency response steps (e.g., "Recommend restarting XX service instance B", "Please check the status of network leased line C").

[0149] Warning messages are sent through a "unified notification center." This center intelligently selects the notification channel and personnel based on the warning level, duty roster, and personnel skill tags.

[0150] Example Process: A P1-level alarm, "Decreased Success Rate of Unified Drug Procurement Interface," is generated. Notification Center: Based on the "Drug System" tag, prioritize @Drug Information Group duty officers.

[0151] Send the message to the group via instant messaging bot and call the person in charge.

[0152] Meanwhile, in the "Business Health" section of the large screen monitoring system, this business module showed a red light.

[0153] If there is no response within 5 minutes, the system will automatically escalate and notify the team leader.

[0154] The system goes beyond simply reporting errors; some alerts trigger predefined "automatic repair scripts." For example, when the diagnostic engine determines that "a service instance is about to crash due to a memory leak," the system can automatically execute the script at the same time as the alert: 1) Isolate the instance from the service registry; 2) Start a new healthy instance; 3) Switch traffic to the new instance. The entire process is completed within minutes, minimizing business impact, and the result of "self-healing operation performed" is fed back to the alert ticket.

[0155] The second embodiment of this application is as follows: Please see Figure 4 This invention provides a medical consortium business interconnection system based on a platform and a data dual bus, which is applied to a medical consortium business interconnection method based on a platform and a data dual bus as provided in the first embodiment. The data resource center is used to store thematic databases formed after standardization processing. The platform service bus module includes a service registration and discovery center, an intelligent routing gateway, and a service orchestration engine, which are used to implement service registration, discovery, intelligent routing, and process orchestration. The data exchange bus module, including a unified message hub, a data routing and distribution controller, and a format conversion adapter, is used to achieve secure and reliable data transmission and routing. The unified interface service platform module includes an API gateway, a protocol adapter factory, and a semantic mapping and conversion engine, which are used to realize protocol conversion, secure access, and semantic mapping of external systems. The operation monitoring and early warning center includes probes deployed at each layer, a unified monitoring data lake, and a multimodal diagnostic engine, used to achieve end-to-end monitoring, intelligent anomaly diagnosis, and tiered early warning.

[0156] Regarding the system in the above embodiments, the specific ways in which each module performs operations have been described in detail in the embodiments related to the method, and will not be elaborated here.

[0157] For the system embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0158] Accordingly, this application also provides an electronic device, including: one or more processors; a memory for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the above-described method for interconnecting medical consortium services based on a platform and data dual bus. Figure 4 The diagram shown is a hardware structure diagram of any device with data processing capabilities within a medical consortium business interconnection system based on a platform and data dual bus, as provided in an embodiment of the present invention. (Except for...) Figure 4 In addition to the processor, memory, and network interface shown, any data processing device in the embodiment may also include other hardware depending on the actual function of the data processing device, which will not be described in detail here.

[0159] Accordingly, this application also provides a computer-readable storage medium storing computer instructions, which, when executed by a processor, implement the aforementioned method for interconnecting medical consortium services based on a platform and data dual-bus architecture. The computer-readable storage medium can be an internal storage unit of any data-processing device as described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be an external storage device, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units of any data-processing device and external storage devices. The computer-readable storage medium is used to store the computer program and other programs and data required by the data-processing device, and can also be used to temporarily store data that has been output or will be output.

[0160] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure 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.

[0161] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A method for interconnecting and interoperating medical consortium services based on a platform and a dual data bus, characterized in that, Includes the following steps: Heterogeneous business data is extracted in a timed batch or real-time event-driven manner; the extracted raw data is sent to the data resource center for parsing, cleaning, coding standardization and patient identity merging processing to form a standardized thematic database; the extracted raw data includes core diagnosis and treatment data, drug and material data, resource and management data, public health and health data and business collaboration data; A platform service bus is constructed for registering, discovering, scheduling, and monitoring encapsulated business services within the medical consortium; a data exchange bus is constructed for data transmission between different data producers and consumers; the platform service bus and the data exchange bus coordinate and link through metadata; The core business capabilities of the medical consortium are encapsulated into reusable services with standardized interfaces and registered to the platform service bus; through the intelligent routing of the platform service bus, external business requests are dynamically routed to service instances based on business content, system load and preset strategies. The platform receives business requests from external systems through a unified interface service platform, performs protocol conversion, security verification, and semantic mapping, converts external requests into standard internal service call requests, routes them to the corresponding internal services for execution via the platform service bus, and returns the execution results to the external system after reverse conversion. Collect full-link metrics of infrastructure, platform bus, application services, and data quality; perform multimodal anomaly judgment on the collected metrics, and issue graded warnings and notifications based on the anomaly level.

2. The method for interconnecting and interoperating medical consortium services based on a platform and data dual bus as described in claim 1, characterized in that, The core business capabilities of the medical consortium are encapsulated into reusable services with standardized interfaces, including: Identify and classify atomic services and composite services, and define a service contract for each service that includes input and output parameters and a quality of service protocol; when a service instance is executed, it obtains standardized data from the data resource center by calling the unified interface provided by the data exchange bus, thereby decoupling business logic from the data source.

3. The method for interconnecting and interoperating medical consortium services based on a platform and data dual bus as described in claim 2, characterized in that, The intelligent routing process specifically includes: When an external business request carrying a service identifier and business context arrives at the intelligent routing gateway of the platform service bus; After the intelligent routing gateway verifies the security of the request, it queries the service registry to obtain a list of available service instances, and combines real-time load information, business context content, and preset routing policies to dynamically calculate and select the optimal target service instance for request forwarding.

4. The method for interconnecting and interoperating medical consortium services based on a platform and data dual bus as described in claim 3, characterized in that, Based on the global service-data lineage graph, the intelligent routing gateway attaches a data prefetch metadata instruction before forwarding a service request, triggering the data exchange bus to push the associated data to the target service instance in advance.

5. The method for interconnecting and interoperating medical consortium services based on a platform and data dual bus as described in claim 1, characterized in that, The process of a unified interface service platform handling external requests includes: Convert external heterogeneous protocol requests into internal intermediate data structures; Based on predefined mapping rules, key parameters of the external data model are mapped to unified identifiers and data models within the medical consortium; The service routing proxy routes the transformed internal requests to the corresponding internal business service for execution. The service obtains the required data and completes the business logic through the data exchange bus. The execution results of internal services are reverse-engineered and returned as a response message that meets the expectations of the external system.

6. The method for interconnecting and interoperating medical consortium services based on a platform and data dual bus as described in claim 5, characterized in that, The semantic mapping stage relies on a mapping rule base that is associated with the medical consortium master data management platform and the patient master index service, ensuring accurate conversion between external encoding and internal unified encoding.

7. The method for interconnecting and interoperating medical consortium services based on a platform and data dual bus as described in claim 1, characterized in that, The collected indicators are subjected to multimodal anomaly detection, and graded early warnings and notifications are issued based on the anomaly level, including: Anomaly detection is performed based on preset static thresholds and trend rules; Establish dynamic behavioral baselines for monitoring metrics and detect abnormal patterns that deviate from these baselines; When multiple alarms occur, correlation analysis is performed based on the system dependency topology to locate the root cause, and graded warnings and notifications are issued according to the anomaly level.

8. The method for interconnection and interoperability of medical consortium services based on a platform and data dual bus as described in claim 7, characterized in that, Based on the level of abnormality, tiered early warnings and notifications are issued, including: Early warnings are categorized based on the breadth and depth of the abnormal impact; a diagnostic snapshot is generated that includes an anomaly summary, the scope of impact, preliminary root cause analysis, and action recommendations. Based on the warning level, duty roster, and personnel skill tags, the notification channels and recipients are determined.

9. The method for interconnecting and interoperating medical consortium services based on a platform and data dual bus as described in any one of claims 1 to 8, characterized in that, The data exchange bus adopts a unified message hub architecture based on message queues, and implements conditional routing and distribution of data through a data routing and distribution controller.

10. A medical consortium business interconnection system based on a platform and a dual data bus, applied to the medical consortium business interconnection method based on a platform and a dual data bus as described in claim 1, characterized in that, include: The data resource center is used to store thematic databases that have undergone standardization processes. The platform service bus module includes a service registration and discovery center, an intelligent routing gateway, and a service orchestration engine, which are used to implement service registration, discovery, intelligent routing, and process orchestration. The data exchange bus module, including a unified message hub, a data routing and distribution controller, and a format conversion adapter, is used to achieve secure and reliable data transmission and routing. The unified interface service platform module includes an API gateway, a protocol adapter factory, and a semantic mapping and conversion engine, which are used to realize protocol conversion, secure access, and semantic mapping of external systems. The operation monitoring and early warning center includes probes deployed at each layer, a unified monitoring data lake, and a multimodal diagnostic engine, used to achieve end-to-end monitoring, intelligent anomaly diagnosis, and tiered early warning.

Images