An emergency cross-hospital data intercommunication method and system

Abstract

The present application relates to the field of medical informatization and emergency medical technology, and particularly relates to an emergency cross-hospital data intercommunication method and system. The method collects core data, performs timestamp marking and terminal identification binding, and generates an initial collection data set; processes the initial collection data set to form an EDXP data packet; in response to a cross-hospital referral event, desensitizes, compresses and encrypts the EDXP data packet, and transmits the EDXP data packet to a target receiving terminal after attaching a data integrity check code; after the target receiving terminal receives the data, performs data integrity verification, analyzes and extracts the data, and completes cross-hospital referral data intercommunication. The EDXP data packet of the present application has a three-layer structure design of'mandatory fields + optional fields + disease-specific extension fields', encapsulates only structured data necessary for emergency treatment classified by disease, eliminates redundant data, and solves the problems of existing transmission redundancy inefficiency and complex heterogeneous system docking.

Description

Technical Field

[0001] This invention relates to the fields of medical information technology and emergency medicine, and in particular to a method and system for cross-hospital data exchange in emergency care. Background Technology

[0002] In emergency inter-hospital referrals, the real-time nature, standardization, and security of data interoperability directly determine the efficiency of patient treatment. Currently, there are prominent pain points in clinical practice: within the "golden time window" of emergency care (e.g., 4.5 hours for stroke, 2 hours for myocardial infarction), high data transmission latency across hospitals prevents receiving hospitals from quickly grasping the patient's condition; incompatible data formats between different hospitals' heterogeneous systems (HIS / EMR / emergency systems) lead to cumbersome integration; an imbalance between data anonymization and clinical usability results in either excessive anonymization affecting diagnosis and treatment or inaccurate anonymization leaking privacy; and chaotic data transmission timing and easy data loss lead to biased diagnostic and treatment decisions. According to the "China Emergency Medicine Development Report (2024)," 78.3% of emergency inter-hospital referrals experience data transmission delays, with an average latency of 12.6 seconds, and 32.1% of referrals result in information gaps due to data incompatibility.

[0003] The existing technology has four major flaws: 1. It uses a general data protocol to transmit all data, which is redundant and inefficient, with a transmission latency of 10-15 seconds, making it unsuitable for the urgency of emergency care; 2. The data standardization and specifications are not tailored to emergency scenarios, lack disease-specific fields, and make it cumbersome to interface with heterogeneous systems; 3. The anonymization method is fixed and does not dynamically adjust the granularity according to the needs of emergency treatment, failing to balance privacy and usability; 4. There is no dedicated time-series synchronization and fault-tolerance mechanism, making data prone to time-series disorder and loss, and lacking self-healing ability.

[0004] Therefore, there is an urgent need for a lightweight, standardized, secure, controllable, and highly efficient emergency cross-hospital data interoperability solution. Summary of the Invention

[0005] The purpose of this invention is to overcome at least one of the above-mentioned defects in the prior art and to provide a method and system for inter-hospital data exchange in emergency departments.

[0006] The first aspect of this invention provides a method for inter-hospital data exchange in emergency departments, comprising the following steps:

[0007] The system collects four types of core data from emergency patients: vital signs, initial medical records, keyframes of images, and immediate examination results. It also timestamps and binds the core data to the terminal identifier to generate an initial dataset.

[0008] The initial collected dataset is processed according to a pre-defined emergency inter-hospital data standardization specification to generate structured standard data conforming to the Emergency Specific Lightweight Data Exchange Protocol (EDXP), forming an EDXP data package. The EDXP protocol defines a lightweight data structure containing a pre-defined number of required fields, optional fields, and at least one disease-specific extended field. The required fields include unique identifiers and spatiotemporal metadata, continuously monitored physiological parameters, basic awareness and symptom assessment values, on-site treatment process data, and key safety warning labels. The optional fields include historical background data, multimodal examination conclusion summaries, deep-specific indicators, and social support and payment attributes. The disease-specific extended field includes key data for emergency treatment decisions for that disease.

[0009] In response to inter-hospital referral events, the EDXP data packets are desensitized, compressed, and encrypted before being transmitted to the target receiving terminal, and a check code for verifying data integrity is attached during the transmission process.

[0010] After the target receiving terminal receives the EDXP data packet, it verifies the data integrity based on the check code, and after successful verification, it parses the EDXP data packet to extract the core data, thus completing the inter-hospital referral data exchange.

[0011] Furthermore, in the data collection step, a dynamically adjusted collection frequency is used for emergency patients with different diseases. The collection frequency is calculated based on the disease priority weight Wi, where Wi∈[0,1].

[0012] The calculation formula is: ,

[0013] in, The collection frequency for disease category i. The preset minimum frequency, The preset maximum frequency;

[0014] And / or,

[0015] Before generating the initial dataset, the 3σ criterion is used to remove outlier data and filter out blank or invalid format data.

[0016] Furthermore, before generating the EDXP data packet, the desensitization is dynamic desensitization, and the dynamic desensitization calculates the desensitization strength based on the product of the data sensitivity level and the receiving terminal's permission level.

[0017] Furthermore, if the verification code fails, a fault tolerance mechanism is triggered, which includes: recording the transmission breakpoint location and resuming the transmission from the breakpoint, and performing limited retransmissions if the number of retransmissions does not exceed a preset number and the interval between each retransmission is a preset time; if the retransmission still fails, an abnormal alarm is sent to the operation and maintenance personnel.

[0018] A second aspect of the present invention provides an emergency inter-hospital data interoperability system, comprising:

[0019] The data acquisition module is deployed at the terminal of a primary hospital, the terminal of an ambulance, or the terminal of a higher-level hospital. It is used to collect vital signs, initial diagnosis and treatment records, key frames of images, and real-time examination results of emergency patients, and generate an initial collection dataset with timestamps and terminal identifiers.

[0020] The cloud-based standardization processing module is used to process the initial collected dataset according to the preset emergency cross-hospital data standardization specifications, generate structured standard data that conforms to the Emergency-Specific Lightweight Data Exchange Protocol (EDXP), and form an EDXP data packet. The EDXP protocol defines a lightweight data structure that includes a preset number of required fields, optional fields, and at least one disease-specific extended field.

[0021] The dynamic desensitization and encryption module is used to perform dynamic desensitization on the structured standard data based on data level and receiving terminal permissions, and then encrypt it.

[0022] The lightweight transmission module is used to respond to inter-hospital referral events by transmitting encrypted EDXP data packets to the target receiving terminal through the communication network, and includes a checksum for verifying data integrity.

[0023] The receiving and feedback module, deployed at the target receiving terminal, is used to receive the EDXP data packet, verify data integrity, decrypt and parse the data packet to extract core data, and return a reception confirmation message to the sending end.

[0024] The timing synchronization and fault tolerance module is used to calibrate the time of each terminal through BeiDou time synchronization and PTP protocol, and to perform breakpoint resume or limited retransmission when transmission is abnormal.

[0025] Compared with the prior art, this application has at least the following beneficial effects:

[0026] 1. This application designs an emergency-specific lightweight data exchange protocol (EDXP), which differs from existing general data protocols. In this application, the structured standard data conforming to the emergency-specific lightweight data exchange protocol (EDXP) only encapsulates the structured data necessary for emergency treatment classified by disease, eliminating redundant data, reducing transmission latency to ≤3 seconds, and is compatible with the WS / T 846.1-2024 industry standard, solving the problems of inefficient transmission redundancy and cumbersome interfacing with heterogeneous systems in the existing system.

[0027] 2. This application adopts an emergency data dynamic hierarchical desensitization engine, which differs from the existing fixed desensitization method. It dynamically adjusts the desensitization granularity according to "data sensitivity level + receiving terminal permission level", covering the entire link of collection-transmission-storage, and finally performs encryption processing to achieve a balance between privacy security and clinical usability.

[0028] 3. This application integrates BeiDou time synchronization and PTP precise time synchronization algorithm to achieve accurate synchronization of cross-institute data timestamps (error ≤ 0.05 seconds). At the same time, it designs a fault tolerance mechanism of breakpoint resume transmission + data verification + anomaly alarm to solve the problems of time sequence disorder and data loss in the existing technology and improve the accuracy and reliability of data synchronization.

[0029] 4. This application designs a standardized specification for cross-hospital emergency data, clarifies the core data fields, formats and code conversion rules for emergency, designs disease-specific fields, and adapts to various terminals in pre-hospital ambulances, primary hospitals and higher-level hospitals. It solves the defects of existing industry standards that do not fit the emergency scenario and achieves deep adaptation of standardized specifications with emergency diseases and terminal equipment. Attached Figure Description

[0030] 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.

[0031] Figure 1 This is a flowchart of an emergency cross-data interoperability method according to an embodiment of this application. Detailed Implementation

[0032] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0033] A method for inter-hospital data exchange in emergency departments, such as Figure 1 As shown, it includes the following steps:

[0034] S1. Collect four types of core data from emergency patients: vital signs, initial diagnosis and treatment records, key frames of images, and immediate examination results. Then, timestamp and bind the core data to the terminal identifier to generate an initial data collection dataset.

[0035] This step is performed by the data collection module deployed in primary hospital clinics, ambulance terminals, or community health service centers. When the attending physician selects the "suspected case requiring referral" label in the electronic medical record system, or when the emergency personnel click the "start transfer" button on the vehicle terminal, the system automatically triggers the emergency data collection process.

[0036] Preferably, a dynamically adjusted acquisition frequency is used for emergency patients with different diseases, and the acquisition frequency is calculated based on the disease priority weight Wi, where Wi∈[0,1];

[0037] The calculation formula is: ,

[0038] in, The collection frequency for disease category i. The preset minimum frequency, The preset maximum frequency;

[0039] For example, the system matches a preset disease database with preliminary diagnostic keywords (such as "chest pain," "limb weakness," and "coma") to determine the disease type and retrieve the corresponding disease priority weight Wi. If a patient suddenly experiences left-sided limb weakness and the doctor initially diagnoses it as "cerebral infarction," the system identifies the disease as "acute ischemic stroke." If a patient presents with chest pain and the electrocardiogram shows ST segment elevation ≥2mm in leads V2-V4, the system determines it as "acute myocardial infarction."

[0040] If it is "acute ischemic stroke", then Wi=0.95;

[0041] If it is "acute myocardial infarction", then Wi=0.98;

[0042] If it is "common soft tissue contusion", then Wi=0.3.

[0043] Subsequently, the sampling frequency is calculated, assuming the system's preset minimum frequency. =0.2 times / second, maximum frequency =1.0 times / second, then the calculation result is:

[0044] Collection frequency of "acute ischemic stroke" 0.96 times / second; similarly, the sampling frequency for "acute myocardial infarction" is 0.984 times / second; and the sampling frequency for "common soft tissue contusion" is 0.44 times / second.

[0045] This application establishes a linear mapping relationship between the severity of a disease and the density of data collection through a formula for calculating the dynamic acquisition frequency. This design not only technically resolves the contradiction between "congestion caused by full-volume acquisition" and "missed diagnoses caused by low-frequency acquisition," but also embodies the principle of "life first, optimal resource allocation" in clinical ethics.

[0046] Based on the calculated acquisition frequency above, the following four categories of core data are collected: patient vital signs, initial medical records, keyframe images, and immediate examination results. Specifically, these include: Vital signs: heart rate (bpm), systolic / diastolic blood pressure (mmHg), oxygen saturation (%), respiratory rate (breaths / min), etc.; Initial medical records: chief complaint, present medical history, level of consciousness (GCS score), NIHSS score (for stroke patients), etc.; Keyframe images: head CT plain scan images, chest X-ray (PA view), 12-lead electrocardiogram waveform, key sections of abdominal ultrasound, etc.; Immediate examination results: bedside rapid test results, such as troponin (ng / mL), blood glucose (mmol / L), etc. All data are appended with a local system timestamp (accurate to milliseconds) and a unique terminal identifier to form the initial acquisition dataset.

[0047] More preferably, data cleaning and anomaly removal are performed on the raw data before forming the initial collection dataset: for example, for continuously collected vital sign sequences, the mean μ and standard deviation σ within the sliding window are calculated; the 3σ criterion is applied: if a certain measurement value satisfy Values ​​greater than 3σ are considered outliers and removed. Simultaneously, blank fields (such as unfilled allergy history) or invalid formats (such as blood pressure values ​​with non-numeric characters) are filtered. For non-continuous data, the following rules can be applied for validation, but are not limited to: numeric fields (such as age, NIHSS score) exceeding the medically reasonable range are marked as invalid; categorical fields (such as gender, level of consciousness) not in the preset list of valid values ​​attempt automatic mapping or prompts for correction; text fields (such as chief complaint) undergo length, keyword conflict, and sensitive word checks; logical consistency checks are performed between multiple fields (e.g., comatose patients should not have NIHSS=0); if a required field is empty, the process is interrupted and a prompt for completion is displayed; if an optional field is empty, the empty value is retained.

[0048] The four types of core data, after cleaning, are integrated in chronological order and labeled as the "initial data set". This data has undergone preliminary noise reduction and contains accurate timestamps and terminal identifiers. It serves as the sole input for the standardization process in step S2, ensuring that the standardization process has reliable, accurate, and traceable raw data, and avoiding deviations in subsequent processing due to abnormal raw data.

[0049] S2. The initial collected dataset is processed according to the preset emergency cross-hospital data standardization specification to generate structured standard data that conforms to the Emergency Dedicated Lightweight Data Exchange Protocol (EDXP) and form an EDXP data packet, wherein the EDXP protocol defines a lightweight data structure containing a preset number of required fields, optional fields and at least one disease-specific extended field.

[0050] The system processes the initial collected dataset according to the preset emergency cross-hospital data standardization specifications, generating structured data that conforms to EDXP, specifically including:

[0051] S2.1 Convert the raw data into a preset standard format.

[0052] For example, time should be standardized to ISO8601 format (e.g., "2024-05-01T08:30:00Z"), blood pressure should be standardized to "systolic / diastolic" numerical pairs (e.g., "180 / 100" → {systolic: 180, diastolic: 100}), and units should be standardized to international standards (e.g., blood glucose mmol / L, troponin ng / mL).

[0053] S2.2 Automatic Data Matching

[0054] For non-standard medical terminology, terminology mapping is performed: non-standard medical terms in the raw data are compared with standard terms in a pre-defined standard terminology database, and the similarity is calculated using the Jaccard similarity coefficient.

[0055]

[0056] Where A and B are the word segmentation sets of the two terms;

[0057] If Sim≥0.8, it will be automatically mapped to standard terms; otherwise, a manual verification pop-up will be triggered.

[0058] In other words, during the term matching process, the system performs Chinese word segmentation on the original term and the preset standard term respectively, resulting in two word sets; the ratio of the number of elements in the intersection of the two sets to the number of elements in the union of the two sets is used as the similarity score.

[0059] For example, in the original collected data, the term is "myocardial infarction," with segmentation A = {heart, infarction}, and B is the standard term "acute myocardial infarction," with segmentation B = {acute, myocardium, infarction}. Sim=0, the automatic mapping condition is not met, and the system pop-up window prompts: "'Myocardial infarction' did not match the standard term. Please select: ① Acute myocardial infarction ② Old myocardial infarction ③ Other". The doctor selects ① and the mapping is completed.

[0060] For example, the word segmentation results of the original term "cerebral infarction" and the standard term "cerebral infarction" have a high degree of overlap, with a similarity score of 0.85, which exceeds the threshold. The system automatically maps it to "cerebral infarction".

[0061] In this step, as a preferred embodiment, during the standardization process, the field completeness of the initial dataset is first weighted and scored. This score is based on a preset field weight table, and only when the score is not lower than 80 points is it allowed to enter the subsequent processing flow; when the score is lower than 80 points, the system will return a data incomplete prompt, requiring the collection end to supplement the missing information.

[0062] For example, core data includes heart rate, systolic blood pressure, onset time, and level of consciousness. If the "onset time" field is missing from the data, the preset weight of this field is 0.2, resulting in a total score of 76. Since 76 < 80, the system refuses to proceed to the next step and pops up a window on the terminal saying: "Data integrity is insufficient, please supplement the onset time." After the doctor supplements the data, S2 is triggered again, the score is 85, and the system passes and continues with subsequent processing.

[0063] Data integrity checks ensure that every piece of uploaded data is clinically usable.

[0064] S2.3 Encapsulate EDXP data packets by disease type

[0065] The standardized data is organized according to the EDXP protocol structure, that is, all required fields are filled, optional fields are filled according to their actual existence, and disease-specific extended fields are written according to the diagnosis type; and structured standard data is output, that is, a JSON object conforming to the EDXP protocol is generated as input for the next step of desensitization and compression.

[0066] This application defines a lightweight data exchange protocol that conforms to the Emergency Data Exchange Protocol (EDXP). This protocol includes a preset number of required fields, optional fields, and at least one disease-specific extended field, forming a lightweight data structure.

[0067] The required fields consist of real-time dynamic data necessary for constructing a minimal assessment model of the current vital signs of emergency patients. These include unique identifiers and spatiotemporal metadata (e.g., patient's unique referral number, gender, age, onset time, first medical contact time, vital sign collection time, referral initiating institution, referral destination institution, ambulance number, and initial physician identifier), continuously monitored physiological parameters (e.g., heart rate, systolic blood pressure, diastolic blood pressure, respiratory rate, blood oxygen saturation, and body temperature), basic consciousness and symptom assessment values ​​(e.g., level of consciousness, pain score), on-site treatment process data (e.g., chief complaint, key description of present medical history, preliminary diagnosis, initial department, reason for referral, referral type, emergency measures implemented, names and dosages of medications used), and key safety warning labels (including allergy history and key examination result summaries).

[0068] Optional fields can be supplementary data that relies on historical records, asynchronous data transfers, or individual-specific data. The absence of this data does not affect emergency response initiation but can improve diagnostic accuracy. These include historical background data (e.g., summaries of past medical history, long-term medication history, past surgical history, family medical history, detailed allergy history, etc.), summaries of multimodal examination results (e.g., brief conclusions of electrocardiograms, imaging examination results, etc.), deep-specific indicators (e.g., height and weight, blood glucose levels, key abnormal values ​​of laboratory indicators, etc.), and social support and payment attributes (family contact information, medical insurance / fee type identifiers, etc.).

[0069] In this embodiment, the EDXP is defined to include 28 required fields, 12 optional fields, and disease-specific extended fields that are dynamically loaded according to the type of acute and critical illness.

[0070] 1. The 28 required fields defined in this embodiment are as follows: 1) Patient's unique referral number, 2) Gender, 3) Age, 4) Heart rate, 5) Systolic blood pressure, 6) Diastolic blood pressure, 7) Respiratory rate, 8) Blood oxygen saturation, 9) Body temperature, 10) Level of consciousness, 11) Onset time, 12) Time of first medical contact, 13) Chief complaint, 14) Key description of present illness, 15) Pain score (NRS), 16) Preliminary diagnosis, 17) First-visit department, 18) Reason for referral, 19) Type of referral, 20) Time of vital signs collection, 21) Identifier of the first-visit physician, 22) Initiating institution of referral, 23) Target institution of referral, 24) Ambulance number, 25) Emergency measures implemented, 26) Name and dosage of medications used, 27) Allergy history ( / None), 28) Summary of key examination results;

[0071] 2. The 12 optional fields defined in this embodiment are as follows: 1) Summary of past medical history, 2) History of long-term medication, 3) Detailed information on allergy history, 4) History of previous surgeries, 5) Family medical history, 6) Height and weight, 7) Blood glucose level, 8) Brief conclusion of electrocardiogram, 9) Conclusion of imaging examination, 10) Key abnormal values ​​of laboratory indicators, 11) Contact information of family members (de-sensitized), 12) Medical insurance / fee type identifier;

[0072] 3. Disease-specific extended fields

[0073] Based on different emergency disease types, corresponding disease-specific extended fields are dynamically loaded on the EDX protocol. Each disease-specific extended field includes at least one core mandatory field and zero to several clinically optional fields (which may or may not be present). The core mandatory field is the key basis for emergency treatment decisions for that disease and must be provided in the referral data packet; the clinically optional fields are filled in as needed based on the actual examination capabilities of the medical institution and may be omitted. This example lists the following disease-specific extended fields:

[0074] 1) Stroke (ischemic stroke / cerebral infarction): The core required field is the NIHSS score, and the clinical optional fields are the time from onset to the first CT scan, contraindications for thrombolysis, pupil size and light reflex, etc.

[0075] 2) Acute myocardial infarction: The core required field is the ST segment elevation amplitude, and the clinical optional fields are troponin I / T results, chest pain onset time, Killip functional classification, etc.

[0076] 3) Trauma / Multiple Trauma: The core required field is the Injury Severity Score (ISS), and the clinical optional fields are systolic blood pressure trauma grade, duration of loss of consciousness, bleeding site and amount of bleeding, etc.

[0077] 4) Cerebral hemorrhage: The core required field is the estimated hemorrhage volume, and the clinical optional fields are midline shift indicator, pupil status, GCS score, etc.

[0078] 5) Acute respiratory failure / severe pneumonia: The core required field is the oxygenation index, and the clinical optional fields are respiratory distress score, oxygen concentration, intubation status, etc.

[0079] 6) Acute abdomen: The core required field is the peritoneal irritation sign indicator, and the clinical optional fields are abdominal pain location zoning, white blood cell count, key conclusions of abdominal ultrasound, etc.

[0080] The three-tiered structure of the EDXP protocol—comprising mandatory fields, optional fields, and disease-specific extended fields—is the core mechanism by which this invention achieves both "lightweight" and "clinical precision." Mandatory fields contain essential information for all emergency patients (e.g., heart rate, blood pressure, level of consciousness, onset time), ensuring cross-disease applicability and providing a minimum amount of assessable information for any referred patient. Optional fields provide non-urgent but comprehensive assessment information (e.g., allergy history, surgical history, family contact information), enhancing information richness and allowing for the inclusion of supplementary information as needed without increasing the burden on the main protocol, balancing efficiency and completeness. Disease-specific extended fields, defined for specific high-risk diseases (e.g., NIHSS score, ST-segment elevation), support precise treatment, upgrading the general protocol to an "intelligent diagnostic and treatment carrier," directly supporting second-level decision-making at higher-level hospitals. The collaboration of these three technologies avoids the "large and comprehensive but slow transmission" of general protocols (such as FHIR) and overcomes the "fragmentation and incompatibility" of custom protocols, thus achieving an emergency data model that is "commonly unified and highly individualized".

[0081] This application adds disease-specific extended fields to the EDXP protocol, which has the following advantages:

[0082] It can improve the accuracy of treatment. Since the key decision criteria for different emergencies are completely different (for example, stroke: NIHSS score ≥6 is an indication for thrombolysis; myocardial infarction: ST segment elevation ≥1mm is a criterion for PCI initiation; trauma: ISS score ≥16 indicates multiple injuries requiring multidisciplinary consultation), if only general vital signs are transmitted, senior doctors cannot determine whether to activate the green channel. EDXP transforms "raw data" into "decision signals" by expanding fields, so that the receiving end can act without secondary inquiries.

[0083] This technology enables lightweight, disease-specific customization, avoiding redundant transmission. Existing technologies typically cover all diseases, with protocols containing hundreds of fields, 90% of which are empty in a single referral. In contrast, the EDXP protocol in this application only activates the extended fields required for the current disease, omitting the remaining fields, resulting in smaller data packets and faster transmission.

[0084] Promote the standardization of emergency care across regions and regulate primary care practices. Primary care physicians often neglect key assessment items (such as failing to perform NIHSS scoring) due to insufficient experience. EDXP mandates that "stroke patients must complete NIHSS scoring" at the data collection point, thereby driving process standardization through agreements and improving the quality of primary care initial care.

[0085] It supports intelligent triage and resource pre-scheduling. The receiving system can automatically parse extended fields and trigger different contingency plans. For example, if the NIHSS score is greater than or equal to 6, the neurology department and CT room will be automatically notified to be on standby. This enables data-driven resource scheduling, rather than relying on manual judgment.

[0086] Therefore, the three-layer structure design of "mandatory fields + optional fields + disease-specific extended fields" in the EDXP protocol of this application can significantly improve the response speed and treatment accuracy of higher-level hospitals without increasing the burden on primary care facilities or sacrificing transmission speed.

[0087] S3. In response to an inter-hospital referral event, the EDXP data packet is desensitized, compressed, and encrypted before being transmitted to the target receiving terminal, and a verification code for verifying data integrity is attached during the transmission process;

[0088] This step is executed by a lightweight transmission module deployed on a cloud server in conjunction with the communication interfaces of each terminal, aiming to ensure that emergency data is delivered safely, quickly, and completely to the target hospital within the "golden time window." Specifically, it includes:

[0089] S3.1: Monitor and respond to inter-hospital referral events

[0090] The system monitors the operational status of terminals in primary hospitals or ambulances in real time. A "cross-hospital referral event" is triggered when any of the following situations occur (but not limited to these scenarios):

[0091] The doctor clicks the "Request Referral" or "Send Transfer Request" button in the electronic medical record system;

[0092] The ambulance's onboard terminal received a "transfer instruction" from the dispatch center;

[0093] The patient's vital signs are critical (e.g., systolic blood pressure <90 mmHg) and the system automatically determines that higher-level support is required.

[0094] Once triggered, the system immediately locks the currently generated EDXP data packets and prepares to start the transmission process.

[0095] S3.2 Identify Recipient Permissions

[0096] The system identifies the receiver's permissions based on the target receiving terminal identifier and determines the receiver's role, such as attending physician, emergency medical personnel, administrative dispatcher, etc. Based on the above role information, it maps to the terminal permission level P of that role: for example, if it is an attending physician, P=1.0, if it is an emergency medical personnel, P=0.8, and if it is an administrative dispatcher, P=0.6.

[0097] S3.3 Dynamic desensitization based on recipient permissions

[0098] The system reads the standardized data (EDXP data packet) generated in step S2, and for each data field, calculates the desensitization strength D by combining its preset data sensitivity level W with the recipient permission level P determined in step S3.2.

[0099]

[0100] Implement a differentiated desensitization strategy based on the D value: Non-desensitizing, 0.3 Partial desensitization, 7. Complete desensitization.

[0101] In this embodiment, the preset sensitivity level is: core treatment data. =0.7, general medical data =0.2, privacy data =0.1. The definitions and specific examples of various data types are as follows:

[0102] Core treatment data

[0103] Definition: Key diagnostic and treatment data that directly impacts emergency diagnosis, treatment decisions, patient assessment, and risk assessment. This is core information that must be accurately and completely transmitted during emergency referrals, with the lowest degree of desensitization. Specific examples include: heart rate, systolic blood pressure, diastolic blood pressure, respiratory rate, blood oxygen saturation, body temperature, level of consciousness, time of onset, pain score, preliminary diagnosis, key examination results, electrocardiogram conclusions, NIHSS score, ST segment elevation, troponin results, trauma ISS score, estimated blood loss, oxygenation index, implemented emergency measures, and medications used and their dosages.

[0104] General medical data

[0105] Definition: Non-core, non-privacy data used to assist in disease assessment and improve diagnostic information, but which does not directly determine emergency treatment plans, may be anonymized appropriately. Specific examples include: summary of past medical history, long-term medication history, past surgical history, family medical history, height, weight, blood glucose level, allergy history, referral number, institution name, ambulance number, and initial physician identification, etc.

[0106] Privacy data

[0107] Definition: Sensitive information that can directly identify a patient's personal identity, family information, contact information, etc., but is not directly related to emergency treatment, must be strictly anonymized to meet the requirements of medical data security and privacy protection regulations. Specific examples include: patient's name, ID number, home address, contact number, family member's name and contact information, work unit, detailed household registration information, medical insurance card number, etc.

[0108] For example, regarding core treatment data =0.7, recipient is a doctor, P=1.0, =0.3, no anonymization was performed, meaning doctors could see the complete blood pressure values, NIHSS scores, original CT images, etc. The recipient was administrative dispatch personnel, P=0.6. =0.58, the execution part is de-sensitized, and administrative dispatchers can only see the "critical condition" label, while the specific value is blurred.

[0109] For example, regarding privacy data, =0.1, the recipient is a doctor, P=1.0, =0.9, complete anonymization is performed; even doctors do not need to see the patient's ID number, as the system automatically replaces it with "****", retaining only the name for verification. The recipient is the emergency medical personnel, P=0.8. =0.92, perform complete desensitization, hide detailed address, and only retain general area.

[0110] This step demonstrates that the same original standardized data can have its visibility granularity dynamically adjusted based on the recipient's role and permissions. A "high-availability version" is generated when sent to doctors, while a "high-privacy version" is generated when sent to administration. This runtime dynamic generation mechanism avoids the waste of resources storing multiple copies and prevents the risk of historical data leakage due to changes in permissions, achieving a perfect balance between "privacy security" and "clinical usability."

[0111] S3.3 compression

[0112] After completing the dynamic desensitization for a specific recipient, the system immediately calls the lightweight compression module to perform lossless compression, preferably with the compressed data packet size not exceeding 100KB.

[0113] In this embodiment, the LZ77 lossless compression algorithm is used, which ensures that the decompressed data is completely consistent with the original, meeting the requirements for medical data integrity. Furthermore, the LZ77 lossless compression algorithm has a high compression ratio for structured text and low algorithm complexity, allowing for rapid execution on grassroots terminals or in the cloud without introducing significant latency. The LZ77 lossless compression algorithm also has high compatibility, as it is the basis for standards such as GZIP and ZIP, ensuring high decompression support at the receiving end. Of course, variations of this scheme, such as LZSS and Deflate algorithms, can also be used, as long as a compression ratio of ≥60% is achieved. The LZ77 lossless compression algorithm used in this embodiment is itself an existing technology; therefore, the specific compression method will not be elaborated upon here.

[0114] S3.4 Encryption

[0115] This embodiment uses the national cryptographic SM4 algorithm to encrypt the compressed data packet; the specific encryption method will not be described in detail.

[0116] This application employs the national standard SM4 block cipher algorithm for end-to-end encryption in the data transmission stage, which has the following significant advantages: It strictly adheres to the "Cryptography Law of the People's Republic of China" and medical industry information security standards, meeting the mandatory requirements of Level 3 Information Security Protection for important data encryption, ensuring the legal and compliant deployment of the system in medical institutions at all levels and regional health platforms; It uses a domestically developed cryptographic algorithm, completely eliminating dependence on foreign encryption standards, removing potential backdoor risks and technical blockade hazards, and effectively safeguarding the national security sovereignty of medical and health big data; The SM4 algorithm has a highly efficient structure and widely supports hardware acceleration instructions for domestically produced chips (actual tests show that on embedded terminals, SM4 encryption takes less than 1ms, completely unaffected by the end-to-end transmission time of emergency data '≤3 seconds'), achieving a balance between security and speed; It can build a purely domestic security ecosystem with national standard algorithms such as SM2 and SM3, solving the compatibility problem of hybrid algorithm systems, while its low power consumption significantly extends the battery life of emergency mobile terminals, adapting to the complex and ever-changing pre-hospital emergency environment.

[0117] S3.5: Generate data integrity check codes

[0118] Before transmission is initiated, the system performs a CRC32 (Cyclic Redundancy Check) algorithm on the compressed EDXP binary data packet to generate a 32-bit (4-byte) checksum. In this embodiment, the checksum is appended to the end of the EDXP data packet, forming a transmission unit of "data body + checksum tail".

[0119] S3.6: Intelligent Communication Link Selection The system dynamically selects the optimal transmission path based on the current network environment:

[0120] Primary link: Prioritize the use of a 5G medical private network. This network provides ≥100Mbps bandwidth and millisecond-level low latency, is dedicated to medical data transmission, and offers high security.

[0121] Backup link: If the 5G signal strength is detected to be lower than the preset threshold (e.g., RSRP < -110dBm) or the real-time rate is lower than 50Mbps, the system will automatically and seamlessly switch to the 4G public network or satellite communication link;

[0122] Edge computing assistance: If the data is located at the edge of a network blind spot, it can be temporarily stored at the nearest edge computing node and forwarded instantly once the link is restored.

[0123] S3.7: Perform data transfer

[0124] The system will send the EDXP data packet with the checksum to the target receiving terminal (such as the emergency department workstation of a higher-level hospital) through the selected link.

[0125] S4. After the target receiving terminal receives the EDXP data packet, it verifies the data integrity based on the check code, and after the verification is successful, it parses the EDXP data packet to extract the core data, thus completing the inter-hospital referral data exchange.

[0126] This step is executed collaboratively by the receiving and feedback module and the time synchronization module deployed on the target receiving terminal (such as the emergency department workstation of a higher-level hospital or the stroke center server). Its core task is to quickly reconstruct emergency patient information while ensuring data integrity and time accuracy, and to automatically trigger a repair mechanism in case of transmission anomalies. Specifically, it includes the following steps:

[0127] Step S4.1: Receive EDXP data packets and extract the checksum.

[0128] The target receiving terminal receives the transmission data stream from the cloud through the communication interface (5G / 4G / satellite). The system first extracts the additional 32-bit CRC32 checksum from the end of the data stream and temporarily stores the remaining part as the "data body to be verified" (i.e., the compressed EDXP data packet).

[0129] Step S4.2: Perform data integrity verification

[0130] The system immediately re-executes the CRC32 algorithm on the "data body to be verified", calculates the local check value, and compares it with the sender's check code extracted in step S4.1:

[0131] If the verification is successful, it is determined that no bit flips or loss occurred during data transmission, and the data integrity verification is passed. The system then proceeds to step S4.4 for timing synchronization and parsing.

[0132] If the verification fails, it is determined that the data was damaged during transmission (e.g., some bytes were corrupted due to signal interference), and the integrity verification fails. The system immediately triggers the fault tolerance mechanism (proces to step S4.3).

[0133] Step S4.3: Trigger the fault tolerance mechanism

[0134] When verification fails, the system automatically initiates a multi-level fault tolerance strategy to restore data integrity, specifically including:

[0135] Record breakpoint location: The system records the location (breakpoint) of the last byte that has been successfully received and verified, and marks it as P. break .

[0136] Initiating a limited retransmission request: The receiving end sends a retransmission command to the sending end (cloud or basic terminal), carrying the breakpoint location P. break The system is set to a maximum number of retransmissions, for example, 3, with an interval of 100ms between each retransmission request; after receiving the instruction, the sending end only retransmits from P... breakInstead of retransmitting the entire packet, it starts sending the remaining data from the point where the interruption occurred (resume transmission).

[0137] Re-verification: Each time retransmitted data is received, the CRC32 verification in step S4.2 is immediately re-executed.

[0138] Anomaly Alarm: In this embodiment, if the verification still fails after three consecutive retransmissions, the system determines that there is a serious link fault, stops automatic retransmission, and performs the following alarm operation:

[0139] A red warning box pops up on the receiving end interface: "Data reception failed, retransmission limit reached, please check network". It automatically sends an SMS or system notification to the hospital's information technology department maintenance personnel, including the faulty terminal ID, patient ID and failure time.

[0140] Step S4.4: Synchronize BeiDou time service with PTP precise time

[0141] After data integrity verification is passed, the system immediately performs time calibration to ensure that the time base of cross-departmental data is consistent. In this embodiment, the time of each terminal is synchronized through BeiDou satellite time synchronization and PTP (Precise Time Protocol): the BeiDou time synchronization module built into the receiving terminal receives satellite signals to obtain high-precision absolute time (accuracy ≤10ns) and corrects the local system clock; the IEEE 1588PTP (Precise Time Protocol) algorithm is used to calculate the network transmission delay of data packets from the sending end to the receiving end. Add the original collection timestamp carried in the data packet to The compensation value yields the calibrated standard timestamp.

[0142]

[0143] in, , For the sender's timestamp, , This is the timestamp of the receiving end.

[0144] In this way, the time synchronization error of multi-source data across institutes can be ensured to be less than 0.05 seconds.

[0145] Step S4.5: After the decryption and EDXP protocol parsing time synchronization is completed, the system restores the data, including data decryption and parsing of EDXP data packets.

[0146] In this embodiment, the data body is decrypted using the national cryptographic SM4 algorithm based on the key ID in the data packet header, restoring it to plaintext JSON data; and the core data is extracted layer by layer according to the field structure (required fields, optional fields, and disease-specific extended fields) defined by the EDXP protocol.

[0147] The extracted data is stored in the hospital database, displayed as needed, and status confirmation information (such as "received successfully, verification passed, time synchronized") is generated and sent back to the sending end and the cloud, completing the closed loop of cross-hospital referral data exchange.

[0148] The method described in this implementation significantly improves the efficiency and quality of cross-hospital data exchange in emergency departments, reducing transmission latency from the current 10-15 seconds to ≤3 seconds and reducing data transmission volume by more than 60%, effectively saving precious time for emergency treatment. Standardized specifications are compatible with over 95% of heterogeneous hospital systems and emergency terminals, resolving cumbersome interface issues. The dynamic desensitization engine balances privacy and clinical usability, reducing the risk of privacy leaks by 99% and meeting medical data compliance requirements. BeiDou timing and fault-tolerance mechanisms ensure data synchronization errors ≤0.05 seconds and integrity ≥99.9%, avoiding biases in diagnostic and treatment decisions. This invention requires no large-scale modification of existing equipment, has low deployment costs, and can be directly applied to various cross-hospital emergency referral scenarios, significantly improving referral response efficiency and treatment quality, reducing readmission rates, and possessing outstanding clinical practical value and promotional significance.

[0149] This application also provides an emergency inter-hospital data interoperability system for implementing the emergency inter-hospital data interoperability method described in the foregoing embodiments, specifically including:

[0150] The data acquisition module is deployed at the terminal of a primary hospital, the terminal of an ambulance, or the terminal of a higher-level hospital. It is used to collect vital signs, initial diagnosis and treatment records, key frames of images, and real-time examination results of emergency patients, and generate an initial collection dataset with timestamps and terminal identifiers.

[0151] The cloud-based standardization processing module is used to process the initial collected dataset according to the preset emergency cross-hospital data standardization specifications, generate structured standard data that conforms to the Emergency-Specific Lightweight Data Exchange Protocol (EDXP), and form an EDXP data packet. The EDXP protocol defines a lightweight data structure that includes a preset number of required fields, optional fields, and at least one disease-specific extended field.

[0152] The dynamic desensitization and encryption module is used to perform dynamic desensitization on the structured standard data based on data level and receiving terminal permissions, and then encrypt it after compression;

[0153] The lightweight transmission module is used to respond to inter-hospital referral events by transmitting encrypted EDXP data packets to the target receiving terminal through the communication network, and includes a checksum for verifying data integrity.

[0154] The receiving and feedback module, deployed at the target receiving terminal, is used to receive encrypted EDXP data packets, verify data integrity, decrypt and parse the data packets to extract core data, and return receiving confirmation information to the sending end.

[0155] The timing synchronization and fault tolerance module is used to calibrate the time of each terminal through BeiDou time synchronization and PTP protocol, and to perform breakpoint resume or limited retransmission when transmission is abnormal.

[0156] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A method for inter-hospital data exchange in emergency departments, characterized in that, Includes the following steps: The system collects four types of core data from emergency patients: vital signs, initial medical records, keyframes of images, and immediate examination results. It also timestamps and binds the core data to the terminal identifier to generate an initial dataset. The initial collected dataset is processed according to the preset emergency inter-hospital data standardization specifications to generate structured standard data conforming to the emergency-specific lightweight data exchange protocol EDXP, forming an EDXP data packet. The EDXP protocol defines a lightweight data structure containing a preset number of required fields, optional fields, and at least one disease-specific extended field. The required fields include unique identifiers and spatiotemporal metadata, continuously monitored physiological parameters, basic awareness and symptom assessment values, on-site treatment process data, and key safety warning labels. The optional fields include historical background data, multimodal examination conclusion summaries, deep-specific indicators, and social support and payment attributes. The disease-specific extended fields include key data for emergency treatment decisions for that disease. In response to inter-hospital referral events, the EDXP data packets are desensitized, compressed, and encrypted before being transmitted to the target receiving terminal, and a check code for verifying data integrity is attached during the transmission process. After the target receiving terminal receives the EDXP data packet, it verifies the data integrity based on the check code, and after the verification is successful, it parses the EDXP data packet to extract the core data, thus completing the inter-hospital referral data exchange. In the data collection step, a dynamically adjusted collection frequency is used for emergency patients with different diseases. The collection frequency is calculated based on the disease priority weight Wi, where Wi∈[0,1]. The calculation formula is: , in, The collection frequency for disease category i. The preset minimum frequency, The preset maximum frequency; The desensitization is dynamic desensitization, and the dynamic desensitization calculates the desensitization strength based on the product of the data sensitivity level and the receiving terminal permission level. After the target receiving terminal receives the EDXP data packet, it synchronizes the time of each terminal with the BeiDou satellite time synchronization and PTP precise time protocol. If the verification code fails, a fault tolerance mechanism is triggered. The fault tolerance mechanism includes: recording the transmission breakpoint location and resuming the transmission from the breakpoint, and performing limited retransmissions if the number of retransmissions does not exceed a preset number and the interval between each retransmission is a preset time. If the retransmission still fails, an abnormal alarm is sent to the operation and maintenance personnel.

2. The method as described in claim 1, characterized in that, Before generating the initial dataset, the 3σ criterion is used to remove outlier data and filter out blank or invalid format data.

3. The method as described in claim 1 or 2, characterized in that, The pre-defined emergency cross-hospital data standardization and processing includes a terminology code matching step: the non-standard medical terms in the original collected data are compared with the pre-defined standard terminology database for similarity calculation. When the similarity is not lower than the similarity threshold, it is automatically mapped to the corresponding standard term; otherwise, a manual verification process is triggered.

4. The method as described in claim 3, characterized in that, The pre-defined standardization and processing of emergency cross-hospital data includes: weighting the integrity of fields and allowing them to proceed to the next processing step only when the score is not lower than 80.

5. The method as described in claim 4, characterized in that, The compression uses the LZ77 lossless compression algorithm, with a data compression ratio of no less than 60%.

6. The method as described in claim 1, characterized in that, The disease-specific extended fields in the EDXP protocol include at least one core mandatory field and multiple optional clinical fields. The core mandatory field is key data for emergency treatment decisions for that disease.

7. An emergency inter-hospital data interoperability system applying the emergency inter-hospital data interoperability method according to any one of claims 1-6, characterized in that, include: The data acquisition module is deployed at the terminal of a primary hospital, the terminal of an ambulance, or the terminal of a higher-level hospital. It is used to collect vital signs, initial diagnosis and treatment records, key frames of images, and real-time examination results of emergency patients, and generate an initial collection dataset with timestamps and terminal identifiers. The cloud-based standardization processing module is used to process the initial collected dataset according to the preset emergency cross-hospital data standardization specifications, generate structured standard data that conforms to the Emergency-Specific Lightweight Data Exchange Protocol (EDXP), and form an EDXP data packet. The EDXP protocol defines a lightweight data structure that includes a preset number of required fields, optional fields, and at least one disease-specific extended field. The dynamic desensitization and encryption module is used to perform dynamic desensitization on the structured standard data based on data level and receiving terminal permissions, and then encrypt it after compression; The lightweight transmission module is used to respond to inter-hospital referral events by transmitting encrypted EDXP data packets to the target receiving terminal through the communication network, and includes a checksum for verifying data integrity. The receiving and feedback module is deployed at the target receiving terminal. It is used to receive the encrypted EDXP data packet, verify the data integrity, decrypt and parse the EDXP data packet to extract the core data, and return a reception confirmation message to the sending end. The timing synchronization and fault tolerance module is used to calibrate the time of each terminal through BeiDou time synchronization and PTP protocol, and to perform breakpoint resume or limited retransmission when transmission is abnormal.

Images