Pre-hospital emergency medical record intelligent quality control method and system based on event driving

Abstract

The application discloses a pre-hospital emergency electronic medical record intelligent quality control method and system based on event driving. The method comprises the following steps: matching the pre-hospital emergency medical record text based on a preset keyword dictionary, mapping the scene keywords to the event type, and mapping the crowd keywords to the special examination module and automatically enabling; according to the event type, the diagnosis information and the vital sign data, the standardized disposal items are determined one by one in three states, and the must execute, optional execute or inapplicable state is output; when the must execute state is determined, the recommended execution mode and the default parameter are generated according to the vital sign severity gradient; the three-state determination results are displayed in different groups and the explainable label is provided; when the must execute item is missing and the submission is triggered, the interaction blocking is executed, the structured unexecuted reason is required to be supplemented, and the quality control score is updated after the blocking is removed. The application fuses the quality control system and the clinical decision assistance, and improves the emergency quality and the doctor disposal efficiency.

Description

Technical Field

[0001] This invention relates to the field of medical information technology and intelligent quality control, specifically to an event-driven intelligent quality control method and system for pre-hospital emergency electronic medical records. Background Technology

[0002] Electronic medical records (EMR) in pre-hospital emergency care are the core data carrier for emergency care quality management, and their quality directly affects the standardization of emergency services and the treatment outcomes for patients. With the advancement of emergency medical information technology, EMR systems have become an indispensable infrastructure in the pre-hospital emergency care workflow, undertaking multiple functions such as recording patient conditions, guiding treatment, and supporting quality control management. However, existing pre-hospital emergency medical record systems generally use fixed forms or simple diagnosis-based rules, revealing numerous technical bottlenecks in practical applications and failing to meet the needs of complex and ever-changing emergency scenarios.

[0003] Existing pre-hospital emergency medical record systems mainly use fixed forms or simple diagnosis-based rules to record medical records and manage quality. These systems typically have a pre-set list of treatment items for doctors to select and rely on post-treatment spot checks for quality control. While some systems can trigger simple rule prompts based on a single diagnostic piece of information, they lack the ability to intelligently link based on the patient's multidimensional dynamic information and cannot implement real-time intervention and precise evaluation during the medical record writing process.

[0004] Existing technologies suffer from the following prominent problems: First, the procedures are rigid, with all patients presented with the same list of procedures, requiring doctors to manually select or ignore a large number of inapplicable items, resulting in low efficiency and a high risk of overlooking crucial procedures. Second, there is a lack of intelligent linkage; the system cannot automatically activate corresponding specialist examination modules or procedures based on dynamic information such as the patient's chief complaint, symptoms, and vital signs. Third, quality control relies on post-event spot checks, failing to intervene in real-time during the medical record writing process, leading to missing crucial procedures and inconsistent medical record quality. Fourth, the necessity of procedures cannot be quantified; the system cannot distinguish between mandatory, optional, and unnecessary procedures, resulting in vague quality control standards and an inability to achieve precise assessment and exemptions. Therefore, there is an urgent need for an intelligent medical record system that can identify emergency events, dynamically link modules, intelligently determine the necessity of procedures, and implement real-time quality control interaction. Summary of the Invention

[0005] This invention proposes an event-driven intelligent quality control method and system for pre-hospital emergency electronic medical records, which solves the problem that existing systems cannot implement real-time quality control blocking and interaction.

[0006] To address the aforementioned technical problems, this invention provides an event-driven intelligent quality control method for pre-hospital emergency electronic medical records, comprising the following steps: Step S1: Extract scenario keywords from the pre-hospital emergency medical record text and map them to preset event types, then activate the medical record module corresponding to the event type; Step S2: Based on the event type, diagnostic information, and vital sign data, evaluate each standardized treatment item according to the rules, and output a three-state judgment result of mandatory execution, optional execution, or inapplicable. Step S3: For the treatment items determined to be mandatory in the three-state determination results, automatically recommend the specific execution method and default parameters of the treatment items based on the severity gradient of the vital sign data; Step S4: When the required action item is not recorded and the user triggers a submission operation, block the submission operation, require the supplementary action record or fill in the structured reason for non-execution, and update the quality control score after the block is lifted.

[0007] Preferably, the triggering condition that must be executed in the three-state determination result in step S2 is at least one of the following conditions: The vital signs data meet the unstable conditions, which include systolic blood pressure below 90 mmHg, diastolic blood pressure below 60 mmHg, heart rate above 120 beats / min or below 50 beats / min, respiratory rate above 24 breaths / min or below 10 breaths / min, and pulse oximetry below 90%. The diagnostic information belongs to a preset mandatory diagnostic path, which includes coma, shock, cardiac and respiratory arrest, hematemesis, and traumatic brain injury. There are pre-defined critical clinical manifestations, including coma and active massive bleeding.

[0008] Preferably, the triggering condition that is not applicable in the three-state determination result in step S2 is that the following conditions are met simultaneously: The vital signs data meet the absolute stability conditions, which include systolic blood pressure between 90 mmHg and 140 mmHg, diastolic blood pressure between 60 mmHg and 90 mmHg, heart rate between 60 beats / min and 100 beats / min, respiratory rate between 12 breaths / min and 20 breaths / min, body temperature between 36.0℃ and 37.3℃, and pulse oximetry not less than 95%. The diagnostic information is neither part of the mandatory diagnostic path nor a preset optional diagnostic path. The optional diagnostic paths include chest pain, hemoptysis, dyspnea, and abdominal pain. There is no indication for intravenous intervention or oxygen therapy.

[0009] Preferably, step S3, which involves automatically recommending the specific execution method and default parameters of the treatment item based on the severity gradient of the vital sign data, includes the following steps: When the treatment is oxygen therapy and the diagnostic information belongs to the preset oxygen therapy classification recommended diagnostic pathway, if the pulse oximetry is not lower than 93%, nasal cannula or face mask oxygenation is recommended, with a default flow rate of 2 to 10 L / min; if the pulse oximetry is not lower than 80% but lower than 93%, non-invasive mechanical ventilation is recommended; if the pulse oximetry is lower than 80%, endotracheal intubation combined with invasive mechanical ventilation is recommended.

[0010] Preferably, the recommended diagnostic pathway for oxygen therapy grading includes coma, shock, chest pain, traumatic brain injury, hematemesis, and dyspnea. When the diagnostic information is cardiac and respiratory arrest, the treatment item is automatically associated with open airway and bag-valve-mask ventilation or mechanical ventilation as a mandatory associated treatment item.

[0011] Preferably, step S1, which involves extracting scenario keywords from pre-hospital emergency medical record text and mapping them to preset event types, further includes the following steps: extracting population keywords from the pre-hospital emergency medical record text and mapping the population keywords to preset specialist physical examination modules, wherein the specialist physical examination modules include obstetric examination modules, neonatal APGAR scoring modules, and Glasgow Coma Scale modules; once the medical record module and the specialist physical examination module are enabled, they are marked as pending completion.

[0012] Preferably, blocking the submission operation in step S4 includes the following steps: popping up a defect list window, which lists all unrecorded mandatory actions, with a one-click jump button next to each action, which, when triggered, locates and highlights the corresponding missing field; the structured reasons for non-execution include the reason item selected from a preset reason list, the responsible person's identifier, and a timestamp, and the preset reason list includes on-site condition limitations, family refusal, and stable condition that does not require execution at this time.

[0013] Preferably, the updating of the quality control score in step S4 includes the following steps: calculating the medical record quality control score according to a preset scoring configuration, wherein in the scoring configuration, if the mandatory treatment item is not recorded and the structured reason for non-execution is not filled in, a preset score is deducted; if the optional treatment item is not recorded, no score is deducted; and if the inapplicable treatment item is not included in the scoring range; the full score of the quality control score is 100 points, including the score for general items, the score for chief complaint and present illness, the score for physical examination, the score for specialist examination, the score for auxiliary examination, the score for emergency treatment, and the score for informed consent record; the deduction value for the mandatory treatment item is deducted from the score for emergency treatment.

[0014] Preferably, the three-state determination result in step S2 is also used for interface rendering. The interface rendering includes: displaying the mandatory disposal items at the top and highlighting them, displaying the optional disposal items in a normal style as secondary items, and folding or hiding the inapplicable disposal items by default. An interpretable label is set next to each disposal item. The interpretable label includes the rule number that triggered the three-state determination result and a summary of the hit conditions.

[0015] This invention also provides an event-driven intelligent quality control system for pre-hospital emergency electronic medical records, implemented based on the aforementioned event-driven intelligent quality control method for pre-hospital emergency electronic medical records, comprising: Event recognition and module linkage unit: used to extract scene keywords from pre-hospital emergency medical record text and map them to preset event types, and automatically activate the medical record module corresponding to the event type; Rule evaluation and three-state determination unit: It is used to evaluate the standardized treatment items one by one according to the event type, diagnostic information and vital sign data, and output a three-state determination result of mandatory execution, optional execution or inapplicable. Treatment Recommendation Unit: This unit is used to automatically recommend specific execution methods and default parameters for treatment items that are determined to be mandatory in the three-state determination results, based on the severity gradient of the vital sign data. Interactive control and blocking closed-loop unit: When the required action item is not recorded and the user triggers the submission operation, the unit blocks the submission operation, requires the supplementary recording of the action item or the filling in of the structured reason for non-execution, and triggers the quality control score update after the blocking is lifted.

[0016] The advantages of this invention include at least the following: 1. The system automatically activates modules related to the patient's condition and collapses irrelevant items, reducing the time doctors spend searching and manually selecting, enabling doctors to quickly complete medical record recording within the tight timeframe of pre-hospital emergency care; 2. By displaying mandatory statuses at the top and using interactive blocking mechanisms, we ensure that necessary treatment for high-risk patients is not overlooked, thus guaranteeing the quality of emergency care from the source. 3. Based on the severity gradient of vital sign data, automatically recommend the most suitable treatment method to doctors, assisting them in making quick decisions under high-pressure conditions; 4. Shift from post-hospital deductions to in-process assistance and intervention, using a differentiated scoring mechanism to provide feedback on doctors' clinical treatment capabilities and continuously improve the quality of pre-hospital emergency care. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the overall system structure according to an embodiment of the present invention; Figure 2This is a flowchart illustrating the three-state determination and interface display process according to an embodiment of the present invention. Figure 3 This is a schematic diagram of the interaction blocking process when a required execution item is missing, as described in an embodiment of the present invention. Figure 4 This is a logic diagram for rule versioning and site differentiation loading in an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of the present invention.

[0019] This invention provides an event-driven intelligent quality control method for pre-hospital emergency electronic medical records, such as... Figure 1 and Figure 2 As shown, the method includes six core steps: event recognition and module linkage, three-state determination of disposal items, hierarchical recommendation of disposal methods for mandatory items, differentiated group display and interpretable tag generation, interaction blocking and cause closure, and quality control score update. The steps communicate with each other through an event bus.

[0020] First, the system identifies events from the pre-hospital emergency medical records entered by the user. The medical records include two core fields: chief complaint and present illness history. The system is pre-configured with a scenario keyword dictionary and a population keyword dictionary. The scenario keyword dictionary stores keyword entries corresponding to emergency scenarios, such as car accident, fall, coma, chest pain, difficulty breathing, hematemesis, cardiac and respiratory arrest, and poisoning. The population keyword dictionary stores keyword entries corresponding to specific populations, such as newborns, pregnant women, and children.

[0021] Examples of the mapping relationships between scenario keyword dictionaries and event types are as follows: Car accidents, drowning, falls, knife wounds, crushing, and impacts are mapped to trauma events; chest pain, chest tightness, and precordial pain are mapped to chest pain events; coma, loss of consciousness, and impaired consciousness are mapped to consciousness disorder events; difficulty breathing, shortness of breath, wheezing, and panting are mapped to respiratory distress events; vomiting blood, coughing up blood, black stools, and bloody stools are mapped to bleeding events; cardiac arrest, respiratory arrest, and cardiac arrest are mapped to cardiac and respiratory arrest events; poisoning, accidental ingestion, and poisoning are mapped to poisoning events. Examples of the mapping relationships between population keyword dictionaries are as follows: External injuries are mapped to the Trauma Index physical examination module; pregnant women, postpartum women, and pregnant women are mapped to the obstetric examination module; newborns and premature infants are mapped to the Neonatal APGAR score module. The entries in the above dictionaries can be expanded and updated according to the actual needs of emergency medical services.

[0022] The system matches medical record texts based on the two preset keyword dictionaries mentioned above. In pre-hospital emergency scenarios, medical record texts typically contain at least one fatal scenario keyword; the system only needs to identify this fatal keyword to complete the event classification. After matching, the system maps the scenario keywords to preset event type sets. For example, the keywords "car accident" and "fall" are mapped to trauma events, the keyword "coma" is mapped to "disorder of consciousness" events, and the keyword "chest pain" is mapped to "chest pain" events. Simultaneously, the system maps population keywords to corresponding specialist examination modules; for example, pregnant women are mapped to the obstetric examination module, and newborns are mapped to the newborn APGAR scoring module.

[0023] Once the mapping is complete, the system automatically enables and displays the aforementioned modules in the medical record interface and marks them as pending completion. This step allows the medical record interface to dynamically adjust according to the patient's specific condition, presenting modules and treatment items relevant to the current emergency scenario, while collapsing or hiding irrelevant content to reduce interface clutter and improve doctors' operational efficiency in emergency situations.

[0024] The core aspect of this invention is to perform a three-state determination on each of the preset standardized treatment items. The rule evaluation module receives the event type identified in the previous step and, in conjunction with diagnostic information and real-time collected vital sign data, independently evaluates the necessity of each standardized treatment item, outputting one of three determination results: mandatory execution, optional execution, or inapplicable.

[0025] In this embodiment of the invention, standardized procedures include, but are not limited to, establishing intravenous access, oxygen therapy, opening the airway, oropharyngeal airway insertion, bag-valve-mask ventilation, endotracheal intubation, non-invasive mechanical ventilation, invasive mechanical ventilation, chest compressions, defibrillation, intravenous adrenaline injection, hemostasis and bandaging, cervical collar fixation, splint fixation, spinal splint fixation, pelvic fixation belt fixation, physical cooling, and intravenous injection of 50% glucose solution. Each of the above standardized procedures is configured with independent three-state judgment rules, including general trigger conditions and specific trigger conditions.

[0026] The three-state decision uses an asymmetric logic structure for condition evaluation. For decisions regarding states that must be executed, an OR logic is used, meaning that the decision is triggered if any of the following conditions are met: The vital signs data meet the preset unstable conditions, or the diagnostic information belongs to the preset set of critical diagnosis pathways, or there are preset critical clinical manifestations.

[0027] Unstable conditions specifically include at least one of the following: systolic blood pressure below 90 mmHg, diastolic blood pressure below 60 mmHg, mean arterial pressure below 65 mmHg, heart rate above 120 bpm or below 50 bpm, respiratory rate above 24 breaths per minute or below 10 breaths per minute, and pulse oximetry below 90%. The critical illness diagnostic pathway includes coma, shock, cardiac and respiratory arrest, hematemesis, and traumatic brain injury. Critical clinical manifestations include coma and active massive bleeding.

[0028] For determining inapplicable states, AND logic is used, meaning that all of the following conditions must be met simultaneously: The vital signs data are within the preset stable range, the diagnostic information does not belong to the critical care diagnostic pathway set, and there are no preset intervention indications.

[0029] The stable range is defined as follows: systolic blood pressure between 90 mmHg and 140 mmHg, diastolic blood pressure between 60 mmHg and 90 mmHg, heart rate between 60 bpm and 100 bpm, respiratory rate between 12 breaths per minute and 20 breaths per minute, body temperature between 36.0 degrees Celsius and 37.3 degrees Celsius, and pulse oximetry not lower than 95%.

[0030] In this embodiment of the invention, some standardized treatment items are also configured with specific vital sign triggering conditions. For example, the specific triggering condition for physical cooling is a body temperature higher than 39 degrees Celsius. When this condition is met, physical cooling is determined to be mandatory, but other treatment items are not affected by this condition. Similarly, when systolic blood pressure is higher than 180 mmHg or diastolic blood pressure is higher than 120 mmHg, the use of antihypertensive drugs and related information recording are determined to be mandatory, but treatment items not directly related to hypertension, such as oxygen therapy and endotracheal intubation, are not affected by this condition.

[0031] When a standardized treatment item does not meet the criteria for either mandatory or inapplicable status, the system classifies it as optional. This asymmetric logic structure employs a wide trigger strategy for mandatory status to ensure no high-risk treatments are missed, while a narrow trigger strategy for inapplicable status ensures no potentially needed treatments are mistakenly excluded. Optional status serves as a fallback between the two, allowing physicians to decide whether to execute the treatment based on clinical judgment.

[0032] When the same standardized procedure is triggered by multiple event types and produces different three-state judgment results, the system takes the most stringent judgment state as the final result. The stringency of the "mandatory" state is higher than that of the "optional" state, and the stringency of the "optional" state is higher than that of the "inapplicable" state. For example, if a trauma event determines the establishment of intravenous access as a mandatory state, while an obstetric event determines the same procedure as an optional state, the system takes the mandatory state as the final judgment result.

[0033] When a standardized treatment item is determined to be mandatory, the rule evaluation module further automatically generates a recommended execution method and default parameters for that treatment item based on the severity gradient of vital sign data. This function extends the quality control system's capabilities from determining the necessity of treatment items to recommending specific execution plans, assisting doctors in making rapid treatment decisions in the high-pressure, short-time environment of pre-hospital emergency care.

[0034] Taking oxygen therapy as an example, once the procedure is deemed mandatory, the system provides a three-tiered recommendation based on the pulse oximetry reading. When the pulse oximetry is not lower than 93%, the recommended method is nasal cannula or face mask oxygenation, with default parameters of 2-5 L / min for nasal cannula or 5-10 L / min for face mask. When the pulse oximetry is lower than 93% but not lower than 80%, the recommended method is non-invasive mechanical ventilation. Many modes are available, the simplest being S / T mode. The initial inhaled oxygen concentration (FiO2) can be set to a high concentration, such as 60%-100%, with an inspiratory pressure (IPAP) of at least 12-14 cmH2O and an expiratory pressure (EPAP) of at least 6-8 cmH2O. These can be adjusted subsequently based on blood oxygen levels and tolerance. When pulse oximetry saturation is below 80%, the recommended approach is endotracheal intubation combined with invasive mechanical ventilation. The initial mode can be PCV or VCV, with an inhaled oxygen concentration (FiO2) of 100%, a tidal volume of 6-8 ml / kg at ideal body weight, and an initial positive end-expiratory pressure (PEEP) of at least 10-12 cmH2O. Subsequent titration adjustments should be made based on oxygenation, plateau pressure, and driving pressure. For patients experiencing cardiac and respiratory arrest, the system will also automatically associate open airway and bag-valve-mask assisted ventilation or mechanical ventilation.

[0035] Taking the establishment of intravenous access as an example, when the diagnostic information belongs to the critical care diagnostic pathway set and the vital signs data meet the unstable condition, the recommended procedure is to establish intravenous access and perform fluid resuscitation. When the diagnostic information belongs to the potential risk diagnostic pathway set and the vital signs data are in the stable range, the recommended procedure is to prophylactically establish intravenous access. The potential risk diagnostic pathway set includes chest pain, hemoptysis, dyspnea, and abdominal pain.

[0036] Taking endotracheal intubation as an example, once this procedure is deemed mandatory, the system makes recommendations based on pulse oximetry and respiratory rate. When pulse oximetry is below 80% or respiratory rate is below 6 breaths per minute, endotracheal intubation is recommended, with default parameters of endotracheal tube diameter of 7.5-8.0 mm (male) and 7.0-7.5 mm (female). When the patient is in cardiac and respiratory arrest and chest compressions have been initiated, the system recommends performing endotracheal intubation during the intervals between chest compressions, and linking it to bag-valve-mask ventilation as a transitional measure before intubation.

[0037] The recommended methods and default parameters mentioned above will be dynamically updated as vital signs data change in real time. For example, if a patient's pulse oximetry saturation drops from 95% to 85% during transport, the system will automatically change the recommended oxygen therapy method from nasal cannula to non-invasive mechanical ventilation and update the default parameters accordingly. Doctors can adopt the system's recommendations or modify the implementation methods and parameters based on clinical judgment.

[0038] In this embodiment of the invention, the interface rendering module differentiates and displays standardized processing items based on the three-state determination results. Standardized processing items in the mandatory execution state are displayed at the top, highlighted in red, with the recommended execution method and default parameters displayed next to them. Standardized processing items in the optional execution state are displayed in a secondary manner, using a normal style. Standardized processing items in the inapplicable state are collapsed or hidden by default to reduce interface clutter.

[0039] Each standardized procedure is accompanied by an interpretable label. This label contains the rule number that triggered the decision, along with a summary of the key fields and thresholds involved. For example, when establishing intravenous access is determined to be mandatory, the interpretable label will show the rule number matched and the diagnosis of coma with a systolic blood pressure below 90 mmHg. Doctors can click on the interpretable label to expand and view the complete rule logic, ensuring the decision-making process is traceable and understandable.

[0040] like Figure 3 As shown, when a user completes medical record entry and attempts to submit, sign, or archive it, the system checks whether all standardized procedures that are required to be performed have been recorded. If any required procedures are not recorded, the system blocks the interaction.

[0041] The specific process for interactive blocking is as follows: The system first pops up a defect list window, which lists all standardized procedures that are in a mandatory execution state but have not been recorded. Each standardized procedure has a one-click jump control next to it. After the user clicks the one-click jump control, the system automatically locates and highlights the corresponding missing field. The user can choose to supplement the procedure record; the system checks the completeness of the supplemented content, and if complete, the blocking for that item is lifted. The user can also choose to select a reason for not executing from a preset structured reason list. The structured reason list includes options such as on-site condition limitations, family refusal, and stable condition requiring no further action. After the user selects a reason for not executing, the system records the responsible person's information and a timestamp; the blocking is lifted after the user confirms.

[0042] Standardized actions in the optional execution state do not trigger interactive blocking, but the system provides an interface for choosing whether to execute. If the user selects not to execute, the system also provides a structured list of reasons for the user to select and record. Standardized actions in the inapplicable state do not require any user action; the system background automatically records the criteria for determining whether they meet the inapplicability rules.

[0043] After the blockage is lifted, the system triggers a quality control score update, assigning a 100-point score to the current pre-hospital emergency medical record based on the preset scoring configuration. The scoring configuration categorizes the scoring items into general items, chief complaint and present illness history, physical examination, specialist examinations or scores, auxiliary examinations, diagnosis, emergency treatment and changes in condition, informed consent records, emergency handover records, and timeliness of data entry. Each category has a corresponding standard score, and the sum of the standard scores for all categories is 100 points.

[0044] In the scoring calculation, if a standardized procedure that is required to be performed is not recorded and no reason is provided for its non-performance, points will be deducted according to the corresponding deduction value in the scoring configuration. For example, failure to establish intravenous access deducts four points, failure to administer oxygen deducts three points, failure to perform endotracheal intubation deducts five points, failure to administer adrenaline deducts four points, failure to perform cervical collar immobilization deducts two points, and failure to perform splint immobilization deducts five points. Standardized procedures that are optional or inapplicable are not included in the deduction calculation. This differentiated scoring mechanism ensures that the quality control score truly reflects the physician's clinical management ability, rather than just the completeness of the medical record.

[0045] like Figure 4 As shown, this embodiment of the invention also includes a configuration and version management module. This module supports loading different rule versions, keyword mapping tables, and scoring configurations for each site. All sites share the same event-driven engine and three-state judgment framework as the core judgment logic, but each site can have its own independent set of required fields, deduction weights, and keyword mapping tables. The rule version management module contains a rule version library, supports canary releases and version rollbacks, and records the currently used rule version fields each time a medical record is evaluated, ensuring the traceability of the evaluation results.

[0046] Example 1: The Necessary Execution Decision for Triggering a Traumatic Event and Establishing Intravenous Access In this embodiment, a doctor sees a patient injured in a car accident, whose chief complaint is "coma following the accident." The system matches the chief complaint text with a preset keyword dictionary, extracts the scenario keywords "car accident" and "coma," maps the car accident to the trauma event type, and automatically activates the craniocerebral injury-related physical examination module.

[0047] The rule evaluation module receives an event type of traumatic event, a diagnostic pathway including coma, and reads vital sign data, including a systolic blood pressure of 85 mmHg, which is below the first blood pressure threshold of 90 mmHg. Since the diagnosis of coma falls within the critical care diagnostic pathway set and the systolic blood pressure meets the unstable condition, the system determines the establishment of intravenous access as a mandatory action. Furthermore, because the diagnosis belongs to the critical care diagnostic pathway set and the vital sign data meets the unstable condition, the system recommends establishing intravenous access and performing fluid resuscitation.

[0048] The interface rendering module will prominently display the intravenous access treatment item at the top, highlighted in red, with interpretable labels showing the hit rules and trigger field summaries. When a doctor completes the form and attempts to submit, the system detects that the intravenous access treatment has not been recorded and pops up a blocking window indicating that the patient is in shock and coma and an intravenous access must be established. The doctor can choose to supplement the treatment, or select on-site conditions or family refusal from the structured reason list and sign to confirm. After the loop is closed, the blocking is lifted and the quality control score is updated.

[0049] Example 2: Optional Decision-Making for Patients with Stable Chest Pain In this embodiment, the patient's chief complaint was chest pain for half an hour, and the vital signs data were systolic blood pressure 125 mmHg, diastolic blood pressure 80 mmHg, heart rate 88 bpm, and pulse oxygen saturation 97%.

[0050] The rule evaluation module determined that the diagnosis belonged to the chest pain pathway, but all vital signs data were within a stable range, with pulse oxygen saturation at a stable threshold of 97% not lower than 95%. Since chest pain belongs to the potential risk diagnostic pathway set rather than the critical illness diagnostic pathway set, and the vital signs data did not meet the unstable condition, the system determined both oxygen therapy and establishing intravenous access as optional execution states.

[0051] The interface rendering module displays the two treatment options in a normal style in the selectable area, without forcibly placing them at the top. The doctor determines that the patient's chest pain has subsided, selects "not to be performed," and chooses "condition stable, no treatment needed" from the structured reason list. The system records the reason and allows submission; these two treatment options are not included in the score deduction calculation.

[0052] Example 3: Criteria for Inapplicability of Scalp Contusion In this embodiment, the patient was diagnosed with scalp contusion, and the vital signs were systolic blood pressure 120 mmHg, diastolic blood pressure 80 mmHg, heart rate 72 bpm, respiratory rate 16 breaths per minute, and pulse oximetry 99%.

[0053] The rule assessment module determined that all vital signs data were within a stable range, the diagnosis of scalp contusion did not fall within the critical care diagnostic pathway set, and there were no indications for intravenous intervention or oxygen therapy. Simultaneously, all conditions for an inapplicable state were met. Therefore, the system determined both establishing intravenous access and oxygen therapy as inapplicable.

[0054] The interface rendering module collapses or hides the two treatment items by default, requiring no action from the doctor. The system backend automatically records the criteria for determining whether they meet the inapplicable rules, and these two treatment items are not included in the quality control missing item assessment.

[0055] Example 4: Recommendations for Tiered Oxygen Therapy Treatment This example demonstrates the tiered recommendation function for treatment within a mandatory procedure. The patient is diagnosed with dyspnea, and their vital signs show an oxygen saturation of 88% and a respiratory rate of 28 breaths per minute.

[0056] The rule assessment module determines that the diagnosis falls under the critical care diagnostic pathway of dyspnea, and the pulse oximetry saturation of 88% is below the first oxygenation threshold of 90%, thus classifying oxygen therapy as mandatory. When recommending the treatment method, the system, based on the pulse oximetry saturation of 88% falling within the 80% to 93% range, recommends non-invasive mechanical ventilation, with default parameters set to S / T ventilation mode and corresponding positive inspiratory and expiratory pressures.

[0057] During transport, the patient's condition worsened, and their pulse oximetry saturation dropped to 75%. The system detected that the pulse oximetry saturation was below the third oxygenation threshold of 80%, and automatically updated the recommended treatment to endotracheal intubation combined with invasive mechanical ventilation. The default parameters were updated to VCV ventilation mode, 6-8 ml / kg tidal volume, and 5 cmH2O positive end-expiratory pressure. The interface simultaneously refreshed to display the updated recommended treatment, allowing doctors to quickly adjust the management plan accordingly.

[0058] This invention also provides an event-driven intelligent quality control system for pre-hospital emergency electronic medical records, such as... Figure 1 As shown, the system includes an event recognition and module linkage unit, a rule evaluation and three-state determination unit, an interface rendering and group display unit, and an interactive control and blocking closed-loop unit.

[0059] The event recognition and module linkage unit is used to match pre-hospital emergency medical record texts based on a preset keyword dictionary, map the matched scene keywords to event types, and map the matched population keywords to the specialist physical examination module and automatically activate it.

[0060] The rule evaluation and three-state determination unit is used to perform three-state determination on each preset standardized treatment item according to the event type, diagnostic information and vital sign data, and output the mandatory execution state, optional execution state or inapplicable state. When the determination is a mandatory execution state, the recommended execution method and default parameters of the standardized treatment item are generated according to the severity gradient of the vital sign data.

[0061] The interface rendering and group display unit is used to differentiate and display standardized processing items based on the results of the three-state determination and generate interpretable tags.

[0062] The interactive control and blocking closed-loop unit is used to perform interactive blocking when a standardized action item in a mandatory state is not recorded and the user triggers a submission operation, requiring the user to fill in the action record or select the reason for non-execution from a preset structured reason list. After the blocking is lifted, the quality control score is updated.

[0063] The system also includes a quality control scoring module and a configuration and version management module. The quality control scoring module reads medical record completeness and mandatory item coverage metrics, calculates scores according to the scoring configuration, and updates scores in real time. The configuration and version management module loads the corresponding rule version, keyword mapping table, and scoring configuration based on the site identifier, supporting canary releases and version rollbacks. The modules communicate with each other via an application programming interface (API) or an event bus.

[0064] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described; only preferred embodiments of the present invention are illustrated. The descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention. As long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0065] It should be noted that those skilled in the art can make various modifications and improvements without departing from the inventive concept, and these all fall within the scope of protection of this invention. Therefore, the scope of protection of this invention should be determined by the appended claims.

Claims

1. An event-driven intelligent quality control method for pre-hospital emergency electronic medical records, characterized in that, Includes the following steps: Step S1: Extract scenario keywords from the pre-hospital emergency medical record text and map them to preset event types, then activate the medical record module corresponding to the event type; Step S2: Based on the event type, diagnostic information, and vital sign data, evaluate each standardized treatment item according to the rules, and output a three-state judgment result of mandatory execution, optional execution, or inapplicable. Step S3: For the treatment items determined to be mandatory in the three-state determination results, automatically recommend the specific execution method and default parameters of the treatment items based on the severity gradient of the vital sign data; Step S4: When the required action item is not recorded and the user triggers a submission operation, block the submission operation, require the supplementary action record or fill in the structured reason for non-execution, and update the quality control score after the block is lifted.

2. The event-driven intelligent quality control method for pre-hospital emergency electronic medical records according to claim 1, characterized in that: The triggering condition that must be executed in the three-state determination result in step S2 is at least one of the following conditions: The vital signs data meet the unstable conditions, which include systolic blood pressure below 90 mmHg, diastolic blood pressure below 60 mmHg, heart rate above 120 beats / min or below 50 beats / min, respiratory rate above 24 breaths / min or below 10 breaths / min, and pulse oximetry below 90%. The diagnostic information belongs to a preset mandatory diagnostic path, which includes coma, shock, cardiac and respiratory arrest, hematemesis, and traumatic brain injury. There are pre-defined critical clinical manifestations, including coma and active massive bleeding.

3. The event-driven intelligent quality control method for pre-hospital emergency electronic medical records according to claim 2, characterized in that: The triggering condition that is not applicable in the three-state determination result in step S2 is that the following conditions are met simultaneously: The vital signs data meet the absolute stability conditions, which include systolic blood pressure between 90 mmHg and 140 mmHg, diastolic blood pressure between 60 mmHg and 90 mmHg, heart rate between 60 beats / min and 100 beats / min, respiratory rate between 12 breaths / min and 20 breaths / min, body temperature between 36.0℃ and 37.3℃, and pulse oximetry not less than 95%. The diagnostic information is neither part of the mandatory diagnostic path nor a preset optional diagnostic path. The optional diagnostic paths include chest pain, hemoptysis, dyspnea, and abdominal pain. There is no indication for intravenous intervention or oxygen therapy.

4. The event-driven intelligent quality control method for pre-hospital emergency electronic medical records according to claim 1, characterized in that: Step S3, which involves automatically recommending specific execution methods and default parameters for the treatment items based on the severity gradient of the vital sign data, includes the following steps: When the treatment is oxygen therapy and the diagnostic information belongs to the preset oxygen therapy classification recommended diagnostic pathway, if the pulse oximetry is not lower than 93%, nasal cannula or face mask oxygenation is recommended, with a default flow rate of 2 to 10 L / min; if the pulse oximetry is not lower than 80% but lower than 93%, non-invasive mechanical ventilation is recommended; if the pulse oximetry is lower than 80%, endotracheal intubation combined with invasive mechanical ventilation is recommended.

5. The event-driven intelligent quality control method for pre-hospital emergency electronic medical records according to claim 4, characterized in that: The recommended diagnostic pathways for oxygen therapy grading include coma, shock, chest pain, traumatic brain injury, hematemesis, and dyspnea. When the diagnostic information indicates cardiac and respiratory arrest, the treatment item is automatically associated with open airway and bag-valve-mask ventilation or mechanical ventilation as a mandatory associated treatment item.

6. The event-driven intelligent quality control method for pre-hospital emergency electronic medical records according to claim 1, characterized in that: The step S1, which involves extracting scenario keywords from pre-hospital emergency medical record text and mapping them to preset event types, further includes the following steps: extracting population keywords from the pre-hospital emergency medical record text and mapping the population keywords to preset specialist physical examination modules, which include obstetric examination modules, neonatal APGAR scoring modules, and Glasgow Coma Scale modules; once the medical record module and the specialist physical examination module are enabled, they are marked as pending completion.

7. The event-driven intelligent quality control method for pre-hospital emergency electronic medical records according to claim 1, characterized in that: Step S4, blocking the submission operation, includes the following steps: a defect list window pops up, listing all unrecorded mandatory actions, with a one-click jump button next to each action item. When the one-click jump button is triggered, it locates and highlights the corresponding missing field; the structured reasons for non-execution include the reason item selected from the preset reason list, the responsible person's identifier, and a timestamp. The preset reason list includes on-site condition limitations, family refusal, and stable condition that does not require execution at this time.

8. The event-driven intelligent quality control method for pre-hospital emergency electronic medical records according to claim 1, characterized in that: The updated quality control score in step S4 includes the following steps: calculating the medical record quality control score according to the preset scoring configuration. In the scoring configuration, if the mandatory treatment items are not recorded and the structured reason for non-execution is not filled in, points are deducted according to the preset score; if the optional treatment items are not recorded, no points are deducted; and if the inapplicable treatment items are not included in the scoring range, the full score of the quality control score is 100 points, including the score for general items, the score for chief complaint and present illness history, the score for physical examination, the score for specialist examination, the score for auxiliary examination, the score for emergency treatment, and the score for informed consent record. The deduction value for the mandatory treatment items is deducted from the score for emergency treatment.

9. The event-driven intelligent quality control method for pre-hospital emergency electronic medical records according to claim 1, characterized in that: The three-state determination result in step S2 is also used for interface rendering. The interface rendering includes: displaying the mandatory actions at the top and highlighting them; displaying the optional actions in a normal style at a secondary level; and folding or hiding the inapplicable actions by default. An interpretable label is set next to each action, and the interpretable label includes the rule number that triggered the three-state determination result and a summary of the hit conditions.

10. An event-driven intelligent quality control system for pre-hospital emergency electronic medical records, implemented based on the event-driven intelligent quality control method for pre-hospital emergency electronic medical records as described in any one of claims 1-9, characterized in that, include: Event recognition and module linkage unit: used to extract scene keywords from pre-hospital emergency medical record text and map them to preset event types, and automatically activate the medical record module corresponding to the event type; Rule evaluation and three-state determination unit: It is used to evaluate the standardized treatment items one by one according to the event type, diagnostic information and vital sign data, and output a three-state determination result of mandatory execution, optional execution or inapplicable. Treatment Recommendation Unit: This unit is used to automatically recommend specific execution methods and default parameters for treatment items that are determined to be mandatory in the three-state determination results, based on the severity gradient of the vital sign data. Interactive control and blocking closed-loop unit: When the required action item is not recorded and the user triggers the submission operation, the unit blocks the submission operation, requires the supplementary recording of the action item or the filling in of the structured reason for non-execution, and triggers the quality control score update after the blocking is lifted.

Images