Method and apparatus for generating programming language based on clinical DVP forms

Abstract

This application relates to the field of artificial intelligence, and particularly to methods, apparatus, media, electronic devices, and computer program products for generating programming languages ​​from clinical Data Verification (DVP) forms. By automatically reading clinical DVP forms and generating corresponding program code, this application significantly reduces the time and cost of manual programming. This not only improves the efficiency of data validation but also reduces data quality issues caused by human error. Furthermore, this application ensures comprehensive and accurate validation of clinical trial data. This comprehensive validation mechanism improves data quality and reliability, providing strong support for the smooth progress of clinical research.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence, and in particular to methods, apparatus, media, electronic devices, and computer program products for generating programming languages ​​from clinical DVP forms. Background Technology

[0002] A Data Verification Plan (DVP) is a crucial component of clinical trial data management. It details the rules and procedures for data verification to ensure the authenticity, completeness, accuracy, and reliability of clinical trial data. Clinical DVP forms typically contain detailed rules for validating data points.

[0003] To improve the efficiency of data verification, it is necessary to achieve automatic conversion from clinical DVP tables to program code, thereby reducing manual intervention and error rates. However, clinical trial data often involves multiple variables and complex logical relationships, and different clinical trials may have different clinical DVP tables. Therefore, accurately converting the rules in clinical DVP tables into executable program code is a technical challenge. Summary of the Invention

[0004] This application provides methods, apparatus, media, electronic devices, and computer program products for generating programming languages ​​based on clinical DVP forms.

[0005] In a first aspect, embodiments of this application provide a method for generating a programming language based on a clinical DVP table, for use in an electronic device, the method comprising:

[0006] The table parsing step utilizes a large model to parse the clinical DVP table in order to identify and extract the validation rules in the clinical DVP table;

[0007] The rule conversion step utilizes the mapping relationship between the verification rules and the syntax and logical structure of the target programming language to convert the verification rules into logical code segments of the target programming language;

[0008] The code generation step involves selecting a code template for the target programming language and filling the code template with the logical code segment to generate program code.

[0009] Secondly, embodiments of this application provide an apparatus for generating a programming language based on a clinical DVP table, the apparatus comprising:

[0010] The table parsing unit uses a large model to parse the clinical DVP table in order to identify and extract the validation rules in the clinical DVP table;

[0011] The rule conversion unit uses the mapping relationship between the verification rules and the syntax and logical structure of the target programming language to convert the verification rules into logical code segments of the target programming language;

[0012] The code generation unit selects a code template for the target programming language and fills the logical code segment into the code template to generate program code.

[0013] Thirdly, embodiments of this application provide a computer-readable storage medium storing instructions that, when executed by a computer, cause the computer to perform the method for generating a programming language from a clinical DVP table as described in the first aspect above.

[0014] Fourthly, embodiments of this application provide an electronic device including one or more processors and one or more memories; the one or more memories store one or more programs, which, when executed by the one or more processors, cause the electronic device to perform the method for generating a programming language from a clinical DVP table as described in the first aspect above.

[0015] Fifthly, embodiments of this application provide a computer program product including computer-executable instructions that are executed by a processor to implement the method for generating a programming language from a clinical DVP table as described in the first aspect above.

[0016] This application significantly reduces the time and cost of manual programming by automatically reading clinical data validation forms and generating corresponding program code. This not only improves the efficiency of data validation but also reduces data quality issues caused by human error. Furthermore, this application ensures comprehensive and accurate validation of clinical trial data. This comprehensive validation mechanism improves data quality and reliability, providing strong support for the smooth progress of clinical research. Attached Figure Description

[0017] Figure 1 According to an embodiment of this application, a flowchart of a method for generating a programming language based on a clinical DVP form is shown;

[0018] Figure 2 According to an embodiment of this application, a schematic diagram of an apparatus for generating a programming language based on a clinical DVP form is shown;

[0019] Figure 3 According to an embodiment of this application, a block diagram of an electronic device is shown. Detailed Implementation

[0020] The illustrative embodiments of this application include, but are not limited to, methods, apparatus, media, electronic devices, and computer program products for generating programming languages ​​from clinical DVP forms.

[0021] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0022] Figure 1 This application illustrates a method for generating a programming language from a clinical DVP table, as described in an embodiment of the present application, for use in... Figure 3 The electronic device shown.

[0023] like Figure 1 As shown, in the table parsing step S11, the large model is used to parse the clinical DVP table in order to identify and extract the validation rules in the clinical DVP table.

[0024] Specifically, a user interface can be provided to allow users to upload or input clinical DVP forms. The clinical DVP forms can contain detailed rules for data validation, such as field names, data types, and validation conditions. Furthermore, the received clinical DVP forms can be preprocessed, such as denoising and formatting, to facilitate subsequent parsing.

[0025] Furthermore, the preprocessed clinical DVP table can be converted into a graph structure, where cells in the clinical DVP table are nodes, and relationships between cells (such as row / column relationships, logical relationships, etc.) are edges. Graph Convolutional Networks (GCNs) can be used to extract features from the graph structure to obtain node feature vectors and edge feature vectors. This application uses a multi-layer GCN to extract global structural features and local relationship features of the table, thereby capturing complex relationships and contextual information within the table.

[0026] Specifically, the formula for GCN is: Among them, H (l) It is the feature vector of the node in the l-th layer. It is an adjacency matrix. It is a degree matrix, W (l) σ is a learnable parameter, and σ is the activation function.

[0027] And specifically, for cell C i C j Their node feature vectors v i ,v j Each includes cell C i C j The text content, data type, and location information, and the edge feature vector E between them. ij =σ(W e ·[vi ;v j ]+b e ), where σ is the activation function, W e and b e These are learnable parameters, [v] i ;v j ] is the node feature vector v i ,v j splicing.

[0028] Furthermore, a pre-trained language model can be used to semantically embed the text content of the cells corresponding to the nodes whose feature vectors correspond to the nodes, thereby obtaining a semantic embedding vector. Specifically, the language model includes the BERT model, and the semantic embedding vector S... i =BERT(T) i ), where T i It is cell C i The text content. This application uses semantic embedding to extract rule descriptions, conditions, and actions.

[0029] Furthermore, validation rules can be generated based on semantic embedding vectors. Specifically, the validation rules include the range check validation rule Rulek:IFS. i ∈[LowerBound, UpperBound]THENValidELSEInvalid, where Rulek is the k-th validation rule, S i It is a semantic embedding vector, where LowerBound is the lower bound of the range and UpperBound is the upper bound of the range.

[0030] Furthermore, the validation rules can be dynamically optimized based on the following loss function. Where Rulek is the k-th validation rule, GTk is the k-th true rule, λ is the regularization parameter, and ||W||2 is the L2 norm of the language model parameters. This application utilizes a deep learning model to dynamically optimize the accuracy of rule extraction and parsing, adapting to different DVP table formats.

[0031] In addition, a user feedback mechanism can be introduced to dynamically optimize the verification rules based on user feedback, thereby supporting users to correct and optimize the extracted rules and improve the intelligence level of the system.

[0032] Continue as Figure 1 As shown, in rule conversion step S12, the verification rules are converted into logical code segments of the target programming language by utilizing the mapping relationship between the verification rules and the syntax and logical structure of the target programming language. The logical code segment can be an internal data structure or an intermediate representation, facilitating subsequent code generation.

[0033] The validation rules parsed from the clinical DVP forms represent a natural logic language used for data validation. This natural logic language has a strong mapping relationship with programming languages ​​in terms of syntax and logical structure. Therefore, this mapping relationship can be pre-defined, automatically converting the validation rules into logical code segments in a programming language. The selection of the target programming language can also be done through the user interface described above. This application does not depend on a specific programming language but can design corresponding mapping relationships for each supported programming language, thereby achieving multi-language support and enabling wide application in different data processing and analysis environments, enhancing its versatility and flexibility.

[0034] Continue as Figure 1 As shown, in code generation step S13, a code template for the target programming language is selected, and logical code segments are filled into the code template to generate program code.

[0035] Similarly, this application can design corresponding code templates for each supported programming language. After the logic code segments are filled into the corresponding code templates, the generated program code can run correctly in the target programming language and is available for users to view on the user interface. Since the generated program code conforms to standard programming language specifications, it can be easily deployed and run on different operating systems and platforms without the need for complex adaptation work.

[0036] Furthermore, when the validation rules in the clinical DVP form change, these changes can be automatically detected, and the form parsing step S11, rule conversion step S12, and code generation step S13 can be executed again to update the generated program code accordingly. This application introduces an automated update mechanism, which simplifies the rule update process and reduces maintenance costs.

[0037] Figure 2 An apparatus for generating a programming language based on a clinical DVP form, according to an embodiment of this application, is shown.

[0038] like Figure 2 As shown, the table parsing unit 201 uses a large model to parse the clinical DVP table to identify and extract the validation rules in the clinical DVP table; the rule conversion unit 202 uses the mapping relationship between the validation rules and the syntax and logical structure of the target programming language to convert the validation rules into logical code segments of the target programming language; the code generation unit 203 selects a code template of the target programming language and fills the logical code segments into the code template to generate program code.

[0039] It is understandable that the table parsing unit 201, the rule conversion unit 202, and the code generation unit 203 can be... Figure 3The processor 302 in the electronic device has the functions of these modules or units to implement them.

[0040] This application also provides a computer-readable storage medium storing instructions that, when executed by a computer, cause the computer to perform... Figure 1 The method shown.

[0041] This application also provides a computer program product, including computer-executable instructions that are executed by a processor to perform [the program]. Figure 1 The method shown.

[0042] Figure 3 An electronic device according to an embodiment of this application is shown.

[0043] like Figure 3 As shown, the electronic device may include one or more processors 302, system control logic 308 connected to at least one of the processors 302, system memory 304 connected to the system control logic 308, non-volatile memory (NVM) 306 connected to the system control logic 308, and communication interface 310 connected to the system control logic 308.

[0044] Processor 302 may include one or more single-core or multi-core processors. Processor 302 may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, baseband processors, etc.). In embodiments herein, processor 302 may be configured to perform... Figure 1 The method shown.

[0045] In some embodiments, system control logic 308 may include any suitable interface controller to provide any suitable interface to at least one of the processors 302 and / or any suitable device or component communicating with system control logic 308.

[0046] In some embodiments, system control logic 308 may include one or more memory controllers to provide an interface to system memory 304. System memory 304 may be used to load and store data and / or instructions. In some embodiments, system memory 304 of an electronic device may include any suitable volatile memory, such as suitable dynamic random access memory (DRAM).

[0047] NVM / Memory 306 may include one or more tangible, non-transitory computer-readable media for storing data and / or instructions. In some embodiments, NVM / Memory 306 may include any suitable non-volatile memory such as flash memory and / or any suitable non-volatile storage device, such as at least one of HDD (Hard Disk Drive), CD (Compact Disc) drive, and DVD (Digital Versatile Disc) drive.

[0048] NVM / Storage 306 may include a portion of storage resources mounted on an electronic device, or it may be accessible by the device but is not necessarily part of the device. For example, NVM / Storage 306 may be accessed over a network via communication interface 310.

[0049] Specifically, system memory 304 and NVM / memory 306 may each include a temporary copy and a permanent copy of instruction 320. Instruction 320 may include instructions that, when executed by at least one of processors 302, cause the electronic device to perform... Figure 1 The instructions for the method shown are as follows. In some embodiments, the instructions 320, hardware, firmware, and / or their software components may additionally / alternatively be located in the system control logic 308, the communication interface 310, and / or the processor 302.

[0050] The communication interface 310 may include a transceiver for providing a radio interface to the electronic device, thereby enabling communication with any other suitable device (such as a front-end module, antenna, etc.) via one or more networks. In some embodiments, the communication interface 310 may be integrated into other components of the electronic device. For example, the communication interface 310 may be integrated into at least one of a processor 302, system memory 304, NVM / memory 306, and firmware device (not shown) with instructions, which, when at least one of the processors 302 executes the instructions, enable the electronic device to implement… Figure 1 The method shown.

[0051] The communication interface 310 may further include any suitable hardware and / or firmware to provide a multiple-input multiple-output radio interface. For example, the communication interface 310 may be a network adapter, a wireless network adapter, a telephone modem, and / or a wireless modem.

[0052] In one embodiment, at least one of the processors 302 may be packaged together with the logic of one or more controllers for system control logic 308 to form a system-in-package (SiP). In another embodiment, at least one of the processors 302 may be integrated on the same die with the logic of one or more controllers for system control logic 308 to form a system-on-a-chip (SoC).

[0053] The electronic device may further include an input / output (I / O) device 312. The I / O device 312 may include a user interface enabling a user to interact with the electronic device; the peripheral component interface is designed to allow peripheral components to also interact with the electronic device. In some embodiments, the electronic device may also include sensors for determining at least one type of environmental condition and location information related to the electronic device.

[0054] In some embodiments, the user interface may include, but is not limited to, a display (e.g., a liquid crystal display, a touch screen display, etc.), a speaker, a microphone, one or more cameras (e.g., a still image camera and / or a video camera), a flashlight (e.g., a light-emitting diode flash), and a keyboard.

[0055] In some embodiments, the peripheral component interface may include, but is not limited to, a non-volatile memory port, an audio jack, and a power interface.

[0056] In some embodiments, the sensor may include, but is not limited to, a gyroscope sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of or interact with the communication interface 310 to communicate with components of the positioning network (e.g., Global Positioning System (GPS) satellites).

[0057] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0058] Program code can be applied to input instructions to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0059] The program code can be implemented using a high-level procedural language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used when needed. In fact, the mechanisms described in this paper are not limited to any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0060] One or more aspects of at least one embodiment can be implemented by representational instructions stored on a computer-readable storage medium, the instructions representing various logics in a processor, which, when read by a machine, cause the machine to create logic for performing the techniques described herein. These representations, referred to as “IP cores,” can be stored on a tangible computer-readable storage medium and provided to multiple customers or production facilities for loading into manufacturing machines that actually manufacture the logic or processor.

[0061] Unless the context otherwise requires, the terms “contains,” “has,” and “includes” are synonyms. The phrase “A / B” means “A or B.” The phrase “A and / or B” means “(A and B) or (A or B).”

[0062] As used herein, the terms “module” or “unit” may refer to, be, or include: application-specific integrated circuits (ASICs), electronic circuits, (shared, dedicated, or group) processors and / or memories that execute one or more software or firmware programs, combinational logic circuits, and / or other suitable components that provide the described functionality.

[0063] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored thereon on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed via a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism, but not limited to, for storing or transmitting information in a machine-readable (e.g., computer-readable) form, such as floppy disks, optical disks, read-only memory (CD-ROM), magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information over the Internet via electrical, optical, acoustic, or other forms of propagation signals (e.g., carrier waves, infrared signals, digital signals, etc.). Therefore, machine-readable media include any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0064] In the accompanying drawings, certain structural or methodological features are shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be necessary. In some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. Furthermore, the inclusion of structural or methodological features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may be omitted or may be combined with other features.

[0065] It should be understood that although terms such as "first," "second," etc., may be used herein to describe various units or data, these units or data should not be limited by these terms. These terms are used merely to distinguish one feature from another. For example, without departing from the scope of the exemplary embodiments, a first feature may be referred to as a second feature, and similarly, a second feature may be referred to as a first feature.

[0066] It should be noted that in this specification, similar reference numerals and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

Claims

1. A method for generating a programming language based on a clinical DVP form, for use in electronic devices, characterized in that, The method includes: The table parsing step utilizes a large model to parse the clinical DVP table in order to identify and extract the validation rules in the clinical DVP table; The rule conversion step utilizes the mapping relationship between the verification rules and the syntax and logical structure of the target programming language to convert the verification rules into logical code segments of the target programming language; The code generation step involves selecting a code template for the target programming language and filling the code template with the logical code segment to generate program code. Specifically, the large model is used to parse the clinical DVP table to identify and extract the validation rules from the clinical DVP table, including: The clinical DVP table is converted into a graph structure, where the cells in the clinical DVP table are nodes and the relationships between cells are edges. The graph structure is used to extract features to obtain the node feature vectors of the nodes and the edge feature vectors of the edges. A pre-trained language model is used to perform semantic embedding on the text content of the cell corresponding to the node corresponding to the node feature vector, so as to obtain a semantic embedding vector. The verification rules are generated based on the semantic embedding vector.

2. The method according to claim 1, characterized in that, For cells Their node feature vectors Each includes the cells The text content, data type, and location information, and the edge feature vectors between them. ,in, It is an activation function. and These are learnable parameters. It is the node feature vector splicing.

3. The method according to claim 2, characterized in that, The language model includes the BERT model, and the semantic embedding vectors ,in, It is a cell The text content.

4. The method according to claim 3, characterized in that, The verification rules include range check verification rules. ,in, It is the kth verification rule. It is the semantic embedding vector. It is the lower limit of the range. It is the upper limit of the range.

5. The method according to claim 4, characterized in that, The verification rules are dynamically optimized based on the following loss function. ， in, It is the kth verification rule. It is the kth real rule. It is a regularization parameter. It is the L2 norm of the language model parameters.

6. An apparatus for generating a programming language based on a clinical DVP form, characterized in that, The device includes: The table parsing unit uses a large model to parse the clinical DVP table in order to identify and extract the validation rules in the clinical DVP table; The rule conversion unit uses the mapping relationship between the verification rules and the syntax and logical structure of the target programming language to convert the verification rules into logical code segments of the target programming language; The code generation unit selects a code template for the target programming language and fills the logical code segment into the code template to generate program code; Specifically, the large model is used to parse the clinical DVP table to identify and extract the validation rules from the clinical DVP table, including: The clinical DVP table is converted into a graph structure, where the cells in the clinical DVP table are nodes and the relationships between cells are edges. The graph structure is used to extract features to obtain the node feature vectors of the nodes and the edge feature vectors of the edges. A pre-trained language model is used to perform semantic embedding on the text content of the cell corresponding to the node corresponding to the node feature vector, so as to obtain a semantic embedding vector. The verification rules are generated based on the semantic embedding vector.

7. A computer-readable storage medium, characterized in that, The storage medium stores instructions that, when executed by a computer, cause the computer to perform the method of generating a programming language from a clinical DVP table according to any one of claims 1 to 5.

8. An electronic device, characterized in that, It includes one or more processors and one or more memories; the one or more memories store one or more programs that, when executed by the one or more processors, cause the electronic device to perform the method of generating a programming language from a clinical DVP table according to any one of claims 1 to 5.

9. A computer program product, characterized in that, It includes computer-executable instructions that are executed by a processor to implement a method for generating a programming language from a clinical DVP table according to any one of claims 1 to 5.

Images