WO2025037194A1 - Transcription of health records to database - Google Patents

Abstract

Disclosed are methods, non-transitory computer-readable medium and devices useful for transcribing data from electronic health records to a database. For example, in some preferred embodiments the data in the electronic health record is at least partially gathered during a clinical trial and the database is a clinical trial database.

Description

TRANSCRIPTION OF HEALTH RECORDS TO DATABASE

RELATED APPLICATION

The present application gains priority from US Provisional Patent Applications US 63/532,681 filed 15 August 2023 and US 63/572,946 filed 2 April 2024 both which are included by reference as if fully set-forth herein.

FIELD AND BACKGROUND OF THE INVENTION

The invention, in some embodiments, relates to the field of electronic data capture (EDC), and more particularly, but not exclusively, to methods and/or device for transcribing data from electronic health records to a database. For example, in some preferred embodiments the data in the electronic health record is at least partially gathered during a clinical trial and the database is a clinical trial database.

Clinical trials study the effect of a medical intervention on human subjects. Typical clinical trials study the safety, effects and efficacy of an intervention such as a novel medical device or a novel medicament such as a novel active pharmaceutical ingredient, composition, dosage form and dosage.

Generally, a sponsor, for example a developer of an intervention, designs a clinical trial which defines the profile of the subjects to be tested (e.g., age, medical condition), how and for how long the intervention is performed and what clinical data of interest are to be monitored during the trial. The sponsor (independently or with the help of a CRO, clinical research organization) also establishes a clinical trial database that includes fields that correspond to the data of interest.

The sponsor (directly, or indirectly by a CRO hired by the sponsor) out-sources the actual performance of the clinical trial to one or more sites such as hospitals and clinics. During the performance of the clinical trial, the sites gather data about the subject from, for example a questionnaire filled out by a subject, historical medical files of a subject, the results of examination by a medical professional and the results of tests such as chemical tests (blood, urine). The data gathered includes data for internal use by the site as well as the data of interest for the clinical trial. These data are recorded in physical format (e.g., paper medical file) and/or in an electronic health record (EHR) of a subject.

At any one or multiple stages of a clinical trial, the sites provide the electronic health records to the sponsor (directly or indirectly through a CRO). The data of interest for the clinical trial are transcribed from the sites' electronic health records into the sponsor's clinical trial database. The data in the clinical trial database is subsequently analyzed to draw conclusions about the intervention.

In reality, transcription of data of interest from electronic health records to a clinical trial database is not straightforward due to the variability in identifiers for any given parameter. A given parameter typically has multiple different identifiers, that is to say names, abbreviations and/or units. Which one of the multiple identifiers is used for a given parameter varies in different geographical locations, different sites and even in different wards of the same site.

Additionally, misspellings, typographical errors, unconventional or unusual terminology and or different units of measure make transcription of EHRs to clinical trial databases challenging.

Particularly problematic are pharmaceuticals as these have multiple names (generic, chemical and trade names) and different codes from different code systems.

Due to these reasons, transcription is typically performed manually by relatively skilled personnel, for example medical students or nurses. Such manual transcription is timeconsuming and expensive.

It would be useful to have methods and/or device for transcribing data of interest from electronic health records gathered during a clinical trial to a clinical trial database.

SUMMARY OF THE INVENTION

The invention, in some embodiments thereof, relates to methods and/or device for transcribing data from electronic health records to a database. In some preferred embodiments the data in the electronic health record is at least partially gathered during a clinical trial and the database is a clinical trial database.

According to an aspect of some embodiments of the teachings herein, there is provided a method of transcribing data from an electronic health record to a database, comprising: a. establishing a database implemented using software running on suitable hardware, the database having patient records, each patient record having data fields, each data fields corresponding to a specified medical data type having a specified format; b. receiving an electronic health record (EHR) generated by a site, the EHR including medical data associated with a specific patient, each the medical data including a data type identifier and a value; c. subsequent to 'b', providing the received EHR as input to a large language model (LLM) with instructions to identify to which data field in the database is presumed that a data type identifier of the EHR most likely corresponds and with what probability; d. subsequent to 'c', receiving results of the identification from the LLM and, on a display screen, displaying the medical data from the EHR including the data type identifier and the value together with the identified presumptive corresponding data field in the database, a presumptive value for entry to the database that is equivalent to the EHR value and the probability; e. subsequent to 'd', accepting from an input device at least one instruction selected from the group of instructions consisting of: i. that the presumptive corresponding field of the database is correctly identified as corresponding to the data type identifier of the medical data from the EHR and that the presumptive value for entry into the database is correct, and therefore the instruction is to populate a presumptive corresponding data field of a patient record corresponding to the specific patient of the database with the presumptive value, ii. that the presumptive corresponding field in the database is incorrectly identified as corresponding to the data type identifier of the medical data from the EHR and therefore the instruction is not to populate a presumptive corresponding data field of a patient record corresponding to the specific patient of the database with the presumptive value; and iii. optionally, at least one instruction that is different from 'i' or 'ii', thereby transcribing the data from the electronic health record to the database, so that the database is populated with data from the electronic health record. In some embodiments, there is no third instruction 'iii' in the group of instructions. Alternatively, in some embodiments, there is a single third instruction 'iii' in the group of instructions. Alternatively, in some embodiments, there are at least two different third instructions 'iii' in the group of instructions.

In some embodiments, at least of some data in the received EHR is gathered during a clinical trial.

In some embodiments, the database is a clinical trial database.

In some embodiments, the site is a medical-service providing site, selected from the group consisting of a hospital and a clinic. In some embodiments, the EHR includes a site identifier that identifies the site that provided the data for the EHR.

In some embodiments, the instructions to the LLM include instructions to consider both data and metadata of the EHR to perform the identification.

In some embodiments, the instructions to the LLM include that the identity of the site that generated the EHR is found in metadata of the EHR.

In some embodiments, the identification by the LLM includes conversion of the value of the data in the EHR to a different presumptive value that is equivalent to the value of the data in the EHR but having the specified format of the presumptive database data field. In some such embodiments, the conversion of the value comprises at least one of converting a text-format medical data found in the EHR to a numerical value of the presumptive database data field; converting a numerical-format medical data found in the EHR to a text value of the presumptive database data field; and converting a numerical value having specific units of the medical data in the EHR to a different presumptive numerical value that is equivalent to the numerical value of the medical data in the EHR but having the specified units of the presumptive database data field.

In some embodiments, prior to 'e' (accepting from an input device at least one instruction), an option to select the instruction 'i' is displayed on the display screen.

In some embodiments, prior to 'e', an option to select the instruction 'ii' is displayed on the display screen.

In some embodiments, instruction 'ii' that is not an instruction to populate a presumptive corresponding data field of a patient record corresponding to the specific patient of the database with the presumptive value, the instruction comprises: accepting from the input device a correct corresponding database field. In some such embodiments, the instruction further comprises populating the correct corresponding data field of the patient record received from the input device to the specific patient of the database with the presumptive value. Alternatively, in some such embodiments, the method further comprises accepting from the input device one of confirmation that the presumptive value is correct; or accepting from the input device a correct value instead of the presumptive value. In some such embodiments, the instruction further comprises populating the correct corresponding data field of the patient record received from the input device to the specific patient of the database with the correct value if accepted, else with the presumptive value.

In some embodiments, an instruction accepted from an input device 'd' is used to train the LLM for future the identifying. According to an aspect of some embodiments of the teachings herein, there is also provided a non-transitory computer-readable medium storing computer-processor executable instructions for transcribing data from an electronic health record to a database, in accordance with any one of the embodiments of the methods disclosed herein.

According to an aspect of some embodiments of the teachings herein, there is also provided a device comprising a circuit having a computer processor and a computer memory storing instructions that are executable by the computer processor, the device configured for transcribing data from an electronic health record to a database, in accordance with any one of the embodiments of the methods disclosed herein.

According to an aspect of some embodiments of the teachings herein, there is also provided a non-transitory computer-readable medium storing computer-processor executable instructions for transcribing data from an electronic health record to a database, the medium comprising: a. instructions for communicating with a database implemented using software running on suitable hardware, the database having patient records, each patient record having data fields, each data field corresponding to a specified medical data type having a specified format; b. instructions for receiving an EHR generated by a site, the EHR including medical data associated with a specific patient, each medical data including a data type identifier and a value; c. instructions for providing a received EHR as input to a LLM with instructions to identify to which data field in the database is presumed that a data type identifier of the EHR most likely corresponds and with what probability; d. instructions for receiving results of an identification from the LLM and, on a display screen, displaying the medical data from the EHR including the data type identifier and the value together with the identified presumptive corresponding data field in the database, a presumptive value for entry to the database that is equivalent to the EHR value and the probability; e. instructions to accept from an input device and subsequently perform at least one instruction responsive to the displaying 'd', the instruction selected from the group of instructions consisting of: i. that the presumptive corresponding field of the database is correctly identified as corresponding to the data type identifier of the medical data from the EHR and that the presumptive value for entry into the database is correct, and therefore the instruction is to populate a presumptive corresponding data field of a patient record corresponding to the specific patient of the database with the presumptive value; ii. that the presumptive corresponding field in the database is incorrectly identified as corresponding to the data type identifier of the medical data from the EHR and therefore the instruction is not to populate a presumptive corresponding data field of a patient record corresponding to the specific patient of the database with the presumptive value; and iii. optionally, at least one instruction that is different from 'i' or 'ii'

In some embodiments, there is no third instruction 'iii' in the group of instructions. Alternatively, in some embodiments, there is a single third instruction 'iii' in the group of instructions. Alternatively, in some embodiments, there are at least two different third instructions 'iii' in the group of instructions.

In some embodiments, the database is a clinical trial database. In some embodiments, the instructions for communicating with the database are instructions for communicating with a local database running on a same computer as the instructions. Additionally or alternatively, in some embodiments, the instructions for communicating with the database are instructions for communicating with a remote database running on a different computer than the instructions.

In some embodiments, the instructions comprise the LLM running on a same computer as the instructions that is to say, the computer-readable medium also stores the LLM software.

In some embodiments, the instructions for providing the input to a LLM are to a local LLM running on a same computer as the instructions.

In some embodiments, the instructions for providing the input to a LLM are to a remote LLM running on a different computer than the instructions.

In some embodiments, the EHR includes a site identifier that identifies the site that provided the data for the EHR.

In some embodiments, the instructions to the LLM include instructions to consider both data and metadata of the EHR to perform the identification.

In some embodiments, the instructions to the LLM include that the identity of the site that generated the EHR is found in metadata of the EHR.

In some embodiments, the identification by the LLM includes conversion of the value of the data in the EHR to a different presumptive value that is equivalent to the value of the data in the EHR but having the specified format of the presumptive database data field. In some embodiments, the conversion of the value comprises at least one of converting a textformat medical data found in the EHR to a numerical value of the presumptive database data field; converting a numerical-format medical data found in the EHR to a text value of the presumptive database data field; and converting a numerical value having specific units of the medical data in the EHR to a different presumptive numerical value that is equivalent to the numerical value of the medical data in the EHR but having the specified units of the presumptive database data field.

In some embodiments, the medium further comprises instructions to display on the display screen, together with the displaying of the medical data from the EHR, an option to select the instruction 'i'_

In some embodiments, the medium further comprises instructions to display on the display screen, together with the displaying of the medical data from the EHR, an option to select the instruction 'ii'.

In some embodiments, wherein instruction 'ii' that is not an instruction to populate a presumptive corresponding data field of a patient record corresponding to the specific patient of the database with the presumptive value, the instruction 'ii' comprises: accepting from the input device a correct corresponding database field. In some such embodiments, the instruction 'ii' further comprises populating the correct corresponding data field of the patient record received from the input device to the specific patient of the database with the presumptive value.

In some embodiments, the medium further comprises instructions for accepting from the input device one of confirmation that the presumptive value is correct; or accepting from the input device a correct value instead of the presumptive value. In some such embodiments, the instruction 'ii' further comprises populating the correct corresponding data field of the patient record received from the input device to the specific patient of the database with the correct value if accepted, else with the presumptive value.

In some embodiments, the medium further comprises instructions to train the LLM for future the identifying using an instruction 'i'_ 'ii' and/or "iii' accepted from an input device.

According to an aspect of some embodiments of the teachings herein, there is also provided a device comprising a circuit having a computer processor and a computer memory storing instructions that are executable by the computer processor for transcribing data from an electronic health record to a database, in accordance with any one of the embodiments of the computer-processor executable instructions stored on a non-transitory computer-readable medium storing computer-processor disclosed herein.

According to an aspect of some embodiments of the teachings herein, there is also provided a device comprising a circuit having a computer processor and a computer memory storing instructions that are executable by the computer processor for transcribing data from an electronic health record to a database, the device configured to: a. communicate with a database implemented using software running on suitable hardware, the database having patient records, each patient record having data fields, each data field corresponding to a specified medical data type having a specified format; b. receive an EHR generated by a site, the EHR including medical data associated with a specific patient, each medical data including a data type identifier and a value; c. provide a received EHR as input to a LLM with instructions to identify to which data field in the database is presumed that a data type identifier of the EHR most likely corresponds and with what probability; d. receive results of an identification from the LLM and, on a display screen, displaying the medical data from the EHR including the data type identifier and the value together with the identified presumptive corresponding data field in the database, a presumptive value for entry to the database that is equivalent to the EHR value and the probability; e. accept from an input device and subsequently perform at least one instruction responsive to the displaying 'd', the instruction selected from the group of instructions consisting of: i. that the presumptive corresponding field of the database is correctly identified as corresponding to the data type identifier of the medical data from the EHR and that the presumptive value for entry into the database is correct, and therefore the instruction is to populate a presumptive corresponding data field of a patient record corresponding to the specific patient of the database with the presumptive value; ii. that the presumptive corresponding field in the database is incorrectly identified as corresponding to the data type identifier of the medical data from the EHR and therefore the instruction is not to populate a presumptive corresponding data field of a patient record corresponding to the specific patient of the database with the presumptive value; and iii. optionally, at least one instruction that is different from 'i' or 'ii'.

In some embodiments, there is no third instruction 'iii' in the group of instructions. Alternatively, in some embodiments, there is a single third instruction 'iii' in the group of instructions. Alternatively, in some embodiments, there are at least two different third instructions 'iii' in the group of instructions.

In some embodiments, the device further comprises the database as a local database.

In some embodiments, the configuration for communicating with the database comprises configuration for communicating with a remote database running on a computer different from the device.

In some embodiments, the device further comprises the LLM as a local LLM.

In some embodiments, the configuration for providing a received EHR with instructions to an LLM is configuration for providing a received EHR with instructions to a remote LLM running on a computer different from the device.

In some embodiments, the display screen is a component of the device. Alternatively, in some embodiments, the display screen is a remote display screen that is not a component of the device.

In some embodiments, the input device is a component of the device. Alternatively, in some embodiments, the input device is a remote input device that is not a component of the device.

In some embodiments where the display screen and the input are remote devices allow a remote worker to check the LLM results, for example, from home, for example, using a personal device.

In some embodiments, the database is a clinical trial database.

In some embodiments, the EHR includes a site identifier that identifies the site that provided the data for the EHR.

In some embodiments, the instructions to the LLM include instructions to consider both data and metadata of the EHR to perform the identification.

In some embodiments, the instructions to the LLM include that the identity of the site that generated the EHR is found in metadata of the EHR. nt presumptive value that is equivalent to the value of the data in the EHR but having the specified format of the presumptive database data field. In some such embodiments, the conversion of the value comprises at least one of: converting a text-format medical data found in the EHR to a numerical value of the presumptive database data field; converting a numerical-format medical data found in the EHR to a text value of the presumptive database data field; and converting a numerical value having specific units of the medical data in the EHR to a different presumptive numerical value that is equivalent to the numerical value of the medical data in the EHR but having the specified units of the presumptive database data field.

In some embodiments, the device is further configured to display on the display screen, together with the displaying of the medical data from the EHR, an option to select the instruction 'i'_

In some embodiments, the device is further configured to display on the display screen, together with the displaying of the medical data from the EHR, an option to select the instruction 'ii'.

In some embodiments, where instruction 'ii' that is not an instruction to populate a presumptive corresponding data field of a patient record corresponding to the specific patient of the database with the presumptive value, the instruction 'ii' comprises: accepting from the input device a correct corresponding the database field. In some embodiments, the instruction 'ii' further comprises populating the correct corresponding data field of the patient record received from the input device to the specific patient of the database with the presumptive value.

In some embodiments, the device is further configured to accept from the input device one of confirmation that the presumptive value is correct; or a correct value instead of the presumptive value. In some embodiments, the instruction 'ii' further comprises populating the correct corresponding data field of the patient record received from the input device to the specific patient of the database with the correct value if accepted, else with the presumptive value.

In some embodiments, the device is further configured to train the LLM for future the identifying using an instruction 'i'_ 'ii' and/or "iii' accepted from the input device.

Additional aspects and embodiments of the invention are described in the description hereinbelow and in the appended claims and Figures.

BRIEF DESCRIPTION OF THE FIGURES

Some embodiments of the invention are described herein with reference to the accompanying figures. The description, together with the figures, makes apparent to a person having ordinary skill in the art how some embodiments of the invention may be practiced. The figures are for the purpose of illustrative discussion and no attempt is made to show structural details of an embodiment in more detail than is necessary for a fundamental understanding of the invention. For the sake of clarity, some objects depicted in the figures are not to scale.

In the Figures:

Figure 1 is a flowchart of an exemplary embodiment of a method according to the teachings herein;

Figure 2 is a graphic depiction of an embodiment of a clinical trial database;

Figures 3A, 3B and 3C schematically depict stages in applying an embodiment of the method according to the teachings herein, wherein Figure 3A is a graphic depiction of an exemplary EHR at least partially gathered during a clinical trial; Figure 3B depicts an embodiment of the display of the results of an identification performed by a LLM according to the teachings herein; and Figure 3C depicts medical data from the EHR of Figure 3A populated in a clinical trial database of Figure 2; and

Figure 4 depicts an alternative embodiment of the display of the results of an identification performed by a LLM according to the teachings herein.

DESCRIPTION OF SOME EMBODIMENTS OF THE INVENTION

The invention, in some embodiments thereof, relates to methods and/or devices for transcribing data from electronic health records to a database. In some preferred embodiments the data in the electronic health record is gathered during a clinical trial and the database is a clinical trial database.

The principles, uses and implementations of the teachings herein may be better understood with reference to the accompanying description and figures. Upon perusal of the description and figures present herein, one skilled in the art can implement the invention without undue effort or experimentation. In the figures, like reference numerals refer to like parts throughout.

Before explaining at least one embodiment in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth herein. The invention is capable of other embodiments or of being practiced or carried out in various ways. The phraseology and terminology employed herein are for descriptive purpose and should not be regarded as limiting. Method of the teachings herein

According to an aspect of some embodiments of the teachings herein, there is provided a method of transcribing data from an electronic health record (EHR) to a database. In Figure 1, a flowchart 10 depicts an exemplary embodiment of the method.

In some embodiments, the method comprises: a. in box 12, establishing a database implemented using software running on suitable hardware, the database having patient records, each patient record having data fields, each data field corresponding to a specified medical data type having a specified format; b. in box 14, receiving an electronic health record (EHR) generated by a site, the EHR including medical data associated with a specific patient, each medical data of the EHR including a data type identifier and a value; c. in box 16, subsequently to 'b', providing the received EHR as input to a large language model (LLM) with instructions to identify to which data field in the database is presumed that a data type identifier of the EHR most likely corresponds and with what probability (i.e., the confidence that the identification is correct); d. in box 18, subsequent to 'c', receiving results of the identification from the LLM and, on a display screen, displaying the medical data from the EHR including the data type identifier and the value together with the identified presumptive corresponding data field in the database, a presumptive value for entry to the database that is equivalent to the EHR value and the probability; e. in box 20, subsequent to 'd', accepting from an input device at least one instruction selected from the group of instructions consisting of: i. that the presumptive corresponding field of the database is correctly identified as corresponding to the data type identifier of the medical data from the EHR and that the presumptive value for entry into the database is correct (that is to say, is equivalent to the value of the medical data from the EHR), link 22, and therefore the instruction is to populate the presumptive corresponding data field of the patient record corresponding to the specific patient of the database with the presumptive value, box 24, ii. that the presumptive corresponding field in the database is incorrectly identified as corresponding to data type identifier of the medical data from the EHR, link 25, and therefore the instruction is not to populate the presumptive corresponding data field of the patient record corresponding to the specific patient of the database with the presumptive value, box 26; and iii. optionally, an instruction that is different from 'i' or 'ii', thereby transcribing data from the EHR to the database, so that the database is populated with data from the EHR.

In some embodiments, 'iii' is not present and the only two instructions in the group are 'i' and 'ii'. Alternatively in some embodiments, 'iii' is an instruction that is present in the group together with 'i' and 'ii'.

The method is a computer-implemented method, that is to say, 'a', 'b', 'c', 'd' and 'e' are performed by a suitably-configured (by a combination of software and hardware) computer or combination of computers. Typically, the method is performed on a single computer or on two or more computers in mutual communication.

The input device is any suitable human-operable input device that allows a human to input commands and data into a computer that is implementing the method. Examples of suitable input devices include a keyboard, a mouse and a touch screen, together with the required software, hardware and the like.

In some embodiments, the site that generated the EHR is a medical-service providing site, selected from the group consisting of a hospital and a clinic.

Preliminary test transcriptions performed by the Applicant using a commercially- available LLM that was not pretrained for EHR transcription have shown that the method of the teachings herein allows transcription of data from an EHR to a database with substantially no substantive requirements or limitations on the EHR and on the database. It has also been found that typical embodiments of the embodiment allow semi-automatic and highly efficient transcription.

Database

Any suitable database implemented using any suitable software running on any suitable hardware may be used, for example, a local general-purpose computer or a server running custom or suitably-modified commercially available software. In some preferred embodiments, the database is a clinical trial database.

An advantage of the teachings herein is that the entity which wants to transcribe electronic health records to the database (e.g., a clinical trial sponsor and/or a CRO) can define the database as desired with no substantial limitations imposed by the method.

An embodiment of a database suitable for implementing the method is graphically depicted in Figure 2, database 28. Database 28 is established and implemented using software running on suitable hardware. Database 28 has five patient records 30a, 30b, 30c, 30d and 30e (collectively 30).

Each patient record 30 of database 28 has six data fields 32a, 32b, 32c, 32d, 32e and 32f (collectively 32). Each data field has a specified medical data type having a specified format.

Data field 32a is a patient identifier, in database 28 having integer format.

Data field 32b is a site identifier, identifying the site where the data for the EHR was gathered, in database 28 having text format.

Data field 32c is the weight of the subject in kilograms in numerical format

Data field 32d is the systolic blood pressure in units of mm Hg in integer format.

Data field 32e is the diastolic blood pressure in units of mm Hg in integer format.

Data field 32f is the blood sugar level in units of mg/dL in numerical format.

In some preferred embodiments, at least one data field in a database identifies the site that provided the data for the EHR. In database 28, field 32b is such a site identifier, in text format. In some embodiments, a site identifier is format different from text, for example, an integer or a number. In some alternative embodiments, the database does not include a data field that identifies the site that provided the data for the EHR.

In some preferred embodiments, at least one data field in a database comprises an EHR identifier to identify the specific EHR from which the data was transcribed. Such an EHR identified assists in error checking and validating results. In some alternative embodiments, such as database 28, a database is devoid of a data field that identifies the specific EHR from which the data was transcribed.

In some embodiments, at least one data field in the database holds a numerical value where the specified format includes specific units. In database 28, fields 32c, 32d, 32e and 32f hold numerical values with specific units for various medical data.

EHR

As noted in box 14, the method comprises receiving an electronic health record (EHR) generated by a site, the EHR including medical data associated with a specific patient, each medical data in the EHR including a data type identifier and a value. In some preferred embodiments, the electronic health record is at least partially gathered during a clinical trial.

In some embodiments, an EHR includes an EHR identifier that uniquely identifies that EHR. In some embodiments, an EHR identifier is present as data in the EHR. Additionally or alternatively, in some embodiments an EHR identifier is present as metadata (e.g., at least part of a file name or other metadata) of the EHR. In some embodiments, an EHR is devoid of a site identifier that identifies the site that provided the data for the EHR. Alternatively, in preferred embodiments, an EHR includes a site identifier that identifies the site that provided the data for the EHR. In some embodiments, a site identifier is present as data in the EHR. Additionally or alternatively, in some embodiments, a site identifier is present as metadata (e.g., at least part of a file name or other metadata) of the EHR. It has been found that EHRs provided from a specific site often have many common features, for example, use the same data type identifiers and data formats for specific types of data, and/or use the same set of medical data presented in the same order with the same units. As a result, providing an EHR with a site identifier may improve the efficiency and/or accuracy of identification by an LLM when used in accordance with the teachings herein.

In preferred embodiments, an EHR includes a patient identifier that identifies the specific patient with which the medical data in the EHR is associated. In some embodiments, a patient identifier is present as data in the EHR. Additionally or alternatively, in some embodiments a patient identifier is present as metadata (e.g., at least part of a file name or other metadata) of the EHR.

Importantly, in some preferred embodiments there is no need that the format of the EHR or of the medical data in the EHR be ordered or correlated in some way with the data fields of the database. That said, in some alternative embodiments there is at least one requirement, for example, where in the EHR and/or in what format at least one data type is found. For example, in some embodiments there is a requirement for an EHR identifier that uniquely identifies that EHR and/or a requirement for a patient identifier that uniquely identifies the specific patient with which the medical data in the EHR is associated and/or for a site identifier.

An exemplary EHR is graphically depicted, EHR 34 in Figure 3A. EHR 34 includes six data type identifiers with an associated value: a patient identifier 34a, a site identifier 34b, weight 34c, systolic blood pressure 34d, diastolic blood pressure 34e and blood sugar level 34e. Site identifier 34b appears as a value without an explicit data type identifier. Weight 34c and blood sugar level 34f appear as a value with an explicit data type identifier including units. Systolic blood pressure 34d and diastolic blood pressure 34e appear together with an explicit data type identifier comprising the text "B.P." together and the "/" symbol. LLM

As noted in box 16, the method comprises providing a received EHR as input to a large language model (LLM) with instructions to identify to which data field in the database does a data type identifier of the EHR most likely correspond and with what probability.

In some embodiments, the LLM is instructed to ignore metadata and only consider data in a received EHR. Alternatively, in some embodiments the LLM is instructed to consider both data and metadata in a received EHR.

In some embodiments, the identity of at least some of the information in the metadata of an EHR is known (e.g., is a predetermined requirement for an EHR for that specific embodiments) and the LLM is instructed to use this knowledge to help with the required identification. For example, as noted above it has been found that EHRs provided from a specific site often have many common features so that the simple recovering of the identity of a site from metadata may, in some embodiments, improve the efficiency and/or accuracy of identification by the LLM.

Any suitable LLM may be used, including a commercially-available LLM or a custom LLM.

In some embodiments, the LLM is a commercially-available general-purpose LLM.

In some embodiments, the LLM is a commercially-available LLM specifically configured (e.g., trained) for implementing the teachings herein, i.e., for transcribing data from EHRs to a database.

In some embodiments, the LLM is a custom LLM specifically configured for implementing the teachings herein.

In some embodiments, access to the LLM is controlled by a sponsor of a clinical trial. For example, an intervention-development organization controls and operates an own LLM, preferably an LLM that is trained for efficient transcription of EHRs that are related to one or more trials of the sponsor.

In some embodiments, access to the LLM is controlled by a CRO, a clinical research organization. In some such embodiments, as part of the service the CRO provided to sponsors, the CRO controls and operates an own LLM. In some embodiments, the LLM is trained for efficient transcription of EHRs that are related to one or more trials that the CRO performs for sponsors.

In some embodiments, access to the LLM is controlled by a company that provides transcription services for CROs and/or for sponsors. Receiving and displaying results

As noted in box 18, the method further comprises receiving the results of the identification performed by the LLM and, on a display screen, displaying the medical data from the EHR including the data type identifier and the value together with the most likely corresponding database data field identified by the LLM and the associated probability. The display screen is any suitable display screen as known in the art, preferably implementing a GUI (graphic user interface). Such displaying allows review of the LLM output by a human.

Automated conversion of EHR value to database field value

In some embodiments, at least one database data field comprises a specified format, and the results of the identification by the LLM includes conversion of the value of the medical data in the EHR to a different presumptive value that is presumably equivalent to the value of the medical data in the EHR but having the specified format of the presumptive database data field.

For example, in some embodiments, a presumptive database data field requires a numerical value and the results of the identification include conversion of text-format medical data found in the EHR to a numerical value suitable for populating the presumptive database data field.

For example in some embodiments, the presumptive database data field requires a text value and the results of the identification include conversion of numerical-format medical data found in the EHR to a text value suitable for populating the presumptive database data field.

For example, in some embodiments, at least one presumptive database data field comprises a numerical value where the specified format of that field includes specified units, and the results of the identification by the LLM include conversion of the numerical value of the medical data in the EHR to a presumptive numerical value that is equivalent to the numerical value of the medical data in the EHR but having the specified units of the presumptive database data field.

For example in some embodiments, the presumptive database data field requires a numerical value having kg units and the results of the identification includes conversion of medical data having pound (lbs) units found in the EHR to a numerical value having kg units suitable for populating the presumptive database data field.

For example in some embodiments, the presumptive database data field requires a numerical value having gram units and the results of the identification includes conversion of medical data having milligram units found in the EHR to a numerical value having gram units suitable for populating the presumptive database data field.

In some embodiments, the method comprises, prior to providing a received EHR as input to the LLM, a pre-processing step where at least one medical data found in the EHR as a numerical value having original units is updated to an equivalent numerical value of different units and subsequently, the EHR with the updated medical data is provided as input to the LLM. Such embodiments are useful for reducing potential unit-conversion errors by the LLM and reduce the effort made by a person reviewing the results from the LLM.

Figure 3B is a schematic depiction of a display screen 38 on which is displayed the medical data 34a to 34f from EHR 34 together with the most likely presumptive value / presumptive database data field pair identified by the LLM 40a to 40f and the associated probability 42a, 42c to 42f that expresses the confidence that the presumptive database data field is correctly identified.

In Figure 3B, for two medical data in EHR 34, data 34a ("subject" followed by an integer) and data 34f ("sugar" followed by an integer followed by "mg/dL" ), the LLM returns a 100% probability of corresponding with database data field 32a (subject) and database data field 32f (sugar [mg/dL]) respectively. This 100% probability likely arises from a combination of identical format, identical units (for data 34f) and similar titles for medical data 34a and 34f and the headers of the presumptive corresponding database data fields 32a and 32f.

In Figure 3B, for two medical data in EHR 34, data 34d and data 34e (both found in "B.P." followed by two integers separated by a slash), the LLM returns a 90% probability of corresponding with data base data fields 32d (BP-sys [mm Hg]) and 32e (BP-dia [mm Hg]) respectively. Presumably, this high probability is found due to the format of the values being correct and the label "B.P." being very similar to the headers of the presumptive corresponding database data fields 32d and 32e despite the fact that medical data 34d and 34e in EHR 32 lack units.

In Figure 3B, medical data 34b is the site identifier. In the depicted embodiment, the site identifier is a fixed parameter (a fixed header present in all EHR produced by the site) for which no doubt exists about its value and is provided as such to the LLM. Accordingly, the value of medical data 34b is simply copied to database data field 40b ("site") and no probability is listed. In Figure 3B, medical data 34c (the weight of subject in stone) is found to most likely correspond to presumptive database data field 40c (weight in kg) but with only a 50% possibility. Further, the numerical value of medical data 34c (10) is converted to a different presumptive numerical value (63.5). Since medical data 34c is clearly labeled with the string "weight" it is very likely that there is correspondence between medical data 34c and database data field 32c. However, the conversion of the numerical value 10 of medical data 34c to 63.5 as a presumptive value for entry into database data field 32c is highly uncertain and based on an LLM assumption that the numerical value " 10" followed by the string "stone" can be converted to "63.5" to yield a kilogram weight value.

In the embodiment depicted in Figure 3B, the probabilities 42a to 42f that express the confidence that a presumptive value / presumptive database data field pair is correctly identified by the LLM is indicated as a percentage having a value between 0 and 100. Depending on the embodiments, any other type or combination of indications are used to express the probability. Suitable indications include integer ranges (1-5, 1-10, 1-20) alphabetic ranges (A-F) and/or formats such as character color of the presumptive value / presumptive database data field pair (e.g., greener characters indicate higher probability, redder characters indicate lower probability) and/or character shade of the presumptive value / presumptive database data field pair (bolder characters indicate higher probability, fainter characters indicate lower probability)

Review and database population

As discussed above with reference to box 18 in Figure 1 and as depicted in Figure 3B, the medical data from the EHR including the data type identifier and the value is displayed on a display screen together with the presumptive corresponding data field in the database and a presumptive value for entry to the database as identified by the LLM together with the probability received from the LLM. The display screen is any suitable display screen as known in the art, preferably implementing a GUI (graphic user interface), for example, a touch screen. Such displaying allows review of the LLM output by a human.

Typically, after the displaying the computer implementing the method waits to receive and accept instructions from an input device that is functionally-associated with the computer. The input device is any suitable such device that is suited to be used together with the display screen, for example, a mouse, a keyboard, and the like. In some preferred embodiments, the display screen is a touch screen which integrates display and input from a human into a single physical device. A human views the display screen displaying the medical data from the EHR together with the most likely corresponding database data field identified by the LLM and the associated probability. The probability assists the human in quickly, efficiently and accurately reviewing the accuracy of the identifications performed by the LLM. Specifically, the person reviewing the results consults a probability associated with a displayed correspondence between the EHR data type identifier and a presumptive data field. When a correspondence has a high probability, especially a 100% correspondence, the reviewer can confirm that the correspondence is correct, if required, using the input device quickly and with little intellectual effort. When a correspondence has a relatively low probability, the reviewer can choose to invest more time and/or effort and/or skill to ensure that the correspondence is correct before confirming and, optionally, correcting the correspondence.

The reviewer uses the input device to provide instructions to the computer based on whether or not the LLM correctly identified the correspondence between .

When the reviewer decides that the presumptive corresponding field of the database is correctly identified as corresponding to the data type identifier from EHR 22 and that the presumptive value for entry into the database is correct (i.e., is equivalent to the value from EHR 22), the instruction provided is to populate the presumptive corresponding data field of the patient record corresponding to the specific patient of the database with the presumptive value, box 24, as is graphically depicted in Figure 3C.

When the reviewer decides that the presumptive corresponding field of the database is incorrectly identified as corresponding to the data type identifier from the EHR, the instruction provided What specifically follows subsequent to receipt of such instruction is embodiment-dependent. For example, in some embodiments following the receipt of an instruction that indicates that a correspondence is incorrect, an option is provided for further review by a different reviewer. For example, in some embodiments following the receipt of an instruction that indicates that a correspondence is incorrect, an option is provided for the reviewer to manually enter the correct database data field that corresponds to the data type identifier of the EHR and/or to manually enter a value for entry into the manually-entered correct corresponding data field of the patient record corresponding to the specific patient of the database.

In some embodiments, the only instructions that are accepted from the input device are either 'i' or 'ii' as described above. In some alternative embodiments, one or more other instructions can be accepted. For example, in some embodiments, an instruction can be provided that the presumptive corresponding field of the database is correctly identified as corresponding to the data type identifier of the EHR but that the presumptive value for entry into the database is incorrect.

Accordingly, in box 20 in Figure 1, subsequently to the display 'd', accepting from an input device at least one instruction selected from the group of instructions consisting of i. that the presumptive corresponding field of the database is correctly identified as corresponding to the data type identifier of the medical data from the EHR and that the presumptive value for entry into the database is correct, and therefore the instruction is to populate a presumptive corresponding data field of a patient record corresponding to the specific patient of the database with the presumptive value, ii. that the presumptive corresponding field in the database is incorrectly identified as corresponding to the data type identifier of the medical data from the EHR and therefore the instruction is not to populate a presumptive corresponding data field of a patient record corresponding to the specific patient of the database with the presumptive value; and iii. optionally, at least one instruction that is different from 'i' or 'ii',

In some embodiments, prior to the computer accepting an instruction from the input device, an option to select instruction 'i' is displayed on the display screen, preferably together with the displayed results of the identification from the LLM.

In some embodiments, prior to the computer accepting an instruction from the input device, an option to select instruction 'ii' is displayed on the display screen, preferably together with the displayed results of the identification from the LLM.

In some preferred embodiments, prior to the computer accepting an instruction from the input device, an option to select instruction 'i' and an option to select instruction 'ii' are both displayed on the display screen, most preferably together with the displayed results of the identification from the LLM.

Instruction when the presumptive corresponding field is correct

The first possible instruction is that the LLM correctly identified the presumptive corresponding field of the database is correctly identified as corresponding to the data type identifier of the medical data from the EHR and that the presumptive value for entry into the database is correct, and therefore the instruction provided to the computer is to populate a presumptive corresponding data field of a patient record corresponding to the specific patient of the database with the presumptive value. In some embodiments, such an instruction requires a single action by a human using the input device, for example, entry of a single command instructing the computer to populate the presumptive corresponding database data field of the patient record corresponding to the specific patient of the database with the presumptive value.

In some alternative embodiments, such an instruction requires at least two actions by a human using the input device, for example, a first action confirming that the identification is correct and a subsequent second action actually instructing the computer to populate the presumptive corresponding database data field of the patient record corresponding to the specific patient of the database with the presumptive value.

Instruction when the presumptive corresponding field is incorrect

The second possible instruction is that a presumptive database data field identified by the LLM as corresponding to a data type identifier of the EHR is incorrect, and therefore the computer is not instructed to populate the presumptive database data field of the patient record corresponding to the specific patient of the database with the presumptive value.

In some embodiments, such an instruction requires a single action by a human using using the input device. In some alternative embodiments, such an instruction requires at least two actions by a human using the input device.

In some such embodiments, such an instruction comprises the computer accepting from the input device a correct corresponding field in a database (for example, as determined by the person using the input device). Typically, such a correct corresponding field received from the input device replaces the presumptive corresponding field incorrectly identified by the LLM. In some such embodiments, the instruction further comprises populating the correct corresponding data field of the patient record received from the input device to the specific patient of the database with the presumptive value. Alternatively, in some such embodiments, the instruction further comprises populating the correct corresponding data field of the patient record received from the input device to the specific patient of the database with a correct value different from the presumptive value, for example, a correct value received from the input device

In some such embodiments, the instruction further comprises accepting from the input device one of: confirmation that the presumptive value is correct; or accepting from the input device a correct value instead of the presumptive value (as determined by the person). In some such embodiments, the computer accepts instructions to, and then populates, the correct corresponding data field of the patient record received from the input device to the specific patient of the database with the presumptive value or with the correct value accepted from the input device, whichever is applicable.

In the embodiment depicted in Figures 3, each one of the data (34a, 34c to 34f) found in EHR 34 is displayed in Figure 3B with a corresponding presumptive corresponding database field / corresponding value pair (40a, 40c to 40f, respectively) together with a GUI button 44 labeled "accept" and a GUI button 46 labeled "edit". In Figure 3B there are five GUI buttons 44 labeled "accept" and five GUI buttons labeled "edit" but, to reduce clutter, only one of each is explicitly labeled.

A human reviewer views display screen 38 and, for each one of presumptive corresponding field / corresponding value pairs (40a, 40c to 40f) which the reviewer considers to be correct, provides the computer with the instruction 'i' to populate the presumptive corresponding data field of the patient record corresponding to the specific patient of the database with the presumptive value by manipulating the respective "accept" GUI button 44 in the usual way, e.g., using a mouse, a specified key on a keyboard, or touching a button 44 with a finger or stylus if display screen 38 is a touchscreen.

For the presumptive corresponding field / corresponding value pairs (40a, 40c to 40f) which the reviewer considers the correspondence to be incorrect, the reviewer manipulates the "edit" GUI button 46 in the usual way. As a result, the computer is not sent an instruction to populate the presumptive corresponding data field of the patient record corresponding to the specific patient of the database with the presumptive value. Instead, as is known in the art of computing, the reviewer is provided with a window that allows input of the correct database data field (i.e., that database data field that the reviewer knows corresponds to the data type identifier in the EHR) and, in some embodiments, also the correct value. The entered correct database data field (and, if relevant, value) are displayed on display screen 38. If the person is satisfied with the thus manually-entered correct database data field / value, the person manipulates the corresponding "accept" GUI button 44 in the usual way.

When all five "accept" GUI buttons 44 have been manipulated by the reviewer, the computer accepts the manipulation of the five "accept" GUI buttons 44 as instructions to populate the data fields of the patient record in the database with the values approved by the reviewer. For those data pairs which the LLM correctly identified (as confirmed by the reviewer-instructions received via the input device), the computer populates the presumptive corresponding data field of a patient record corresponding to the specific patient of the database with the presumptive value. For those data pairs which the LLM incorrectly identified (as confirmed by the instructions received via the input device) the computer populates the correct corresponding data field of a patient record corresponding to the specific patient of the database with the correct value if received via the input device, else with the presumptive value.

In Figure 4 is depicted an alternative display of the data (34a to 34f) found in EHR 34 together with the corresponding presumptive corresponding database field / corresponding value pairs (40a, 40c to 40f, respectively) and the corresponding probabilities (42a, 42c to 42f). In Figure 4, associated with each database field / corresponding value pairs (40a, 40c to 40f) is a GUI button 46 labeled "edit". A person can manipulate one of GUI buttons 46 to provide the computer with instructions that the data field (one of 40a, 40b to 40f) of the database that is presumed to correspond to the data type identifier (one of 34a, 34b to 34f, respectively) in EHR 34 associated with the GUI button 46 is incorrectly identified and to provide to the computer a correct corresponding database field and a correct corresponding value.

In Figure 4, the display further comprises a single GUI button 44 labeled "accept". Manipulation of GUI button 44 allows providing the computer with a command for all of the corresponding database field / corresponding value pairs with a single action For those pairs that were not changed using a GUI button 46 labeled "edit", manipulation of GUI button 44 is an instruction that the presumptive corresponding field / presumptive value pair is correct and to populate a presumptive corresponding data field of a patient record corresponding to the specific patient of the database with the presumptive value. For those pairs that were changed using a GUI button 46 labeled "edit", manipulation of GUI button 44 labeled "accept" is an instruction to populate the correct corresponding data field of the patient record received from the input device to the specific patient of the database with the correct value that was entered, else with the presumptive value.

In some embodiments, confirmation is required for presumptive correspondences having a probability of less than some threshold. In some embodiments, any correspondence having a probability of less than 100% requires confirmation. Additionally, in some embodiments, some or all correspondences having a probability of 100% also require confirmation.

In some embodiments, an EHR includes medical data for which no corresponding database data field is identified. In some such embodiments, such medical data is not displayed (on a display screen such as 38, during 'd'). In some alternative embodiments, such medical data from the EHR is displayed on a display screen, providing a reviewer the option to investigate such medical data.

In the examples discussed above, a single presumptive corresponding data field and a single presumptive value are displayed for review by a human. In some alternative embodiments, the method comprises optionally providing at least two presumptive corresponding data fields each with an associated probability and/or at least two presumptive values each with an associated probability. In such embodiments, the reviewer can select the correct corresponding data field and/or the correct value from the displayed presumptive data fields / data and/or perform a more rigorous review to decide how to populate the database. In some such embodiments, the decision to display more than one presumptive corresponding data field and/or more than one presumptive value is based on having at least two presumptive corresponding data fields and/or at least two presumptive values of similar probability.

Improving future identifications

In preferred embodiments, the instructions received from the input device are used to improve future identifications.

In some such embodiments, the accuracy of future identification by the LLM is improved by the actual use of the method. For example, 'e', accepting from an input device whether the identification performed by the LLM is correct or incorrect (box 20, Figure 1) is used, for example, as data to train the LLM for future identifications. Specifically, in preferred embodiments during actual operational use of the LLM for implementing the teachings herein, the LLM is also trained for accurate identification as opposed to being trained during a dedicated training session. In some embodiments, training during operational use of the LLM is performed using the standard training routines of the LLM. Accordingly, in some embodiments the method further comprises that an instruction accepted from an input device in 'd' is used to train the LLM for future identifying to which data field in the database is presumed that a data type identifier of the EHR most likely corresponds.

It is known, that typically a given site has a relatively consistent format for the various medical data found in an EHR produced by or for the site. So even the format of medical data in an EHR from one site is very different from the format of medical data in an EHR from a different site, the format of medical data of most or all EHR from a single site is very similar and even identical. In some embodiments, future identification is improved by site-dependent improvement. For example, and with reference to the example discussed with referenced to Figures 3. In such embodiments, an association is made that for an EHR identified as coming from the site 40b "STH, London" that includes medical data 34c labeled with the string "weight" followed by a number followed by the string "stone", the presumptive database data field is 32c "weight" and that the numerical value from the EHR should be converted using the 6.35 kg/stone conversion formula.

In some embodiments, improvements, including site-dependent improvements, are implemented using the standard learning protocol of the LLM.

Additionally or alternatively, in some embodiments such improvements, especially site-dependent improvements are made subsequent to the receiving results of the identification form the LLM but prior to displaying the results in a second computational unit. Specifically, the second computational unit includes a list of site-dependent correspondences including, for example, correspondences that include changing a numerical value from the EHR units to an equivalent value having different units. The second computational unit receives the results of the identification from the LLM, identifies the site and checks if there are any site-dependent correspondences that are correct but are associated with a low probability (in which case the low probability is replaced with a higher probability) or incorrect but can be corrected with reference to the list. The results of the identification that are subsequently received and displayed on the display screen are the results output by the second computational unit.

Device of the teachings herein

A device according to the teachings herein is any suitable device that is configured to implement at least one embodiment of the method of the teachings herein. In some embodiments, the device includes: a computer configured to receive an EHR; to provide a received EHR to an LLM with instructions as described above; to receive results from the LLM in response to the instructions; to display results of an identification as described above on a display screen; to receive instructions from an input device relating to results displayed on a display screen; and to populate a database in accordance with received instructions, as described above. In some embodiments, the computer is a single discrete computer. In some embodiments the computer is a combination of at least two discrete computer in mutual communication one with the other.

In some embodiments, the LLM is a component of the device. Alternatively, in some embodiments the device is in communication with an LLM that is not a component of the device.

In some embodiments, the database is implemented on the device. Alternatively, in some embodiments the device is in communication with a different computer implementing the database, the different computer not being a component of the device.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention pertains. In case of conflict, the specification, including definitions, takes precedence.

As used herein, the terms “comprising”, “including”, "having" and grammatical variants thereof are to be taken as specifying the stated features, integers, steps or components but do not preclude the addition of one or more additional features, integers, steps, components or groups thereof. As used herein, the indefinite articles "a" and "an" mean "at least one" or "one or more" unless the context clearly dictates otherwise.

As used herein, when a numerical value is preceded by the term "about", the term "about" is intended to indicate +/-10%. As used herein, a phrase in the form “A and/or B” means a selection from the group consisting of (A), (B) or (A and B). As used herein, a phrase in the form “at least one of A, B and C” means a selection from the group consisting of (A), (B), (C), (A and B), (A and C), (B and C) or (A and B and C).

It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the invention. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

Embodiments of methods and/or devices described herein may involve performing or completing selected tasks manually, automatically, or a combination thereof. Some methods and/or devices described herein are implemented with the use of components that comprise hardware, software, firmware or combinations thereof. In some embodiments, some components are general-purpose components such as general purpose computers, digital processors or oscilloscopes. In some embodiments, some components are dedicated or custom components such as circuits, integrated circuits or software.

For example, in some embodiments, some of an embodiment is implemented as a plurality of software instructions executed by a data processor, for example which is part of a general-purpose or custom computer. In some embodiments, the data processor or computer comprises volatile memory for storing instructions and/or data and/or a non-volatile storage, for example, a magnetic hard-disk and/or removable media, for storing instructions and/or data. In some embodiments, implementation includes a network connection. In some embodiments, implementation includes a user interface, generally comprising one or more of input devices (e.g., allowing input of commands and/or parameters) and output devices (e.g., allowing reporting parameters of operation and results.

Although the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the scope of the appended claims.

Citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the invention.

Section headings are used herein to ease understanding of the specification and should not be construed as necessarily limiting.

Claims

CLAIMS:

1. A method of transcribing data from an electronic health record to a database, comprising: a. establishing a database implemented using software running on suitable hardware, said database having patient records, each patient record having data fields, each said data fields corresponding to a specified medical data type having a specified format (12); b. receiving an electronic health record (EHR) generated by a site, said EHR including medical data associated with a specific patient, each said medical data including a data type identifier and a value (14); c. subsequent to 'b', providing said received EHR as input to a large language model (LLM) with instructions to identify to which data field in said database is presumed that a data type identifier of said EHR most likely corresponds and with what probability (16); d. subsequent to 'c', receiving results of said identification from said LLM and, on a display screen, displaying said medical data from said EHR including said data type identifier and said value together with said identified presumptive corresponding data field in said database, a presumptive value for entry to said database that is equivalent to said EHR value and said probability (18); e. subsequent to 'd', accepting from an input device at least one instruction (20) selected from the group of instructions consisting of: i. that said presumptive corresponding field of said database is correctly identified as corresponding to said data type identifier of said medical data from said EHR and that said presumptive value for entry into said database is correct, and therefore said instruction is to populate a presumptive corresponding data field of a patient record corresponding to said specific patient of the database with said presumptive value (24), ii. that said presumptive corresponding field in said database is incorrectly identified as corresponding to said data type identifier of said medical data from said EHR (26) and therefore said instruction is not to populate a presumptive corresponding data field of a patient record corresponding to said specific patient of the database with said presumptive value (26); and iii. optionally, at least one instruction that is different from 'i' or 'ii', thereby transcribing said data from said electronic health record to said database, so that said database is populated with data from said electronic health record.

2. The method of claim 1, wherein at least of some data in said received EHR is gathered during a clinical trial.

3. The method of any one of claims 1 to 2, wherein said database is a clinical trial database.

4. The method of any one of claims 1 to 3, wherein said EHR includes a site identifier that identifies the site that provided the data for the EHR.

5. The method of any one of claims 1 to 4, wherein said instructions to said LLM include instructions to consider both data and metadata of said EHR to perform said identification.

6. The method of any one of claims 1 to 5, wherein said instructions to said LLM include that the identity of said site that generated said EHR is found in metadata of said EHR.

7. The method of any one of claims 1 to 6, wherein said identification by said LLM includes conversion of said value of said data in said EHR to a different presumptive value that is equivalent to said value of said data in said EHR but having the specified format of said presumptive database data field.

8. The method of claim 7, wherein said conversion of said value comprises at least one of: converting a text-format medical data found in said EHR to a numerical value of said presumptive database data field; converting a numerical -format medical data found in said EHR to a text value of said presumptive database data field; and converting a numerical value having specific units of said medical data in said EHR to a different presumptive numerical value that is equivalent to said numerical value of said medical data in the EHR but having the specified units of said presumptive database data field.

9. The method of any one of claims 1 to 8, wherein prior to 'e', an option to select said instruction 'i' is displayed on said display screen.

10. The method of any one of claims 1 to 9, wherein prior to 'e', an option to select said instruction 'ii' is displayed on said display screen.

11. The method of any one of claims 1 to 5, wherein instruction 'ii' that is not an instruction to populate a presumptive corresponding data field of a patient record corresponding to said specific patient of the database with said presumptive value, the instruction comprises: accepting from said input device a correct corresponding said database field.

12. The method of claim 11, said instruction further comprises populating the correct corresponding data field of the patient record received from said input device to the specific patient of said database with said presumptive value.

13. The method of claim 11, further comprising accepting from said input device one of: confirmation that said presumptive value is correct; or accepting from said input device a correct value instead of said presumptive value.

14. The method of claim 13, said instruction further comprises populating the correct corresponding data field of the patient record received from said input device to the specific patient of said database with said correct value if accepted, else with said presumptive value.

15. The method of any one of claims 1 to 14, wherein an instruction accepted from an input device 'd' is used to train said LLM for future said identifying.

16. A non-transitory computer-readable medium storing computer processor executable instructions for transcribing data from an electronic health record to a database, in accordance with the method of any one of claims 1 to 15.

17. A device comprising a circuit having a computer processor and a computer memory storing instructions that are executable by the computer processor, configured for transcribing data from an electronic health record to a database in accordance with the method of claims 1 to 15.

18. A non-transitory computer-readable medium storing computer-processor executable instructions for transcribing data from an electronic health record to a database, comprising: a. instructions for communicating with a database implemented using software running on suitable hardware, said database having patient records, each patient record having data fields, each said data fields corresponding to a specified medical data type having a specified format; b. instructions for receiving an electronic health record (EHR) generated by a site, said EHR including medical data associated with a specific patient, each said medical data including a data type identifier and a value; c. instructions for providing a received EHR as input to a large language model (LLM) with instructions to identify to which data field in said database is presumed that a data type identifier of said EHR most likely corresponds and with what probability; d. instructions for receiving results of an identification from said LLM and, on a display screen, displaying said medical data from said EHR including said data type identifier and said value together with said identified presumptive corresponding data field in said database, a presumptive value for entry to said database that is equivalent to said EHR value and said probability; e. instructions to accept from an input device and subsequently perform at least one instruction responsive to said displaying 'd', said instruction selected from the group of instructions consisting of i. that said presumptive corresponding field of said database is correctly identified as corresponding to said data type identifier of said medical data from said EHR and that said presumptive value for entry into said database is correct, and therefore said instruction is to populate a presumptive corresponding data field of a patient record corresponding to said specific patient of the database with said presumptive value; ii. that said presumptive corresponding field in said database is incorrectly identified as corresponding to said data type identifier of said medical data from said EHR and therefore said instruction is not to populate a presumptive corresponding data field of a patient record corresponding to said specific patient of the database with said presumptive value; and iii. optionally, at least one instruction that is different from 'i' or 'ii'.

19. A device comprising a circuit having a computer processor and a computer memory storing instructions that are executable by the computer processor for transcribing data from an electronic health record to a database, said instructions in accordance with claim 18.

20. A device comprising a circuit having a computer processor and a computer memory storing instructions that are executable by the computer processor for transcribing data from an electronic health record to a database, the device configured to: a. communicate with a database implemented using software running on suitable hardware, said database having patient records, each patient record having data fields, each said data fields corresponding to a specified medical data type having a specified format; b. receive an electronic health record (EHR) generated by a site, said EHR including medical data associated with a specific patient, each said medical data including a data type identifier and a value; c. provide a received EHR as input to a large language model (LLM) with instructions to identify to which data field in said database is presumed that a data type identifier of said EHR most likely corresponds and with what probability; d. receive results of an identification from said LLM and, on a display screen, displaying said medical data from said EHR including said data type identifier and said value together with said identified presumptive corresponding data field in said database, a presumptive value for entry to said database that is equivalent to said EHR value and said probability; e. accept from an input device and subsequently perform at least one instruction responsive to said displaying 'd', said instruction selected from the group of instructions consisting of: i. that said presumptive corresponding field of said database is correctly identified as corresponding to said data type identifier of said medical data from said EHR and that said presumptive value for entry into said database is correct, and therefore said instruction is to populate a presumptive corresponding data field of a patient record corresponding to said specific patient of the database with said presumptive value; ii. that said presumptive corresponding field in said database is incorrectly identified as corresponding to said data type identifier of said medical data from said EHR and therefore said instruction is not to populate a presumptive corresponding data field of a patient record corresponding to said specific patient of the database with said presumptive value; and iii. optionally, at least one instruction that is different from 'i' or 'ii'.