Method, system and related device for generating medical forms

Abstract

The application provides a medical form generation method, system and related equipment, and the method comprises the following steps: receiving a form creation instruction, analyzing a medical context in the instruction through natural language processing; obtaining a matched basic template from a specialty template library based on the medical context and generating a field candidate set; screening the field candidate set through a collaborative filtering algorithm and combining medical business rules to obtain a recommended field list; rendering the basic template according to the recommended field list, and initiating a query request to a clinical term service when rendering a medical term field; binding the medical term field with a standard clinical term in the clinical term service through a multi-strategy mapping; and deploying a front-end instant verification and back-end deep verification mechanism for a user input part of the basic template. The medical form generation method of the application combines context awareness, dynamic term binding and multi-level verification to collaboratively realize form generation, and improves the flexibility and security of form generation.

Description

TECHNICAL FIELD

[0001] The present application relates to the medical technology field, and in particular to a medical form generation method and system and related equipment. BACKGROUND

[0002] In the field of medical informatization, the generation of electronic forms and data collection are core links. Most existing electronic form systems use pre-set fixed templates, which cannot dynamically adapt to changing clinical scenarios. When users need to create specialty forms, they often need to manually select from hundreds of fields, which is time-consuming and prone to missing key fields. Moreover, the binding of medical terms in the form requires manual intervention, which has a high error rate and poor real-time performance. The verification mechanism is also not comprehensive enough to meet the needs of medical scenarios.

[0003] Therefore, the prior art still needs to be improved and developed. SUMMARY

[0004] The present application provides a medical form generation method and system and related equipment. The main purpose of the present application is to solve the technical problems mentioned in the background of the prior art.

[0005] The first aspect of the present application provides a medical form generation method, comprising:

[0006] Receiving a form creation instruction, and obtaining the medical context in the instruction through natural language processing;

[0007] Based on the medical context, a matching basic template is selected from a specialty template library, and a field candidate set is generated;

[0008] The field candidate set is filtered through a pre-set collaborative filtering algorithm combined with medical business rules to obtain a recommended field list;

[0009] The basic template is rendered according to the recommended field list, and when a medical term field in the recommended field list is rendered, a query request is initiated to a clinical term service;

[0010] In the clinical term service, the medical term field is bound to a standard clinical term using a multi-strategy mapping;

[0011] A multi-level collaborative verification mechanism is deployed for the user input of the basic template, which includes front-end instant verification based on medical rules and back-end deep verification based on data security and business logic.

[0012] In an optional implementation of the first aspect of the present application, the filtering of the field candidate set through the pre-set collaborative filtering algorithm combined with the medical business rules to obtain the recommended field list comprises:

[0013] Based on the historical form database, the co-occurrence frequency of each field in the field candidate set under the same medical scenario is counted;

[0014] According to the co-occurrence frequency and the scenario similarity correction coefficient, the initial weight of each field in the field candidate set is calculated;

[0015] The set of mandatory associated fields is extracted from the medical business rule library, and a rule weight is attached to the mandatory field, wherein when the field belongs to the CDISC standard mandatory field, the rule weight is 1, and when the field does not belong to the CDISC standard mandatory field, the rule weight = rule priority × rule library confidence coefficient;

[0016] The comprehensive weight obtained by adding the initial weight and the rule weight of each field in the field candidate set is calculated;

[0017] The fields in the field candidate set are sorted in descending order according to the comprehensive weight, and the target field ranked in the top N is selected to generate a recommended field list.

[0018] In an optional implementation of the first aspect of the present application, the multi-strategy mapping in the clinical term service includes:

[0019] The medical term field is precisely matched with the preferred term in the standard term library;

[0020] When the precise match fails, the similar term is found through the synonym library and the fuzzy matching algorithm;

[0021] After matching to the similar term, the context consistency of the similar term is verified by using the hierarchical structure in the standard term library, and the similar term that best matches the medical context of the medical term field is selected as the standard clinical term.

[0022] In an optional implementation of the first aspect of the present application, after matching to the similar term, the context consistency of the similar term is verified by using the hierarchical structure in the standard term library, and the similar term that best matches the medical context of the medical term field is selected as the standard clinical term.

[0023] For each of the similar terms, the superior concept term of the similar term is obtained by tracing upwards along the hierarchical structure in the standard term library;

[0024] The semantic correlation score between each of the superior concept term and the medical term field is calculated;

[0025] The similar term with the highest semantic correlation score is selected as the final output standard clinical term.

[0026] In an alternative implementation of the first aspect of the present application, the deploying a multi-level collaborative verification mechanism for the user input of the base template comprises:

[0027] For the front-end instant verification, preset medical rules are compiled into lightweight client scripts, which are triggered when the user inputs data, to achieve real-time feedback and interception of data format, numerical range and simple logic;

[0028] For the back-end deep verification, a distributed verification micro-service cluster is used to perform complex business logic verification including cross-field data consistency, clinical term accuracy and drug compatibility contraindication after data submission;

[0029] The front-end instant verification and the back-end deep verification maintain the consistency of core rules through a shared verification rule library, forming a front-back collaborative verification system.

[0030] In an alternative implementation of the first aspect of the present application, for the back-end deep verification, a distributed verification micro-service cluster is used to perform complex business logic verification including cross-field data consistency, clinical term accuracy and drug compatibility contraindication after data submission, which comprises:

[0031] When the back-end receives a batch verification task, the batch verification task is split into multiple sub-tasks according to a preset sharding key;

[0032] The data volume of each sub-task is monitored, and secondary sharding processing is performed on the sub-tasks that exceed a threshold;

[0033] The sharded sub-tasks are distributed to the distributed verification micro-service cluster through an asynchronous message queue;

[0034] A weighted least connection number algorithm is used in the verification nodes of the distributed verification micro-service to dynamically obtain each sub-task;

[0035] Term verification, logic rule verification and data consistency verification are performed in parallel by the distributed verification micro-service cluster;

[0036] The verification results of the distributed verification micro-service cluster are merged, deduplicated and counted by an aggregator to generate a global verification report.

[0037] In an alternative implementation of the first aspect of the present application, the filtering a matching base template from a specialty template library based on the medical context and generating a field candidate set comprises:

[0038] The application scenario and disease type for creating a form are obtained from the medical context;

[0039] According to the application scene and the disease type, a basic template with the highest matching degree is screened out from a preset professional template library in a label matching manner;

[0040] Based on the medical ontology and the historical form data corresponding to the basic template, a field candidate set containing professional core fields is generated.

[0041] The second aspect of the application provides a medical form generation system, which comprises:

[0042] An instruction receiving module is configured to receive a form creation instruction and obtain a medical context in the instruction through natural language processing;

[0043] A template matching module is configured to screen a matched basic template from a professional template library based on the medical context and generate a field candidate set;

[0044] A field screening module is configured to screen the field candidate set through a preset collaborative filtering algorithm and in combination with medical business rules to obtain a recommended field list;

[0045] A form rendering module is configured to perform form rendering on the basic template according to the recommended field list, and initiate a query request to a clinical term service when rendering a medical term field in the recommended field list;

[0046] A term mapping module is configured to bind the medical term field to a standard clinical term in the clinical term service by using a multi-strategy mapping;

[0047] A verification configuration module is configured to deploy a multi-level collaborative verification mechanism for a user input of the basic template, wherein the multi-level collaborative verification mechanism comprises front-end instant verification based on medical rules and back-end deep verification based on data security and business logic.

[0048] The third aspect of the application provides a medical form generation device, which comprises a memory and at least one processor, the memory stores instructions, and the memory and the at least one processor are interconnected through a circuit;

[0049] The at least one processor invokes the instructions in the memory to enable the medical form generation device to perform the medical form generation method according to any one of the first aspect of the application.

[0050] The fourth aspect of the application provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the medical form generation method according to any one of the first aspect of the application.

[0051] Beneficial effects: the present application provides a medical form generation method, system and related equipment, the method comprises receiving form creation instruction, analyzing medical context in the instruction through natural language processing;Based on the medical context, the matching basic template is obtained from the specialist template library and the field candidate set is generated;The field candidate set is screened to obtain the recommended field list through the collaborative filtering algorithm combined with the medical business rules;According to the recommended field list, the basic template is rendered, and when the medical term field is rendered, the query request is initiated to the clinical term service;In the clinical term service, the medical term field is bound to the standard clinical term by using the multi-strategy mapping;The front-end instant verification and back-end deep verification mechanism are deployed for the user input of the basic template. The medical form generation method of the present application combines context awareness, dynamic term binding and multi-level verification to realize form generation, which improves the flexibility and security of form generation. BRIEF DESCRIPTION OF DRAWINGS

[0052] Figure 1 An embodiment schematic diagram of the main steps of the medical form generation method of the present application;

[0053] Figure 2 An embodiment schematic diagram of the medical form generation system of the present application;

[0054] Figure 3 An embodiment schematic diagram of the medical form generation equipment of the present application. DETAILED DESCRIPTION

[0055] The terms "first", "second", "third", "fourth" and the like in the description, claims, and drawings of the present application, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the use of these terms in the present description are to be construed to cover a general order so that "first" and "second" steps are conducted at the same time or sequentially, unless otherwise indicated by the context by express language meaning. Moreover, the terms "comprise" or "have", and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, product or apparatus that comprises a list of steps or elements not necessarily limited to those listed and can include additional steps or elements not expressly listed or inherent to such process, method, product or apparatus.

[0056] For the sake of understanding, the specific process of the embodiments of the present application is described below, please refer to Figure 1 The first aspect of the present application provides a medical form generation method, which can be configured in a system manner with a terminal device, the system can be built based on the formCreate framework, the core components include a medical field rendering engine, a clinical term service and a rule verification microservice cluster, and the medical form generation method comprises:

[0057] S100, receiving a form creation instruction, and analyzing a medical context in the instruction through natural language processing; in the present application, when a user starts to create a form, the application scenario and target disease are first identified through dialogue or metadata, and the process analyzes the input content of the user by using natural language processing (NLP) technology, and identifies the intention and entity by comparing complete information models in a domain knowledge base.

[0058] S200, screening a matched basic template from a specialized template library based on the medical context, and generating a field candidate set; in the present application, according to the medical context (including the scenario and the disease) identified in the previous step, a basic template (for example, a tumor clinical trial eCRF template) with high matching degree is screened from the specialized template library, and an initial field candidate set is constructed based on a medical ontology (Ontology) and historical form data. For example, for a lung cancer clinical trial, the candidate set will automatically contain key fields such as “ECOG score”, “tumor primary site”, “TNM stage”, etc.

[0059] That is, in an optional embodiment of step S200 of the present application, the screening of the matched basic template from the specialized template library based on the medical context and the generation of the field candidate set include: obtaining the application scenario and the disease type of creating the form from the medical context; according to the application scenario and the disease type, the basic template with the highest matching degree is screened from the pre-stored specialized template library through label matching; and based on the medical ontology and the historical form data corresponding to the basic template, a field candidate set containing specialized core fields is generated. In this embodiment, the similarity between the medical context (including the application scenario and the disease type) and the label of each template in the template library is calculated = number of matched words / total number of words in the context, and the field candidate set can be constructed by using a medical ontology reasoning engine to expand the associated field set from the basic template, extracting a high-frequency field set of the same medical scenario based on a historical form database, and obtaining the field candidate set through the union set of the associated field set and the historical form database.

[0060] S300, filtering the field candidate set by a preset collaborative filtering algorithm combined with medical business rules to obtain a recommended field list; in the present application, the collaborative filtering algorithm analyzes the field use frequency and combination rules of historical forms in the same scenario, if 90% of lung cancer eCRFs contain the "gene mutation detection result" field, the field will obtain a high recommendation weight; the built-in medical business rules (such as CDISC standard, diagnosis and treatment guidelines) will forcibly recommend the mandatory fields, for example, according to the CDISC standard, the adverse event (AE) related form must contain the "AE term", "occurrence time", "severity" and other fields, finally the algorithm combines the collaborative filtering result and the business rule to calculate the recommendation score of each candidate field, and presents the intelligent recommendation list according to the score.

[0061] In an optional embodiment of step S300 of the present application, the filtering of the field candidate set by a preset collaborative filtering algorithm combined with medical business rules to obtain a recommended field list comprises: based on the historical form database, the co-occurrence frequency of each field in the field candidate set under the same medical scenario is counted (the number of times the field appears in the historical form / the total number of historical forms in the same scenario); according to the co-occurrence frequency and the scene similarity correction coefficient (the value range is 0-1, which can be calculated according to the disease type matching degree of the current scene and the historical scene, and is used to dynamically adjust the reference value of historical data), the initial weight of each field in the field candidate set is calculated (the co-occurrence frequency x the scene similarity correction coefficient); the mandatory field set is extracted from the medical business rule library, and the rule weight is added to the mandatory field, wherein when the field belongs to the CDISC standard mandatory field, the rule weight is 1, and when the field does not belong to the CDISC standard mandatory field, the rule weight = rule priority (the degree of urgency of the field in clinical decision, the value range is [0, 10]) x rule library confidence coefficient (the coefficient is different for fields from different sources, for example, the value of international standard is 1, the value of national diagnosis and treatment guidelines is 0.9, the value of core journal clinical research is 0.7, etc.); the comprehensive weight obtained by adding the initial weight and the rule weight of each field in the field candidate set is calculated; the fields in the field candidate set are sorted in descending order according to the comprehensive weight, and the target fields ranked in the top N are filtered to generate a recommended field list. The recommended field list generated by the method of the present application has good scene adaptability.

[0062] S400, rendering the form according to the recommended field list, and when rendering the medical term field in the recommended field list, initiating a query request to the clinical term service; in the present application, when the field rendering engine processes a specific medical field (such as "adverse event description"), a query request is initiated to the clinical term service, and the context information of the field (such as the type of the form it belongs to, the department, etc.) is carried in the request.

[0063] S500, binding the medical term field with standard clinical terms in the clinical term service by using multi-strategy mapping; in this embodiment, the term service receives a request and then performs MedDRA coding mapping by using multi-strategy combination to ensure accuracy and fault tolerance: accurate matching is preferred; first, an accurate match with a preferred term (PT) in the MedDRA dictionary is attempted. Synonyms and fuzzy matching: if accurate matching fails, similar terms are found through a synonym library and a fuzzy matching algorithm (such as calculating a Levenshtein distance). For example, “eating is not possible”, the system can be mapped to the MedDRA PT “Decreased appetite”. Hierarchy verification: after matching to similar terms, the system checks the hierarchy above the similar term to ensure that the selected term accurately reflects the meaning of the reported language. For example, “intrauterine infection” may be directed to a more accurate “intrauterine infection” rather than “uterine infection”.

[0064] In an optional implementation of the first aspect of the present application, the binding of the medical term field with standard clinical terms in the clinical term service by using multi-strategy mapping comprises:

[0065] accurately matching the medical term field with a preferred term in a standard term library; the preferred term in the standard term library is stored in binding with the corresponding term field, and this step is to find out whether the standard term library has the medical term field, and if so, directly obtaining the preferred term bound with the medical term field;

[0066] when accurate matching fails, similar terms are found through a synonym library and a fuzzy matching algorithm; in this step, when the standard term library does not have the medical term field, the medical term field can be matched through synonyms or field matching in the standard term library based on a venshtein distance fuzzy algorithm to obtain similar terms.

[0067] After the similar terms are matched, context consistency verification is performed on the similar terms using the hierarchical structure (PT→HLT→HLGT→SOC) in the standard term library (the hierarchical structure can be simply understood as SOC corresponding to a department (such as internal medicine), HLGT is a specialty (such as the respiratory department), and HLT is a disease category (pneumonia), and PT is a specific diagnosis (bacterial pneumonia)). The similar term that is most consistent with the medical context of the medical term field is selected as the standard clinical term. In this step, for each similar term, the superior concept term of the similar term is obtained by tracing upwards along the hierarchical structure in the standard term library (for example, the similar term matched belongs to the HLT level, and the semantic relevance of the medical term field with the concept term of the HLGT level and the concept term of the SOC level is calculated); the semantic relevance score between each superior concept term and the medical term field is calculated; and the similar term with the highest semantic relevance score is selected as the final output standard clinical term. The term service returns the matched standard term to the rendering engine, and the rendering engine binds this information to the medical term field, such as drop-down options and automatic completion prompts.

[0068] S600, a multi-level collaborative verification mechanism is deployed for the user input of the base template, and the multi-level collaborative verification mechanism includes front-end instant verification based on medical rules and back-end deep verification based on data security and business logic.

[0069] The application constructs a multi-level and collaborative verification system, and the front end and the back end have different focuses, which together guarantee data quality and security. Table 1 shows the following.

[0070] Table 1 Multi-level collaborative verification system of the application

[0071]

[0072] In an optional embodiment of the step S600 of the present application, the user input deployment of the multi-level collaborative verification mechanism for the base template comprises: for the front-end instant verification, preset medical rules are compiled into lightweight client scripts (lightweight verification rules are compiled into JavaScript, which is executed in real time on the user side), which are triggered when the user inputs data, to realize real-time feedback and interception of data format, numerical range and simple logic; for the back-end deep verification, a distributed verification micro-service cluster is used to perform complex business logic verification (based on components such as clinical term service gateway and medical rule compilation engine) including cross-field data consistency, clinical term accuracy and drug compatibility contraindication after data submission; the front-end instant verification and the back-end deep verification maintain consistency of core rules through a shared verification rule library, forming a front-back collaborative verification system. Specifically, in the present application, the front-end verification intercepts most obvious errors and provides instant feedback; the back-end verification performs more thorough and secure data verification, and the rules of the two are kept consistent through a shared verification rule library, etc., to jointly form a solid data quality defense line.

[0073] In an optional embodiment of the first aspect of the present application, for the back-end deep verification, the complex business logic verification including cross-field data consistency, clinical term accuracy and drug compatibility contraindication performed by the distributed verification micro-service cluster after data submission comprises: when the back-end receives a batch verification task, the batch verification task is split into multiple sub-tasks according to a preset sharding key; the data volume of each sub-task is monitored, and the sub-tasks exceeding a threshold are subjected to secondary sharding processing; the sharded sub-tasks are distributed to the distributed verification micro-service cluster through an asynchronous message queue; a weighted least connection number algorithm is used in the verification nodes of the distributed verification micro-service to dynamically obtain each sub-task; term verification, logic rule verification and data consistency verification are performed in parallel by the distributed verification micro-service cluster; the verification results of the distributed verification micro-service cluster are merged, deduplicated and counted by an aggregator to generate a global verification report.

[0074] Specifically, to meet the verification needs of the massive medical data that may exist in the back-end, the present application designs an extensible distributed verification framework, the core working mechanism of which is as follows:

[0075] Task sharding strategy: when the back-end receives a batch verification task, the data is first split into multiple sub-tasks according to a preset sharding key (such as "research center number" or "patient ID hash value"). A dynamic sharding strategy is used to monitor the data volume of each shard, and a large data shard will be subjected to secondary splitting (such as using hash modulo) to avoid excessive load on a single node and ensure parallel processing efficiency.

[0076] Load balancing and task scheduling: the fragmented sub-tasks are put into an asynchronous message queue (such as RabbitMQ / Kafka). The check nodes (Workers) in the cluster consume tasks from the queue. The scheduling center uses dynamic load balancing algorithms such as weighted least connections to preferentially assign tasks to nodes with lighter current load and stronger processing capacity, to maximize resource utilization and processing speed.

[0077] Parallel verification and result aggregation: each check node processes its own data shard in parallel without contradiction, independently performing term verification, logical rule verification, data consistency verification, etc. The verification results (pass / fail and error details) of all nodes are unified into an aggregator (Aggregator). The aggregator merges, de-duplicates, and counts the results to generate a global verification report, including overall pass rate, error distribution, and other indicators.

[0078] In summary, the medical form dynamic generation method provided by the present application includes a context-driven form intelligent generation engine, a clinical term dynamic mapping system, and a multi-level collaborative verification architecture. The present application solves the three industry pain points of poor scene adaptability, lagging term standardization, and data quality defects in medical form generation by constructing an intelligent recommendation-term binding-multi-level verification collaborative technology chain.

[0079] Referring to Figure 2 , the second aspect of the present application provides a medical form generation system, which comprises:

[0080] An instruction receiving module 10 is configured to receive a form creation instruction and obtain a medical context in the instruction through natural language processing analysis;

[0081] A template matching module 20 is configured to filter a matched basic template from a specialty template library based on the medical context and generate a field candidate set;

[0082] A field screening module 30 is configured to screen the field candidate set by a preset collaborative filtering algorithm and in combination with medical business rules to obtain a recommended field list;

[0083] A form rendering module 40 is configured to perform form rendering on the basic template according to the recommended field list, and initiate a query request to a clinical term service when rendering a medical term field in the recommended field list;

[0084] A term mapping module 50 is configured to bind the medical term field to a standard clinical term by using a multi-strategy mapping in the clinical term service;

[0085] The check configuration module 60 is configured to deploy a multi-level collaborative check mechanism for the user input of the basic template, and the multi-level collaborative check mechanism comprises front-end instant check based on medical rules and back-end deep check based on data security and business logic.

[0086] In an optional implementation of the second aspect of the present application, the field screening module comprises:

[0087] The co-occurrence frequency statistical unit is configured to statistically count the co-occurrence frequency of each field in the field candidate set in the same medical scenario based on the historical form database.

[0088] The initial weight calculation unit is configured to calculate the initial weight of each field in the field candidate set according to the co-occurrence frequency and a scenario similarity correction coefficient.

[0089] The rule weight calculation unit is configured to extract a set of mandatory associated fields from a medical business rule library and attach a rule weight to the mandatory fields, wherein when a field belongs to a CDISC standard mandatory field, the rule weight is 1, and when a field does not belong to a CDISC standard mandatory field, the rule weight = rule priority × rule library confidence coefficient.

[0090] The comprehensive weight calculation unit is configured to calculate the comprehensive weight of each field in the field candidate set by adding the initial weight and the rule weight.

[0091] The field screening unit is configured to sort each field in the field candidate set in descending order according to the comprehensive weight, and screen target fields ranked in the top N to generate a recommended field list.

[0092] In an optional implementation of the second aspect of the present application, the term mapping module comprises:

[0093] The accurate matching unit is configured to accurately match the medical term field with a preferred term in a standard term library.

[0094] The fuzzy matching unit is configured to, when the accurate matching fails, find a similar term through a synonym library and a fuzzy matching algorithm.

[0095] The hierarchical check unit is configured to, after matching to the similar term, perform context consistency check on the similar term by using a hierarchical structure in the standard term library, and select the similar term that is most consistent with the medical context of the medical term field as a standard clinical term.

[0096] In an optional implementation of the second aspect of the present application, the hierarchical check unit comprises:

[0097] The upper term tracing subunit is configured to trace upwards along a hierarchy in the standard term library for each of the similar terms to obtain a superior concept term of the similar term;

[0098] The correlation calculation subunit is configured to calculate a semantic correlation score between each of the superior concept terms and the medical term field;

[0099] The standard term output subunit is configured to select the similar term with the highest semantic correlation score as the final output standard clinical term.

[0100] In an optional implementation of the second aspect of the present application, the verification configuration module comprises:

[0101] The front-end configuration unit is configured to compile preset medical rules into a lightweight client script for the front-end real-time verification, and trigger the script when a user inputs data to realize real-time feedback and interception of data format, numerical range and simple logic;

[0102] The back-end configuration unit is configured to perform complex business logic verification including cross-field data consistency, clinical term accuracy and drug compatibility contraindication through a distributed verification micro-service cluster for the back-end deep verification after data submission;

[0103] The coordination configuration unit is configured to keep the consistency of core rules of the front-end real-time verification and the back-end deep verification through a shared verification rule library to form a front-back coordinated verification system.

[0104] In an optional implementation of the second aspect of the present application, the back-end configuration unit comprises:

[0105] The batch task splitting subunit is configured to split the batch verification task into a plurality of subtasks according to a preset sharding key when the back-end receives the batch verification task;

[0106] The secondary sharding subunit is configured to monitor the data volume of each of the subtasks and perform secondary sharding processing on the subtasks exceeding a threshold value;

[0107] The task asynchronous allocation subunit is configured to allocate the sharded subtasks to the distributed verification micro-service cluster through an asynchronous message queue;

[0108] The task dynamic acquisition subunit is configured to dynamically acquire each of the subtasks in the verification node of the distributed verification micro-service by using a weighted least connection number algorithm;

[0109] The cluster parallel verification subunit is configured to perform term verification, logic rule verification and data consistency verification in parallel through the distributed verification micro-service cluster;

[0110] The check result aggregation subunit is configured to merge, deduplicate and count the check results of the distributed check micro-service cluster by an aggregator to generate a global check report.

[0111] In an optional implementation of the second aspect of the present application, the template matching module comprises:

[0112] The context reading unit is configured to obtain an application scenario and a disease type for creating a form from the medical context.

[0113] The template screening unit is configured to screen out a basic template with the highest matching degree from a preset specialized template library by label matching according to the application scenario and the disease type.

[0114] The field set generating unit is configured to generate a field candidate set containing specialized core fields based on a medical ontology corresponding to the basic template and historical form data.

[0115] Figure 3 is a structural schematic diagram of a medical form generation device provided by an embodiment of the present application. The medical form generation device can have great differences due to different configurations or performances, and can include one or more processors 60 (central processing units, CPU) (for example, one or more processors) and a memory 70, one or more storage media 80 (for example, one or more mass storage devices) storing application programs or data. The memory and the storage medium can be temporary storage or persistent storage. The programs stored in the storage medium can include one or more modules (not shown in the figure), and each module can include a series of instruction operations in the medical form generation device. Further, the processor can be configured to communicate with the storage medium and execute a series of instruction operations in the storage medium on the medical form generation device.

[0116] The medical form generation device can further include one or more power supplies 90, one or more wired or wireless network interfaces 100, one or more input and output interfaces 110, and / or one or more operating systems, such as Windows Serve, Mac OS X, Unix, Linux, FreeBSD, etc. Those skilled in the art can understand that, Figure 3 The structure of the medical form generation device shown does not constitute a limitation on the medical form generation device, and can include more or fewer components than shown, or combine certain components, or different component arrangements.

[0117] The application further provides a computer readable storage medium, which can be a nonvolatile computer readable storage medium or a volatile computer readable storage medium, and the computer readable storage medium stores instructions, and the instructions make a computer execute the steps of the medical form generation method when the instructions are run on the computer.

[0118] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described system or unit can refer to the corresponding processes in the foregoing method embodiments, and will not be described here.

[0119] The integrated unit, if realized in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the application or the whole or part of the technical solutions that make essential contributions to the prior art can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for making a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the method described in each embodiment of the application. The foregoing storage medium includes a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various program code storage media.

[0120] The above-described embodiments are only used to illustrate the technical solutions of the application, rather than limit the application; although the application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the application.

Claims

1. A method of generating a medical form, characterized by, The method comprises the following steps: receiving a form creation instruction, and analyzing a medical context in the instruction through natural language processing; screening a matched basic template from a specialty template library based on the medical context, and generating a field candidate set; screening the field candidate set through a preset collaborative filtering algorithm and in combination with medical business rules to obtain a recommended field list; rendering the basic template according to the recommended field list, and initiating a query request to a clinical term service when a medical term field in the recommended field list is rendered; binding the medical term field to a standard clinical term in the clinical term service through multi-strategy mapping; deploying a multi-level collaborative verification mechanism for a user input part of the basic template, wherein the multi-level collaborative verification mechanism comprises front-end instant verification based on medical rules and back-end deep verification based on data security and business logic; the step of binding the medical term field to the standard clinical term in the clinical term service through multi-strategy mapping comprises: performing exact matching of the medical term field with a preferred term in a standard term library; when the exact matching fails, finding a similar term through a synonym library and a fuzzy matching algorithm; after the similar term is matched, performing context consistency verification on the similar term by using a hierarchical structure in the standard term library, and selecting the similar term that best matches a medical context of the medical term field as a standard clinical term; the step of deploying the multi-level collaborative verification mechanism for the user input part of the basic template comprises: for the front-end instant verification, compiling preset medical rules into a lightweight client script, and triggering the script when user data is inputted, so as to realize real-time feedback and interception of data format, numerical range and simple logic; for the back-end deep verification, performing complex business logic verification including cross-field data consistency, clinical term accuracy and drug compatibility contraindication through a distributed verification micro-service cluster after data is submitted; keeping consistency of core rules of the front-end instant verification and the back-end deep verification through a shared verification rule library, and constituting a front-back collaborative verification system.

2. The medical table form generation method according to claim 1, wherein the step of screening the field candidate set through the preset collaborative filtering algorithm and in combination with the medical business rules to obtain the recommended field list comprises: based on a historical form database, counting co-occurrence frequencies of each field in the field candidate set under the same medical scenario; calculating initial weights of each field in the field candidate set according to the co-occurrence frequencies and a scenario similarity correction coefficient; extracting a set of mandatory associated fields from a medical business rule library, and adding a rule weight to the mandatory fields, wherein when a field belongs to a CDISC standard mandatory field, the rule weight is 1, and when a field does not belong to the CDISC standard mandatory field, the rule weight = rule priority × rule library confidence coefficient; calculating a comprehensive weight of each field in the field candidate set by adding the initial weight and the rule weight; sorting each field in the field candidate set in descending order according to the comprehensive weight, and screening target fields ranked in the top N to generate a recommended field list.

3. The medical table generation method according to claim 1, wherein, After the matching to the similar terms, context consistency verification is performed on the similar terms by using the hierarchical structure in the standard terminology library, including: For each of the similar terms, a superior concept term of the similar term is obtained by tracing upwards along the hierarchical structure in the standard terminology library; A semantic correlation score between each of the superior concept term and the medical term field is calculated; The similar term with the highest semantic correlation score is selected as the final output standard clinical term.

4. The medical table form generation method of claim 1, wherein, For the backend deep verification, complex business logic verification including cross-field data consistency, clinical term accuracy and drug compatibility contraindication is performed after data submission by a distributed verification micro-service cluster, including: When the backend receives a batch verification task, the batch verification task is split into multiple sub-tasks according to a pre-set sharding key; The data volume of each of the sub-tasks is monitored, and secondary sharding processing is performed on the sub-tasks that exceed a threshold; The sharded sub-tasks are distributed to the distributed verification micro-service cluster through an asynchronous message queue; A weighted least connection number algorithm is used in the verification nodes of the distributed verification micro-service to dynamically obtain each of the sub-tasks; Term verification, logic rule verification and data consistency verification are performed in parallel by the distributed verification micro-service cluster; The verification results of the distributed verification micro-service cluster are merged, de-duplicated and counted by an aggregator to generate a global verification report.

5. The method of claim 1, wherein, The matching basic template is selected from a specialty template library based on the medical context, and a field candidate set is generated, including: The application scenario and disease type of creating a form are obtained from the medical context; The basic template with the highest matching degree is selected from the pre-set specialty template library by label matching according to the application scenario and disease type; Based on the medical ontology and historical form data corresponding to the basic template, a field candidate set containing specialty core fields is generated.

6. A medical form generation system characterized by, The medical form generation system includes: An instruction receiving module configured to receive a form creation instruction and obtain a medical context in the instruction by natural language processing; A template matching module configured to select a matching basic template from a specialty template library based on the medical context and generate a field candidate set; A field screening module configured to screen the field candidate set by a pre-set collaborative filtering algorithm and in combination with medical business rules to obtain a recommended field list; A form rendering module configured to perform form rendering on the basic template according to the recommended field list, and initiate a query request to a clinical term service when rendering a medical term field in the recommended field list; A term mapping module configured to bind the medical term field to a standard clinical term by using a multi-strategy mapping in the clinical term service; A verification configuration module configured to deploy a multi-level collaborative verification mechanism for user input of the basic template, including front-end instant verification based on medical rules and backend deep verification based on data security and business logic; The term mapping module includes: The precise matching unit is configured to perform precise matching between the medical term field and a preferred term in a standard term library; The fuzzy matching unit is configured to, when the precise matching fails, find a similar term through a synonym library and a fuzzy matching algorithm; The hierarchical verification unit is configured to, after matching to the similar term, perform context consistency verification on the similar term by using a hierarchical structure in the standard term library, and select the similar term that is most consistent with a medical context of the medical term field as a standard clinical term; The verification configuration module comprises: The front-end configuration unit is configured to, for the front-end instant verification, compile a preset medical rule into a lightweight client script, and trigger the script when a user inputs data, so as to realize real-time feedback and interception of data format, numerical range and simple logic; The back-end configuration unit is configured to, for the back-end deep verification, perform complex business logic verification including cross-field data consistency, clinical term accuracy and drug compatibility contraindication through a distributed verification micro-service cluster after data submission; The collaborative configuration unit is configured to keep consistency of core rules between the front-end instant verification and the back-end deep verification through a shared verification rule library, and constitute a front-back collaborative verification system.

7. A medical form generation apparatus characterized by comprising: The medical form generation device comprises a memory and at least one processor, the memory stores instructions, and the memory and the at least one processor are interconnected through a circuit; The at least one processor invokes the instructions in the memory, so that the medical form generation device performs the medical form generation method according to any one of claims 1-5.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to realize the medical form generation method according to any one of claims 1-5.

Images