Form filling and checking method and device based on medical knowledge graph and medium

Abstract

This invention discloses a form filling and validation method, device, and medium based on a medical knowledge graph, relating to the field of smart healthcare technology. The method includes: loading and maintaining a lightweight subset of a medical knowledge graph on the client side; responding to a user's focus event on a target field in the form input interface, querying the subset based on the semantic tags of the target field; dynamically generating and displaying a list of candidate options for filling based on the query results, the list items containing candidate options inferred from the relationships between medical entities; responding to the user's selection, retrieving attribute information of the corresponding medical entity from the subset, and automatically filling one or more subfields of the target field accordingly; and finally, performing real-time compliance validation on the filled content based on predefined rules retrieved from the subset and associated with the selected medical entity. This invention significantly improves the efficiency and accuracy of form filling and enhances the maintainability and validation flexibility of the system.

Description

Technical Field

[0001] This invention relates to the field of smart healthcare technology, and in particular to a form filling and validation method, device, and medium based on a medical knowledge graph. Background Technology

[0002] In current healthcare IT practices, electronic medical record (EMR) systems are widely used for clinical medical order and record entry. However, existing EMR systems still generally suffer from several significant drawbacks affecting efficiency and security, specifically:

[0003] On the one hand, when filling out forms, doctors need to manually input complete drug names, disease codes, and other professional terms, or search and select from lengthy lists one by one. This process is time-consuming and cumbersome, severely reducing work efficiency. On the other hand, relying entirely on manual input and selection is prone to errors such as spelling mistakes and incorrect selection of items, especially regarding critical information such as drug dosage and frequency, which may directly lead to medical safety hazards.

[0004] Furthermore, the fields within a form often have strong medical logical relationships, such as specific diagnoses requiring recommended examinations. However, these relationship rules are usually hard-coded into the system. When medical guidelines are updated or hospital processes are adjusted, the software developer must modify the program code and redeploy it, resulting in insufficient system flexibility and maintainability, making it difficult to adapt to the continuous evolution of clinical knowledge. Summary of the Invention

[0005] This invention provides a form filling and validation method, device, and medium based on medical knowledge graphs. The technical problem it aims to solve is: how to provide an intelligent filling and validation solution that can significantly improve the efficiency and accuracy of electronic medical record form filling, while also possessing high maintainability and flexible correlation validation capabilities.

[0006] In a first aspect, embodiments of the present invention provide a form filling and validation method based on a medical knowledge graph, applied to a client, wherein the client communicates with a server storing a complete medical knowledge graph, and the method includes:

[0007] Load and maintain a lightweight subset of the medical knowledge graph synchronized from the full medical knowledge graph;

[0008] In response to a user's focus event on a target field in a form input interface, the lightweight medical knowledge graph subset is queried based on the semantic tags of the target field to obtain query results;

[0009] Based on the query results, a list of candidate options is dynamically generated and displayed in the form input interface. The items in the list of candidate options include candidate options derived from the relationships between medical entities.

[0010] In response to a user selecting an entry from the candidate list, the system retrieves the medical entity and attribute information corresponding to the selected entry from the lightweight medical knowledge graph subset, and automatically fills one or more subfields of the target field based on the attribute information.

[0011] Based on predefined rules retrieved from the lightweight medical knowledge graph subset and associated with the medical entity, the content already filled in the form input interface is subjected to real-time compliance verification.

[0012] Optionally, loading and maintaining a lightweight subset of the medical knowledge graph synchronized from the full medical knowledge graph includes:

[0013] Obtain the identity attributes of the currently logged-in user, including at least the clinical department to which the user belongs;

[0014] Based on the clinical department to which they belong, we identify the first category of medical entities that are strongly related to the scope of diagnosis and treatment of the department, and the second category of medical entities that are weakly related to the scope of diagnosis and treatment of the department.

[0015] Send a map subset request to the server, the request carrying the identification information of the first type of medical entity and the second type of medical entity;

[0016] The system receives data returned by the server, which includes the complete attributes and relationships of the first type of medical entities, as well as summary information of the second type of medical entities.

[0017] On the client-side, the first type of medical entities are constructed as entity nodes that support complete querying and reasoning, while the second type of medical entities are constructed as entity nodes that only support name retrieval.

[0018] Optionally, the target field is a diagnostic field, and the step of dynamically generating and displaying a list of candidate options in the form input interface based on the query result includes:

[0019] Capture the real-time input string of the user in the diagnostic field input box;

[0020] The real-time input string is used as a search term to retrieve data from the lightweight medical knowledge graph subset, resulting in an initial candidate set.

[0021] Retrieve the content of at least one symptom description field that has been filled in the current form;

[0022] The semantic similarity of the content of the symptom description field with the typical symptom set of each disease entity in the initial candidate set is calculated.

[0023] Based on the results of the semantic similarity matching calculation, the disease entities in the initial candidate set are reordered from high to low according to the matching degree to form and display the populated candidate list.

[0024] Optionally, the target field is a drug field, and the automatic filling of one or more sub-fields of the target field based on the attribute information includes:

[0025] From the lightweight medical knowledge graph subset, obtain the disease entities whose diagnosis field in the current form has been selected;

[0026] Query the association relationship tags between the disease entity and the drug entity, where the association relationship tags include preferred association, secondary association, or contraindicated association;

[0027] When a user starts entering or selecting a drug in the drug field, the drug entities in the candidate list are filtered or prioritized based on the association tags.

[0028] In response to a user's attempt to select a drug with a contraindication label, a pre-set, high-intensity warning interaction is triggered.

[0029] Optionally, the real-time compliance verification of the content already filled in the form input interface includes:

[0030] During real-time compliance verification, the system automatically checks whether the patient's liver or kidney function indicators have been entered in the current form. In the attribute information of the drug entity, there are predefined dosage adjustment rules associated with the patient's liver and kidney function test indicators.

[0031] If the index value is entered, the index value is substituted into the dosage adjustment rule for calculation, and the standard dosage safety range of the drug is dynamically corrected.

[0032] The drug dosage entered by the user is validated based on the revised standard dosage safety range.

[0033] Optionally, the real-time compliance verification of the content already filled in the form input interface includes:

[0034] When the item selected by the user corresponds to a drug entity, and the attribute information of the drug entity contains a rule for calculating dosage by weight, locate the patient age field and the patient weight field in the form input interface.

[0035] Determine whether the value of the patient's age field falls within a preset range of children's ages;

[0036] If the value of the patient's age field falls within the preset child age range, the preset child-specific dosage calculation model is activated. The child-specific dosage calculation model introduces an age-related pharmacokinetic correction factor based on the preset general weight-based calculation rules.

[0037] Based on the pediatric-specific dosage calculation model, the value of the patient's weight field, and the value of the patient's age field, the permissible range of drug dosage applicable to pediatric patients is calculated;

[0038] The drug dosage entered by the user is verified based on the calculated allowable range of drug dosage.

[0039] Optionally, the step of calculating the permissible drug dosage range suitable for pediatric patients based on the pediatric-specific dosage calculation model, the value of the patient's weight field, and the value of the patient's age field includes:

[0040] The values ​​of the patient's weight field and the patient's age field are input together into the pediatric-specific dosage calculation model to calculate the individualized baseline dosage value;

[0041] Based on the preset pediatric medication safety guidelines, an asymmetric allowable range is determined around the individualized baseline dose value, wherein the lower limit allows a smaller percentage of negative fluctuation than the upper limit allows a smaller percentage of positive fluctuation.

[0042] Optionally, the method further includes:

[0043] When it is detected that a user has completed the selection confirmation of a specific disease entity in the diagnosis field, query the phased inspection suggestion relationship related to the specific disease entity in the lightweight medical knowledge graph subset;

[0044] The current treatment stage is determined based on the treatment stage metadata associated with the current form;

[0045] Based on the determined diagnosis and treatment stage, a subset of examination items that match the current stage are selected from the stage-based examination recommendation relationship;

[0046] In the inspection application field area of ​​the form input interface, a subset of the inspection items corresponding to the current stage is dynamically generated and highlighted as the core recommendation.

[0047] Secondly, embodiments of the present invention also provide a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0048] Thirdly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.

[0049] This invention provides a form filling and validation method, device, and medium based on a medical knowledge graph. The method includes: loading and maintaining a lightweight subset of the medical knowledge graph synchronized from the full medical knowledge graph; responding to a user's input focus event on a target field in a form input interface, querying the lightweight medical knowledge graph subset based on the semantic tags of the target field to obtain query results; dynamically generating and displaying a list of candidate options for filling in the form input interface based on the query results, the items in the candidate options list including candidate options inferred from the relationships between medical entities; responding to a user selecting an item from the candidate options list, retrieving the medical entity and attribute information corresponding to the selected item from the lightweight medical knowledge graph subset, and automatically filling one or more sub-fields of the target field based on the attribute information; and performing real-time compliance validation on the filled content in the form input interface according to predefined rules retrieved from the lightweight medical knowledge graph subset and associated with the medical entity. This invention, by deploying a lightweight subset of a knowledge graph locally and triggering queries based on semantic tags, proactively provides fill-in-the-blank candidates based on relational reasoning when doctors input forms. This significantly reduces the time and steps required to manually input complete professional terms or search through lengthy lists. By automatically filling in standardized content for form subfields based on entity attribute information retrieved from the graph, the burden of repetitive data entry is further reduced. Simultaneously, real-time validation of input content is performed using predefined rules dynamically obtained from the same knowledge source and bound to the selected entities. This allows for immediate identification and warning of potential errors, such as excessive drug dosages, effectively preventing the transmission of human input errors to subsequent medical procedures. Furthermore, since the core association, fill-in, and validation logic are all driven by independently manageable and updatable knowledge graph data, changes to medical knowledge rules take effect synchronously without modifying the application code, thereby improving the system's flexibility in adapting to changing clinical business needs. Attached Figure Description

[0050] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1A flowchart illustrating a form filling and validation method based on a medical knowledge graph, provided in an embodiment of the present invention;

[0052] Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0053] 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, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0054] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0055] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0056] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0057] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0058] Please see Figure 1 This invention provides a form filling and validation method based on a medical knowledge graph, applied to a client-side application. The client communicates with a server storing the complete medical knowledge graph. The method includes the following steps:

[0059] S1, Load and maintain a lightweight subset of the medical knowledge graph synchronized from the full medical knowledge graph.

[0060] In practice, this invention operates within a communication connection between the client and a server storing the complete medical knowledge graph. Specifically, when the client starts or initializes a specific form module, it performs a subset loading and maintenance step of the knowledge graph and initiates a synchronization request to the server. This synchronization request may include the template identifier of the form currently pending processing.

[0061] Furthermore, based on the template identifier, the server filters out medical entities, attributes, and relationships that may be related to the form template from the full medical knowledge graph, such as diseases, drugs, examination items, and their common attributes and association rules, and sends this filtered data set as a lightweight medical knowledge graph subset to the client.

[0062] Furthermore, after receiving the data, the client builds a structured data model in local memory or cache, such as in the form of a graph database or a specific object relationship mapping, for subsequent fast querying, and can keep synchronized with the backend version through a heartbeat mechanism or server push.

[0063] It's important to note that a comprehensive medical knowledge graph refers to a structured semantic network covering a wide range of medical knowledge, centrally stored and maintained on a server. Based on a graph-structured data model, it abstracts medical concepts into entity nodes (such as diseases, drugs, examinations, symptoms, etc.) and connects related entities through predefined semantic relationship edges (such as "treatment," "examination," "contraindications," "typical symptoms," etc.), thus forming an interconnected medical knowledge network. This comprehensive medical knowledge graph not only stores the basic attribute information of entities (such as disease codes and drug specifications) but also stores rich relationships between entities and the business rules and logic attached to entities or relationships (such as dosage calculation rules and drug incompatibilities rules). As a complete and authoritative source of knowledge, the comprehensive medical knowledge graph provides downstream applications with unified and standardized knowledge query and reasoning services.

[0064] Furthermore, the lightweight medical knowledge graph subset refers to a subset of knowledge that the client synchronizes on demand from the full medical knowledge graph and maintains locally. Its lightweight nature is reflected in the targeted tailoring of data scale and functionality, aiming to balance the client's resource constraints and business needs. This lightweight medical knowledge graph subset is constructed based on a specific context (such as the current user's clinical department or the type of form to be processed), formed by filtering out medical entities, attributes, and core relationships strongly related to that context. Locally on the client, this lightweight medical knowledge graph subset is constructed as a data structure supporting fast querying, potentially containing two types of nodes: entity nodes supporting complete attribute retrieval and relationship reasoning (for core entities), and simplified entity nodes supporting only identifier and name retrieval (for non-core entities). Its core function is to provide low-latency, highly available local knowledge support for the client's intelligent filling and real-time validation.

[0065] Further, in some preferred embodiments, loading and maintaining a lightweight medical knowledge graph subset synchronized from the full medical knowledge graph includes: obtaining the identity attributes of the currently logged-in user, the identity attributes including at least the affiliated clinical department; determining, based on the affiliated clinical department, a first type of medical entity strongly related to the department's scope of treatment, and a second type of medical entity weakly related to the department's scope of treatment; sending a graph subset request to the server, the request carrying the identification information of the first type of medical entity and the second type of medical entity; receiving data returned by the server, the data containing the complete attributes and relationships of the first type of medical entity, and the summary information of the second type of medical entity; and, locally on the client, constructing the first type of medical entity as an entity node supporting complete query and reasoning, and constructing the second type of medical entity as an entity node supporting only name retrieval.

[0066] In practice, the client first obtains the logged-in user's identity attributes from the current login session or user profile. These identity attributes explicitly include the user's clinical department information, such as cardiology, pediatrics, or respiratory medicine. This information is typically obtained through the authentication interface when the user logs into the system and stored in the client session.

[0067] Furthermore, the client executes entity classification logic based on the acquired clinical department information. This entity classification logic can be determined based on a pre-configured department-entity association mapping table or by calculating the co-occurrence frequency of the department and various medical entities in historical medical data. The system divides medical entities into two categories: Category I medical entities are strongly related to the scope of treatment of the department, such as disease entities related to cardiovascular medicine, such as hypertension and coronary heart disease, as well as commonly used drug entities such as aspirin and nitroglycerin; and Category II medical entities are weakly related to the scope of treatment of the department, such as occasional diseases or infrequently used drugs in other departments.

[0068] Furthermore, the client constructs a graph subset request. This graph subset request explicitly carries a list of identification information for the first and second types of medical entities identified above, such as entity type codes and / or a list of key entity IDs. The client sends this request to the server over the network.

[0069] Furthermore, upon receiving a request, the server processes it based on the identification information. For the first type of medical entities, the server extracts complete data of these entities from the full knowledge graph, including all defined attributes of the entity, various relationships with other entities, and related business rules. For the second type of medical entities, the server only extracts their summary information, typically including only the most basic identification attributes such as entity name and code, omitting detailed attributes, complex relationships, and rules.

[0070] Furthermore, the client receives differentiated data packets returned by the server. When constructing subsets of the knowledge graph locally, the client employs different strategies. For complete data on the first type of medical entities, the client constructs them as fully functional entity nodes, supporting subsequent deep queries, attribute traversal, and relationship-based reasoning operations. For summary information on the second type of medical entities, the client constructs them as simplified nodes, primarily supporting name-based retrieval and display, but lacking in-depth attribute queries or rule application capabilities.

[0071] This invention optimizes the local caching resources on the client by finely classifying and synchronizing the required subset of the medical knowledge graph based on the user's clinical department. Obtaining departmental information gives knowledge loading a clear direction. Dividing entities into strongly related and weakly related categories and requesting data of different granularities from the server accordingly effectively reduces unnecessary data transmission, especially in the context of massive medical knowledge graph data, significantly reducing network load and the time required for client initialization or synchronization. Furthermore, after receiving differentiated data, nodes supporting complete querying and reasoning are built locally on the client for strongly related entities, ensuring that intelligent filling and complex validation functions in the core business scenarios of the department can be executed quickly and without delay, without affecting the user experience. Furthermore, only nodes supporting name retrieval are built for weakly related entities, ensuring that users can still retrieve necessary broad knowledge options when conducting cross-departmental consultations or handling complex cases, avoiding business blockages that may result from complete filtering, and avoiding the waste of memory and computing resources caused by storing and processing a large number of irrelevant detailed attributes and rules locally.

[0072] S2, in response to the user's input focus event on the target field in the form input interface, based on the semantic tags of the target field, query the subset of the lightweight medical knowledge graph to obtain the query results.

[0073] In practice, the client listens for user interaction events in the form input interface. When the user clicks or uses the Tab key to switch the input focus to a target field, such as a diagnosis input field or a drug name input field, an input focus event is triggered. After capturing this input focus event, the client parses the semantic tags pre-configured in the form definition for the target field, such as the field type being diagnosis or drug. Based on these semantic tags, the client initiates a query to a locally maintained lightweight medical knowledge graph subset. The query can be indexed by the field type to retrieve a list of all related entities under that type, or it can prepare for subsequent real-time input matching.

[0074] S3. Based on the query results, dynamically generate and display a list of candidate options in the form input interface. The items in the list of candidate options include candidate options derived from the relationships between medical entities.

[0075] In practice, the client dynamically generates and displays a list of candidate input options in the form input interface based on the initial query results. This candidate input list is generated not only based on string matching. For example, when the semantic tag is "diagnosis," the system not only lists entities whose disease names contain characters already entered by the user, but also infers from predefined relationships in a knowledge graph. Specifically, it can query which diseases use the user's entered suspected symptoms as typical symptoms and add these disease entities as candidates to the list. Furthermore, this candidate input list is typically displayed as a drop-down menu or floating panel below or to the side of the corresponding input box.

[0076] Further, in some preferred embodiments, the target field is a diagnostic field, and the step of dynamically generating and displaying a list of candidate options for filling in the form input interface based on the query result includes: capturing the real-time input string of the user in the diagnostic field input box; using the real-time input string as a search term to search in the lightweight medical knowledge graph subset to obtain an initial candidate set; obtaining the content of at least one symptom description field that has been filled in the current form; performing semantic similarity matching calculation between the content of the symptom description field and the typical symptom set of each disease entity in the initial candidate set; and reordering the disease entities in the initial candidate set according to the matching degree from high to low based on the result of the semantic similarity matching calculation to form and display the list of candidate options for filling in the form.

[0077] In practice, the client first listens to the keyboard input events of the diagnostic field input box, capturing every character typed by the user in real time to form a real-time input string. For example, when the user enters the first character, the system captures the first character of the string.

[0078] Furthermore, the client immediately uses this real-time input string as a search term to perform a search within a local lightweight medical knowledge graph subset. This search first performs fuzzy or prefix matching based on the name attributes of disease entities to obtain the first round of candidate results, called the initial candidate set. For example, it matches disease entities such as headache and dizziness.

[0079] Furthermore, the client retrieves the content of at least one symptom description field in the current form that the user may have already filled in elsewhere. This symptom description field could be a standalone symptom entry box or text content from the chief complaint field. The system then parses this field to extract the keywords describing the symptoms.

[0080] Further, the client performs semantic similarity matching calculations. The system obtains the typical symptom set for each disease entity in the initial candidate set, which is predefined in the attributes of that disease entity in the knowledge graph. The content (or keywords) of the symptom description field extracted in the previous step is compared with the typical symptom set of each disease entity. The comparison can be achieved by calculating the cosine similarity between text vectors or by calculating the semantic distance between symptom terms based on medical ontology, thereby obtaining a quantified matching score.

[0081] Furthermore, based on the calculated semantic similarity matching results, the client reorders all disease entities in the initial candidate set. The sorting rule is to place disease entities with a high degree of matching with the entered symptom descriptions at the top of the list, and those with a low degree of matching at the bottom. For example, if a user has entered "headache" and also filled in "throbbing" and "photophobia" in the symptom description, then "migraine" will be ranked higher due to its high matching of typical symptom sets, followed by "hypertensive encephalopathy," while other diseases whose names only contain the word "head" will be ranked lower. After sorting, the system displays this reordered list to the user as the final candidate list.

[0082] It should be noted that the semantic similarity calculation can be achieved through term distance metrics based on medical ontology (such as SNOMED CT), or through cosine similarity calculation using a pre-trained medical text vector model. The lightweight medical knowledge graph subset can be implemented by synchronizing only entities, attributes, and direct relationships related to the current department, and storing and transmitting them using an efficient serialization format (such as Protocol Buffers).

[0083] This embodiment significantly improves the accuracy and clinical applicability of intelligent recommendation for diagnostic fields by introducing a comprehensive analysis of the entered symptom descriptions. Traditional associative input relies solely on character matching within the current input box. This invention, building upon the initial candidate set generated by character matching, further acquires and utilizes other symptom information already present in the form. Semantic similarity matching calculations are performed between the symptom descriptions and the typical symptom sets of each candidate disease in the knowledge graph. This process simulates the initial thinking in clinical differential diagnosis, namely, assessing the likelihood of different diseases by combining known symptom clusters. Furthermore, the candidate diseases are reordered based on the matching results, giving priority to those diseases that have a higher degree of consistency with the patient's currently described symptoms. This means that when doctors receive input suggestions, the list's order itself contains a preliminary clinical tendency analysis, rather than simply alphabetical or pinyin order. This greatly reduces the time doctors spend identifying and searching among numerous possible options, enabling them to more quickly locate the most relevant diagnostic options and improving the efficiency and accuracy of diagnostic entry.

[0084] S4, in response to the user selecting an entry from the candidate list, retrieve the medical entity and attribute information corresponding to the selected entry from the lightweight medical knowledge graph subset, and automatically fill one or more subfields of the target field based on the attribute information.

[0085] In practice, once a user selects an item from the displayed list of candidate items by clicking with the mouse or selecting with the keyboard, the client immediately performs the autofill step.

[0086] Furthermore, the client uses the unique identifier of the user-selected entry, such as an entity ID, to perform a precise search within a lightweight medical knowledge graph subset, retrieving the complete medical entity object and its attribute information corresponding to that entry. For example, if the user selects the drug entity aspirin enteric-coated tablets, its attribute information might include standard specifications, units, and maximum single dose.

[0087] Furthermore, based on this attribute information, the client automatically fills in the standard specifications and unit values ​​into the specification subfield and unit subfield corresponding to the drug field in the form. Users only need to fill in information such as quantity.

[0088] Furthermore, in some preferred embodiments, the target field is a drug field, and the automatic filling of one or more sub-fields of the target field based on the attribute information includes: obtaining the disease entities selected in the diagnosis field of the current form from the lightweight medical knowledge graph subset; querying the association relationship tags between the disease entities and drug entities, the association relationship tags including preferred association, secondary association, or contraindicated association; when the user starts to input or select a drug in the drug field, filtering or prioritizing the drug entities in the candidate list based on the association relationship tags; and triggering a preset high-intensity warning interaction in response to the user's attempt to select a drug with a contraindicated association tag.

[0089] In practice, firstly, before or simultaneously with the user's interaction with the medication field, the client queries a locally maintained lightweight medical knowledge graph subset to determine if the diagnosis field of the current form has already been selected and a disease entity saved. For example, the diagnosis field may be locked as community-acquired pneumonia.

[0090] Furthermore, starting with the selected disease entity, the client queries all drug entities associated with the disease entity in the knowledge graph subset and obtains specific relationship tags attached to these associations. These tags are predefined in the graph relationships and include, but are not limited to, preferred associations (representing first-line treatment drugs), secondary associations (representing second-line or alternative drugs), and contraindication associations (representing drugs that are prohibited or should be used with caution under this disease).

[0091] Furthermore, when a user begins inputting data in the drug field (keyboard input) or initiates a selection (clicking the drop-down arrow), the client processes the drug entities based on the aforementioned queried association tags during the generation or filtering of the candidate list. Processing methods may include filtering, such as hiding all drugs with contraindication tags by default; or prioritizing drugs, such as adding visual identifiers like first or second lines before the drug name, or placing preferred associated drugs at the top when sorting the list.

[0092] Furthermore, the client monitors the user's selection behavior. If a user attempts to select or finalize a drug entity marked with a contraindication label by manually entering the full name or other means, the client immediately triggers a pre-set, high-intensity warning interaction. This typically manifests as a mandatory modal pop-up that explicitly states the drug is contraindicated with the current diagnosis, requiring the user to confirm or prevent their selection, and may be accompanied by prominent visual warnings, such as a red border and a warning icon.

[0093] This embodiment utilizes detailed association tags between diseases and drugs in a knowledge graph to achieve intelligent guidance and strong safety intervention in drug selection, significantly improving the safety and rationality of medication use. Before automatic filling, the current diagnostic information is first obtained, ensuring that subsequent drug recommendations and verification have a clear clinical context.

[0094] Furthermore, by querying and applying relationship tags such as preferred, secondary, and contraindicated drugs, the system can proactively guide patients during the drug selection stage. Filtering or prioritizing the candidate list based on these tags essentially provides doctors with a list of preferred drugs that conform to current diagnostic and treatment guidelines. This helps standardize treatment practices, improve prescription quality, and saves doctors time from having to sift through a massive drug database from memory to find suitable medications.

[0095] Furthermore, the strong warning interaction associated with contraindications forms a direct and unavoidable safety barrier when users attempt to select contraindicated drugs. This real-time interception before operational intentions are converted into actual data is more proactive and forward-looking than interception during post-approval or dispensing stages. It can effectively avoid serious medication errors caused by negligence, memory bias, or unfamiliarity with the latest guidelines, and greatly reduce the clinical risks of contraindicated drug use.

[0096] S5. Based on the predefined rules retrieved from the lightweight medical knowledge graph subset and associated with the medical entity, perform real-time compliance verification on the content already filled in the form input interface.

[0097] In practice, the client performs a real-time compliance verification step. This step is triggered immediately after the data entry is completed, or it continues whenever the user modifies any relevant field content.

[0098] Furthermore, the rules used for validation are directly related to the currently selected medical entity and are retrieved from a subset of the lightweight medical knowledge graph. For example, for the selected drug entity, a predefined rule for the maximum single dose is defined in its attributes. The client monitors the value of the drug quantity subfield, combines it with the automatically populated specification value, calculates the single dose, and compares it with the maximum allowed by the rule. If the calculated dose exceeds the maximum allowed, a visual or textual alert is provided in real time on the interface, such as highlighting the input box in red and displaying a prompt message, and may prevent form submission.

[0099] This invention maintains a localized, lightweight subset of the knowledge graph, enabling clients to quickly respond to form operations without entirely relying on real-time network server queries. This reduces interaction latency and improves the smoothness of the user experience. Furthermore, by responding to input focus events and querying the knowledge graph based on field semantic tags, the system can provide context-relevant fill options before or at the beginning of user input, transforming traditional passive input into active guidance. This significantly reduces the cognitive burden and operational steps required for users to memorize and fully type complex technical terms. Furthermore, by using the relationships between medical entities in the knowledge graph to generate candidate option lists—for example, associating diseases with symptoms—the intelligent suggestions go beyond literal matching and incorporate the logical thinking of clinical diagnosis, improving the accuracy and practicality of the suggestions. Automatically filling subfields based on entity attribute information retrieved from the graph automatically completes multiple standardized information items that previously required user input, significantly reducing repetitive manual input, improving form filling efficiency, and avoiding format inconsistencies that might arise from manually entering standard information. Furthermore, real-time compliance verification is performed based on predefined rules dynamically acquired from the same subset of the knowledge graph and bound to the selected entities. This ensures that the verification logic is synchronized with the latest medical knowledge and is highly targeted. This real-time verification provides immediate feedback during user operations and can provide early warnings when potential errors occur, thereby effectively intercepting common medical operation errors such as drug overdosing at the source and strengthening the medical safety barrier.

[0100] Furthermore, in some preferred embodiments, the real-time compliance verification of the content already filled in the form input interface includes: during real-time compliance verification, automatically retrieving whether the patient's liver or kidney function index values ​​have been entered in the current form, wherein the attribute information of the drug entity predefines dosage adjustment rules associated with the patient's liver and kidney function test indicators; if the index values ​​have been entered, the index values ​​are substituted into the dosage adjustment rules for calculation, dynamically correcting the standard dosage safety range of the drug; and verifying the drug dosage entered by the user based on the corrected standard dosage safety range.

[0101] In practice, firstly, in the definition of the drug entity's attribute information, in addition to the conventional dosage rules, dosage adjustment rules related to the patient's liver and kidney function test indicators are predefined. These rules may exist in the form of logical conditional statements or calculation formulas. For example, the rule might be defined as: when the patient's creatinine clearance is below 50 ml per minute, the maximum daily dose of the drug should be adjusted to 75% of the conventional dose.

[0102] Furthermore, when the system performs real-time compliance checks on the already filled drug field content, it automatically expands the scope of the verification search. The system will scan each field of the current form to check whether there are predefined specific fields used to enter patient liver function indicators or kidney function indicators, such as serum alanine aminotransferase, serum creatinine, or creatinine clearance rate fields, and attempt to obtain the numerical results already entered in these fields.

[0103] Furthermore, if the system finds that one or more of these liver and kidney function indicator fields have already been entered with valid values, the dosage adjustment process is triggered. The client will substitute the obtained specific indicator values ​​into the predefined dosage adjustment rules in the drug's attribute information for calculation. The calculation process will dynamically correct the original standard dosage safety range of the drug according to the rule logic. For example, based on the creatinine clearance rate value, the adjusted maximum daily dose limit is calculated.

[0104] Furthermore, based on this dynamically adjusted, individualized standard dose safety range, the system validates the drug dosage entered by the user in the drug field. For example, if the user enters a daily dose of 100 mg, while the safe upper limit adjusted according to the patient's liver function indicators is 80 mg, the system will determine that this dose exceeds the limit and issue a warning.

[0105] This invention incorporates real-time liver and kidney function test indicators into the dosage calibration system, achieving a leap from standard dosage calibration based on the general population to personalized dosage calibration based on the individual patient's physiological state, significantly improving the level of refined management of medication safety. Furthermore, dosage adjustment rules linked to liver and kidney function are predefined in the drug attributes, structurally linking complex pharmaceutical knowledge with clinical laboratory knowledge. Further, the system automatically retrieves relevant test indicator values ​​from the form during the calibration process, enabling it to proactively perceive key individual patient factors affecting drug metabolism and excretion. The retrieved indicator values ​​are substituted into the predefined rules for calculation, dynamically correcting the standard safety range. This process essentially simulates the thought process of a clinical pharmacist or physician adjusting medication regimens based on laboratory reports. Finally, the final calibration is performed based on the corrected individualized safety range, ensuring that dosage safety warnings are no longer rigid, uniform thresholds, but rather more targeted safety boundaries that flexibly change according to the patient's current liver and kidney function status. This is especially important for drugs that are metabolized by the liver or excreted by the kidneys, as it can effectively avoid the risk of drug accumulation and toxicity caused by using conventional doses in patients with liver or kidney dysfunction, thus providing proactive protection for the safety of medication use in special populations.

[0106] In some preferred embodiments, the real-time compliance verification of the content already filled in the form input interface includes: when the item selected by the user corresponds to a drug entity, and the attribute information of the drug entity contains a rule for calculating dosage by weight, locating the patient age field and the patient weight field in the form input interface; determining whether the value of the patient age field falls within a preset child age range; if the value of the patient age field falls within the preset child age range, activating a preset child-specific dosage calculation model, which introduces an age-related pharmacokinetic correction factor based on a preset general weight-based calculation rule; calculating the permissible drug dosage range applicable to pediatric patients based on the child-specific dosage calculation model, the value of the patient weight field, and the value of the patient age field; and verifying the drug dosage input by the user based on the calculated permissible drug dosage range.

[0107] In practice, the verification process begins when the system detects that the item selected by the user corresponds to a drug entity, and parses the drug entity's attribute information to find a rule for calculating dosage based on weight. The system first locates and accesses the patient age and patient weight fields in the current form input interface, and reads their values.

[0108] Furthermore, the system compares the value of the patient's age field with a preset age range for children. This range can be defined, for example, as 0 to 14 years old. If the patient's age value falls within this preset range, the patient is determined to be a child.

[0109] Furthermore, for patients identified as children, the system will activate a pre-defined, more complex pediatric-specific dosage calculation model. This pediatric-specific dosage calculation model is not a simple linear function of body weight. It introduces an age-related pharmacokinetic correction factor on top of the general weight-based calculation rules (e.g., mg per kilogram of body weight per day). This correction factor is typically set based on the differences in pharmacokinetic parameters such as drug-metabolizing enzyme activity and volume of distribution at different age stages in children, and may be an age-related piecewise function or coefficient table.

[0110] Furthermore, the system performs a comprehensive calculation based on the activated pediatric-specific dosage calculation model, combined with the specific values ​​of the patient's weight and age fields obtained from the form. The calculated output is a more precise permissible drug dosage range specifically tailored to this pediatric patient.

[0111] Furthermore, the system uses this calculated individualized permissible range for children's medication dosage to validate the value actually entered by the user in the medication dosage field, determining whether it is within the safe range.

[0112] It should be noted that the pediatric-specific dosage calculation model is a dedicated calculation logic embedded in or associated with the entity attributes of a drug, used to calculate individualized allowable drug dosage ranges for pediatric patients. Based on general weight-based dosage rules, this model introduces an age-related pharmacokinetic correction factor to reflect key physiological differences in drug metabolism and distribution at different stages of growth and development in children. Using the patient's weight and age as joint input parameters, the model outputs an individualized baseline dosage value for that specific child through built-in formulas or rule sets. Furthermore, according to pediatric medication safety guidelines, an asymmetric allowable fluctuation range is determined around this baseline dosage value, where the lower limit allows a smaller proportion of negative fluctuation than the upper limit allows a smaller proportion of positive fluctuation. The output of this pediatric-specific dosage calculation model is used for refined and individualized safety verification of the user-input drug dosage.

[0113] This embodiment significantly improves the scientific rigor and safety of pediatric drug dosage verification by designing a dedicated dosage calculation model for pediatric patients. Children are not simply miniature adults; their drug metabolism exhibits significant age dependence. This invention first identifies patient groups requiring specific dosage calculations by determining whether their age falls within the pediatric range. Furthermore, the activated pediatric-specific dosage calculation model incorporates an age-related pharmacokinetic correction factor. This design allows dosage calculations to transcend simple linear weight-based relationships, more accurately reflecting the differences in drug processes at different stages of a child's growth and development. Moreover, based on this pediatric-specific dosage calculation model, and combining the patient's specific weight and age as two key parameters, the calculated permissible drug dosage range is individualized and more aligned with the child's physiological characteristics. Compared to general calculations based solely on weight, this dual-parameter model provides more refined and reasonable dosage guidance for different subgroups, including infants, preschool children, and school-aged children. By using this individualized range for verification, the risk of inaccurate dosage caused by applying the adult weight-based conversion method can be effectively avoided. Whether it is insufficient dosage affecting efficacy or excessive dosage increasing toxicity, better early warning and control can be achieved.

[0114] In some preferred embodiments, the step of calculating the permissible range of drug dosage for pediatric patients based on the pediatric-specific dosage calculation model, the value of the patient weight field, and the value of the patient age field includes: inputting the values ​​of the patient weight field and the patient age field into the pediatric-specific dosage calculation model to calculate an individualized baseline dose value; and determining an asymmetric permissible range around the individualized baseline dose value according to preset pediatric drug safety guidelines, wherein the lower limit allows a smaller negative fluctuation ratio than the upper limit allows a smaller positive fluctuation ratio.

[0115] In practice, firstly, the specific values ​​of the patient's weight (e.g., 20 kg) and age (e.g., 5 years old) obtained from the form are used as input parameters and passed to the activated pediatric-specific dosage calculation model. This model then runs its internal calculation logic and outputs a calculated individualized baseline dose value. This baseline value represents the recommended theoretical dose for a child of that specific weight and age.

[0116] Furthermore, the system does not directly use this baseline dose value as the sole standard. Instead, based on pre-defined pediatric medication safety guidelines, it determines a permissible range of fluctuation around this individualized baseline dose value—an asymmetric permissible range. The asymmetry lies in the different fluctuation ratios of the upper and lower limits of the permissible range relative to the baseline value. Specifically, based on the general principle that pediatric medication typically emphasizes avoiding the risk of overdose, the permissible negative fluctuation ratio of the lower limit (i.e., the allowable range below the baseline value) is set smaller than the permissible positive fluctuation ratio of the upper limit (i.e., the allowable range above the baseline value). For example, the guidelines might set the lower limit to allow a negative fluctuation of 10%, while the upper limit to allow a positive fluctuation of 20%. The system calculates the specific lower and upper dose limits based on these guidelines, thus forming the final permissible drug dosage range.

[0117] This embodiment further refines and optimizes the safety verification strategy for pediatric medication by setting an asymmetric safety allowable range for pediatric dosages. Simply allowing symmetrical fluctuations after obtaining individualized baseline dose values ​​may not be clinically feasible. Children's tolerance to drugs varies, and the risk of overdose is often more concerning than the risk of slightly insufficient dosage. Setting an asymmetric allowable range, where the lower limit allows a smaller proportion of negative fluctuations than the upper limit allows for positive fluctuations, reflects the principle of prudent pediatric medication use: while ensuring a certain therapeutic window, relatively strict restrictions are placed on insufficient dosage (which may affect efficacy), while a wider safety margin is provided for overdose (which may lead to toxicity). Furthermore, this asymmetric verification logic can more sensitively detect potentially low dosages, reminding doctors to assess whether the treatment effect is sufficient; simultaneously, for dosages slightly higher than the baseline value, as long as they do not exceed a large positive fluctuation limit, the system does not easily issue alarms, reserving reasonable space for clinical fine-tuning based on actual conditions and avoiding excessively frequent invalid alarms that interfere with doctors' work.

[0118] In some preferred embodiments, the method further includes: when it is detected that a user has completed the selection confirmation of a specific disease entity in the diagnosis field, querying the phased examination suggestion relationship related to the specific disease entity in the lightweight medical knowledge graph subset; determining the current treatment stage based on the treatment stage metadata associated with the current form; filtering out a subset of examination item entities matching the current stage from the phased examination suggestion relationship based on the determined treatment stage; and dynamically generating and highlighting the subset of examination item entities corresponding to the current stage as core recommendations in the examination application field area of ​​the form input interface.

[0119] In practice, when the system detects that the user has completed the final selection and confirmation of a specific disease entity by listening to the change event of the diagnostic field or the confirmation button event, the subsequent process is triggered.

[0120] First, the client uses the confirmed specific disease entity as the starting point for its query and performs a search within a local lightweight medical knowledge graph subset. The goal of the query is to retrieve the relationships of phased examination recommendations related to the disease entity. These relationships are predefined in the graph; for example, examination item entities are connected to disease entities through different types of relationships such as diagnostic phase examinations, efficacy evaluation phase examinations, and complication monitoring phase examinations.

[0121] Furthermore, the system needs to determine the current treatment stage of the form. This is achieved by reading the treatment stage metadata associated with the current form. This treatment stage metadata can be an attribute inherent to the form template (e.g., the admission medical record template corresponds to the diagnosis stage, and the progress note template corresponds to the treatment stage), or it can be a stage identifier actively selected by the user through specific options in the form.

[0122] Furthermore, based on the determined current treatment stage, the system filters out examination item entities from all the stage-specific examination suggestion relationships retrieved in the previous step. These entities have a relationship type that precisely matches the current stage, forming a subset of examination item entities. For example, if the current stage is the treatment stage, then all items marked as examinations for the efficacy assessment stage will be filtered out.

[0123] Furthermore, the system dynamically renders the interface in the examination application field area of ​​the form input interface. Items from the filtered subset of examination items are inserted into this area as checkboxes, recommendation lists, or other visual formats. These items are highlighted using bolding, background color adjustment, and placement at the top to clearly identify them as the core recommended examinations most relevant to the current stage of diagnosis and treatment.

[0124] This invention, by introducing the concept of diagnostic and treatment stages and differentiating examination recommendations in stages, achieves dynamic and precise recommendations for examination items, thereby improving the standardization of clinical pathway execution. Traditional static association or hard-coded rules often list all potentially related examinations at once, failing to distinguish the different purposes of different diagnostic and treatment stages. After diagnosis is confirmed, this invention queries a knowledge graph for predefined, categorized relationships of staged examination recommendations, reflecting an understanding of the complete diagnostic and treatment process (diagnosis, treatment evaluation, and follow-up monitoring).

[0125] Furthermore, by combining the metadata of the current form's diagnosis and treatment stage, the system can intelligently identify the specific stage currently in which the patient is located. Based on the current stage, the system filters out the most matching subset from all suggestions, making the recommendation list highly timely and targeted. For example, in the diagnosis stage, it recommends differential diagnostic tests required for confirmation; in the treatment stage, it recommends key indicator tests for evaluating efficacy, avoiding repeated recommendations of initial diagnostic tests during the treatment stage, or premature recommendations of long-term monitoring items at the initial diagnosis.

[0126] Furthermore, dynamically rendering and highlighting these core recommendations in the interface can effectively guide doctors to focus on and perform the most critical and necessary examinations at different stages, reducing the chances of missing important examinations or ordering unnecessary ones.

[0127] In some preferred embodiments, the server maintains a version log of the full medical knowledge graph and records the entity types and associated form templates affected by each knowledge update. When the full medical knowledge graph is updated, the server iterates through all online clients, compares the version of the graph subset cached locally on the client with the latest version on the server, and determines the clients that need to be updated. For the clients that need to be updated, the server generates and pushes a minimal set of verification rule update instructions. Further, the method also includes: the client receiving the set of verification rule update instructions and, according to the set of verification rule update instructions, atomically updating the entity attributes or association rules corresponding to the set of verification rule update instructions in the locally maintained lightweight medical knowledge graph subset.

[0128] In practice, the server maintains a detailed version log of the entire medical knowledge graph and records every update to the knowledge graph. The record includes at least the specific medical entity types (such as drugs and diseases) affected by the update and the form template identifiers associated with these entities.

[0129] Furthermore, when any part of the full medical knowledge graph is updated, such as when the maximum dosage attribute of a drug is modified, the server initiates an update distribution process. The server iterates through all currently online client connections. For each online client, the server compares the version number of the graph subset recorded during the client's last synchronization with the server's current latest version number to determine which clients' locally cached graph subsets are outdated and require updating.

[0130] Furthermore, for each client determined to require an update, the server does not resend the entire changed subset of the knowledge graph. Instead, it generates a minimal set of verification rule update instructions. This instruction set may use a specific descriptive language and contains only the most concise information, such as the changed entity identifiers, attribute names, new rule logic, or numerical values.

[0131] Furthermore, on the client side, the execution steps include: the client receiving this verification rule update instruction set from the server via network listening or long-lived connection push. The client then parses the instruction set to understand its intent, such as updating the maximum dosage attribute value of a certain drug entity. Finally, based on the instructions, the client updates the specific entity attributes or specific association rules in the locally maintained lightweight medical knowledge graph subset that precisely correspond to the instruction set. This update is atomic, meaning it only modifies the smallest data unit specified by the instruction, keeping other irrelevant parts of the graph subset completely unchanged.

[0132] This embodiment provides a highly efficient, accurate, and minimally disruptive dynamic knowledge graph update mechanism, ensuring that intelligent filling and validation rules are synchronized with the latest medical knowledge in real time. By maintaining version logs and performing correlation impact analysis, the server can accurately pinpoint the scope of clients affected by each knowledge update. Furthermore, identifying clients requiring updates through version comparison rather than broadcasting avoids unnecessary network communication and client processing overhead. Generating and pushing a minimal set of validation rule update instructions, rather than full or large incremental data, significantly reduces the amount of data transmitted for each update, which is particularly important for clients with limited network bandwidth or in mobile environments, and also reduces the pressure on the server for concurrent updates. Furthermore, after receiving the instruction set, the client performs atomic update operations, meaning the update process is fast and targeted, modifying only a few necessary data points. This avoids the performance overhead and interface lag risks associated with reloading or rebuilding an entire subset of the local knowledge graph to update a small portion of the knowledge, ensuring that the smoothness of doctors' operations during form filling is not affected by background knowledge updates.

[0133] In some preferred embodiments, the method further includes: if it is detected that the diagnosis field, examination result field, and patient basic information field in the form input interface have all been filled, combining the disease entity selected in the diagnosis field, the numerical result entered in the examination result field, and the age and weight values ​​in the patient basic information field to form a composite query condition; using the composite query condition to query the lightweight medical knowledge graph subset; wherein, the lightweight medical knowledge graph subset, based on predefined clinical decision logic, returns a structured treatment plan suggestion that matches the composite query condition; the structured treatment plan suggestion at least includes a recommended drug combination, an initial dosage range, and a treatment cycle; and dynamically rendering and displaying the structured treatment plan suggestion in the form input interface.

[0134] In practice, the system first performs status checks on the form input interface. The logic of the checks is to determine whether the diagnosis field (where the disease entity has been selected), the examination result field (where meaningful numerical results, such as blood routine and white blood cell count, have been entered), and the patient basic information field (which includes at least age and weight) have all been effectively filled. The validity judgment can be based on rules such as fields not being empty and values ​​being within a reasonable range; this invention does not specifically limit this.

[0135] Furthermore, if it is detected that the diagnosis field, examination result field, and patient basic information field in the form input interface have all been filled, the system initiates the suggestion generation process. First, information integration is performed: the specific disease entity selected in the diagnosis field (e.g., pneumonia), the key numerical results entered in the examination result field (e.g., white blood cell count 15x10^9 / L), and the age value (e.g., 35 years old) and weight value (e.g., 65 kg) in the patient basic information field are extracted, and these four types of information are combined to form a composite query condition containing multi-dimensional patient status.

[0136] Furthermore, the system uses this composite query condition to initiate a complex query to a subset of the local lightweight medical knowledge graph. This query is not a simple entity retrieval, but rather triggers predefined clinical decision-making logic within the knowledge graph. This logic may exist in or be associated with the graph in the form of rule chains, decision trees, or algorithmic models, and can handle multiple input parameters.

[0137] Furthermore, based on its internal logic, the knowledge graph subset matches and infers from complex query conditions, ultimately returning a structured treatment plan recommendation tailored to the specific patient's current condition (specific disease, specific test results, specific age and weight). This recommendation is structured data, explicitly including at least the recommended drug combination (e.g., antibiotic A + expectorant B), the initial dosage range for each drug (e.g., antibiotic A: 1-2 grams daily, divided into two intravenous infusions), and the suggested initial treatment duration (e.g., 7-14 days).

[0138] Furthermore, the client dynamically renders and displays this structured treatment plan suggestion in a preset area of ​​the form input interface (such as a sidebar or bottom panel). The display format may be clear text paragraphs, collapsible cards, or lists with actionable buttons for doctors to refer to.

[0139] This embodiment achieves a functional leap from assisting with form completion to assisting in the formulation of preliminary treatment plans by integrating and utilizing multi-dimensional key information already filled in the form and driving the knowledge graph to perform advanced clinical decision reasoning. Traditional assistance systems often focus on optimizing the input of a single field, while this invention integrates diagnostic evidence, objective examination evidence, and the patient's basic physiological parameters to construct a composite query condition that reflects the patient's current state. This provides a solid multi-source data foundation for subsequent decision support.

[0140] Furthermore, by using this composite condition query to query the predefined clinical decision-making logic in the knowledge graph, the knowledge such as clinical guidelines and expert consensus is essentially transformed into a computable reasoning process, which can output a personalized treatment suggestion framework based on specific conditions and individual characteristics.

[0141] Furthermore, the generated structured treatment recommendations, including drug combinations, dosage ranges, and treatment cycles, provide physicians with an immediate and readily referable preliminary treatment blueprint tailored to the patient's specific circumstances. This is particularly valuable for inexperienced physicians or those dealing with complex cases, offering significant decision support.

[0142] Furthermore, this suggestion is dynamically rendered and displayed in the interface, seamlessly integrating it into the existing workflow. Doctors can obtain targeted guidance without switching systems or manually consulting materials, which not only greatly improves the efficiency and standardization of treatment plan formulation, but also helps to promote the standardization and homogenization of clinical practice. This is an important manifestation of the development of intelligent medical systems towards higher-level decision support.

[0143] Please see Figure 2 , Figure 2This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a terminal or a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.

[0144] The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0145] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, it causes the processor 502 to execute a form filling and validation method based on a medical knowledge graph.

[0146] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0147] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a form filling and validation method based on a medical knowledge graph.

[0148] The network interface 505 is used for network communication with other devices. Those skilled in the art will understand that the above structure is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. A specific computer device 500 may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements.

[0149] The processor 502 is used to run a computer program 5032 stored in the memory to implement the steps of a form filling and validation method based on a medical knowledge graph provided in any of the above method embodiments.

[0150] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0151] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program may be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0152] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program. When executed by a processor, the computer program causes the processor to perform the steps of the form filling and validation method based on a medical knowledge graph provided in any of the above method embodiments.

[0153] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk, or any other physical storage medium capable of storing program code. The computer-readable storage medium can be non-volatile or volatile.

[0154] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0155] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0156] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0157] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0158] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0159] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Since these modifications and variations fall within the scope of the claims and their equivalents, this invention also intends to include these modifications and variations.

[0160] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A form filling and checking method based on a medical knowledge graph, characterized in that, Applied to a client, the client communicates with a server storing a complete medical knowledge graph, the method includes: Load and maintain a lightweight subset of the medical knowledge graph synchronized from the full medical knowledge graph; In response to a user's focus event on a target field in a form input interface, the lightweight medical knowledge graph subset is queried based on the semantic tags of the target field to obtain query results; Based on the query results, a list of candidate options is dynamically generated and displayed in the form input interface. The items in the list of candidate options include candidate options derived from the relationships between medical entities. In response to a user selecting an entry from the candidate list, the system retrieves the medical entity and attribute information corresponding to the selected entry from the lightweight medical knowledge graph subset, and automatically fills one or more subfields of the target field based on the attribute information. Based on the predefined rules retrieved from the lightweight medical knowledge graph subset and associated with the medical entity, the content already filled in the form input interface is checked for compliance in real time. The server maintains a version log of the full medical knowledge graph and records the entity types and associated form templates affected by each knowledge update. When the full medical knowledge graph is updated, the server iterates through all online clients, compares the version of the graph subset cached locally on the client with the latest version on the server, and determines the clients that need to be updated. For the clients that need to be updated, the server generates and pushes a minimal set of verification rule update instructions. The client receives the set of verification rule update instructions and, according to the set of verification rule update instructions, atomically updates the entity attributes or association rules corresponding to the set of verification rule update instructions in the lightweight medical knowledge graph subset maintained locally. 2.The medical knowledge graph based form filling and verification method according to claim 1, characterized in that, The loading and maintenance of a lightweight subset of the medical knowledge graph synchronized from the full medical knowledge graph includes: Obtain the identity attributes of the currently logged-in user, including at least the clinical department to which the user belongs; Based on the clinical department to which they belong, we identify the first category of medical entities that are strongly related to the scope of diagnosis and treatment of the department, and the second category of medical entities that are weakly related to the scope of diagnosis and treatment of the department. Send a map subset request to the server, the request carrying the identification information of the first type of medical entity and the second type of medical entity; The system receives data returned by the server, which includes the complete attributes and relationships of the first type of medical entities, as well as summary information of the second type of medical entities. On the client-side, the first type of medical entities are constructed as entity nodes that support complete querying and reasoning, while the second type of medical entities are constructed as entity nodes that only support name retrieval. 3.The medical knowledge graph based form filling and verification method according to claim 1, characterized in that, The target field is a diagnostic field. The step of dynamically generating and displaying a list of candidate options in the form input interface based on the query results includes: Capture the real-time input string of the user in the diagnostic field input box; The real-time input string is used as a search term to retrieve data from the lightweight medical knowledge graph subset, resulting in an initial candidate set. Retrieve the content of at least one symptom description field that has been filled in the current form; The semantic similarity of the content of the symptom description field with the typical symptom set of each disease entity in the initial candidate set is calculated. Based on the results of the semantic similarity matching calculation, the disease entities in the initial candidate set are reordered from high to low according to the matching degree to form and display the populated candidate list.

4. The form filling and validation method based on medical knowledge graph according to claim 1, characterized in that, The target field is a drug field, and the automatic filling of one or more sub-fields of the target field based on the attribute information includes: From the lightweight medical knowledge graph subset, obtain the disease entities whose diagnosis field in the current form has been selected; Query the association relationship tags between the disease entity and the drug entity, where the association relationship tags include preferred association, secondary association, or contraindicated association; When a user starts entering or selecting a drug in the drug field, the drug entities in the candidate list are filtered or prioritized based on the association tags. In response to a user's attempt to select a drug with a contraindication label, a pre-set, high-intensity warning interaction is triggered.

5. The form filling and validation method based on medical knowledge graph according to claim 4, characterized in that, The real-time compliance verification of the content already filled in the form input interface includes: During real-time compliance verification, the system automatically checks whether the patient's liver or kidney function indicators have been entered in the current form. In the attribute information of the drug entity, there are predefined dosage adjustment rules associated with the patient's liver and kidney function test indicators. If the index value is entered, the index value is substituted into the dosage adjustment rule for calculation, and the standard dosage safety range of the drug is dynamically corrected. The drug dosage entered by the user is validated based on the revised standard dosage safety range.

6. The form filling and validation method based on medical knowledge graph according to claim 1, characterized in that, The real-time compliance verification of the content already filled in the form input interface includes: When the item selected by the user corresponds to a drug entity, and the attribute information of the drug entity contains a rule for calculating dosage by weight, locate the patient age field and the patient weight field in the form input interface. Determine whether the value of the patient's age field falls within a preset range of children's ages; If the value of the patient's age field falls within the preset child age range, the preset child-specific dosage calculation model is activated. The child-specific dosage calculation model introduces an age-related pharmacokinetic correction factor based on the preset general weight-based calculation rules. Based on the pediatric-specific dosage calculation model, the value of the patient's weight field, and the value of the patient's age field, the permissible range of drug dosage applicable to pediatric patients is calculated; The drug dosage entered by the user is verified based on the calculated allowable range of drug dosage.

7. The form filling and validation method based on medical knowledge graph according to claim 6, characterized in that, The permissible range of drug dosage for pediatric patients is calculated based on the pediatric-specific dosage calculation model, the value of the patient's weight field, and the value of the patient's age field, including: The values ​​of the patient's weight field and the patient's age field are input together into the pediatric-specific dosage calculation model to calculate the individualized baseline dosage value; Based on the preset pediatric medication safety guidelines, an asymmetric allowable range is determined around the individualized baseline dose value, wherein the lower limit allows a smaller percentage of negative fluctuation than the upper limit allows a smaller percentage of positive fluctuation.

8. The form filling and validation method based on medical knowledge graph according to claim 1, characterized in that, The method further includes: When it is detected that a user has completed the selection confirmation of a specific disease entity in the diagnosis field, query the phased inspection suggestion relationship related to the specific disease entity in the lightweight medical knowledge graph subset; The current treatment stage is determined based on the treatment stage metadata associated with the current form; Based on the determined diagnosis and treatment stage, a subset of examination items that match the current stage are selected from the stage-based examination recommendation relationship; In the inspection application field area of ​​the form input interface, a subset of the inspection items corresponding to the current stage is dynamically generated and highlighted as the core recommendation.

9. A computer device, characterized in that, The computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-8.

Images