Interoperable Platform for Reducing Redundancy in Medical Database Management

Abstract

Systems and methods for reducing redundancy in healthcare database management are disclosed. An example system may include an application programming interface communicatively linked to a user interface associated with each of: a plurality of hospital information systems, a plurality of source devices associated with each of the plurality of hospital information systems, and a plurality of electronic data management systems. The system may also include a mapping module configured to map lexical tokens between patient-specific data forms used by each system component. An example method executable by a computing device having one or more processors may include receiving patient-specific health data from a source device; generating an update to a patient-specific electronic health record (EHR) for the patient; generating patient-specific electronic data capture (EDC) data associated with the patient; and updating the electronic data management system with the patient-specific EDC data.

Description

[0001] Related Applications

[0002] This application claims the benefit and priority of U.S. Patent Application 17 / 374,223, filed Jul. 13, 2021, the entire content of which is incorporated herein by reference. Background of the Invention

[0003] Patient-specific medical data obtained at hospitals, pharmacies, and / or via medical devices is often relied upon by various different electronic database systems and servers and used for various end goals. For example, clinical research, development, and trials to overcome pandemics typically involve large-scale capture of patient-specific data. Unfortunately, such patient-specific data capture often occurs in fragmented silos and / or different settings, which results in inconsistent data entry. In addition, patient-specific data captured at different settings is typically managed by different platforms and vendors, which may use different criteria for entering medical data based on their respective end goals. For patient-specific data captured for clinical trial research, billing and reimbursement, or medical record keeping, such criteria (e.g., format or syntax for entering medical data, required data fields, privacy or encryption levels, etc.) may often vary. As a result, the same patient-specific data may need to be re-entered, reformatted, and / or refined at different electronic data capture systems to achieve different end goals. For example, detailed information about a patient's fever may need to be entered into an electronic medical record for record keeping, billing, and claims forms for reimbursement purposes, as well as for the purposes of an electronic data capture system for clinical trials. This fragmentation in medical data capture typically leads to inefficient clinical data generation, poor clinical data quality, and increased costs in research, development, and healthcare delivery. Accordingly, it is desirable to seamlessly capture and transmit patient-specific data that can be utilized by multiple medical data capture systems with a single data capture.

[0004] Various embodiments are presented herein that address one or more of these disadvantages. Summary of the Invention

[0005] The present disclosure provides new and innovative systems and methods for reducing redundancy in medical database management. In an example, a method performed by a computing device having one or more processors may include, for each of a plurality of hospital information systems, for each of a plurality of source devices associated with the plurality of hospital information systems, and for each of a plurality of patients, performing one or more of the following steps: receiving patient-specific health data of a given patient from a given source device associated with a given hospital information system; generating, based on the patient-specific health data, an update to a patient-specific electronic health record (EHR) of the given patient; and generating, based on the patient-specific EHR, patient-specific electronic data capture (EDC) data associated with the given patient. In some aspects, one form of patient-specific data (e.g., EDC data) may be generated from another form of patient-specific data (e.g., EHR) by a mapping module that maps the structure, format, type, and preferred language of the original form to the new form. For example, lexical tokens may be mapped between a lexicon associated with a given hospital information system and a lexicon associated with a first electronic data management system.

[0006] The method may further include aggregating, in a first electronic data management system of a plurality of electronic data management systems, a plurality of patient-specific EDC data associated with the plurality of patients. In some aspects, the plurality of patient-specific EDC data may be generated based on one or more iterations of the foregoing steps. At a predetermined refresh interval, each of the plurality of electronic data management systems may be updated and / or synchronized to store the plurality of patient-specific EDC data associated with the plurality of patients.

[0007] In some aspects, the update and / or synchronization of each of the plurality of electronic data management systems may include: receiving an update to patient-specific EDC data of a patient among the plurality of patients from a second electronic data management system; and then, at the next occurrence of the predetermined refresh interval, and based on the update to the patient-specific EDC data of the patient, updating the plurality of patient-specific EDC data at the remaining electronic data management systems of the plurality of electronic data management systems.

[0008] The method may further include identifying a destination system for a subset of the plurality of patient-specific EDC data based on a first tag associated with the subset of the plurality of patient-specific EDC data. The subset of the plurality of patient-specific EDC data may then be sent to the destination system. Additionally, the destination system may include, for example, another hospital information system among the plurality of hospital information systems, or a second electronic data management system among the plurality of electronic data management systems.

[0009] In an example, a system for reducing redundancy in healthcare database management is disclosed. The system can include an application programming interface (API) for reducing redundancy in healthcare database management and communicatively linked to a user interface associated with each of: a plurality of hospital information systems, a plurality of source devices associated with each of the plurality of hospital information systems, and a plurality of electronic data management systems. The system can also include a mapping module configured to map lexical tokens between the plurality of source devices, the plurality of hospital information systems, and the plurality of electronic data management systems. The system can further include a memory and one or more processors communicatively coupled to the memory. The memory can store instructions that, when executed by the one or more processors, can cause the processors to perform one or more of the following steps for each of the plurality of hospital information systems, for each of the plurality of source devices associated with the plurality of hospital information systems, and for each of the plurality of patients: receive patient-specific health data of a given patient from a given source device associated with a given hospital information system; generate an update to a patient-specific electronic health record (EHR) for the given patient based on the patient-specific health data and using the mapping module; and generate patient-specific electronic data capture (EDC) data associated with the given patient using the mapping module and based on the patient-specific EHR.

[0010] When executed, the instructions can further cause the processors to aggregate the plurality of patient-specific EDC data associated with the plurality of patients in a first electronic data management system of the plurality of electronic data management systems. In some aspects, the plurality of patient-specific EDC data can be generated based on one or more iterations of the foregoing steps. At a predetermined refresh interval, each of the plurality of electronic data management systems can be updated and / or synchronized to store the plurality of patient-specific EDC data associated with the plurality of patients.

[0011] In an example, a non-transitory computer-readable medium for use on a computer system is disclosed. The non-transitory computer-readable medium can contain computer-executable programming instructions that can cause a processor to perform a method for reducing redundancy in healthcare database management. The method can include performing the following steps for each of the plurality of hospital information systems, for each of the plurality of source devices associated with the plurality of hospital information systems, and for each of the plurality of patients: receive patient-specific health data of a given patient from a given source device associated with a given hospital information system; generate an update to a patient-specific EHR for the given patient based on the patient-specific health data; and generate patient-specific EDC data associated with the given patient based on the patient-specific EHR.

[0012] The method may further include: sending, to a first electronic data management system among a plurality of electronic data management systems, a plurality of patient-specific EDC data associated with a plurality of patients based on the patient-specific EDC data generated for each of the plurality of patients; updating each of the plurality of electronic data management systems at a predetermined refresh interval and using the first electronic data management system to store the plurality of patient-specific EDC data associated with the plurality of patients; identifying a destination system for a subset of the plurality of patient-specific EDC data based on a first tag associated with the subset of the plurality of patient-specific EDC data; and sending the subset of the plurality of patient-specific EDC data to the destination system, where the destination system includes one or more of the following: (1) another hospital information system among a plurality of hospital information systems, or (2) a second electronic data management system of the plurality of electronic data management systems.

[0013] Additional features and advantages of the disclosed methods and apparatuses are described in the following detailed description and the drawings and will be apparent from the following detailed description and the drawings. The features and advantages described herein are not all-inclusive, and in particular, many additional features and advantages will be apparent to those of ordinary skill in the art from the drawings and the description. Further, it should be noted that the language used in this specification has been selected primarily for readability and guidance purposes and not to limit the scope of the inventive subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 A block diagram illustrating an example computer network environment of a fragmented system that includes an interoperable platform for capturing and using medical data and adding to reduce redundancy in medical database management.

[0015] Figure 2 A block diagram illustrating an example computer network environment for using an interoperable platform to reduce redundancy in medical database management according to an example embodiment of the present disclosure.

[0016] FIG. 3 illustrates an example of a fragmented data capture interface showing inconsistencies in the captured patient-specific data.

[0017] Figure 4 A flowchart illustrating how an interoperable platform reduces redundancy in medical data capture according to an example embodiment of the present disclosure.

[0018] Figure 5 A flowchart illustrating an example method for reducing redundancy in medical database management according to an example embodiment of the present disclosure.

[0019] Figure 6A flowchart illustrating an example method of relaying patient-specific data using an interoperable platform for reducing redundancy in medical database management in accordance with an example embodiment of the present disclosure.

[0020] Figure 7 A flowchart illustrating an example method of relaying patient-specific data related to medications using an interoperable platform for reducing redundancy in medical database management in accordance with an example embodiment of the present disclosure.

[0021] Figure 8 A flowchart illustrating an example method of relaying clinical trial data using an interoperable platform for reducing redundancy in medical database management in accordance with an example embodiment of the present disclosure. DETAILED DESCRIPTION

[0022] Patient-specific medical data obtained, for example, via medical devices in hospitals, pharmacies, testing facilities, and / or homes is typically relied upon by various different electronic database systems and servers and used for various end goals. Unfortunately, such patient-specific data capture may lack coordination or standardization and often occurs in fragmented silos. As a result, traditional methods and systems for patient-specific data capture often lead to inconsistent data entry. In addition, patient-specific data captured in different settings is typically managed by different platforms and vendors. Each platform or vendor may use different criteria for entering medical data based on their respective end goals. For example, for patient-specific data captured for clinical trial research, billing and reimbursement, or medical record keeping, such criteria (e.g., the format or syntax for entering medical data, required data fields, privacy or encryption levels, etc.) may typically vary. Thus, the same patient-specific data may need to be re-entered, reformatted, and / or refined at different electronic data capture systems to achieve different end goals. This fragmentation in medical data capture typically results in inefficient clinical data generation, poor clinical data quality, and increased costs for research, development, and healthcare delivery.

[0023] Inconsistencies between healthcare data capture sites and databases can be a major burden for healthcare and research. For example, incorrect patient data entered into an electronic system can endanger patient safety and may involve medical liability claims. The fragmented and repetitive nature of traditional patient-specific healthcare data capture typically results in healthcare providers enduring more screen time and less face-to-face time, which can be a major cause of stress and burnout among healthcare providers. In addition, healthcare data capture sites often do not adequately raise awareness of ongoing clinical research or provide access to ongoing clinical research to the public, which often results in a large portion of healthcare data capture sites being unable to recruit a single patient. For example, the vast majority of eligible cancer patients globally are often unable to participate in clinical trials used to develop essential cancer drugs. In addition, poor-quality healthcare data and manual redundant processes for capturing healthcare data (both of which can be mitigated through optimized technology) typically result in increased healthcare and research costs. As will be discussed herein, various embodiments of systems and methods for reducing redundancy in healthcare database management are described.

[0024] Patient-specific data can be presented in a variety of forms. For example, patient-specific data can include, but is not limited to, patient-specific raw data (e.g., unstructured and / or uncoded data received from a source device at the point of patient care), patient-specific electronic health records (EHRs), and patient-specific electronic data capture (EDC) data (e.g., presented to a clinical trial site). As used herein, a form can refer to the structure, format, and type of data fields for the desired or required presentation of patient-specific data by a particular computing system (e.g., a hospital information system, a clinical trial management system, a financial and billing computing system, etc.). A form can also include the desired or required language or vocabulary for data entry in those data fields. The systems and methods presented herein discuss converting or translating patient-specific data from an earlier form (e.g., patient-specific raw data) into a new form required by a destination system. As used herein, translation or conversion can include transforming the presentation of patient-specific data from a previous form into a new form, including transferring the structure, format, and type of the data fields of the patient-specific data from the previous form to the structure, format, and type of the data fields of the new form; and any change in the language or vocabulary of the terms used in the patient-specific data.

[0025] Computing Systems for Healthcare Database Management in a Network Environment

[0026] Figure 1FIG. illustrates a block diagram of an example computer network environment 100 of a fragmented system that includes an interoperable platform for capturing and using medical data and adding to reduce redundancy in medical database management. The fragmented system may include one or more source devices 102, one or more hospital information systems 108, one or more front-end electronic data capture (EDC) systems 124, one or more back-end electronic data capture (EDC) servers 136, one or more clinical data management systems 140, one or more clinical trial management systems (CTMS) 146, a risk-based monitoring system 154, an interactive voice response system 156, and a financial system 158. Each system of the network environment 100 may communicate with one or more of the remaining systems via a communication network. Figure 1 Also illustrated is a server (e.g., a front-end interoperable capture system (FICS) server 160) of an interoperable platform for reducing redundancy in medical database management. The FICS server 160 may be added (e.g., as shown by the dashed line addition) to a network of a fragmented system that includes an interoperable platform for capturing and using medical data to reduce redundancy in medical database management. As will be discussed in conjunction with Figure 2 As further discussed, the FICS server 160 may help eliminate redundancy in medical database management by more effectively managing patient-specific data streams via the fragmented system described above. In addition, Figure 2 The components of the FICS server 160 and how adding the FICS server 160 to the network environment of the fragmented system changes the relationships of the fragmented system will be described in more detail.

[0027] The source device 102 may include a stand-alone or portable computing device (e.g., a mobile device, a personal digital assistant, a laptop computer, a tablet computer, a smart camera, etc.) having one or more of the sub-components described herein to allow a user (e.g., a medical staff member, a patient, a caregiver, etc.) to obtain measurement data of patient-specific medical data and / or input patient-specific medical data. Each source device 102 may include a user interface 106 for allowing a user to enter patient-specific data, for example, as patient-specific raw data. In some aspects (e.g., where the source device is a wearable medical device and / or a medical instrument), the source device may include one or more sensors 104 for obtaining measurement results including patient-specific raw data. For example, the sensor 104 may include a thermometer for obtaining a patient's body temperature, a sphygmomanometer for obtaining a patient's blood pressure, a blood glucose meter for obtaining a patient's blood glucose level, etc.

[0028] The hospital information system 108 may include one or more computing systems that facilitate the import of patient-specific data and the storage of patient-specific electronic health records (EHRs) 112 in a database (e.g., patient database 110). The hospital information system 108 may include, but is not limited to, a pharmacy information system 114, a radiology information system 116, a pathology information system 118, a laboratory information system 120, and other health information systems 122.

[0029] The front-end EDC system 124 includes one or more computing systems that allow users (e.g., medical staff, researchers, scientists, etc.) to enter, access, and / or analyze electronic patient-specific data used, for example, in clinical trials, clinical data management, risk-based monitoring, or finance and billing. The front-end EDC system 124 may include a user-facing interface (e.g., EDC interface 126) that is capable of receiving electronic patient-specific data to be entered for storage in the back-end EDC server 136. The EDC interface 126 may include, for example, a user interface, an input / output module, a display, and other functionality that allows for the entry of data. The front-end EDC system 124 may include a query engine 128 that may include software, programs, modules, and / or plugins that allow users to search for specific patient-specific EDC data and receive query results (e.g., answers to questions, search results, the location of specific EDC data or files, etc.). The analysis interface 130 may allow users to analyze the results, trends, predictions, and / or comparisons of patient-specific EDC data stored in the back-end EDC server 136, for example, in audio, visual, and / or text form.

[0030] The back-end EDC server 136 may include one or more servers for storing patient-specific EDC data in one or more databases (e.g., EDC repository 138). For example, the EDC repository 138 may be updated and / or accessed by the front-end EDC system 124. In some aspects, other computing systems in the network environment 100 (e.g., CDMS 140, CTMS 146, risk-based monitoring system 154, IVR system 156, and finance system 158) may access, update, and / or retrieve, and / or copy the EDC data stored in the back-end server 136. These other computing systems may include separate databases that also store a subset of the EDC data stored in the back-end EDC server 136. In some aspects, the back-end EDC server 136 may be remote from the front-end EDC system 124. By its association with the front-end EDC system 124, the back-end EDC server 136 may include an electronic data management system.

[0031] The CDMS 140 may include an electronic data management system for storing and accessing clinical trial data that complies with applicable regulatory requirements. For example, the CDMS 140 may include one or more servers that access a backend EDC server 136 to query and / or analyze clinical trial data from a database of patient-specific EDC data (e.g., the EDC repository 138). In some aspects, the CDMS 140 may include a query engine 142 and an analysis interface 144. The query engine 142 may include software, programs, modules, and / or plugins that allow a user to search for clinical data from the stored patient-specific EDC data and receive query results (e.g., answers to questions, search results, the location of specific clinical data or files, etc.). The analysis interface 144 may allow a user to analyze the results, trends, predictions, and / or comparisons of clinical data generated from patient-specific EDC data stored, for example, in the backend EDC server 136 in audio, visual, and / or text form. In some aspects, the clinical data management system 140 may reformat, aggregate, and / or otherwise convert patient-specific EDC data into clinical trial data.

[0032] The CTMS 146 may include an electronic data management system whereby the sponsor of a clinical trial can enter data, upload documents, analyze data, track documents, and monitor the progress of a clinical trial. The CTMS 146 may include one or more servers that communicate with the backend EDC server 136 to request and receive patient-specific EDC data related to a clinical trial. The CTMS 146 may include a safety monitoring system 148, a clinical trial management interface 150, and an electronic trial master file (eTMF) 152. The safety monitoring system 148 may include any software, application, program, or module to assist in monitoring safety in a clinical trial in accordance with regulatory requirements. The clinical trial management interface 150 may include a user interface, application interface, software, application, or program for allowing a user to initiate, conduct, and / or manage a clinical trial. The eTMF 152 may include an electronic repository for storing and sharing basic clinical trial documents, images, and other digital content that complies with applicable regulatory requirements.

[0033] The network environment 100 may also include other computing systems 153 that may rely on the stored patient-specific EDC data, such as a risk-based monitoring system 154, an IVR system 156, and a financial system 158. Such patient-specific EDC data may need to be re-converted, re-formatted, enhanced, and / or manually re-entered based on the requirements of a given computing system or the functionality of a given computing system (e.g., risk monitoring, IVR, billing, etc.).

[0034] System components of an interoperable platform for reducing redundancy in medical database management

[0035] Figure 2 FIG. illustrates a block diagram of an example computer network environment 200 for using an interoperable platform to reduce redundancy in medical database management in accordance with an example embodiment of the present disclosure. Additionally, the computer network environment 200 may result from the transformation of a previously fragmented environment for capturing and using medical data by different and / or fragmented systems via an interoperable platform. The transformation may help reduce redundancy and fragmentation in medical database management by allowing the capture and storage of patient-specific data to be more standardized (e.g., by automatically reformatting data into other formats), more synchronized across medical databases (e.g., by periodically ensuring that one or more databases are updated with the latest patient-specific data), and more accessible to users (e.g., by automatically directing patient-specific data to destination systems and seamlessly allowing the retrieval, tagging, and / or otherwise compilation of data based on clinical trials). Additionally, the transformation may improve the collective processing time of various operations (e.g., requesting, searching, and compiling relevant clinical information for clinical trials) by using tags generated immediately in real-time after capturing patient-specific raw data from devices at different locations and then directing the patient-specific data with associated tags to appropriate locations. This approach is proactive compared to traditional methods that rely on initiating clinical trials to communicate with clinics and hospitals to query relevant patient-specific data. Additionally, the standardization of patient-specific data and the dynamic generation of patient-specific forms (e.g., by prompting operators to provide additional data based on previous inputs and / or based on insufficient responses) allow for higher accuracy and reliability of patient-specific data exchanged across different computing systems.

[0036] The network environment 200 may include servers of an interoperable platform for reducing redundancy in medical database management (e.g., a Front-End Interoperable Capture System (FICS) server 202), multiple source devices 242, one or more hospital information systems 248, and multiple electronic data management systems 290. The multiple electronic data management systems 290 may include, but are not limited to, one or more of an Electronic Data Capture (EDC) server 258, a Clinical Trial Management System 266, a Clinical Data Management System 274, and other data management systems 282 (e.g., a risk-based monitoring system, a finance and / or billing system, a health insurance claims system, etc.). Each system of the network environment 100 may communicate with one or more of the remaining systems via a communication network 240. The communication network 240 may include wired and wireless networks. Examples of wired networks may include a Wide Area Network (WAN) or a Local Area Network (LAN), a client-server network, a peer-to-peer network, etc. Examples of wireless networks include Wi-Fi, a Global System for Mobile Communications (GSM) network, a General Packet Radio Service (GPRS) network, an Enhanced Data GSM Environment (EDGE) network, an 802.5 communication network, a Code Division Multiple Access (CDMA) network, a Bluetooth network, or a Long-Term Evolution (LTE) network, an Advanced LTE (LTE-A) network, or a Fifth Generation (5G) network.

[0037] In addition, each source device 242, hospital information system 248, EDC server 258, clinical trial management system 266, and clinical data management system 274 may share one or more components and perform one or more functions previously described separately for source device 102, hospital information system 108, backend EDC server 136, clinical trial management system 146, and clinical data management system 140. For example, one or more hospital information systems (HIS) 248, such as the hospital information system 108 shown in Figure 1 may store patient-specific electronic health records (EHRs) 252, similar to EHR 112. As another example, each EDC server 258 may include an EDC repository 262, which stores patient-specific EDC data similar to the Figure 1 EDC repository 138 shown. In at least one embodiment, the FICS server 160 may reduce or eliminate the need for different front-end electronic data capture systems by automatically converting patient-specific data obtained from source devices 242 and hospital information systems 248 into patient-specific EDC data (e.g., as shown in Figure 1as in the front-end EDC system 124 shown. In some aspects, components or functionality previously described for the front-end EDC system 124 may be included or performed by one or more devices or systems associated with the hospital information system 248. Additionally or alternatively, components or functionality previously described for the front-end EDC system 124 may be included or performed by one or more devices or systems associated with the EDC server 258.

[0038] In some aspects, each system of the network environment 200 (e.g., the FICS server 202, each source device 242, each hospital information system 248, or each electronic data management system 290) may include a network interface (e.g., network interface 234, network interface 244, network interface 254, network interface 260, network interface 268, network interface 276, and network interface 284) that allows the corresponding system to communicate with other systems via the communication network 240. For example, the corresponding network interface may include a wired interface (e.g., an electrical interface, an RF interface (via coaxial cable), an optical interface (via optical fiber)), a wireless interface, a modem, etc.

[0039] The FICS server 202 may include a local or remote computing system that serves as an interoperable platform for reducing redundancy in medical database management. The FICS server 202 may include a FICS Application Programming Interface (API) 204 to provide and manage interfaces for applications (e.g., FICS Application 246, FICS Application 256, FICS Application 261, FICS Application 270, FICS Application 278, and FICS Application 286, etc.) used by one or more systems of the network environment 200 to reduce redundancy in medical database management. The ability of users at each computing system to use the applications to contribute to and / or take advantage of opportunities to reduce redundancy in medical database management will be further explained herein. The corresponding applications (FICS Applications) may include cloud-native web-based applications built on React / Javascript. In addition, the FICS Applications may include user interfaces that allow form-based (e.g., having structured fields) data entry. Additionally or alternatively, the FICS Applications may allow the entry of natural, unstructured patient-specific data (e.g., patient-specific raw data), which may be arranged by the FICS server 202 into structured fields. Further, the FICS Applications may allow users to visualize data stored in the medical database (e.g., tables, aggregated information, dashboards, etc.). Each system that utilizes the application may be identified by the FICS server 202 via corresponding device and / or system IDs (e.g., Source Device ID 243, Hospital Information System (HIS) ID 250, EDC Server ID 264, CTMS ID 272, CDMS ID 280, System ID 288), allowing the FICS server to efficiently and accurately receive requests for information (e.g., patient-specific data) between systems, retrieve, process, transform, and relay the information. For example, the FICS server 202 may receive patient-specific data from a given source device 242, identify the source device 242 by its Source Device ID 243, transform the patient-specific data into a form suitable for the electronic health record 252, identify the HIS as the destination of the EHR 252 by mapping the Source Device ID 243 to the HIS ID 250 associated with the HIS 248, and send the EHR to the identified HIS 248.

[0040] The FICS server 202 may include an EHR module 206, software and / or hardware subcomponents of the FICS server 202 for generating patient-specific EHR data. For example, the EHR module may generate patient-specific EHR data by prompting the input of EHR data via a source device 242 and / or by converting patient-specific health data already received from the source device 242 into patient-specific EHR data (e.g., by reformatting or changing the syntax of the patient-specific health data). The EHR module 206 may include a natural language processor (NLP) 208, a form generator 210, and multiple patient profiles 212 associated with multiple patients. The NLP 208 may include one or more processors, processing units, programs, applications, and / or plugins for processing and analyzing natural language data (e.g., audio and / or text natural language). The NLP may include, for example, a parser, a lexical analyzer, and a tokenizer to determine, for example, recognizable tokens from an input natural language string for processing by the FICS server 202. The form generator 210 may include programs, applications, and / or plugins for generating data fields of an electronic health record form. The specific identity, type, quantity, and scope of the data fields of the EHR may vary based on the patient. In some aspects, the data fields may vary based on the hospital information system or electronic data management system seeking the EHR. In additional aspects, one or more subsequent data fields of the EHR form may be generated dynamically based on the completion (e.g., entry of a response) of another data field of the EHR form. Since the data fields of the EHR form are populated with responses related to the patient, for simplicity, the populated EHR form with patient-specific information may be referred to as patient-specific EHR. Each patient-specific EHR may be linked to or otherwise associated with a patient profile. The patient profiles 212 may include a repository of identifiers of different patients to map, associate, link, and / or reference various patient-specific data (e.g., patient-specific EHR data) of each patient.

[0041] The FICS server 202 may also include, for example, as part of its FICS API 204, a mapping module 214. The mapping module 214 may include software and / or hardware sub-components of the FICS server 202 for mapping and converting a first type of patient-specific medical data into a second type of patient-specific medical data. The types of patient-specific data may include, but are not limited to, patient-specific raw data, patient-specific electronic health records (EHRs), and patient-specific electronic data capture (EDC) data. Patient-specific raw data includes data obtained at the source device 102. Patient-specific raw data may include, for example, uncoded data related to a patient's health or medical history. Raw data may be obtained from medical devices (e.g., instrument measurements), handwritten notes scanned and uploaded to the source device, data entered via forms generated by the FICS server 202, etc. Patient-specific EHRs may include a coded and systematized collection of a patient's health information in digital format. Patient-specific EHRs may include a range of data, including but not limited to demographics, medical history, medications and allergies, immunization status, laboratory test results, radiology images, vital signs, personal statistics such as age and weight, and billing information. While EDC data may include medical data related to a specific clinical trial, patient-specific EDC data may include EDC data attributable to a specific patient. EDC data and / or patient-specific EDC data may be further segmented and / or customized (e.g., based on preferred syntax, forms, etc.) based on the electronic data management system 290 that utilizes it (e.g., a clinical trial management system 266, a clinical data management system 274, or other data management system 282). For each of the above types of patient-specific data, the mapping module 214 may store a repository or database of terms (e.g., raw terms 215, EDC terms 216, EHR terms 218) associated with each type.

[0042] The mapping module 214 may also include one or more dictionaries (e.g., dictionary 222) to determine the definition of each term. For example, a dictionary may be a program that identifies the scope of a given term based on other terms falling within the given term. The mapping module 214 may include a linking engine 224, which may include a program, application, software, or code that can periodically form links or associations between one term (e.g., for a first type of patient-specific data) and another term (e.g., for a second type of patient-specific data). For example, the linking engine 224 may be used to form an association between a common name of a symptom and a clinical name of the symptom, where the common name of the symptom may be a term used in patient-specific raw data, and the clinical name of the symptom may be a term used in patient-specific EDC data. In some aspects, the FICS server 202 may identify the information it receives as belonging to one or more of the above types of patient-specific data based on the information sent by the source system. Thus, the FICS API 204 can facilitate the mapping of terms used between different presentation forms of patient-specific data (e.g., patient-specific raw data versus patient-specific EHR versus patient-specific EDC forms). Patient-specific data entered in accordance with a specific data dictionary can be translated into appropriate matching terms of another data dictionary. For example, medical staff may enter a patient's medication at the source device 242 according to the RX NORM standard. The FICS API 204 can translate this patient-specific data into the WHO DRUG standard typically used in datasets for regulatory submissions.

[0043] The source verification unit 220 may be a sub-component of the mapping module 214 that has instructions for identifying the source system of the information (e.g., source device 242, hospital information system 248, EDC server 258, clinical trial management system 266, clinical data management system 274, or other data management system 282). In some aspects, the source verification unit 220 and / or the linking engine 224 may be used to map or associate one or more source systems with each other, e.g., for the purpose of relaying information to the correct destination. For example, one or more source devices 242 may be associated with a specific hospital information system 248 (e.g., various computing systems in a pharmacy). Additionally, the source verification unit 220 may track or identify each source system by its respective system or device identifier of each source system (e.g., source device ID 243, hospital information system (HIS) ID 250, EDC server ID 264, CTMS ID 272, CDMS ID 280, system ID 288).

[0044] The FICS server 202 may include a tag generator 226. The tag generator 226 may be a software and / or hardware component of the FICS server 202 that may generate metadata or tags based on received patient-specific data. The tags may be based on processing and identifying various characteristics of the received patient-specific data, such as the patient associated with the patient-specific data, the source system from which the patient-specific data originated, the nature of the patient-specific data (e.g., diagnosis, treatment, drug, therapy, billing, examination, measurement, or reading, etc.), the time and / or date of generation or receipt of the patient-specific data, the intended recipient, any clinical trials associated with the patient-specific data, any drug development associated with the patient-specific data, etc.

[0045] The FICS server 202 may include a refresh application programming interface (API) 228, a processor 230, a memory 232, a network interface 234, a data relay unit 236, an update interface 238, and an encryption unit 239. The refresh API 228 may include any application, program, software, code, or plug-in that allows operations and data transmissions performed since the last refresh to be accessible at periodic intervals during the next refresh, thereby allowing the transmission, reformatting, transformation, and storage of medical data to occur in real-time or near real-time. The processor 230 may include any one or more types of digital circuits configured to perform operations on data streams, including the functions described in this disclosure. The memory 232 may include any type of long-term, short-term, volatile, non-volatile, or other memory and is not limited to any particular type of memory or the specific amount of memory, or the type of medium on which the memory is stored. The memory may store instructions that, when executed by the processor 230, enable the FICS server 202 to perform one or more of the methods discussed herein. The data relay unit 236 may include any application, program, software, code, or plug-in that can receive patient-specific data, identify (e.g., via a tag or metadata associated with the patient-specific data) the intended destination, determine the network address associated with the intended destination, and send the patient-specific data. In some aspects, the patient-specific data may be pre-converted into the desired format, syntax, and / or structure of the intended destination. In other aspects, the data relay unit 236 may cause the mapping module 214 to convert and / or transform the patient-specific data into the desired format, syntax, and / or structure (e.g., patient-specific raw data to patient-specific EHR, patient-specific raw data to patient-specific EDC data, patient-specific EHR to patient-specific EDC data, etc.) after identifying the intended destination. The update interface 238 may include any application, program, software, code, or plug-in for allowing an operator or an external system to update one or more databases or repositories of the FICS server 202. For example, the update interface 238 may allow an operator to enter into the dictionary 222, for example, a raw term database 215, an EDC term database 216, and / or an EHR term database 218 for newly identified diseases or symptoms, or newly discovered treatments. It should be understood that patient-specific data may include sensitive or confidential information. The intended destination may not necessarily be authorized to view all or some aspects of the patient-specific data. Based on the intended destination of the patient-specific data, the encryption unit 239 may include an application, program, software, code, or plug-in for implementing methods for encrypting and decrypting electronically protected health information. The encryption and decryption protocols implemented by the encryption unit 239 may comply with regulations (e.g., HIPAA). In some aspects, the FICS server 202 is capable of creating appropriate restrictions on access to medical databases.For example, various forms of patient-specific data generated by FICS (eg, from patient-specific raw data submissions) can have access to protected health information removed, encrypted, and / or restricted.

[0046] Traditional methods of managing medical databases

[0047] Fig. 3 illustrates an example of a fragmented data capture interface, which shows inconsistencies in captured patient-specific data. The patient-specific data entered in the two data capture interfaces belong to the same patient and have the same medical experience (e.g., medical diagnosis, symptoms, treatment, etc.), but the differences in the format, grammar, and / or structure of each data capture interface reveal inconsistencies. For example, data capture interface 302 shows an example patient-specific electronic health record (EHR) entered as a clinical note during a study visit. Patient-specific EHRs are entered in a form in a subjective, objective, assessment, and plan (SOAP) format commonly used in electronic health records. Subjective section 304 can prompt the input of the patient's chief complaint, including symptoms and medical history of the current disease. Objective section 306 can prompt the input of any information (e.g., vital signs, laboratory results, physical examination results, etc.) that a healthcare provider can observe or measure from the patient's current presentation. Assessment section 308 can prompt the input of information about the patient's progress toward recovery written from a doctor's perspective. Plan section 310 can prompt the input of a healthcare provider's plan for treating the patient's disease. However, as shown in the entry of these fields, information entry into traditional EHR forms often includes unstructured free text filled with medical terms and abbreviations (e.g., CLL, C5D1, Wnl, RUL, CXR, F / u, c / f, etc.) In addition, the format (e.g., SOAP) that suggests data structure for information entry often results in missing information that may be critical data elements for other medical contexts and databases (e.g., clinical trials).

[0048] For example, the data capture interface 312 shows example patient-specific EDC data entered as part of a case report form (CRF) adverse event log for the same patient with the same medical history. The CRF adverse event log shows that the patient suffered an adverse event (e.g., pneumonia), and can be used to track the effectiveness of treatment in a clinical trial. However, the data capture interface 312 shows that key trial data elements are missing. For example, the data capture interface 312 is missing an end date 314, an indication of additional adverse events 315 (e.g., CLL as mentioned in the patient-specific EHR), and other medications 316. These elements are typically required during generation of patient-specific EDC data for entry into the case report form. However, the systems and methods presented herein can allow for prompting such key data elements for entry or otherwise obtaining such key data elements from an early stage of patient-specific data capture (e.g., when capturing patient-specific raw data). The original source of patient-specific data (e.g., patient-specific raw data), as well as the systems and methods for prompting entry of such patient-specific data, can be automatically used to populate forms and data structures required by different medical databases (e.g., EHR, EDC data). As will be discussed herein, automatically generating forms from patient-specific raw data can eliminate or reduce inconsistent information and missing data elements in different forms.

[0049] Reducing Redundancy in Medical Data Capture

[0050] Figure 4 FIG. shows a flow chart illustrating how an interoperable platform according to an example embodiment of the present disclosure reduces redundancy in medical data capture. Specifically, Figure 4 FIG. shows how an FICS server (e.g., Figure 1 the FICS server 160 shown in Figure 2 or the FICS server 202 shown in Figure 4 helps reduce redundancy in a manner that transfers, transforms, reformats, and updates patient-specific data across medical databases, which helps eliminate or reduce the problems of inconsistent and missing patient-specific data shown in FIG. 3 above. The method 400 shown in Figure 4Illustrated is a scenario where a patient undergoes laboratory tests (e.g., blood tests) and then comes to a healthcare provider (e.g., a family doctor) for a physical examination. The laboratory tests can be performed in an associated laboratory facility, where the laboratory results can be uploaded to a laboratory information system (e.g., an example of the health information system 248). The physical examination can be performed at a hospital or a clinic, where the healthcare provider can enter patient-specific data via the source device 242 (e.g., an office computer near the patient's bedside). Additionally, the patient may or may not have ongoing conditions and / or ongoing treatments relevant to clinical researchers. Such clinical researchers can participate in clinical trials and can be able to access and / or update patient-specific data via the clinical trial management system 266. Figure 4 The method 400 shown in Figure 4 can reduce redundancy in the steps traditionally performed by hospital information systems, healthcare providers, and clinical researchers when accessing, entering, and updating patient-specific data.

[0051] For example, before the patient arrives at the healthcare provider's office, the healthcare provider (e.g., the patient's family doctor) may want to know the patient's laboratory test results (e.g., blood test results). The healthcare provider can request the laboratory test results via the FICS application 246 on the source device 242 (e.g., the healthcare provider's office computer). In response to the request, the FICS server can retrieve pre-visit laboratory data from the health information system (e.g., the laboratory information system of the laboratory test facility) (block 402). This step can be an improvement over traditional methods, according to which it is the task of the patient or the laboratory technician to manually provide the patient's laboratory results, and the healthcare provider spends time and effort understanding the laboratory test results and entering the laboratory test results into the source device 242.

[0052] Then, healthcare personnel can analyze pre-visit laboratory data (e.g., by accessing it via the FICS application 246 on their source device 242) to prepare for a patient visit. After seeing the patient during the visit, the healthcare personnel can enter patient-specific data based on the patient visit into their FICS application (block 404). The laboratory test results and patient-specific data entered by the doctor can be considered patient-specific raw data because such data may not yet be encoded or arranged in the required form or syntax by various medical databases. The FICS server 202 can receive the patient-specific data and laboratory test data entered by the healthcare personnel and can automatically populate the electronic health record (EHR) associated with the patient (block 406). The FICS server 202 can also use the received patient-specific raw data to generate fields for the corresponding patient-specific EDC data (block 408). For example, as previously discussed, the FICS server 202 can rely on a dictionary of terms used in the raw data, EHR data, and EDC data to map the input terms in the patient-specific raw data to the corresponding terms required by the EHR and EDC forms. In some aspects, the FICS server can determine whether a particular form (e.g., an EHR or EDC form) requires additional entry (e.g., final data for a disease) and can prompt the user of the FICS application (e.g., healthcare personnel) for additional input.

[0053] The patient-specific EDC data can be used by clinical researchers. For example, research investigators may be particularly interested in the diseases that a patient has or is suffering from. After analyzing the EDC data related to the patient (e.g., via the FICS application 278 on the clinical data management system 274), the investigator may want to consult the patient to learn more about the disease and any ongoing treatments. The investigator can evaluate the patient and enter additional patient-specific raw data (e.g., notes about their observations of the patient's recovery) into their FICS application (block 410). After receiving the patient-specific raw data, the FICS server 202 can automatically update the patient-specific EHR (block 412) and can automatically update the corresponding patient-specific EDC data (block 414).

[0054] In addition, as previously discussed with respect to the Refresh API 228, the FICS server 202 can routinely synchronize and update in real-time or near real-time a medical database managed by the FICS server 202. This can occur due to ensuring the completion of operations initiated since the previous refresh interval before each subsequent refresh interval (e.g., data transfer, data transformation, data consistency checks between databases, etc.). In some aspects, the completion of the operations may require prompting a user of the FICS API that previously entered patient-specific data to enter any required information to populate relevant forms (e.g., EHR, EDC forms using CTMS and CDMS, etc.). By performing such synchronization and routine update processes, the FICS server can check and confirm that patient-specific data entered in different forms (e.g., EHR and EDC) is consistent (block 416).

[0055] Automatic data capture, translation, and synthesis of patient-specific data across platforms for medical database management

[0056] Figure 5 A flowchart of an example method 500 for reducing redundancy in medical database management in accordance with an example embodiment of the present disclosure is illustrated. One or more steps of method 500 can be performed by a processor 230 of the FICS server 202, for example, based on instructions stored in the memory 232 and based on information received via applications (FICS applications) running on various other devices and computing systems.

[0057] Method 500 can begin with receiving patient-specific raw data for each of a plurality of patients (block 502). As previously described, patient-specific raw data can include, for example, uncoded data related to a patient's health or medical history. The raw data can be obtained from medical devices (e.g., instrument measurements), handwritten notes scanned and uploaded to a source device, data entered via forms generated by the FICS server 202, etc. In some aspects, for example, when the patient-specific raw data is handwritten or in natural language or unstructured form, the NLP 208 of the FICS server 202 can identify lexical tokens and attempt to organize the patient-specific raw data into categories useful for entry in a particular form (e.g., EHR).

[0058] For each patient, the FICS server can determine whether the received patient-specific raw data meets the adequacy threshold of the electronic health record (EHR) (block 504). If the adequacy threshold is not met, the FICS server can prompt for additional input of patient-specific data (block 506). For example, the FICS server 202 can rely on the form generator 210 to create a template EHR. The EHR can be automatically populated with patient-specific raw data. However, if the data fields of the template EHR are lacking or are determined to be insufficient in response (e.g., by the EHR module 206 learning whether lexical tokens meet the requested information within the data field), the FICS server can determine that the adequacy threshold has not been reached. In some aspects, the process of validating completion can occur at the local level. For example, the user interface of the FICS application can verify whether all or most of the required data fields in a particular form are complete. If any or a sufficient number of the required data fields are incomplete (e.g., the date of birth is missing from the patient demographics), the user interface of the FICS application can warn the user (e.g., medical staff) that the form is incomplete and can prevent the user from sending the patient-specific data to the FICS server 202. Whether done locally or at the FICS server, this validation can help ensure the integrity of the patient-specific data before it is transmitted to the FICS server 202 for transformation and storage in the medical database.

[0059] If the adequacy threshold of the EHR is met, the FICS server can generate an update to the corresponding patient-specific EHR for each of the multiple patients based on the patient-specific data of each of the multiple patients (block 508). For example, the patient can be identified from the submitted patient-specific raw data (e.g., retrieving the patient profile 212 associated with the patient via the FICS server 202), and any existing EHR file associated with the patient can be retrieved. In some aspects, a new EHR file can be created for the patient based on the received patient-specific data.

[0060] At block 510, the FICS server can generate patient-specific electronic data capture (EDC) data associated with each of the multiple patients based on the patient-specific EHR of each of the multiple patients.

[0061] The FICS server can determine whether there is a correspondence (e.g., consistency) between the terms of the EHR and the EDC associated with each patient (block 512). In some aspects, as part of the FICS server's routine check for the consistency of data stored across various medical databases, this determination can be periodic (e.g., at a refresh interval).

[0062] If no correspondence exists, the FICS server can prompt for an update to the patient-specific EDC data (block 514). For example, the FICS server can notify, via the FICS application, the user of the patient-specific EDC data who may have previously entered the missing fields. The FICS server can identify the missing fields by searching a list of forms that can be populated with the patient-specific data (e.g., the EDC data used in various clinical study forms), and identify any under-entered or missing data fields.

[0063] If the correspondence is satisfied, and / or after prompting for an update to the patient-specific EDC data, the FICS server can aggregate the multiple patient-specific EDC data associated with multiple patients in one or more of the multiple electronic data management systems (block 516). The electronic data management systems can include, but are not limited to, the EDC server 258, the clinical trial management system 266, the clinical data management system 274, and the other data management systems 282.

[0064] In addition, at a predetermined refresh interval, the FICS server can update each of the multiple electronic data management systems to store the multiple patient-specific EDC data associated with multiple patients (block 518). For example, the FICS server can routinely compare the patient-specific data stored in each electronic data management system and check whether the patient-specific data is consistent, even though the format, syntax, or structure of the patient-specific data at the time of storage can be different between each electronic data management system.

[0065] Relaying Patient-Specific Data

[0066] Figure 6 A flowchart of an example method 600 for relaying patient-specific data using an interoperable platform for reducing redundancy in medical database management, in accordance with an example embodiment of the present disclosure, is illustrated. Specifically, once the FICS server has received and stored the patient-specific data and is determining whether and how to transform, reformat, transmit, and relay the patient-specific data to another computing system in the network of computing systems involved in medical data management, one or more steps of method 600 can be performed. One or more steps of method 600 can be performed by a processor 230 of the FICS server 202 (e.g., based on instructions stored in the memory 232) and based on information received via an application (the FICS application) running on various other devices and computing systems.

[0067] As part of a routine process, the FICS server can re-organize patient-specific data (block 602). In some aspects, this step can occur when the patient-specific data is generated. For example, the patient-specific data can be generated as raw data entered via the source device 242, or can be generated after the FICS server automatically populates a specific form (e.g., EHR, EDC data, etc.) using the raw data. Additionally or alternatively, the FICS server can routinely retrieve the patient-specific data for each patient from a storage database of an electronic data management system, for example.

[0068] For each patient-specific data, the FICS server can determine whether there are any tags (block 604). As previously discussed, a tag can be a form of metadata (e.g., generated by the tag generator 226) that can indicate one or more characteristics of the received patient-specific data, such as the intended destination. Thus, if a tag is found, the FICS server can identify the destination of the patient-specific EDC data (block 606). The destination can include, for example, a certain CDMS, a certain CTMS, another electronic data management system (e.g., a billing and financial calculation system), etc. Additionally, detailed information about the destination can be looked up, including, for example, the network address and the desired or required form, format, syntax, or structure of the patient-specific data.

[0069] The FICS server can determine whether the identified destination requires a different syntax or structure for presenting the patient-specific data (block 608). For example, a particular destination may typically use a specific form and data fields to analyze the patient-specific data and may therefore require the patient-specific data to be filled into such a form. As used herein, a form can refer to the structure, format, and type of data fields for the desired or required presentation of patient-specific data by a particular computing system. A form can also include the desired or required language or vocabulary for data entry in those data fields. Thus, the FICS server can determine whether the received patient-specific data is in a form different from the form required by the destination system.

[0070] If different forms exist, the FICS server may transform the patient-specific data from its earlier form into the form required by the destination system (block 610). As used herein, translating or transforming may include transforming the presentation of patient-specific data from a previous form into a new form, which includes transferring the patient-specific data from the structure, format, and type of the data fields of the previous form to the structure, format, and type of the data fields of the new form, as well as any changes in the language or vocabulary of the terms used in the patient-specific data. If it is determined at block 608 that the forms are not different, the FICS server may send the patient-specific data of a given patient to the destination system (block 612). Alternatively, after the patient-specific data has been translated in block 610, the FICS server may send the translated patient-specific data to the destination system.

[0071] Figure 7 FIG. illustrates a flow chart of an example method 700 for relaying patient-specific data related to a drug using an interoperable platform for reducing redundancy in medical database management in accordance with an example embodiment of the present disclosure. Additionally, method 700 may provide a more specific example of implementing method 600 in the context of relaying patient-specific data about a drug to a pharmacy information system. One or more steps of method 700 may be performed by a processor 230 of the FICS server 202 (e.g., based on instructions stored in the memory 232) and based on information received via applications (FICS applications) running on various other devices and computing systems.

[0072] At block 702, the FICS server may view patient-specific EHR data. For example, the patient-specific EHR data may be viewed as part of a re-organization of the patient-specific data for each patient (e.g., as part of step 602 in Figure 6 ).

[0073] For a given patient's given patient-specific EHR data, the FICS server may determine whether the patient-specific EHR data includes a drug order (block 704). For example, the FICS server may look for tags within the EHR data that indicate a drug. In some aspects, the FICS server may identify terms associated with a drug based on a repository of EHR terms 218 stored in the mapping module 214. If no drug order is identified, the FICS server may continue to view the other patient-specific EHR data for the given and remaining patients.

[0074] If a drug order is recognized, the FICS server can identify the pharmacy information system (block 706). For example, the FICS server can identify the original sender of the patient-specific EHR data (e.g., the hospital information system 248 and / or the source device 242), and then locate the pharmacy information system associated with the original sender (e.g., a pharmacy connected to the hospital). Additionally or alternatively, the FICS server can view the patient profile 212 of the patient associated with the EHR data, identify the pharmacy that the patient may have specified, and then determine the pharmacy information system associated with the pharmacy.

[0075] The FICS server can then receive a conformance profile associated with the pharmacy information system (block 708). The conformance profile can include a prior agreement between the electronic health record system and the destination system (e.g., the pharmacy information system). Additionally, the conformance profile that can be stored for each destination system can specify the form requirements of the message (e.g., patient-specific data) for the message to be accepted by the destination system. For example, a pharmacy information system typically requires the HL7 V2 message format to transmit the appropriate information needed to execute a process (e.g., ordering a drug).

[0076] Thus, the drug order can be transformed to ensure conformance with the conformance profile (block 710). For example, as in Figure 6 block 610, the FICS server can translate and / or transform the drug order from its previous form (e.g., as a data field within the patient-specific EHR) into a form that conforms to the conformance profile (e.g., the HL7 V2 message format).

[0077] The FICS server can then send the transformed drug order to the pharmacy information system. For example, the FICS server can access the network address associated with the pharmacy information system identified in 706 and send the drug order via the communication network 240 using the network interface 234.

[0078] Using an interoperable platform for clinical trials

[0079] Figure 8 FIG. shows a flowchart of an example method 800 of relaying clinical trial data using an interoperable platform for reducing redundancy in medical database management in accordance with an example embodiment of the present disclosure. One or more steps of method 800 can be performed by a processor 230 of the FICS server 202 (e.g., based on instructions stored in the memory 232) and based on information received via applications (FICS applications) running on various other devices and computing systems.

[0080] At block 802, the FICS server may receive an electronic trial master file (eTMF). The eTMF may contain important clinical trial documents, images, and other digital content that comply with applicable regulatory requirements. In some aspects, a subset of the documents associated with the clinical trial may be received rather than the entire eTMF. For example, a researcher may wish to utilize the systems and methods presented herein to obtain a large amount of patient-specific data for a clinical trial. The researcher may request, for example, via the FICS application 270 of the CTMS 266, any patient-specific data related to the clinical trial and may be prompted to submit the eTMF or eTMF files for the FICS server to identify relevant terms for label generation.

[0081] Using the eTMF or a subset of the eTMF, one or more labels associated with the clinical trial may be generated (e.g., at block 804). For example, the eTMF may be scanned to obtain relevant clinical terms (e.g., specific diseases, specific medications, specific treatment plans, etc.), and labels may be generated for those relevant clinical terms (e.g., via the label generator 226).

[0082] The FICS server may query the aggregated patient-specific EDC data to retrieve a subset of the patient-specific EDC data associated with one or more labels. For example, the FICS server may send a query request to the EDC server 258 for all stored patient-specific EDC data having the generated labels. In some aspects, the labels may include terms that may appear within the patient-specific EDC data (e.g., when decoded from encryption). The EDC server 258 may then send (e.g., as a copy) a subset of its stored patient-specific EDC data that has one or more labels or is associated with one or more labels.

[0083] The FICS server may then send the subset of the patient-specific EDC data associated with one or more labels to the clinical trial management system (block 808). The method 800 may occur incrementally, for example, when new patient-specific data is received, generated as patient-specific EDC data, stored in the EDC server 258, and periodically queried by the FICS server. In some embodiments, the patient-specific EDC data may be sorted or otherwise classified by relevance, for example, based on the degree of association of the patient-specific EDC data with one or more labels associated with the clinical trial.

[0084] It should be understood that one or more computer programs or components can be used to implement all of the disclosed methods and processes described herein. These components can be provided as a series of computer instructions on any conventional computer-readable medium or machine-readable medium, which includes volatile or non-volatile memory, such as RAM, ROM, flash memory, magnetic disks or optical disks, optical storage or other storage media. The instructions can be provided as software or firmware, and / or can be implemented in whole or in part as hardware components such as ASICs, FPGAs, DSPs or any other similar devices. These instructions can be configured to be executed by one or more processors, and when a series of computer instructions are executed, the processor performs or facilitates the execution of all or part of the disclosed methods and processes.

[0085] It should be understood that various changes and modifications to the exemplary embodiments described herein will be apparent to those skilled in the art. Such changes and modifications can be made without departing from the spirit and scope of the subject matter and without diminishing its intended advantages. Accordingly, these changes and modifications are intended to be covered by the appended claims.

Claims

1. A method for reducing redundancy in medical database management, the method comprising: For each hospital information system among a plurality of hospital information systems, for each source device among a plurality of source devices associated with the plurality of hospital information systems, and for each patient among a plurality of patients: Receiving, by a computing system having one or more processors and from a given source device associated with a given hospital information system, patient-specific health data for a given patient via a cloud-native and web-based application managed by an interoperable application programming interface (API); Automatically generating, by the computing system, an update to a patient-specific electronic health record (EHR) for the given patient based on the patient-specific health data; And Automatically generating, by a mapping module of the computing system and based on the patient-specific EHR, patient-specific electronic data capture (EDC) data associated with the given patient; Aggregating, in a first electronic data management system of a plurality of electronic data management systems, a plurality of patient-specific EDC data that are automatically generated from a plurality of patient-specific EHRs corresponding to the plurality of patients and are associated with the plurality of patients; Updating, by the computing system and at a predetermined refresh interval, each of the plurality of electronic data management systems to store the plurality of patient-specific EDC data associated with the plurality of patients; Receiving, via the cloud-native and web-based application, a request for a subset of the plurality of patient-specific EDC data; Identifying, by the computing system and based on a first tag associated with the subset of the plurality of patient-specific EDC data and the request, a destination system for the subset of the plurality of patient-specific EDC data, wherein the subset of the plurality of patient-specific EDC data is available for identification without the mapping module generating the subset of the plurality of patient-specific EDC data from a subset of the plurality of patient-specific EHRs in response to the request; and Sending, to the destination system and in response to the request, the subset of the plurality of patient-specific EDC data, wherein the destination system includes one or more of the following: (1) Another hospital information system among the plurality of hospital information systems, or (2) A second electronic data management system among the plurality of electronic data management systems.

2. The method according to claim 1, wherein automatically generating the patient-specific EDC data includes: Mapping lexical tokens between a lexicon associated with the given hospital information system and a lexicon associated with the first electronic data management system.

3. The method according to claim 1, wherein one or more of the plurality of source devices include: A sensor for generating the patient-specific health data from physiological measurements, and A natural language processor for generating the patient-specific health data from natural language input.

4. The method according to claim 1, wherein, the plurality of electronic data management systems includes: an Electronic Data Capture (EDC) module, a Clinical Trial Management System (CTMS), a Clinical Data Management System, an electronic Trial Master File (eTMF), and an Aggregate Data Analysis module, wherein at least one of the plurality of electronic data management systems is communicatively linkable to at least one of the plurality of hospital information systems.

5. The method according to claim 4, further comprising: receiving, by the computing system and from the Clinical Trial Management System, via the cloud-native and web-based application, a second tag associated with a clinical trial; querying, by the computing system, the plurality of patient-specific EDC data associated with the plurality of patients for a second subset of the patient-specific EDC data associated with the second tag; and sending, via the cloud-native and web-based application, the second subset of the patient-specific EDC data to the Clinical Trial Management System, wherein receiving the second tag and sending the second subset occur in real time.

6. The method according to claim 1, further comprising: after receiving the patient-specific health data for the given patient, determining that the patient-specific health data does not meet a sufficiency threshold for automatically generating the update to the patient-specific EHR for the given patient; and prompting, via the cloud-native and web-based application at the given source device, for additional patient-specific health data to meet the sufficiency threshold.

7. The method according to claim 1, wherein, updating each of the plurality of electronic data management systems to store the plurality of patient-specific EDC data includes: receiving, by the computing system and from the second electronic data management system, an update to the patient-specific EDC data for a patient among the plurality of patients; and updating, by the computing system, at the next occurrence of the predetermined refresh interval and based on the update to the patient-specific EDC data for the patient, the plurality of patient-specific EDC data at the remaining electronic data management systems among the plurality of electronic data management systems.

8. The method according to claim 1, wherein, generating the patient-specific EDC data includes: identifying one or more EHR data fields of the patient-specific EHR as not having corresponding EDC data fields of the patient-specific EDC data; and prompting, based on the identified one or more EHR data fields and via the cloud-native and web-based application, for an update to the patient-specific EDC data associated with the given patient.

9. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to perform the following steps, the steps comprising: For each hospital information system among a plurality of hospital information systems, for each source device among a plurality of source devices associated with the plurality of hospital information systems, and for each patient among a plurality of patients: Receive patient-specific health data for a given patient from a given source device associated with a given hospital information system, via a cloud-native and web-based application managed by an interoperable application programming interface (API); Automatically generate an update to a patient-specific electronic health record (EHR) for the given patient, based on the patient-specific health data; And Automatically generate patient-specific electronic data capture (EDC) data associated with the given patient, via a mapping module and based on the patient-specific EHR; Send, to a first electronic data management system among a plurality of electronic data management systems, and based on the generated patient-specific EDC data for each patient among the plurality of patients, a plurality of patient-specific EDC data automatically generated from a plurality of patient-specific EHRs corresponding to the plurality of patients and associated with the plurality of patients; Update, at a predetermined refresh interval and using the first electronic data management system, each electronic data management system among the plurality of electronic data management systems to store the plurality of patient-specific EDC data associated with the plurality of patients; Receive, via the cloud-native and web-based application, a request for a subset of the plurality of patient-specific EDC data; Identify a destination system for the subset of the plurality of patient-specific EDC data, based on a first tag associated with the subset of the plurality of patient-specific EDC data and the request, wherein the subset of the plurality of patient-specific EDC data is available for identification without the mapping module generating the subset of the plurality of patient-specific EDC data from a subset of the plurality of patient-specific EHRs in response to the request; and Send, to the destination system and in response to the request, the subset of the plurality of patient-specific EDC data, Wherein the destination system includes one or more of the following: (1) Another hospital information system among the plurality of hospital information systems, or (2) A second electronic data management system among the plurality of electronic data management systems.

10. The non-transitory computer-readable medium according to claim 9, Wherein, The mapping module is configured to: map lexical tokens among the plurality of source devices, the plurality of hospital information systems, and the plurality of electronic data management systems.

11. The non-transitory computer-readable medium according to claim 9, the steps further Include: After receiving the patient-specific health data for the given patient, determine that the patient-specific health data does not meet a sufficiency threshold for automatically generating the update to the patient-specific EHR for the given patient; And Via the cloud-native and web-based application, prompt for entry of additional patient-specific health data to meet the sufficiency threshold.

12. The non-transitory computer-readable medium according to claim 9, wherein, updating each of the plurality of electronic data management systems to store the plurality of patient-specific EDC data includes: receiving, from the second electronic data management system, an update to the patient-specific EDC data for a patient among the plurality of patients; and updating the plurality of patient-specific EDC data at the remaining electronic data management systems among the plurality of electronic data management systems at the next occurrence of the predetermined refresh interval and based on the update to the patient-specific EDC data for the patient.

13. The non-transitory computer-readable medium according to claim 9, wherein, automatically generating the patient-specific EDC data associated with the patient includes: identifying one or more EHR data fields of the patient-specific EHR as not having corresponding EDC data fields of the patient-specific EDC data; and prompting, based on the identified one or more EHR data fields and via the cloud-native and web-based application, for an update to the patient-specific EDC data associated with the given patient.

14. The non-transitory computer-readable medium according to claim 9, the step further includes: receiving, from a clinical trial management system, an electronic trial master file (eTMF) for a clinical trial via the cloud-native and web-based application managed by the interoperable API; generating a second tag associated with the clinical trial from a scan of the eTMF; querying the plurality of patient-specific EDC data associated with the plurality of patients for a second subset of patient-specific EDC data associated with the second tag; and sending, via the cloud-native and web-based application managed by the interoperable API, the second subset of the patient-specific EDC data to the clinical trial management system, wherein receiving the eTMF and sending the subset of the patient-specific EDC data occur in real time.

15. A system for reducing redundancy in medical database management, the system comprises: An interoperable application programming interface (API) for reducing redundancy in medical database management, wherein the interoperable API manages a cloud-native and web-based application that can access user interfaces associated with each of: a plurality of hospital information systems, a plurality of source devices associated with each of the plurality of hospital information systems, and a plurality of electronic data management systems; A mapping module configured to map lexical tokens among the plurality of source devices, the plurality of hospital information systems, and the plurality of electronic data management systems; One or more processors; and A memory storing instructions that, when executed by the one or more processors, cause the one or more processors to: For each hospital information system among a plurality of hospital information systems, for each source device among a plurality of source devices associated with each hospital information system, and for each patient among a plurality of patients: Receive patient-specific health data for a given patient from a given source device associated with a given hospital information system via the cloud-native and web-based application managed by the interoperable API; Automatically generate an update to a patient-specific electronic health record (EHR) for the given patient based on the patient-specific health data and using the mapping module; and Automatically generate patient-specific electronic data capture (EDC) data associated with the given patient using the mapping module and based on the patient-specific EHR; Aggregate, in a first electronic data management system among the plurality of electronic data management systems, the plurality of patient-specific EDC data automatically generated from and associated with the plurality of patient-specific EHRs corresponding to the plurality of patients; Update the storage of the plurality of patient-specific EDC data associated with the plurality of patients in each of the plurality of electronic data management systems at a predetermined refresh interval; Receive an electronic trial master file (eTMF) for a clinical trial from a clinical trial management system via the cloud-native and web-based application; and Send a subset of the patient-specific EDC data to the clinical trial management system, wherein, prior to receiving the eTMF, the mapping module has generated the subset of the plurality of patient-specific EDC data from a subset of the plurality of patient-specific EHRs corresponding to the plurality of patients, and, wherein the receiving of the eTMF and the sending of the subset of the patient-specific EDC data occur in real time.

16. The system according to claim 15, wherein, when the instructions are executed by the one or more processors, cause the one or more processors to receive the eTMF by: Generating one or more tags associated with the clinical trial from a scan of the eTMF; and Querying the plurality of patient-specific EDC data associated with the plurality of patients for a subset of the patient-specific EDC data associated with the one or more tags.

17. The system according to claim 15, wherein, when the instructions are executed by the one or more processors, cause the one or more processors to: Identify a destination system for the second subset of the plurality of patient-specific EDC data based on one or more tags associated with the second subset of the plurality of patient-specific EDC data; and Send the second subset of the plurality of patient-specific EDC data to the destination system, wherein the destination system includes one or more of the following: (1)Another hospital information system among the plurality of hospital information systems, or (2)The second electronic data management system among the plurality of electronic data management systems.

18. The system according to claim 15, wherein, when the instructions are executed by the one or more processors, cause the one or more processors to: after receiving the patient-specific health data for the given patient, determine that the patient-specific health data does not meet the sufficiency threshold for generating the update to the patient-specific EHR for the given patient; and prompt, via the cloud-native and web-based application at the given source device, for additional patient-specific health data to meet the sufficiency threshold.

19. The system according to claim 17, wherein, when the instructions are executed by the one or more processors, cause the one or more processors to update the storage of the plurality of patient-specific EDC data by: receiving, from the second electronic data management system, an update to the patient-specific EDC data for the patient among the plurality of patients; and updating the plurality of patient-specific EDC data at the remaining electronic data management systems among the plurality of electronic data management systems at the next occurrence of the predetermined refresh interval and based on the update to the patient-specific EDC data for the patient.

20. The system according to claim 15, wherein, when the instructions are executed by the one or more processors, cause the one or more processors to automatically generate the patient-specific EDC data by: identifying one or more EHR data fields of the patient-specific EHR as not having corresponding EDC data fields of the patient-specific EDC data; and prompting, based on the identified one or more EHR data fields, via the cloud-native and web-based application, for an update to the patient-specific EDC data associated with the given patient.

Images