Method and system for improved iterative data extraction from electronic medical records

Abstract

A method for generating a modified patient group includes receiving a plurality of patient records for a plurality of patients; retrieving a predetermined plurality of features for the clinical diagnosis, condition or disease from the clinical feature database; extracting clinical features from the patient record using the predetermined plurality of features to generate a clinical feature data set; generating a feature value table including the extracted clinical feature data set; identifying a first group of patients from the table of feature values based on one of the plurality of clinical diagnoses, conditions, or diseases; providing the first patient group to a user; receiving, from the user, a modification request for modifying the first patient group; modifying the first patient group without additionally extracting clinical features to generate a modified patient group; and providing the modified patient group to the user.

Description

Technical Field

[0001] The present disclosure generally relates to methods and systems for iterative data extraction and patient cohort generation from electronic medical records. Background Art

[0002] Electronic medical record databases contain medical records and information about a large number of patients. Mining information about symptoms, conditions, diseases, treatments, and other health and well-being aspects from these databases has become a very common practice in medical research and treatment. For example, identifying and extracting patient groups of interest from multiple patients in an electronic medical record database is often the first step in developing disease risk prediction models, treatment pathways, and many other research models and analyses.

[0003] In order to identify the patient groups of interest from multiple patients in the electronic medical record database, investigators need to first extract the patient groups from the data source, which include input variable measurements and disease labels. Usually there are: (i) data sources; (ii) labeling criteria; and (iii) a list of input variables as input for identification and extraction.

[0004] As just one example, to build a sepsis prediction model, an investigator can start with the MIMIC-III database (i.e., the data source), apply the Sepsis III labeling criteria for sepsis (i.e., the labeling criteria), and then extract a list of input variables (e.g., white blood cell count, lactate, etc.) that are likely to predict sepsis (i.e., the input variable list). This prior art process is illustrated in flowchart 10 in FIG. 1 .

[0005] However, such data extraction is often a time-consuming and iterative process. For example, during the iteration process, any of the following may be modified: 1) patient dimension; 2) feature dimension; and 3) time dimension. For example, patients and features can be added, removed, or updated. The time window for input data extraction and data interpolation can be updated. Since running the data extraction process shown in Figure 1 is very time-consuming, it is extremely inefficient to rerun the entire identification and extraction process even if a minor modification is made to any of the patient / feature / time dimensions. Summary of the invention

[0006] Therefore, there is a need for methods and systems for faster and more efficient iterative data extraction and patient group generation from electronic medical records. Various embodiments and implementations herein are directed to a patient group creation system that is configured to generate a modified patient group from a database including a plurality of patient records for a plurality of patients. The patient group creation system receives a plurality of patient records for a plurality of patients from the database. The system also retrieves a predetermined plurality of features for a clinical diagnosis, condition, or disease from a clinical feature database, wherein the clinical feature database includes a predetermined plurality of features for each of the plurality of clinical diagnoses, conditions, or diseases. The method also includes extracting clinical features from at least some of a plurality of patient records of a plurality of patients using a predetermined plurality of features for a clinical diagnosis, condition, or disease to generate a clinical feature data set for a first time period; generating a feature table in a memory including the extracted clinical feature data set; identifying a first patient group for a predetermined time period based on the feature table in response to a user request for a patient group based on one of a plurality of clinical diagnoses, conditions, or diseases, wherein the predetermined time period is some or all of the first time period, and wherein the first patient group is a subset of a plurality of patients in the feature table; providing the first patient group to a user; receiving a modification request from the user to modify the first patient group, wherein the modification includes modification of one or more of: (i) patients in the first patient group; (ii) a predetermined time period; and (iii) a predetermined plurality of features for a clinical diagnosis, condition, or disease; modifying the first patient group based on the received modification request and without additionally extracting clinical features to generate a modified patient group; and providing the first patient group to the user.

[0007] In general, in one aspect, a method for generating a modified patient group based on a database including a plurality of patient records of a plurality of patients is provided. The method includes: receiving the plurality of patient records of the plurality of patients from the database; retrieving a predetermined plurality of features for a clinical diagnosis, condition, or disease from a clinical feature database, wherein the clinical feature database includes a predetermined plurality of features for each of a plurality of clinical diagnoses, conditions, or diseases; extracting clinical features from at least some of the plurality of patient records of the plurality of patients using the predetermined plurality of features for the clinical diagnoses, conditions, or diseases to generate a clinical feature data set for a first time period; generating a feature value table including the extracted clinical feature data set in a memory; and identifying a first patient group for a predetermined time period according to the feature value table in response to a user request for a patient group based on one of the plurality of clinical diagnoses, conditions, or diseases. , wherein the predetermined time period is some or all of the first time period, and wherein the first patient group is a subset of the plurality of patients in the feature value table; providing the first patient group to a user via a user interface; receiving a modification request from the user to modify the first patient group, wherein the modification includes modification of one or more of: (i) patients in the first patient group; (ii) the predetermined time period; and (iii) the predetermined plurality of features for the clinical diagnosis, condition or disease; modifying the first patient group based on the received modification request and without additionally extracting clinical features to generate a modified patient group; and providing the modified patient group to the user via the user interface.

[0008] According to one embodiment, the feature value table includes, for each of a plurality of patients, a patient identification and feature values ​​for some or all of the predetermined plurality of features for the clinical diagnosis, condition or disease.

[0009] According to one embodiment, the first patient group and the modified patient group comprise a list of patients, each patient being identified by a patient ID and a feature value for each of the predetermined plurality of features for each patient.

[0010] According to one embodiment, the modified patient group comprises more patients than the first patient group.

[0011] According to one embodiment, the modified patient group comprises one or more additional characteristics compared to the first patient group.

[0012] According to one embodiment, the modified patient group comprises a longer or shorter time period compared to the first patient group.

[0013] According to one embodiment, the modification request received from the user includes identification of a feature not originally listed in the predetermined plurality of features for the clinical diagnosis, condition or disease.

[0014] According to one embodiment, the predetermined period of time is a period of time prior to the onset of the clinical condition.

[0015] According to another aspect, a system for generating a modified patient group is provided. The system includes: a database including multiple patient records for multiple patients; a clinical feature database including multiple predetermined features for each of multiple clinical diagnoses, conditions, or diseases; a user interface; and a processor configured to: (i) retrieve multiple predetermined features for clinical diagnoses, conditions, or diseases from the clinical feature database; (ii) extract clinical features from at least some of the multiple patient records of the multiple patients using the predetermined multiple features for the clinical diagnoses, conditions, or diseases to generate a clinical feature data set for a first time period; (iii) generate a feature value table including the extracted clinical feature data set in a memory; (iv) in response to a user request for a patient group based on one of the multiple clinical diagnoses, conditions, or diseases, identify the clinical feature data set for the predetermined multiple features according to the feature value table; (v) providing the first patient group to a user via the user interface; (vi) receiving a modification request from the user to modify the first patient group, wherein the modification includes modification of one or more of the following: the patients in the first patient group; the predetermined time period; and the predetermined plurality of features for the clinical diagnosis, condition or disease; (vii) modifying the first patient group based on the received modification request and without additionally extracting clinical features to generate a modified patient group; and (viii) providing the modified patient group to the user via the user interface.

[0016] It should be understood that all combinations of the foregoing concepts and the additional concepts discussed in more detail below (provided that these concepts are not mutually inconsistent) are considered part of the inventive subject matter disclosed herein. In particular, all combinations of the claimed subject matter appearing at the end of this disclosure are considered part of the inventive subject matter disclosed herein. It should also be understood that terms explicitly used herein that may also appear in any disclosure incorporated by reference should be given the meaning most consistent with the specific concepts disclosed herein.

[0017] These and other aspects of the various embodiments will be apparent from and elucidated with reference to the embodiment(s) described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In the drawings, the same reference numerals generally refer to the same parts throughout the different views. The drawings illustrate features and modes of implementing various embodiments and should not be construed as limiting other possible embodiments within the scope of the appended claims. Moreover, the drawings are not necessarily drawn to scale, but emphasis is generally placed on illustrating the principles of the various embodiments.

[0019] FIG. 1 is a flow chart of a prior art method for generating patient groups from a database.

[0020] Figure 2 is a flow chart of a method for generating patient groups from a database according to one embodiment.

[0021] Figure 3 is a schematic diagram of a patient group creation system according to one embodiment.

[0022] Figure 4 is a schematic diagram illustrating in three dimensions the complexity caused by modifications to a patient group, according to one embodiment.

[0023] Figure 5 is a flow chart of a method for generating patient groups from a database according to one embodiment. DETAILED DESCRIPTION

[0024] The present disclosure describes various embodiments of systems and methods configured to identify and eliminate one or more clinical concerns based on a clinical risk prediction model. More generally, applicants have recognized and appreciated that it would be beneficial to provide an improved clinical risk prediction model or tool that is more versatile for risk prediction for internal deployments. A clinical risk prediction system receives or obtains a training data set configured to train a clinical risk prediction model.

[0025] The present disclosure describes various embodiments of systems and methods configured to facilitate the rapid and efficient generation and modification of patient groups. More generally, applicants have recognized and appreciated that it would be beneficial to provide an improved patient group creation system that creates patient groups based on a database that includes multiple patient records for multiple patients. The patient group creation system receives multiple patient records for multiple patients from the database. The system also retrieves a predetermined plurality of features for a clinical diagnosis, condition, or disease from a clinical feature database, wherein the clinical feature database includes a predetermined plurality of features for each of the multiple clinical diagnoses, conditions, or diseases. The method also includes: extracting clinical features from at least some of a plurality of patient records of a plurality of patients using a predetermined plurality of features for a clinical diagnosis, condition, or disease to generate a clinical feature data set for a first time period; generating a feature table in a memory including the extracted clinical feature data set; identifying a first patient group for a predetermined time period according to the feature table in response to a user request for a patient group based on one of a plurality of clinical diagnoses, conditions, or diseases, wherein the predetermined time period is some or all of the first time period, and wherein the first patient group is a subset of a plurality of patients in the feature table; providing the first patient group to a user; receiving a modification request from the user to modify the first patient group, wherein the modification includes modification of one or more of: (i) patients in the first patient group; (ii) a predetermined time period; and (iii) a predetermined plurality of features for a clinical diagnosis, condition, or disease; modifying the first patient group based on the received modification request and without additionally extracting clinical features to generate a modified patient group; and providing the first patient group to the user.

[0026] The embodiments and implementations disclosed or otherwise contemplated herein can be used with any research or patient care system, including but not limited to clinical decision support tools and other systems. For example, one application of the embodiments and implementations herein is to improve a system (e.g., Philips Products (manufactured by Royal Philips of the Netherlands) and many other products. However, the present disclosure is not limited to these devices or systems, and thus the disclosure and embodiments disclosed herein can encompass any device or system that may require or be applicable to a patient group.

[0027] refer to Figure 2 , in one embodiment, Figure 21 is a flow chart of a method 100 for generating a modified patient group from a database of multiple patient records including multiple patients using a patient group creation system. The methods described in conjunction with the accompanying drawings are provided by way of example only and should be understood not to limit the scope of the present disclosure. The patient group creation system can be any system described herein or otherwise contemplated. The patient group creation system can be a single system or multiple different systems.

[0028] As an initial step in this method, a patient group creation system is provided. Figure 3 The depicted embodiment of the patient group creation system 200, for example, includes one or more of the following: a processor 220, a memory 230, a user interface 240, a communication interface 250, and a storage device 260, which are interconnected via one or more system buses 212. It should be understood that Figure 3 In some respects, an abstraction is constituted, and the actual organization of the components of the system 200 may be different and more complex than that illustrated. Additionally, the patient group creation system 200 can be any system described or otherwise contemplated herein. Other elements and components of the patient group creation system 200 are disclosed and / or otherwise contemplated herein.

[0029] At step 110 of the method, the patient group creation system 200 receives, retrieves, or otherwise obtains a plurality of patient records for a plurality of patients from a database 270. The database can be any database, including but not limited to an electronic medical record database. For example, the database can be any database that includes medical records for a large number of patients or subjects. The database 270 can be a local database or a remote database and communicate directly and / or indirectly with the patient group creation system 200. The plurality of patient records can be stored in one or more databases and / or the plurality of patient records can be received from one or more databases. Any of these databases can be a local database and / or a remote database. For example, the patient group creation system can include a database 270 of patient records.

[0030] A patient record can include any data about a patient. For example, a patient record can include demographic information, diagnostic information, clinical measurements, treatment information, and / or any other information, including information for each of a plurality of patients over a period of time. According to one embodiment, a patient record includes clinical data measuring a patient's physiological condition (e.g., physiological measurements of vital signs, laboratory results, imaging results, and other data) and event logs (e.g., timestamps of laboratory orders, imaging, medications, consultations, and other data) that can reflect the process a patient receives in a care setting. A patient record can include any other information.

[0031] According to one embodiment, the patient group creation system may include a data preprocessor or similar component or algorithm that is configured to process the received training data. For example, the data preprocessor analyzes patient records to eliminate noise, bias, errors, and other potential problems. The data preprocessor can also analyze the input data to remove low-quality data. Many other forms of data preprocessing or data point identification and / or extraction are also possible.

[0032] Once the patient group creation system 200 receives, retrieves, or otherwise obtains the plurality of patient records for the plurality of patients from the database 270 , the patient records can be used immediately or can also be stored in local and / or remote storage for future use.

[0033] Once the patient group creation system has a plurality of patient records, it can generate a database of extracted features for each of a plurality of different conditions, disorders, diagnoses, treatments, etc. In order to generate this database of extracted features, the patient group creation system must identify or otherwise include or receive or obtain a list of extracted features that should be for each of the different conditions, disorders, diagnoses, and treatments. For example, for condition X, it may be well known or expected that extracted features X1, X2, and X3 are often associated with condition X. Similarly, for condition Y, it may be well known or expected that extracted features Y1 and Y2 are often associated with condition Y. Finally, for condition Z, it may be well known or expected that extracted features X1, X3, and Y2 are often associated with condition Z.

[0034] According to one embodiment, a plurality of different conditions, disorders, diagnoses, treatments, etc. can include anything related to patient care, diagnosis, or treatment. For example, the condition can be sepsis, shock (e.g., cardiogenic shock, septic shock, hypovolemic shock), acute kidney injury, acute respiratory distress syndrome, hemodynamic instability, and a variety of other conditions.

[0035] According to one embodiment, a feature can be any information found in a medical record or other patient record or that can be otherwise obtained or determined from a medical record or other patient record. Some non-limiting examples of features include demographic information (age, sex, weight, height, etc.), diagnosis information (diabetes, heart failure, lung injury, kidney injury, wrist fracture, appendicitis, etc.), treatment information (antibiotic course, appendectomy, dialysis, etc.), and many other information. A feature can be almost any information that: (i) can be extracted from a patient record or otherwise identified in a patient record; and (ii) can be used by researchers, clinicians, or machine learning algorithms to examine or study or understand patient care, diagnosis, or treatment, etc.

[0036] Additionally, the identified, received, or obtained list of features to be extracted from multiple patient records can be a comprehensive feature list that includes many or all features known to be associated with any of a very wide and diverse list of conditions, disorders, diagnoses, treatments, etc. This can be particularly important for research and discovery because, often, some features may be associated with a condition, disorder, diagnosis, or treatment, but such a correlation may not have been discovered or previously associated. Therefore, in order to enable research and discovery, clinicians should have access to a large number of extracted features.

[0037] In addition, in addition to identifying patients and features associated with each of the very broad and diverse list of conditions, symptoms, diagnoses, treatments, etc. (i.e., patient cohorts), the researcher or clinician must also identify a comparison or control group. Such a comparison or control group should include patients with similar phenotypes to the patients in the patient cohort, but who may lack the condition, symptom, diagnosis, treatment, etc. Ideally, the size or number of the comparison or control group should be similar to the patient population. Therefore, for fast and efficient performance of the patient cohort creation system, it is important to have extracted features for multiple patients that include both the final patient cohort and the comparison or control group.

[0038] Therefore, at step 120 of the method, the patient group creation system retrieves a list of features for each of a plurality of different clinical diagnoses, conditions, or diseases from a clinical feature database. The clinical feature database includes a predetermined plurality of features for each of a plurality of clinical diagnoses, conditions, and diseases. The clinical feature database can be a local database or a remote database, and can communicate directly and / or indirectly with the patient group creation system 200. The list of features for a plurality of different clinical diagnoses, conditions, or diseases can be stored in one or more databases, and / or the list of features for a plurality of different clinical diagnoses, conditions, or diseases can be received from one or more databases. Any of these databases can be a local database and / or a remote database. For example, the patient group creation system can include a clinical feature database.

[0039] For example, the clinical feature database includes a list L of features associated with condition X X , where the list of features L X Includes a plurality of features that are known to be associated with condition X, predicted to be associated with condition X, or otherwise associated with condition X. For example, a list of features L X There could be ten different features for condition X (age, gender, antibiotic regimen, etc.). Similarly, the clinical feature database includes a list L of features associated with condition Z. Z , where the list of features L ZIncluded are a plurality of features known to be associated with condition Z, or predicted to be associated with condition Z, or otherwise correlated with condition Z. For a variety of different diagnoses, conditions, disorders or diseases, and so on.

[0040] The clinical feature database may also include a list of features G n (“generic”), which are not necessarily associated with a specific condition but can be expected to be useful for research and discovery. The list of generic features can be any feature that can be extracted from a patient record. It is worth noting that some or all of these lists (e.g., L X , L Z and G n ) can overlap partially or completely.

[0041] Once the patient cohort creation system 200 receives, retrieves, or otherwise obtains the lists of predetermined multiple features for different clinical diagnoses, conditions, or diseases from the clinical features database, these lists can be used immediately or can be stored in local and / or remote memory for future use.

[0042] Once the patient cohort creation system has a plurality of patient records and a list of predetermined plurality of features for different clinical diagnoses, conditions or diseases from the clinical feature database, the patient cohort creation system can generate a database of extracted features for each of a plurality of different conditions, disorders, diagnoses and treatments. Researchers and clinicians can then utilize this database of extracted features.

[0043] Therefore, at step 130 of the method, the patient group creation system uses the identified multiple features for clinical diagnosis, condition or disease to extract feature values ​​for a first time period from multiple patient records of multiple patients. Feature values ​​can be extracted using any known mechanism, process or program to identify and extract feature values ​​for features from medical records. The first time period can be any time period and can be a predetermined, programmed, default, learned or any other time period. According to one embodiment, the time period is the entire time range found in multiple records of the patient. For example, patient P1 may have 6 months of records in the database, so the system will extract feature values ​​for the duration of these 6 months, thereby associating timestamps with extracted features. Similarly, patient P2 may have 4 months of records in the database, so the system will extract feature values ​​for the duration of these 4 months, thereby associating timestamps with extracted features.

[0044] According to one embodiment, the time period is a predetermined time period of 3 months, and therefore the patient group creation system extracts feature values ​​from records for the 3 month time period (starting from admission to a medical care facility, or from diagnosis of a condition, as just one possible example, among many other starting time points or events), thereby associating a timestamp with the extracted feature value.

[0045] Once the patient group creation system 200 extracts feature values ​​from multiple patient records, the extracted feature values ​​can be used immediately, or the extracted feature values ​​can be stored in local and / or remote memory for future use. Therefore, at step 140 of the method, the patient group creation system generates and / or populates a data structure (e.g., a feature value table) using the extracted feature values. The data structure can be any data structure sufficient to store the extracted feature values ​​and enable the features and / or feature values ​​to be identified and retrieved from the data structure. The data structure can be stored in a memory of the patient group creation system. The data structure, database, or memory storing the extracted feature values ​​can be a local database or a remote database, and can communicate directly and / or indirectly with the patient group creation system 200.

[0046] At step 150 of the method, the patient group creation system receives a user request for a patient group from a plurality of patients, wherein the patient group will be a subset of the plurality of patients (e.g., less than all of the plurality of patients). The user request can be received via a user interface of the patient group creation system. For example, the user request can be provided using any method for providing information to a computer system. The request can be provided by speaking, typing, selecting, clicking, or any other method using a user interface. The user interface for providing the user request can be a component of the patient group creation system, or can be remote from the patient group creation system or a component separate from the patient group creation system. For example, the patient group creation system can communicate wired and / or wirelessly with another device including a user interface.

[0047] According to one embodiment, the user request includes the following information, which the patient group creation system will use to identify which patients from the plurality of patients should comprise the patient group. For example, the user request may include identification of one of the plurality of clinical diagnoses, conditions, or diseases for which the feature list is generated. For example, the user request may also include identification of time periods for the patient data and the patient group. Thus, the user request may also include a predetermined time period, which is some or all of the first time period discussed above.

[0048] According to one embodiment, the patient group creation system uses the received user request to identify a first patient group for a predetermined time period based on one of a plurality of clinical diagnoses, conditions or diseases according to the feature value table generated in step 140. The predetermined time period is some or all of the first time period, and the first patient group is a subset of the plurality of patients in the feature value table. The user request includes: information necessary to identify the subset of the plurality of patients in the feature value table, and the predetermined time period.

[0049] Once the patient group creation system identifies the first patient group based on the feature value table, the identified first patient group can be used immediately or can be stored in a local and / or remote memory for future use.

[0050] At step 160 of the method, the patient group creation system provides the identified first patient group to the user via a user interface. The patient group creation system and the user interface can provide the first patient group using any method for providing or reporting information. For example, the first patient group can be provided via a user interface of the patient group creation system, or the first patient group can be transmitted to another device via wired and / or wireless communication. The system can transmit the information to a mobile phone, a computer, a laptop, a wearable device, and / or any other device configured to allow display and / or other communication of information. The reported information can be a list of patients in the group and the relevant medical records of each patient in the group for the first time period.

[0051] At step 170 of the method, the patient group creation system receives a modification request from a user to modify the first patient group. The modification request can be received via a user interface of the patient group creation system. For example, the modification request can be provided using any method for providing information to a computer system. The request can be provided by speaking, typing, selecting, clicking, or any other method using a user interface. The user interface for providing the modification request can be a component of the patient group creation system, or can be remote from the patient group creation system or a component separate from the patient group creation system. For example, the patient group creation system can communicate wired and / or wirelessly with another device including a user interface.

[0052] According to one embodiment, the modification request includes information that the patient group creation system will use to identify how the first patient group should be modified. For example, the modification request may include a request to modify one or more of the following: (i) the patients in the first patient group; (ii) a predetermined time period; and (iii) a predetermined plurality of features for a clinical diagnosis, condition, or disease. For example, the modification request may include features regarding expanding the first patient group and thereby allowing more patients to be added to the first patient group. Alternatively, the modification request may include features regarding shrinking the first patient group and thereby removing patients from the first patient group. For example, the modification request may include identification of new features to be added to the plurality of features for a clinical diagnosis, condition, or disease, so that the first patient group may be expanded or reduced based on the identified new features. As an example, requesting that the first patient group include a new feature L for condition X x1 This may cause more patients to be added to the first patient group, or patients to be removed from the first patient group.As another example, the modification request may include a request to shorten or extend a predetermined time period.

[0053] At step 180 of the method, the patient group creation system uses the received modification request to modify the first patient group to generate a modified patient group, which may include fewer or more patients. Notably, the patient group creation system modifies the first patient group without additionally identifying or extracting clinical features from multiple patient records of multiple patients from the database. This is because the patient group creation system uses the information already populated in the feature value table (i.e., a list of features and extracted feature values) to identify which patients to add or subtract from the first patient group based on the received modification request to generate the modified patient group. This is one of the main advantages of the system over prior art systems. Generating and subsequently utilizing a well-defined and well-populated feature value table allows for significantly faster analysis and generation of patient groups, improved analysis of patient groups, etc. Since identifying and extracting feature values ​​is one of the limiting steps during the creation of patient groups, making this information readily available for the generation of the first patient group or for the modification of the generation of the modified patient group can essentially skip this step, thereby greatly speeding up the system and improving processing efficiency when generating the first patient group or the modified patient group.

[0054] Once the patient group creation system generates the modified patient group based on the characteristic value table, the modified patient group can be used immediately or can be stored in local and / or remote memory for future use.

[0055] At step 190 of the method, the patient group creation system provides the modified patient group to the user via the user interface. The patient group creation system and the user interface can provide the modified patient group using any method for providing or reporting information. For example, the modified patient group can be provided via the user interface of the patient group creation system, or the modified patient group can be transmitted to another device via wired and / or wireless communication. The system can transmit the information to a mobile phone, a computer, a laptop, a wearable device, and / or any other device configured to allow display and / or other communication of information. The reported information can be a list of patients in the group and the relevant medical records of each patient in the group for the first time period or the modified time period.

[0056] refer to Figure 4 , in one embodiment, Figure 4 is a graph 300 illustrating the complexity caused by modifications to patient cohorts in all three dimensions, including the patient dimension, the feature dimension, and the time dimension.

[0057] According to one example, the condition is sepsis (e.g., sepsis is predicted or determined). The patient dimension can include sepsis patients and / or non-septic patients; the feature dimension can include WBC count, lactate, and / or other features used to predict or determine sepsis; the time dimension can include the six hours before the onset of sepsis. Each of these dimensions can be determined by the user via user request or modification, and any of these dimensions can be changed to produce a different or modified patient group. As just one example of a modification, the time dimension can be changed by extending or shortening the time window before sepsis (e.g., to 4 hours or 8 hours).

[0058] The patient group creation system automates the data extraction process so that investigators can spend minimal effort on data extraction. For example, the system avoids the inefficiency of re-running the data extraction process every time there is any modification to the problem definition. According to one possible embodiment, the patient group creation system includes a data extraction pipeline containing multiple APIs for creating / adding / removing / updating patient / feature / time dimensions; and a public shared repository for storing implementations of labeling different clinical conditions.

[0059] refer to Figure 5 , in one embodiment, Figure 5 is a diagram 400 illustrating a data extraction pipeline of a patient cohort creation system. This data extraction pipeline is only one possible embodiment and is provided as a non-limiting example.

[0060] At step 410 of the method, labeling criteria are applied. First, starting from an EHR data source (e.g., MIMIC-III or eICU), a list of (patient ID, event time) can be extracted using labeling criteria. This includes patient cases (using inclusion criteria) and controls (using exclusion criteria). This step can be automated by creating a common shared repository containing implementations of common clinical conditions, which will be described in more detail elsewhere in this article.

[0061] At step 420 of the method, a time series is created or updated for the input variables of the selected set of patients. In the case of a list of input variables, a (timestamp, value) table for each input variable can also be extracted. This creation step can be automated through the following API:

[0062] Define extract input time series(patient ID list, input time series of entire admission, event time list, input time range) where the patient ID list is the set of case / control patients identified from the first step, the input time series of entire admission is the entire time series of multiple clinical variables available in HER; the event time list is the list of onset times of clinical events identified from the first step (e.g., onset time of sepsis); and the input time range is the time range of interest used to build the prediction model (e.g., 12 to 1 hour before the onset time of the clinical event).

[0063] According to one embodiment, the output of this API will be a time series for each feature for each patient. Users can also update existing time series using the following API:

[0064] define update_input_time_series(patient_id_to_add, patient_id_to_remove, update_input_time_range, input_time_series_for_entire_admission, list_of_event_times)

[0065] where Patient IDs to add is a list of patient IDs to be added to the update group; Patient IDs to remove is a list of patient IDs to be removed from the update group; Update input time range is the update time range in the update group; Input time series for the entire admission is the entire time series of multiple clinical variables available in HER; and Event time list is a list of onset times of clinical events identified from the first step (e.g., onset time of sepsis).

[0066] According to one embodiment, the output of step 420 will be a table for each input feature with the following columns: patient ID, timestamp when the feature was measured, the measured feature value, and the unit of the feature value.

[0067] At step 430 of the method, the input features are cleaned. For example, assuming the output table for each feature from step 420, each input feature can be cleaned using the following API by applying feature-specific unit conversion and outlier removal:

[0068] Define clean input features (feature units, feature value range)

[0069] where FeatureUnits is the available feature units for the measured features, and FeatureValueRange is the reasonable range for the input features.

[0070] For each input feature, there is a finite set of input features, and the relationships between these input features can be found in the literature. These contents can be easily implemented in a lookup table. Similarly, reasonable ranges for typical vital signs and laboratories can also be implemented in a lookup table. In addition, assuming that each characteristic name or unit can be documented in a different way, these record patterns can be extracted once for each data source and then saved in a lookup table. In short, this step can also be automated. According to one embodiment, the output of step 430 is a cleaned table for each input feature.

[0071] At step 440 of the method, a patient design matrix is ​​created or updated. The patient design matrix can be created from multiple tables of multiple input features using the following API:

[0072] Define and create design matrix (temporal resolution, interpolation strategy)

[0073] where temporal resolution specifies which time points will be used to create the patient design matrix; and imputation strategy is the imputation strategy used to handle missing values ​​in the design matrix.

[0074] After creating the design matrix, you can also use the following API to update the design matrix:

[0075] Define the update design matrix (features to add, features to remove, features to update)

[0076] Among them, the features to be added are new features to be added to the patient design matrix; the features to be removed are features to be removed from the patient design matrix; and the features to be updated are features that need to be updated from the patient design matrix.

[0077] According to one embodiment, the output of step 440 is a final patient design matrix that can be used for model training.

[0078] According to one embodiment, step 410 of the method may be the most difficult or challenging step due to the diversity of labeling criteria for a variety of clinical conditions. However, they can be implemented in a public repository and reused by different investigators, assuming that consistent definitions often exist for a given disease. Examples include the Sepsis-III criteria for sepsis and the Berlin definition for acute respiratory distress syndrome (ARDS).

[0079] For each contribution to the repository, a wiki page can be used to document: (1) the labeling criteria being implemented; (2) the data sources used to test the labeling criteria; and (3) summary statistics of applying the labeling criteria to the data sources. As for programming languages, Python and SQL can be used, among others, as they are widely accepted in the data science community.

[0080] Therefore, according to one embodiment, data science investigators can apply a patient group creation system to extract patient groups from electronic medical records. Due to the nature of patient groups, patient groups can be widely used to establish any disease prediction model (e.g., hemodynamic instability, sepsis, infection, respiratory distress, etc.). For example, the patient group creation method can be applied in the algorithm development stage. For example, the developed algorithm can be deployed on a patient monitor. In addition, the patient group creation system can save investigators time spent on data extraction (which often takes a lot of time and effort), and spend more energy on algorithm development and verification. The patient group creation system will also facilitate the delivery of higher quality disease risk prediction models.

[0081] refer to Figure 3 , Figure 3 2 is a schematic diagram of a patient group creation system. System 200 may be any system described herein or otherwise contemplated, and may include any components described herein or otherwise contemplated. It should be understood that Figure 3 An abstraction is constituted in some respects, and the actual organization of components of system 200 may be different and more complex than that illustrated.

[0082] According to one embodiment, the system 200 includes a processor 220 capable of executing instructions stored in the memory 230 or the storage device 260, or processing data to, for example, perform one or more steps of the method. The processor 220 may be composed of one or more modules. The processor 220 may take any suitable form, including but not limited to a microprocessor, a microcontroller, multiple microcontrollers, a circuit, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a single processor, or multiple processors.

[0083] Memory 230 can take any suitable form, including non-volatile memory and / or RAM. Memory 230 can include various memories, for example, L1, L2 or L3 cache or system memory. As such, memory 230 can include static random access memory (SRAM), dynamic RAM (DRAM), flash memory, read-only memory (ROM) or other similar memory devices. Among other things, the memory can also store an operating system. The processor uses RAM to temporarily store data. According to one embodiment, the operating system can include code that controls the operation of one or more components of system 200 when executed by the processor. Obviously, in an embodiment where the processor implements one or more functions described herein in hardware, software described as corresponding to such functions in other embodiments can be omitted.

[0084] The user interface 240 may include one or more devices for realizing communication with the user. The user interface can be any device or system that allows transmission and / or reception of information, and may include a display, a mouse and / or a keyboard for receiving user commands. In certain embodiments, the user interface 240 may include a command line interface or a graphical user interface, which may be presented to the remote terminal via the communication interface 250. The user interface may be located at one place with one or more other components of the system, or may be located at a position away from the system and communicated via a wired and / or wireless communication network.

[0085] The communication interface 250 may include one or more devices for implementing communication with other hardware devices. For example, the communication interface 250 may include a network interface card (NIC) configured to communicate according to the Ethernet protocol. In addition, the communication interface 250 may implement a TCP / IP stack for communication according to the TCP / IP protocol. Various alternatives or additional hardware or configurations for the communication interface 250 will be apparent.

[0086] The storage device 260 may include one or more machine-readable storage media, such as a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage medium, an optical storage medium, a flash memory device, or a similar storage medium. In various embodiments, the storage device 260 may store instructions executed by the processor 220 or data that the processor 220 may operate on. For example, the storage device 260 may store an operating system 261 for controlling various operations of the system 200.

[0087] It will be apparent that various information described as being stored in storage device 260 may additionally or alternatively be stored in memory 230. In this regard, memory 230 may also be considered to constitute a storage device, and storage device 260 may also be considered to be a memory. Various other arrangements will be apparent. Additionally, both memory 230 and storage device 260 may be considered to be non-transitory machine-readable media. The term "non-transitory" as used herein will be understood to exclude transient signals, but rather to include all forms of storage devices (including volatile memory and non-volatile memory).

[0088] Although system 200 is shown as including one such component for each described component, in various embodiments, various components may be repeated. For example, processor 220 may include multiple microprocessors that are configured to independently perform the methods described herein, or are configured to perform the steps or subroutines of the methods described herein, so that multiple processors collaborate to implement the functions described herein. In addition, in the case where one or more components of system 200 are implemented in a cloud computing system, various hardware components may belong to separate physical systems. For example, processor 220 may include a first processor in a first server and a second processor in a second server. Many other variations and configurations are possible.

[0089] According to one embodiment, the electronic medical record system 270 is an electronic medical record database from which information about a plurality of patients (including demographic, diagnostic and / or treatment information) can be obtained or received. According to one embodiment, the electronic medical record system 270 is an electronic medical record database from which training data can be obtained or received. The training data can be any data that will be used to create a patient group to train the algorithm. The training data can include any other information. The electronic medical record database can be a local database or a remote database and communicate directly and / or indirectly with the system 200. Therefore, according to one embodiment, the clinical risk prediction system includes an electronic medical record database or system 270.

[0090] According to one embodiment, the storage device 260 of the system 200 may store one or more algorithms, modules and / or instructions to perform one or more functions or one or more steps of the methods described herein or otherwise contemplated. For example, the system may include patient data 262, feature lists 263, feature extraction instructions 264, feature value tables 265, and / or reporting instructions 266, in addition to other instructions or data.

[0091] According to one embodiment, the patient data 262 is a plurality of patient records for a plurality of patients and is obtained from a database (e.g., database 270). Patient records can include any data about a patient. For example, a patient record can include demographic information, diagnostic information, clinical measurements, treatment information, and / or any other information (including information for each of a plurality of patients over a period of time). According to one embodiment, a patient record includes clinical data measuring a patient's physiological condition (e.g., physiological measurements of vital signs, laboratory results, imaging results, and other data) and event logs (e.g., timestamps of laboratory orders, imaging, medications, consultations, and other data) that can reflect the process a patient receives in a care setting. Patient records can include any other information.

[0092] According to one embodiment, feature list 263 is a list of features for each of a plurality of different clinical diagnoses, conditions, or diseases. Feature lists for a plurality of different clinical diagnoses, conditions, or diseases may be stored in one or more databases and / or may be received from one or more databases. For example, a clinical feature database includes a list L of features associated with condition X. X , where the list of features L X Includes a plurality of features that are known to be associated with condition X, predicted to be associated with condition X, or otherwise associated with condition X. For example, a list of features L X There could be ten different features for condition X (age, gender, antibiotic regimen, etc.). Similarly, the clinical feature database includes a list L of features associated with condition Z. Z , where the list of features L Z Included are a plurality of features known to be associated with condition Z, or predicted to be associated with condition Z, or otherwise correlated with condition Z. For a variety of different diagnoses, conditions, disorders or diseases, and so on.

[0093] According to one embodiment, feature extraction instructions 264 direct the system to use the identified multiple features for clinical diagnoses, conditions, or diseases to extract feature values ​​for a first time period from multiple patient records for multiple patients. Feature values ​​can be extracted using any known mechanism, process, or procedure to identify and extract feature values ​​for features from medical records. The first time period can be any time period and can be a predetermined, programmed, default, learned, or any other time period. According to one embodiment, the time period is the entire time range found in multiple records of a patient.

[0094] According to an embodiment, the feature value table 265 is a data structure with extracted feature values. The data structure can be any data structure sufficient to store the extracted feature values ​​and enable identification and retrieval of features and / or feature values ​​from the data structure. The data structure can be stored in a memory of the patient group creation system.

[0095] According to one embodiment, the reporting instructions 266 direct the system to generate and provide information including the first patient group and / or the modified patient group to the user via the user interface. Alternatively, the information can be transmitted to another device via wired and / or wireless communication. For example, the system can transmit the information to a mobile phone, a computer, a laptop, a wearable device, and / or any other device configured to allow display and / or other communication of information.

[0096] According to one embodiment, the patient group creation system is configured to: process thousands or millions of data points in the patient data to identify and extract a list of features for multiple different clinical diagnoses, conditions, or diseases; populate a table of feature values; generate patient groups; and modify patient groups. For example, generating functional patient groups according to the claimed methods and systems requires processing millions of data points from the input data. This may require millions or billions of calculations to generate patient groups. Therefore, generating patient groups includes a process with a large number of calculations and analyses, which cannot be completed by the human brain in a lifetime or several lifetimes.

[0097] By providing an improved patient cohort creation system as described herein or otherwise envisioned, this novel patient cohort creation system has a tremendous positive impact on processing efficiency, researcher time, the basic research itself, and patient care as compared to prior art systems.

[0098] All definitions, as defined and used herein, should be understood to control over dictionary definitions, definitions in documents incorporated by reference, and / or ordinary meanings of the defined terms.

[0099] Unless explicitly stated to the contrary, the terms "a" and "an" as used in this specification and the claims should be understood to mean "at least one."

[0100] The phrase "and / or" as used in this specification and claims should be understood to mean "either or both" of the elements so combined, i.e., elements that are present in combination in some cases and separately in other cases. Multiple elements listed with "and / or" should be interpreted in the same manner, i.e., "one or more" of the elements so combined. In addition to the elements specifically identified with the "and / or" clause, other elements may optionally be present, whether related or unrelated to those elements specifically identified.

[0101] "Or" used in the specification and claims herein should be understood to have the same meaning as "and / or" defined above. For example, when separating items in a list, "or" or "and / or" should be interpreted as inclusive, that is, including at least one, but also including more than one element of a plurality of elements or element lists and (optionally) additional unlisted items. Only terms that clearly indicate the opposite (e.g., "only one of" or "exactly one of" or "consisting of" used in the claims) will refer to including exactly one element in a plurality of elements or element lists. In general, when there is an exclusive term (e.g., "any one of", "one of", "any one of" or "exactly one of") in front of the term "or" used herein, the term "or" should only be interpreted as representing an exclusive alternative (i.e., "one or the other but not both").

[0102] The phrase "at least one" used herein in the specification and claims referring to a list of one or more elements should be understood to mean at least one element selected from any one or more elements in the list of elements, but not necessarily including at least one element of each element specifically listed in the list of elements, and not excluding any combination of elements in the list of elements. This definition also allows for optional elements other than the elements specifically identified in the list of elements to which the phrase "at least one" refers, whether related or unrelated to those elements specifically identified.

[0103] It should also be understood that in any method claimed herein that includes more than one step or action, the order of the steps or actions of the method is not necessarily limited to the order in which the steps or actions of the method are described unless explicitly stated to the contrary.

[0104] In the claims and the description above, all transitional phrases (e.g., "including," "comprising," "carrying," "having," "containing," "involving," "holding," "with," etc.) should be construed as open-ended, i.e., meaning including, but not limited to. Only the transitional phrases "consisting of" and "consisting essentially of" should be closed or semi-closed transitional phrases, respectively.

[0105] Although several inventive embodiments have been described and illustrated herein, a person of ordinary skill in the art will readily appreciate various other units and / or structures for performing functions and / or obtaining results and / or one or more of the advantages described herein. Each of such changes and / or modifications is considered to be within the scope of the inventive embodiments described herein. More generally, it will be readily understood by those skilled in the art that all parameters, dimensions, materials, and configurations described herein are intended to be exemplary, and that actual parameters, dimensions, materials, and / or configurations will depend on one or more specific applications using the teachings of the present invention. Those skilled in the art will recognize or be able to use experimental means not exceeding conventional means to determine many equivalents of the specific inventive embodiments described herein. Therefore, it should be understood that the foregoing embodiments are presented only as examples, and within the scope of the claims and their equivalents, embodiments of the present invention may be practiced in a manner different from that specifically described and claimed. The inventive embodiments of the present disclosure relate to each individual feature, system, article, material, kit, and / or method described herein. In addition, if such features, systems, articles, materials, kits, and / or methods are not mutually contradictory, any combination of two or more such features, systems, articles, materials, kits, and / or methods can be included within the scope of the invention of the present disclosure.

Claims

1. A method for generating a modified patient group from a database comprising a plurality of patient records for a plurality of patients, the modified patient group comprising a subset of the plurality of patients in the database, the method comprising: receiving the plurality of patient records for the plurality of patients from the database; retrieving a predetermined plurality of features for a clinical diagnosis, condition, or disease from a clinical features database, wherein the clinical features database includes a predetermined plurality of features for each of a plurality of clinical diagnoses, conditions, or diseases; extracting clinical features from at least some of the plurality of patient records of the plurality of patients using the predetermined plurality of features for the clinical diagnosis, condition, or disease to generate a clinical feature dataset for a first time period; generating a feature value table including the extracted clinical feature data set in a memory; identifying, in response to a user request for a group of patients based on one of the plurality of clinical diagnoses, conditions, or diseases, a first group of patients for a predetermined time period from the table of characteristic values, wherein the predetermined time period is some or all of the first time period, and wherein the first group of patients is a subset of the plurality of patients in the table of characteristic values; providing the first patient group to a user via a user interface; Receiving a modification request from the user to modify the first patient group, wherein the modification comprises modification of one or more of: (i) patients in the first patient group; (ii) the predetermined time period; and (iii) the predetermined plurality of features for the clinical diagnosis, condition, or disease; modifying the first patient group based on the received modification request and without additionally extracting clinical features to generate a modified patient group; and The modified patient group is provided to the user via the user interface.

2. The method according to claim 1, wherein: The feature value table includes, for each of a plurality of patients, a patient identification and feature values ​​for some or all of the predetermined plurality of features for the clinical diagnosis, condition or disease.

3. The method according to claim 1, wherein: The first patient group and the modified patient group include a list of patients, each patient being identified by a patient ID and a feature value for each of the predetermined plurality of features for each patient.

4. The method according to claim 1, wherein: The modified patient group includes more patients than the first patient group.

5. The method according to claim 1, wherein: The modified patient group includes one or more additional characteristics compared to the first patient group.

6. The method according to claim 1, wherein: The modified patient cohort includes a longer or shorter time period than the first patient cohort.

7. The method according to claim 1, wherein: The modification request received from the user includes identification of a feature not originally listed in the predetermined plurality of features for the clinical diagnosis, condition, or disease.

8. The method according to claim 1, wherein: The predetermined period of time is the period of time prior to the onset of the clinical condition.

9. A system for generating a modified patient cohort, comprising: a database comprising a plurality of patient records for a plurality of patients; a clinical profile database comprising a predetermined plurality of profiles for each of a plurality of clinical diagnoses, conditions or diseases; User interface; as well as A processor configured to: (i) retrieve a predetermined plurality of features for a clinical diagnosis, condition, or disease from a clinical feature database; (ii) extracting clinical features from at least some of the plurality of patient records of the plurality of patients using the predetermined plurality of features for the clinical diagnosis, condition or disease to generate a clinical feature dataset for a first time period; (iii) generating a feature value table including the extracted clinical feature data set in a memory; (iv) in response to a user request for a patient group based on one of the multiple clinical diagnoses, conditions or diseases, identifying a first patient group for a predetermined time period based on the feature value table, wherein the predetermined time period is some or all of the first time period, and wherein the first patient group is a subset of the multiple patients in the feature value table; (v) providing the first patient group to the user via the user interface; (vi) receiving a modification request from the user to modify the first patient group, wherein the modification includes modification of one or more of the following: the patients in the first patient group; the predetermined time period; and the predetermined multiple features for the clinical diagnosis, condition or disease; (vii) modifying the first patient group based on the received modification request and without additionally extracting clinical features to generate a modified patient group; and (viii) providing the modified patient group to the user via the user interface.

10. The system according to claim 9, wherein: The feature value table includes, for each of a plurality of patients, a patient identification and feature values ​​for some or all of the predetermined plurality of features for the clinical diagnosis, condition or disease.

11. The system according to claim 9, wherein: The first patient group and the modified patient group include a list of patients, each patient being identified by a patient ID and a feature value for each of the predetermined plurality of features for each patient.

12. The system according to claim 9, wherein: The modified patient group includes more patients than the first patient group.

13. The system according to claim 9, wherein: The modified patient group includes one or more additional characteristics compared to the first patient group.

14. The system according to claim 9, wherein: The modified patient cohort includes a longer or shorter time period than the first patient cohort.

15. The system according to claim 9, wherein: The modification request received from the user includes identification of a feature not originally listed in the predetermined plurality of features for the clinical diagnosis, condition, or disease.

Images