A method, system and storage medium for automatically including a patient with a disease and associating a cross-visit course of treatment
Patent Information
- Application Number
- CN202611316016.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-28
- Publication Date
- 2026-10-30
AI Technical Summary
[0004]（1）患者主索引只解决"是否为同一患者"的身份统一问题，其标识对象是人，不能表达"某次纳入某专病形成的病程实例"，也无法区分同一患者并存的多个专病病程
[0018]与现有技术相比，本发明的有益效果包括：
Smart Images
Figure CN123017410A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of medical information technology, specifically to data processing technology for electronic medical record systems, clinical decision support systems, and standardized diagnosis and treatment management of specific diseases, and particularly to a method, system, and storage medium for automatically including patients with specific diseases and associating them across the course of their medical treatment. Background Technology
[0002] In the standardized diagnosis and treatment management of specific diseases, hospitals need to maintain separate management rules for multiple specific diseases; after being included in a specific disease, patients often experience multiple outpatient visits, hospitalizations, and emergency visits. The implementation of specific disease pathways, follow-up, quality control, and querying of specific disease clinical data need to clearly define "which visits fall within the scope of this specific disease management".
[0003] The existing technical solutions mainly have the following problems:
[0004] (1) The patient master index only solves the problem of identity consistency of "whether they are the same patient". Its identification object is a person, and it cannot express "a course instance formed by a certain disease in a certain period of inclusion", nor can it distinguish multiple disease courses of the same patient.
[0005] (2) Clinical pathway entry / exit paths are mostly based on a single hospitalization. Generally, a disease course master index that can be used continuously across outpatient, inpatient, emergency and multiple visits is not established, and it is also difficult to serve as a unified data boundary for follow-up, disease data query and other businesses.
[0006] (3) The purpose of screening clinical trials or research cohorts is to screen people. Usually, it does not change the ownership of in-hospital outpatient business data, does not generate a master index of the disease course of the path / follow-up, and does not solve the problem of "whether the re-visit should be merged into the same course or re-included".
[0007] (4) General rule engines or clinical decision support systems can output prompts or review conclusions, but lack a closed loop from the judgment result to the generation of the disease course master index and then to the association of multiple visits.
[0008] (5) If each visit is re-included, the same disease course is split into multiple unrelated records, and the path and follow-up cannot be continuous; if only the disease is labeled according to the patient identification, it is impossible to distinguish the data range of different diseases and different inclusion batches.
[0009] Therefore, how to automatically complete the inclusion of electronic medical records according to the pre-configured inclusion rules when electronic medical record business occurs, establish a disease course master index for each inclusion, and link subsequent outpatient, inpatient, and emergency visits to the master index until exit, thereby solving the technical problem of "disease management lacking a cross-visit course master index, easy repeated inclusion of revisit visits, or unclear data boundaries", is an urgent technical problem to be solved in this field. Summary of the Invention
[0010] To address the problems existing in the prior art, this invention provides a method, system, and storage medium for automatically including patients with specific diseases and associating them across medical treatment processes. The system uses "a medical process instance formed by including a specific disease once" as the management unit, and establishes a main index of specific disease processes that is independent of the patient's main index and the single medical treatment serial number, thereby realizing the automatic inclusion of patients with specific diseases and the association of them across medical treatment processes.
[0011] In a first aspect, the present invention provides a method for automatically including and associating patients with specific diseases across medical treatment courses, executed by a standardized diagnosis and treatment management server for specific diseases, comprising:
[0012] Rule configuration steps: Store basic information for multiple diseases, associate at least one inclusion rule with each disease, and form an inclusion rule association table;
[0013] Event triggering steps: When a clinical business operation occurs in the electronic medical record system, the rule component performs an inclusion rule matching judgment on the operation data of the clinical business operation. If it meets the inclusion rule of a certain disease, an inclusion request is sent to the standardized diagnosis and treatment management server of the disease.
[0014] Master index creation or reuse steps: The standardized diagnosis and treatment management server for specific diseases determines the specific disease code based on the inclusion request, and queries whether there is a specific disease course record in the inclusion status according to the patient identifier and the specific disease code; if it does not exist, a new specific disease course master index is generated and written into the specific disease patient record, and the specific disease course master index identifies the course instance formed by a patient being included in a specific disease at one time; if it already exists, the existing specific disease course master index is reused, and no new specific disease course master index is created.
[0015] The steps for linking medical visits are as follows: Query whether a corresponding linking record exists using the main index of the specific disease course and the visit serial number of the current visit. If it does not exist, a new linking record containing the main index of the specific disease course and the visit serial number of the current visit is added. If it already exists, it is not written again. When a patient in the included state has another outpatient, inpatient, or emergency visit, only the linking record is added to the new visit serial number, and the main index of the specific disease course is not created.
[0016] Secondly, the present invention provides a system for automatically including patients with specific diseases and associating them across medical treatment processes, including a standardized diagnosis and treatment management server for specific diseases, used to execute the method described in the first aspect above.
[0017] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method described in the first aspect above.
[0018] Compared with the prior art, the beneficial effects of the present invention include:
[0019] (1) Specialty course can be instantiated and coexist: The same patient can generate multiple specialty course master indexes due to different specialties or re-inclusion. The management unit is the course formed by one inclusion, rather than "person" or "single hospitalization".
[0020] (2) Integration with clinical operations reduces omissions and post-event supplementary recording: Clinical operations such as diagnosis, surgery, medical orders, and reports can trigger automatic inclusion without relying on manual screening.
[0021] (3) Continuous management of disease course across outpatient, inpatient and emergency departments: Multiple visit serial numbers are associated with the same disease course master index. Downstream businesses such as disease path execution, follow-up and disease clinical data query can use the disease course master index to query data in a unified manner.
[0022] (4) Avoid duplicate inclusion leading to fragmentation of the disease course: When patients visit again while the disease is included, only the association is added and no new disease course master index is created, so as to ensure that the disease course boundary is stable and traceable.
[0023] (5) Clear demarcation between the patient master index and single path entry: The data boundaries of downstream business are clear. Attached Figure Description
[0024] Figure 1 The system architecture and data flow diagram provided for embodiments of the present invention;
[0025] Figure 2 A flowchart for the establishment and reuse of a disease-specific disease course master index provided in this embodiment of the invention;
[0026] Figure 3 This is a flowchart illustrating the association of medical visit serial numbers provided in an embodiment of the present invention.
[0027] Figure 4 The state machine diagram provided for embodiments of the present invention;
[0028] Figure 5 This is a schematic diagram of the core database table relationships provided for an embodiment of the present invention. Detailed Implementation
[0029] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.
[0030] Terminology Explanation: **Disease-Specific Course Master Index:** This refers to the unique serial number identifying a patient's course instance formed during a specific disease inclusion. The field name is DSP_FLOW (Disease-Specific Course Number). **Visit Serial Number:** This refers to a single outpatient, inpatient, or emergency visit serial number. The field name is IOE_PID. **Patient Identifier:** This refers to the ID identifying a specific patient. The field name is PID. **Disease Code:** This refers to the category of a specific disease. The field name is DISEASE_CODE. **Outpatient / Emergency / Inpatient Flag:** The field name is INOUT_FLAG, with a value range of o / e / i. **CDSS (Clinical Decision Support System):** This refers to the Clinical Decision Support System. **Rule Configuration Serial Number:** The field name is RULE_CFG_SN, which refers to the serial number generated when the CDSS rule component saves the disease inclusion rule. **EMR (Electronic Medical Record):** This refers to the electronic medical record. **Inclusion / Exit Status:** This indicates whether the disease course is currently under management. The field name is LEVEL_STATUS: 10 indicates inclusion, 20 indicates exit. The execution entity in this embodiment is a standardized diagnosis and treatment management server for specific diseases (hereinafter referred to as the server).
[0031] Step 1: Configure multiple disease inclusion rules
[0032] The server stores basic information for multiple diseases (disease code, disease name, availability) and applicable hospital areas and departments. For each disease, at least one inclusion rule is associated, and the disease code, rule configuration serial number, and rule description information are saved to the inclusion rule association table. The rule content is maintained by the CDSS rule component, and the saved rule configuration serial number represents the association between the disease and the rule. This step forms the basis for subsequent configuration decisions regarding inclusion criteria and database writing.
[0033] Specifically, when associating each disease with an inclusion rule, the server calls the maintenance interface of the CDSS rule component. After maintaining the inclusion rule content for that disease in this interface, the CDSS rule component generates a rule configuration serial number and returns it to the server. The server then writes the disease code, rule configuration serial number, and rule description information into the inclusion rule association table, completing the association between the disease and the inclusion rule. Each disease is configured with inclusion rules independently according to the above process, and the associated inclusion rules do not affect each other.
[0034] Taking diabetes as an example: the disease code is DISEASE_CODE=DM01, and the disease name is diabetes. The server calls the maintenance interface of the CDSS rule component to configure the inclusion conditions. The inclusion conditions are, for example, a combination of logical OR and logical AND conditions: (Condition A) The ICD-10 code of the diagnosis belongs to the E10 to E14 range; or (Condition B) The prescription includes insulin and the fasting blood glucose result in the test is not lower than 7.0 mmol / L. After the CDSS rule component generates a rule configuration serial number and returns it, the server writes the rule configuration serial number, disease code, rule description, etc., into the inclusion rule association table. At runtime, the rule component reads the corresponding clinical data according to the business event type (such as diagnosis, prescription, test report) to complete the rule matching.
[0035] Step 2: Receive clinical business events and trigger rule matching
[0036] When business operations such as saving diagnoses, surgeries, issuing / submitting medical orders, and publishing test or examination reports occur in the EMR, the EMR sends the relevant data to the rules component. The rules component determines whether the data meets the inclusion rule for a specific disease associated in step 1, and sends a request to the server (including the patient's visit serial number, patient identifier, outpatient / emergency / hospitalization marker, rule configuration serial number, and operation time). The server retrieves the disease code from the inclusion rule association table based on the rule configuration serial number and proceeds to step 3.
[0037] In one embodiment, the parameters of the inclusion request sent by the rule component to the server include at least: visit serial number, patient identifier, outpatient / emergency / inpatient marker (value range: o / e / i), rule configuration serial number, and operation time; the server's response includes at least a success indicator and explanatory information. The call sequence is as follows: after the EMR service is successfully saved, the CDSS rule component performs rule matching. If a match is successful, the server's inclusion interface is called. After the server completes the database write, it returns information indicating whether the process was successful.
[0038] Furthermore, the same patient may be repeatedly included in a short period of time due to multiple business operations such as saving diagnoses and issuing medical orders. The server implements mutual exclusion using patient identifiers and disease codes as lock keys (which can be implemented using database row locks, distributed locks, or synchronization queues) to ensure that only one inclusion transaction executes the query "whether there is a disease course record in the inclusion state" and writes to the database to determine whether to create or reuse the record at any given time. Duplicate requests for the same rule configuration serial number and the same visit serial number are handled idempotently: if the disease course master index has been established and the visit association record already exists, the existing disease course master index is reused and no duplicate insertion is performed, thereby avoiding the generation of multiple disease course master indexes in the inclusion state in concurrent scenarios.
[0039] Step 3: Establish or reuse a disease-specific master index.
[0040] like Figure 2 As shown, this step includes:
[0041] (3-1) Verify whether the current department is a department applicable to this disease; otherwise, terminate the inclusion.
[0042] (3-2) By patient identifier and disease code, check if there is a disease course record in the inclusion status: If not, generate a new disease course master index DSP_FLOW and write it into the disease patient record (including DSP_FLOW, disease code, disease name, inclusion time, rule serial number, inclusion status, etc.); if it already exists, reuse the disease course master index (i.e., the same DSP_FLOW) and do not create a new one. This step instantiates the course on a one-time inclusion basis for different disease types to avoid duplicate creation.
[0043] Step 4: Link the medical record number to the disease-specific disease progress master index
[0044] like Figure 3 As shown, the system checks if a corresponding associated record exists between the disease-specific disease progression main index DSP_FLOW and the current visit's visit serial number IOE_PID. If not, a new record is created (including at least DSP_FLOW (disease-specific disease progression number), visit serial number, patient identifier, outpatient / emergency / hospitalization marker, and creation time). If an associated record exists, it is not written repeatedly. When the patient subsequently visits the outpatient / inpatient / emergency department and remains under the included status, only the new visit serial number is associated; no new disease-specific disease progression main index is created. This step enables multiple visits across outpatient, inpatient, and emergency departments to be attributed to the same disease-specific disease progression.
[0045] Step 5: Exit the specific disease treatment program. For example... Figure 4 As shown, when an operator manually exits, the standardized diagnosis and treatment management server for specific diseases uses the attending physician's identifier registered in the current specific disease visit record (usually from the attending physician field of the electronic medical record system for this visit) as the standard and compares it with the user identifier of the current operator. If they match, the current operator is identified as the attending physician for this patient's visit, and the exit operation is allowed. If they do not match, the exit operation is prohibited, and the message "Only the current patient's attending physician can perform the exit operation for the specific disease" is returned. After allowing the exit operation but before officially executing the exit operation, the operator is reconfirmed. After passing the reconfirmation, the corresponding specific disease course master index DSP_FLOW is located, updated to the exit status, and the exit time and reason are recorded. After exiting, the specific disease course master index will no longer automatically inherit new visit associations; if it is triggered again by clinical business in EMR and meets the inclusion rules, the specific disease course master index is created according to steps 2 and 3.
[0046] like Figure 4As shown, the inclusion status state machine includes two states: inclusion status (LEVEL_STATUS=10) and exit status (LEVEL_STATUS=20). A disease-specific disease progression master index in the inclusion status can accept new patient visit associations; after the aforementioned permission verification and secondary confirmation, an exit operation is performed, and the status changes to exit status; a disease-specific disease progression master index in the exit status no longer automatically accepts new patient visit associations; if it is triggered again by clinical business in EMR to meet the inclusion rules, a new disease-specific disease progression master index is created and enters the inclusion status.
[0047] This embodiment also includes the following exception and boundary case handling: (a) When the rule matching is successful but the department verification fails, the inclusion is terminated, and the records are not written to the disease patient record table or the visit association table. The caller is also given a prompt message that the department is not applicable; (b) When there are multiple exit status records for the same patient and the same disease, the query in step 3 to check whether there are included disease course records only filters records with included status (LEVEL_STATUS=10); if all have exited, it is considered that there are no included disease courses, and a new disease course master index is created; historical exit records are retained for traceability, and the exit record with the latest inclusion time can be used as an audit reference, but it is not involved in the reuse judgment; (c) When there is a conflict in the visit serial number association, it is handled according to the above conflict handling strategy.
[0048] Step 6: Downstream businesses access data by the disease-specific disease process master index.
[0049] like Figure 1 As shown, downstream services, such as disease-specific pathway execution, follow-up, full lifecycle management, and disease-specific clinical data query, use the disease-specific disease course master index DSP_FLOW as the query boundary and use all associated medical visit serial numbers for data querying. This is different from general patient data querying by patient identifier and querying inpatient / outpatient / emergency data querying by single medical visit serial number.
[0050] The following is an example of the query interface for downstream business: The input parameter is the disease-specific disease course master index DSP_FLOW, which retrieves path execution records, follow-up records, or clinical detail data as needed; the output is a dataset rooted at the disease-specific disease course master index. It should be noted that downstream business must not use patient identifiers alone to replace the disease-specific disease course master index as the scope of disease management; otherwise, it will be impossible to distinguish between multiple coexisting disease-specific disease courses and different inclusion batches.
[0051] This embodiment also provides a system for automatically including patients with specific diseases and associating them across treatment courses, including a standardized diagnosis and treatment management server for specific diseases. The server includes: a rule configuration module, used to store basic information of multiple specific diseases and associate at least one inclusion rule with each specific disease to form an inclusion rule association table; an event receiving module, connected to the rule configuration module, used to receive inclusion requests sent by the rule component when a clinical business operation occurs in the electronic medical record system and it is determined that the inclusion rule for a certain specific disease is met; a master index management module, connected to the event receiving module, used to determine the specific disease code according to the inclusion request, and query whether there is a specific disease course record in the inclusion status according to the patient identifier and the specific disease code. If it does not exist, a new specific disease course master index is generated and written into the specific disease patient record. If it already exists, it is reused and not newly created; a treatment course association module, connected to the master index management module, used to query whether there is a corresponding treatment course association record according to the specific disease course master index and the treatment serial number of the current treatment. If it does not exist, it is added; if it exists, it is not written again. If the patient is under the inclusion status, subsequent treatments only add the association and do not create a new specific disease course master index.
[0052] like Figure 1 As shown, the architecture of the above system includes a configuration layer and an operation layer. In the configuration layer, the server is responsible for maintaining disease-specific information. When configuring inclusion rules for each disease, it calls the maintenance interface of the CDSS rule component. After the rule content is maintained in this interface, the CDSS rule component generates a rule configuration serial number and returns it to the server. The server then associates the disease with the inclusion rule. Each disease is configured independently according to the above process, and the rules do not affect each other. In the operation layer, when the electronic medical record system saves business operations such as diagnoses, surgeries, medical orders, and test / examination reports, it sends the relevant clinical data to the CDSS rule component. After determining that a certain disease's inclusion rule is met, the rule component sends an inclusion request to the server. The server completes the creation or reuse of the corresponding disease-specific disease progression master index and associates the visit serial number with the disease-specific disease progression master index, writing it to the database. Disease path execution, follow-up, and disease clinical data query are downstream business functions within the server, uniformly accessing data in the data storage using the disease-specific disease progression master index as the query boundary.
[0053] The core data table in this embodiment is as follows: Figure 5 As shown, it includes:
[0054] Table 1: DSP_PATIENT Patient Record Table, with the DSP_FLOW primary key as the primary key for the DSP_PATIENT disease course index. Key fields include: DSP_FLOW (DSP_PATIENT primary index), DISEASE_CODE (disease code), DISEASE_NAME (disease name), LEVEL_STATUS (inclusion / exclusion status, 10 for inclusion, 20 for exit), IN_DISEASE_TIME (inclusion time), EXIT_DISEASE_TIME (exclusion time), EXIT_REASON (exclusion reason), RULE_CFG_SN (logo number that triggered inclusion), and RULE_DESC (rule description).
[0055] Table 2: Patient Visit Association Table (DSP_PATIENT_X_VISIT), with main fields including: REC_SN (associated record serial number), DSP_FLOW (foreign key, pointing to the disease-specific patient record table), IOE_PID (patient visit serial number), PID (patient identifier), INOUT_FLAG (outpatient / emergency / hospitalization flag, value range is o / e / i), and CREATE_TIME (creation time).
[0056] Table 3: Inclusion Rule Association Table (DSP_INCLUDE_EXIT_RULE), with the rule configuration serial number RULE_CFG_SN as the primary key. The main fields include: RULE_CFG_SN (rule configuration serial number), DISEASE_CODE (disease code), and RULE_DESC (rule description).
[0057] Table 4: Disease-Specific Department Table (DSP_DISEASE_X_DEPT), with main fields including: CFG_SN (configuration serial number, primary key), DISEASE_CODE (disease code), DEPT_CODE (department code), and DEPT_NAME (department name).
[0058] The relationships between the above data tables are as follows: During configuration, the CDSS rule component generates a rule configuration serial number and returns it to the server. The server writes the disease code, rule configuration serial number, and rule description into the rule association table, and stores the disease code, the selected department code, and the department name into the disease-related department table. The disease-related patient record table and the visit association table have a one-to-many relationship, that is, a disease-related primary index is associated with multiple visits.
[0059] The conflict handling strategy when associating medical visit serial numbers is as follows: if the same medical visit serial number has already been associated with other disease-specific primary indexes, then coexistence is allowed, meaning the same medical visit can belong to different disease-specific primary indexes; if the same disease-specific primary index and the same medical visit serial number already have an associated record, then it is considered idempotent and will not be written repeatedly.
[0060] Taking the comprehensive management of patients with diabetes as an example: Patient A (patient identifier PID=P001) was diagnosed with type 2 diabetes in the outpatient clinic, subsequently underwent related surgery in the hospital, had a follow-up outpatient visit after the surgery, withdrew from management midway, and was reinstated due to abnormal blood glucose levels. The specific process is as follows:
[0061] (1) Outpatient diagnosis: The ICD-10 code of the diagnosis saved by EMR is E11, and the event type is diagnosis; the CDSS rule component successfully matches the diabetes inclusion rule; the server verifies that the visiting department is applicable; the special disease patient record table and the visit association table are checked together. There is no record of diabetes special disease (disease code DM01) with inclusion status (LEVEL_STATUS=10) for this patient. Therefore, a special disease course master index DSP_FLOW=F001 is created and written into the special disease patient record table. At the same time, the outpatient visit serial number IOE_PID=R1001 and the patient identifier P001 (outpatient, emergency and inpatient are marked as o) are written into the visit association table.
[0062] (2) Inpatient surgery: The patient is admitted and the visit serial number is IOE_PID=I2001 (outpatient and emergency inpatient is marked as i). When confirming admission, the special disease patient record table and visit association table are checked through the patient identifier P001. The patient has a record in the inclusion status. The server reuses F001, does not create a new special disease course master index, and only adds I2001 to F001.
[0063] (3) Postoperative outpatient follow-up: A new outpatient visit serial number R1002 is generated. The patient is still included. Only R1002 is added to F001. No new disease course master index is created.
[0064] (4) Exit: The doctor performs an exit operation on F001, updates the inclusion / exit status field to exit status (LEVEL_STATUS=20), and records the exit time and exit reason; thereafter, new visits will no longer be automatically associated with F001.
[0065] (5) Re-inclusion: Several months later, the outpatient department re-saves diagnostic, laboratory, or examination data that meet the inclusion rules. The server finds records that are not included (F001 has been withdrawn), so a new disease-specific disease course master index DSP_FLOW=F002 is created and associated with a new visit serial number. F001 and F002 coexist and are traceable. Downstream businesses query data within the corresponding disease course range by F001 and F002 respectively.
[0066] Through the above process, the same patient and the same disease form two disease course instances. Outpatient and inpatient visits within each disease course are merged into the same disease course master index, and the boundary between exit and re-inclusion is clear.
[0067] In other embodiments, the following alternative implementation methods may also be used:
[0068] Firstly, alternative triggering timing: In addition to synchronous triggering when EMR saves business data, asynchronous triggering via message queue can be used, or the association can be supplemented at nodes such as discharge, transfer to another department, registration, and admission registration, while still executing the logic of establishing the disease-specific disease course master index and associating it with medical treatment.
[0069] Secondly, alternative strategies for generating disease-specific disease course master indexes: When creating a new disease-specific disease course master index, in addition to using random serial numbers, a combination of disease codes, patient identifiers, and inclusion times can also be used to generate the disease-specific disease course master index. This also conforms to the logic of generating one disease-specific disease course master index per inclusion and reusing it during subsequent visits.
[0070] Third, alternatives to manual / automatic paths: provided that the inclusion rules are met and the patient does not have any disease-specific course records in the inclusion status, a prompt can be displayed for the doctor to choose whether to include the records, or a manual inclusion entry can be provided in the patient list or other interfaces, allowing the doctor to actively initiate the creation of a new disease-specific course master index. The difference between this and fully automatic inclusion is only that a doctor confirmation or doctor-initiated step is added. The logic for writing database objects, determining whether to create or reuse records, and cross-visit associations is the same as the automatic path, and it is an equivalent alternative.
[0071] Fourth, the scope of association is expanded: based on outpatient, inpatient, and emergency services, the marking of other types of visits, such as day care, can be further expanded; the association of follow-up visits can also be supplemented during registration or admission, and the logic of establishing the disease course master index and associating visits is still executed.
[0072] This embodiment also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method described in any of the above method embodiments. The computer-readable storage medium includes, but is not limited to, disk storage, read-only memory (ROM), random access memory (RAM), flash memory, etc.
[0073] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A method for automatically including and associating patients with specific diseases across different medical treatment stages, characterized in that, Executed by the standardized diagnosis and treatment management server for specific diseases, including: Rule configuration steps: Store basic information for multiple diseases, associate at least one inclusion rule with each disease, and form an inclusion rule association table; Event triggering steps: When a clinical business operation occurs in the electronic medical record system, the rule component performs an inclusion rule matching judgment on the operation data of the clinical business operation. If it meets the inclusion rule of a certain disease, an inclusion request is sent to the standardized diagnosis and treatment management server of the disease. Master index creation or reuse steps: The standardized diagnosis and treatment management server for specific diseases determines the specific disease code based on the inclusion request, and queries whether there is a specific disease course record in the inclusion status according to the patient identifier and the specific disease code; if it does not exist, a new specific disease course master index is generated and written into the specific disease patient record, and the specific disease course master index identifies the course instance formed by a patient being included in a specific disease at one time; if it already exists, the existing specific disease course master index is reused, and no new specific disease course master index is created. The steps for linking medical visits are as follows: Query whether a corresponding linking record exists using the main index of the specific disease course and the visit serial number of the current visit. If it does not exist, a new linking record containing the main index of the specific disease course and the visit serial number of the current visit is added. If it already exists, it is not written again. When a patient in the included state has another outpatient, inpatient, or emergency visit, only the linking record is added to the new visit serial number, and the main index of the specific disease course is not created.
2. The method for automatically including and associating patients with specific diseases across medical treatment stages according to claim 1, characterized in that, In the rule configuration step, the basic information of the disease includes the disease code, disease name, and availability, as well as the hospital area and department to which the disease applies; when associating at least one inclusion rule for each disease, the disease code, rule configuration serial number, and rule description information are saved to the inclusion rule association table; the rule content of the inclusion rule is maintained by the rule component of the clinical decision support system, and the rule configuration serial number is the serial number generated when the rule component saves the inclusion rule.
3. The method for automatically including and associating patients with specific diseases across treatment courses according to claim 1, characterized in that, In the event triggering step, the clinical business operation includes at least one of saving diagnosis, surgery, issuing or submitting medical orders, issuing test reports, and issuing examination reports; the inclusion request includes a visit serial number, patient identifier, outpatient / emergency / hospitalization marker, rule configuration serial number, and operation time; in the main index creation or reuse step, the inclusion rule association table is read according to the rule configuration serial number in the inclusion request to obtain the corresponding disease code.
4. The method for automatically including and associating patients with specific diseases across treatment courses according to claim 1, characterized in that, The steps for creating or reusing the master index also include: verifying whether the current department is a department applicable to the specific disease; if not, the inclusion process is terminated.
5. The method for automatically including and associating patients with specific diseases across medical visits according to claim 1, characterized in that, In the step of establishing or reusing the master index, the written patient records for the specific disease include the master index of the specific disease course, disease code, disease name, inclusion time, rule configuration serial number, and inclusion status.
6. The method for automatically including and associating patients with specific diseases across medical visits according to claim 1, characterized in that, In the aforementioned medical visit association step, the newly added medical visit association record includes a disease course master index, medical visit serial number, patient identifier, outpatient / emergency / hospitalization marker, and creation time; the value range of the outpatient / emergency / hospitalization marker includes outpatient, emergency, and inpatient services.
7. The method for automatically including and associating patients with specific diseases across medical visits according to claim 1, characterized in that, The process also includes an exit step: When responding to a user's manual exit operation, the user's identifier is compared with the attending physician's identifier registered in the current disease-specific medical record. If they match, the exit operation is allowed, and the user is re-confirmed before the exit operation. After the re-confirmation, the corresponding disease-specific medical record master index is located, the corresponding disease-specific medical record is updated to an exit status, and the exit time and reason are recorded. After exiting, the disease-specific medical record master index will no longer automatically inherit the association of new medical visits. If they do not match, the exit operation is prohibited and a prompt message is returned. If the clinical business operation in the electronic medical record system triggers the inclusion rule again, a new disease-specific medical record master index is created.
8. The method for automatically including and associating patients with specific diseases across medical visits according to claim 1, characterized in that, It also includes data access steps: downstream services use the disease-specific disease course master index as the query boundary and use all medical visit serial numbers associated with the disease-specific disease course master index to perform data queries; the downstream services include at least one of disease-specific pathway execution, follow-up, full life cycle management, and disease-specific clinical data query; the query boundary is the disease-specific disease course master index, and the downstream services do not use patient identifiers or single medical visit serial numbers to replace the disease-specific disease course master index for data queries.
9. A system for automatically including patients with specific diseases and linking them across different medical treatment stages, characterized in that, This includes a standardized diagnosis and treatment management server for specific diseases, which includes: The rule configuration module is used to store basic information of multiple diseases, associate at least one inclusion rule with each disease, and form an inclusion rule association table; The event receiving module, connected to the rule configuration module, is used to receive the inclusion request sent by the rule component when a clinical business operation occurs in the electronic medical record system and it is determined that the inclusion rule of a certain disease is met. The master index management module, connected to the event receiving module, is used to determine the disease code based on the inclusion request, and query whether there is a disease course record in the inclusion status according to the patient identifier and the disease code; if it does not exist, a new disease course master index is generated and written into the disease patient record, the disease course master index identifying the course instance formed by a patient being included in a certain disease at one time; if it already exists, the existing disease course master index is reused, and no new disease course master index is created. The visit association module, connected to the main index management module, is used to query whether a corresponding visit association record exists using the disease course main index and the visit serial number of the current visit. If it does not exist, a new visit association record containing the disease course main index and the visit serial number of the current visit is added. If it already exists, it is not written again. When a patient in the included state visits outpatient, inpatient or emergency departments again, the visit association record is only added to the new visit serial number, and the disease course main index is not created. The system is used to perform the method for automatically including and associating patients with specific diseases across medical visits, as described in any one of claims 1 to 8.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method for automatically including and associating patients with specific diseases across medical visits as described in any one of claims 1 to 8.