Medical data processing method and medical information system

Abstract

The invention relates to the technical field of medical data processing, in particular to a medical data processing method and a medical information system.The medical data processing method comprises the steps that a dual-channel mode comprising a dominant change channel and an implicit change channel is adopted for automatically collecting data, the data are compared with historical data, and whether newly-added fields appear or not is judged; carrying out data sampling and three-dimensional data slicing on the newly added field, carrying out term matching and structure analysis on data obtained after slicing, and carrying out dynamic rule packaging to generate an execution rule packet; and performing rule sandbox verification based on the execution rule packet, and performing double-engine operation based on data acquisition time to realize automatic sensing of data source change and dynamic adjustment of configuration.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of medical data processing, and in particular to a medical data processing method and a medical information system. BACKGROUND

[0002] In recent years, in order to enhance the informatization construction of medical treatment, diversified data terminals have been produced, including medical and nursing large screens, bedside screens, corridor screens, door screens, infusion monitoring, mattress monitoring and other Internet of Things devices, aiming to create all-round intelligent scenes (referred to as smart medical systems) in the medical industry.

[0003] The existing medical data conversion scheme realizes the conversion of non-standard data to standard format through preconfigured templates, which reduces custom development, but still has significant defects: when the interface or data structure of the hospital information system is upgraded, the mapping rules, interface configurations and other static parameters of the template engine need to be manually maintained. In the medical scene, the data source changes frequently, such as HIS system version update and inspection equipment interface upgrade, and manual maintenance is costly and prone to errors, resulting in interruption of system conversion services. There is an urgent need for a conversion mechanism that can automatically perceive data source changes and dynamically adjust configurations. SUMMARY

[0004] The purpose of the present application is to provide a medical data processing method and a medical information system that can automatically perceive data source changes and dynamically adjust configurations.

[0005] To achieve the above purpose, in a first aspect, the present application provides a medical data processing method, comprising the following steps: Automatically collecting data in a dual-channel mode and comparing with historical data to determine whether new fields appear; Analyzing the new fields and constructing knowledge base linkage rules according to the analysis results to generate an execution rule package; Based on the execution rule package, rule sandbox verification is performed, and dual-engine operation is performed based on data collection time.

[0006] The dual-channel mode includes an explicit change channel and an implicit change channel, the explicit change channel is used to obtain version update logs in the upgrade announcement platform of the hospital information system, and the implicit change channel is used to automatically collect multiple pieces of anonymous data of each department.

[0007] The dual-channel mode is used to automatically collect data and compare with historical data to determine whether new fields appear, which includes: Data is automatically collected in a dual-channel mode, and fingerprint extraction is performed on the collected data; Compare the fingerprint features of the current data with the fingerprint features of the historical data to determine whether new fields appear.

[0008] wherein the new field is parsed, and a knowledge base linkage rule is constructed according to the parsing result, an execution rule package is generated, including: Data sampling is performed on the original data corresponding to the new field, and three-dimensional data slicing is performed on each piece of original data; The data obtained after slicing is subjected to term matching and structure analysis, and dynamic rule packaging is performed to generate an execution rule package.

[0009] wherein the data sampling is performed on the original data corresponding to the new field, and three-dimensional data slicing is performed on each piece of original data, including: The original data corresponding to the new field is sampled based on data characteristics; Each piece of original data is subjected to three-dimensional data slicing according to field level, structure level and semantic level.

[0010] wherein after the three-dimensional data slicing is performed on each piece of original data, the method further includes: The sliced data obtained is converted into a feature matrix, wherein the features include naming features, numerical features, structure features and semantic features.

[0011] wherein the execution rule package is subjected to rule sandbox verification, and based on the data collection time, a double-engine operation is performed, including: The execution rule package is subjected to historical data backtracking test and real-time traffic simulation test in sequence; Based on the data collection time, the matching engine mode is determined, wherein the double engine includes a new engine and an old engine; The medical data obtained is subjected to data conversion based on the matching engine mode.

[0012] wherein the method further includes: The frequency of the rules used in the execution rule package is recorded, and the invalid rules are archived and stored.

[0013] wherein when the knowledge base linkage rule is constructed according to the parsing result, the method further includes: If the new field cannot construct the knowledge base linkage rule, auxiliary correction is performed.

[0014] In a second aspect, the present application provides a medical information system, including: one or more processors, a memory and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs include a medical data processing method for executing the first aspect.

[0015] This invention discloses a medical data processing method and medical information system that automatically collects data using a dual-channel mode including explicit change channels and implicit change channels, compares the data with historical data to determine if any new fields have appeared; performs data sampling and three-dimensional data slicing on the new fields, performs term matching and structure parsing on the sliced ​​data, and dynamically encapsulates rules to generate an execution rule package; performs rule sandbox verification based on the execution rule package, and runs a dual-engine system based on the data collection time to automatically detect changes in the data source and dynamically adjust the configuration. Attached Figure Description

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

[0017] Figure 1 This is a schematic diagram of the steps of a medical data processing method according to the first embodiment of the present invention.

[0018] Figure 2 This is a flowchart illustrating a medical data processing method provided by the present invention.

[0019] Figure 3 This is a flowchart illustrating step S101 provided by the present invention.

[0020] Figure 4 This is a flowchart illustrating step S102 provided by the present invention.

[0021] Figure 5 This is a flowchart illustrating step S103 provided by the present invention.

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

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

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

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

[0026] The first embodiment of the present application is: Please refer to Figures 1-5 The present application provides a medical data processing method, comprising the following steps: S101, automatically collecting data in dual-channel mode and comparing with historical data to determine whether new fields appear.

[0027] Specifically, the dual-channel mode includes an explicit change channel and an implicit change channel. The explicit change channel interfaces with the upgrade announcement platform of the hospital information system, and real-time extracts version update logs, such as HIS system upgrading from V2.1 to V3.0. Key change descriptions are extracted, including new data fields, abandoned fields, and structure adjustment fields. The new data field can be a PDF link field for adding genetic test report; the abandoned field can be an old version medical record number field; and the structure adjustment can be a change from a one-level field to a two-level nested field for patient basic information. The implicit change channel automatically extracts the latest 10 anonymous data of each department in the early morning, such as laboratory reports and electronic prescriptions; then, a unique feature identifier of the data is generated by fingerprint extraction, including field name and hierarchical relationship, for example, laboratory report.blood analysis.white blood cell count; data type distribution, for example, numerical field accounts for 60%, and text field accounts for 40%; and key value characteristics, for example, blood pressure value field is in "XXX / XXX mmHg" format.

[0028] Through multi-dimensional feature fusion, a unique "fingerprint" is generated for medical data, and the core is to capture the essential features of data structure and content. The whole process is divided into three layers of dissection: First layer: field topological map construction The system first scans the overall architecture of the data file to establish a complete topology of the field path. Taking a JSON format inspection report as an example, the system parses its tree structure layer by layer: Path encoding: Convert nested fields into positioning paths. For example, "inspection report.heart marker.high-sensitivity troponin T" indicates that the field is located in the heart marker category under the inspection report. This encoding can accurately locate the field position, even if the field name is the same (such as "white blood cell count" in different departments), and the path difference can distinguish it. Relationship weight marking: Record the association strength between fields. For example, "systolic pressure" and "diastolic pressure" often appear in pairs, and the system will add a "symbiotic weight value" (such as 0.95) to this pair of fields, while the symbiotic weight of "blood glucose value" and "image number" is close to 0.

[0029] Second layer: data type feature extraction The system conducts in-depth analysis of the data type of each field: basic type identification: determine whether the field belongs to numerical type (such as test results), text type (such as diagnosis description), image link (such as CT image URL), or composite type (such as JSON array).

[0030] Numerical type fine processing: statistical value distribution characteristics: automatically generate a histogram to record the minimum value, maximum value, 25% / 75% quantile (for example, blood pressure values are concentrated in the 80-140 mmHg interval). Outlier detection: identify outliers through box plot algorithm (such as abnormal value of 200% for blood oxygen saturation).

[0031] Text type feature extraction: keyword density analysis: calculate the frequency of medical terms (such as "malignant" "nodule" density in CT report). Format pattern extraction: construct regular expression templates. For example, blood pressure field is automatically summarized as \d{2,3} / \d{2,3}mmHg, and medical record number matches the [A-Z]{2}\d{8} rule.

[0032] Third layer: semantic fingerprint generation Inject medical semantic understanding on the basis of features: term standardization mapping: match the original field name with the standard medical term library. For example, "hs-TnT" (doctor's shorthand) is mapped to "high-sensitivity troponin T" and bound to LOINC code (laboratory code) LP200015-1.

[0033] Contextual association analysis: infer semantics through sibling nodes of the field. For example, when field A ("fasting blood glucose") and field B ("glycated hemoglobin") coexist, it is automatically marked as "diabetes monitoring combination".

[0034] Strengthen understanding according to parent node classification: the "CA125" field under the "tumor marker" category automatically adapts to the gynecological tumor standard (not the digestive department standard).

[0035] Dynamic weight adjustment: The "heart rate value" field reported by the emergency department is given a higher weight (as it relates to a critical value), while the same field in the physical examination department is given a lower weight.

[0036] Fourth layer: fingerprint compression and comparison Final generation of lightweight fingerprint identification: Feature vector compression: encode multi-dimensional features (path, type, semantics) into 128-bit hash values. For example: field path hash (a3f8b1) + data type marker (N4: numerical type 4 bytes) + semantic encoding (C_LP200015) → generate final fingerprint a3f8b1N4C_LP200015.

[0037] Intelligent difference comparison: When comparing the new data fingerprint a3f8b1N4C_LP200015 with the historical fingerprint a3f8b1N4C_LP200012, the system finds that the semantic encoding has changed (LP200015 → LP200012), and automatically triggers the "field term upgrade" alarm. If the historical fingerprint is a3f8b1**T8**C_LP200015 (T8 represents text type 8 bytes), and the new fingerprint is numerical type (N4), it is determined as "data type change".

[0038] Compare the fingerprint features of newly captured medical data with the fingerprint features of historical data, and automatically trigger alarms when differences are found: field-level changes: addition or deletion, structure-level changes: original field drug list changed from text string to JSON array; and automatically label the change type to determine whether a new field appears.

[0039] S102, parse the new field, and construct knowledge base linkage rules according to the parsing result to generate an execution rule package.

[0040] Specifically, when a new field is determined to appear, data sampling is performed based on the original data corresponding to the new field, specifically: from the newly arrived data stream, 100 continuous same type reports are intercepted as a sample pool; stratified sampling according to data characteristics: 20 reports containing extreme values, such as detection value abnormally high / low; 30 typical value reports, representing common cases; 50 full-field complete reports; ensure to cover all new fields.

[0041] Perform medical data desensitization on the sampled data: remove sensitive information such as patient name and ID number, and retain field structure and numerical characteristics. Data integrity verification: through missing value analysis algorithm, automatically exclude reports with incomplete key fields (such as missing detection time records).

[0042] Then the three-dimensional data slicing is performed, that is, each piece of original data is sliced according to three dimensions, including field-level slicing, structure-level slicing and semantic-level slicing. The field-level slicing is to extract the complete life cycle data of a single field, such as high-sensitivity troponin T, including field name, data type, unit mark (such as "ng / L"), value range (12.5-350.2); the structure-level slicing is to capture the JSON / XML tree path where the field is located, and record the relationship between adjacent fields, such as test report -> cardiac marker -> high-sensitivity troponin T; the semantic-level slicing is to extract the medical context of the field, including the detection category to which it belongs, the related disease and the clinical significance.

[0043] The processing process of the field-level slicing is as follows: Basic metadata extraction: automatically capture field name, data type (numeric type / text type / image), storage format (floating point precision, string length). For example, the blood pressure field is marked as "composite numeric type", including two floating point numbers (systolic pressure / diastolic pressure) and a unit identifier (mmHg).

[0044] Value domain space mapping: analyze historical data to generate value distribution heat map: normal value interval: blood glucose value is concentrated in 4.0-6.1 mmol / L (green safe zone); abnormal fluctuation zone: > 11.1 mmol / L (diabetes warning threshold, red high-risk zone); outlier capture: for example, a machine error value of 200% appears in blood oxygen saturation Unit system standardization: intelligently strip units and establish conversion relationship: test value "125 mg / dL" is disassembled into numeric value "125" + unit "mg / dL"; automatically associate knowledge base: 1 mg / dL = 0.0555 mmol / L, to ensure the comparability of data across departments.

[0045] Life cycle tracking: record the evolution track of the field: for example, the "troponin T" field used the unit "μg / L" before 2023, and was upgraded to "ng / L" in 2024 (sensitivity improved by 1000 times), and the system automatically marks the version difference and adapts the conversion rule.

[0046] The processing process of the structure-level slicing is as follows: Path coordinate positioning: use file path-like coding to record the field position: radiology CT report: imaging report / chest CT / lung nodule / volume calculation; laboratory report: test sheet / tumor marker / CA199; the same field name "volume" is distinguished as lung nodule volume (unit mm 3 ) and prostate volume (unit mL) in different paths.

[0047] Nested relationship deconstruction: Analyze the tree structure of JSON / XML: Parent node analysis: "Blood pressure" as a parent node contains two child nodes "systolic pressure" and "diastolic pressure"; sibling node association: when "fasting blood glucose" and "2h postprandial blood glucose" coexist, they are automatically bound as a diabetes monitoring combination.

[0048] Cross-document structure comparison: Identify structural differences between similar reports: ECG report V1 version: heart rate as a first-level field; V2 version upgrade: heart rate is included in / signs and symptoms / heart function / heart rate three-level path system automatically marks such structural adjustments to avoid rule invalidation.

[0049] The processing process of semantic-level slicing is: Terminology knowledge graph binding: The original field "HbA1c" is automatically matched with the standard term "glycosylated hemoglobin" (LOINC code 17856-6); associate clinical significance through the graph: this indicator reflects the average blood glucose level for 3 months, which is used for diabetes diagnosis.

[0050] Contextual semantic enhancement: Department scene adaptation: "C-reactive protein" in the emergency department > 100 mg / L → associate "bacterial infection critical value"; the same value in the rheumatology department → associate "rheumatoid arthritis activity monitoring" Time series behavior analysis: monthly increase in "CA125" indicator for tumor patients → mark "recurrence risk warning" The obtained sliced data is converted into a feature matrix, where the features include dimensionality, including named features, numerical features, structural features, and semantic features, as shown in Table 1.

[0051] Table 1 Feature Matrix Feature dimension Example data Quantization method Named feature High-sensitivity troponin T Tokenized vector: [high-sensitivity, troponin, T] Numerical feature Value distribution: 12.5-350.2 ng / L Box plot Figure five Numerical summary Structural feature Nested depth: 3 layers Tree path encoding Semantic feature Associated disease: myocardial infarction Medical term coding ICD-10 Before performing three-dimensional data slicing, the data needs to be cleaned, including: character-level cleaning: remove meaningless symbols (such as "*", "#", "——"), unify full-width and half-width brackets. Case normalization: convert all English abbreviations to uppercase (e.g., "wbc" → "WBC"). Unit stripping: split "troponin T 35.2 ng / L" into "troponin T" + "35.2" + "ng / L" triplets to avoid numerical interference matching. Stop word filtering: filter high-frequency but semantically insignificant words such as "detection", "result", "prompt", etc.

[0052] Perform term matching and structure analysis on the data obtained after slicing, and perform dynamic rule packaging to generate an execution rule package, including: According to the field name obtained by slicing, match the field name with the standard term library, output the corresponding standard medical term code, and automatically associate the superior classification, where automatically associating the superior classification actually means feature backtracking based on the field name, and associating the superior classification based on the context.

[0053] Based on the data obtained from field-level slicing, transformation is performed according to field mapping rules. Structural and semantic slice data are also transformed according to structural recombination rules. Specifically, during transformation based on field mapping rules, the unit system in the original data is converted to standard formulas in the medical knowledge database, and warning values ​​are automatically generated for alerts. During transformation based on structural recombination rules, the original data is sliced ​​at both structural and semantic levels, converting the CT report from text to structured data. For example, the original text: "8mm ground-glass nodule seen in the upper lobe of the right lung, thin-section CT follow-up recommended in 3 months," the structural slice data includes [Location Block] Right Upper Lobe; [Description Block] 8mm Ground-Glass Nodule; the semantic slice data is [Recommendation Block] Thin-section CT follow-up in 3 months. The location is determined based on the location block in the structural slice data, identifying standard medical terminology codes and corresponding CT image sequence coordinates. Feature words are extracted from the description block to generate structured fields. The time in the recommendation block is extracted and matched with the examination protocol.

[0054] Field-level, structure-level, and semantic-level sliced ​​data are bound to corresponding standard fields, and the units are standardized and transformed. After adding risk labels, an execution rule package is generated. A rule is broken down into three parts: "trigger condition - transformation action - post-validation": Trigger condition: Add a new field name = "High-sensitivity troponin T" AND value range ∈ [0, 10000] ng / L; Transformation action: Unit is standardized to "ng / L", retaining one decimal place; if the value > 100 ng / L, it is labeled "critical value"; Post-validation: Check whether the transformed value falls within the medical decision level table range; if not, it is marked as "abnormal transformation". A "department priority matrix" is introduced, with emergency department rule weight > cardiology department > physical examination department, to avoid rule conflicts for the same field in multi-department scenarios.

[0055] If a newly added field cannot match the standard library, the newly added field will be marked as an unmapped field and similar candidates will be pushed. After manually binding the gene test result → molecular pathology test, the system will automatically: record the operation: add a new mapping rule; update the knowledge base: add "gene test result" as a standard term alias.

[0056] S103. Perform rule sandbox verification based on the execution rule package, and run dual engines based on data collection time.

[0057] Specifically, new rule packages must pass rigorous sandbox testing before going live. The execution rule packages undergo historical data backtracking testing and real-time traffic simulation testing sequentially to verify their accuracy. Historical data backtracking testing involves obtaining all similar reports from the past 30 days and verifying them in batches: Batch 1: Old format reports, including the traditional troponin field; Verification point: ensuring the new rules do not disrupt the original mappings; Batch 2: Mixed format reports, with both old and new fields; Verification point: checking field priority settings, such as prioritizing the new fields; Batch 3: Purely new format reports; Verification point: verifying the correctness of all new rules.

[0058] Real-time traffic simulation testing constructs a realistic hospital traffic model. Within a set time frame, tests are conducted based on the report volume of specific departments, using a Poisson distribution to simulate departmental report arrival rates: λ = 2.1 reports / second for the laboratory and λ = 0.8 reports / second for the radiology department. A "pulse traffic" sub-test is introduced: during the morning peak period of 8:00-8:15, λ instantaneously increases to 5 times, verifying that the rule package operates without lock contention or memory leaks under high concurrency. For example, from 8:00-10:00 AM, tests are conducted in the laboratory and radiology departments at a report volume of 120 reports per second. The stress testing strategy is as follows: Baseline test: 1x traffic volume for 30 minutes; Peak test: a sudden 3x traffic surge (simulating the morning peak); Duration test: 8 hours of moderate load.

[0059] Based on the effective time of the execution rule package, the medical data collection time is compared with the effective time. Medical data collected after the effective time is processed using the old engine, while data collected after the effective time is processed in real time according to the execution rule package. If the data collection time T is compared with the rule package effective time T0, and T∈[T0-5min, T0+5min], then a "grayscale window" is entered, and both the old and new engines are run simultaneously, comparing the output differences; the official flow switch is only performed if the difference rate is <0.1%. If the new engine triggers ≥3 cases of "critical value missed reports" within 24 hours, it automatically rolls back to the old engine and pushes a "rule package rollback" alert to the administrator.

[0060] The frequency of rules used in the execution rule package is recorded, and invalid rules are archived and stored. High-frequency rules are upgraded to core rules, and a general rule package is generated: the daily hit count is recorded by the triple "department × field × rule" to generate a heat map; rules with zero hits for 7 consecutive days are marked "to be archived"; invalid rules, along with their last effective time and the reason for invalidity (field obsolescence / terminology update / business offline), are written into the "rule history database", and the original triggering conditions and conversion actions are retained for easy auditing and tracing.

[0061] The second embodiment of this application is as follows: The present invention provides a medical information system, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs include a method for processing medical data in a first embodiment.

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

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

[0064] Accordingly, this application also provides an electronic device, comprising: one or more processors; a memory for storing one or more programs; and, when the one or more programs are executed by the one or more processors, causing the one or more processors to implement the medical data processing method described above. Figure 6 The diagram shown is a hardware structure diagram of any device with data processing capabilities that houses a medical information system, as provided in an embodiment of the present invention. Except for... Figure 6 In addition to the processor, memory, and network interface shown, any data processing device in the embodiment may also include other hardware depending on the actual function of the data processing device, which will not be described in detail here.

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

[0066] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

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

Claims

1. A method for processing medical data, characterized in that, Includes the following steps: The system automatically collects data using a dual-channel mode and compares it with historical data to determine if any new fields have been added. The newly added fields are parsed, and knowledge base linkage rules are constructed based on the parsing results to generate an execution rule package; The rules are validated in a sandbox based on the execution rule package, and the dual-engine operation is performed based on the data collection time.

2. The medical data processing method as described in claim 1, characterized in that, The dual-channel mode includes an explicit change channel and an implicit change channel. The explicit change channel is used to obtain version update logs from the hospital information system's upgrade announcement platform, while the implicit change channel is used to automatically collect multiple anonymous data entries from various departments.

3. The medical data processing method as described in claim 1, characterized in that, The system automatically collects data using a dual-channel mode and compares it with historical data to determine if any new fields have been added, including: The system automatically collects data using a dual-channel mode and extracts fingerprints from the collected data. The fingerprint features of the current data are compared with the fingerprint features of the historical data to determine whether any new fields have been added.

4. The medical data processing method as described in claim 1, characterized in that, The newly added fields are parsed, and knowledge base linkage rules are constructed based on the parsing results to generate an execution rule package, including: Data sampling is performed based on the original data corresponding to the newly added field, and three-dimensional data slicing is performed on each piece of original data; The sliced ​​data is subjected to term matching and structure parsing, and dynamic rule encapsulation is performed to generate an execution rule package.

5. The medical data processing method as described in claim 4, characterized in that, Data sampling is performed based on the original data corresponding to the newly added field, and three-dimensional data slicing is performed on each piece of original data, including: Based on data characteristics, perform stratified sampling of the original data corresponding to the newly added fields; Each piece of original data is sliced ​​in three dimensions according to the field level, structure level, and semantic level.

6. The medical data processing method as described in claim 4, characterized in that, After performing three-dimensional data slicing on each piece of original data, the method further includes: The obtained slice data is transformed into a feature matrix, where the features are dimensions including named features, numerical features, structural features, and semantic features.

7. The medical data processing method as described in claim 6, characterized in that, Based on the execution rule package, rule sandbox verification is performed, and dual-engine operation is carried out based on data acquisition time, including: The execution rule package was subjected to historical data backtracking tests and real-time traffic simulation tests in sequence; Based on the data collection time, the matching engine method is determined. Among them, dual engines include a new engine and an old engine. The acquired medical data is transformed using a matching-based engine approach.

8. The method for processing medical data as described in claim 1, characterized in that, The method further includes: The frequency of rules used in the execution rule package is recorded, and invalid rules are archived and stored.

9. The method for processing medical data as described in claim 1, characterized in that, When constructing knowledge base linkage rules based on the parsing results, the method further includes: If the newly added field cannot build knowledge base linkage rules, then auxiliary corrections will be made.

10. A medical information system, characterized in that, include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including a method for processing medical data according to any one of claims 1 to 9.

Images