Method and apparatus for identifying high risk patients for protective percutaneous coronary intervention therapy

Abstract

Methods and devices are provided for identifying whether a patient meets a protective percutaneous coronary intervention # imgabs0 # condition. The method comprises the following steps: receiving medical information of a patient; extracting one or more features from the received medical information; classifying the patient with respect to an eligibility of the patient for protective # imgabs1 # based at least in part on the extracted one or more features to produce a patient classification; and outputting an indication of the patient classification.

Description

Technical Field

[0001] The present disclosure relates to identifying patients for protected percutaneous coronary intervention. Background Art

[0002] Percutaneous coronary intervention (PCI) is a minimally invasive procedure used to open blocked coronary arteries. Examples of PCI include balloon angioplasty, angioplasty with stents, and atherectomy. Patients with coronary artery blockage may be candidates for PCI, where some patients qualify for regular PCI, other patients qualify for high-risk PCI, and other patients do not qualify for high-risk PCI due to major risk factors, depending on various risk factors. Summary of the invention

[0003] Described herein are systems and methods for identifying patients who are at high risk for complications and who may benefit from mechanical circulatory support during percutaneous coronary intervention (PCI).

[0004] In some embodiments, a method is provided for identifying whether a patient is eligible for protected percutaneous coronary intervention (protective The method includes: receiving medical information of a patient; extracting one or more features from the received medical information; determining a protective condition for the patient based at least in part on the extracted one or more features; classifying the patient based on the eligibility of the patient to produce a patient classification; and outputting an indication of the patient classification.

[0005] In one aspect, the medical information of the patient includes one or more of an electronic health record, a laboratory report, an electrocardiogram report, and a medical imaging report. In one aspect, the medical information includes structured data and unstructured data. In one aspect, extracting one or more features includes extracting at least some of the one or more features from the unstructured data using natural language processing. In one aspect, extracting one or more features includes extracting at least some of the one or more features using natural language processing. In one aspect, extracting at least some of the one or more features using natural language processing includes performing natural language processing across multiple types of the medical information.

[0006] In one aspect, the one or more features include left ventricular ejection fraction and / or values ​​associated with one or more comorbidities of the patient. In one aspect, the one or more features further include one or more of diagnostic information. In one aspect, the one or more features further include at least one cardiac value, one or more angiographic values, and one or more features of a heart disease.

[0007] In one aspect, the method further comprises: determining whether the patient satisfies one or more inclusion criteria and / or one or more exclusion criteria, and classifying the patient to generate the patient classification comprises generating the patient classification based at least in part on whether the patient satisfies the one or more inclusion criteria and / or the one or more exclusion criteria. In one aspect, classifying the patient comprises determining that the patient does not meet the protective criteria when the patient does not meet at least one of the one or more inclusion criteria and / or when the patient meets at least one of the one or more exclusion criteria. In one aspect, at least one of the one or more inclusion criteria is based at least in part on the extracted one or more features. In one aspect, the one or more inclusion criteria include at least one criterion based on left ventricular ejection fraction.

[0008] In one aspect, classifying the patient comprises providing the extracted one or more features as input to at least one model, wherein the patient classification is generated based at least in part on an output of the at least one model. In one aspect, the at least one model is a trained statistical model. In one aspect, the method further comprises: receiving an indication indicating whether the patient is receiving protective or will be eligible to receive protective data received; and updating the at least one model based at least in part on a comparison of the received data with the generated patient classification. In one aspect, the at least one model is configured to output a score, and wherein the patient classification is generated based at least in part on the score output from the at least one model. In one aspect, the method further includes: determining whether the score output from the at least one model is above a threshold; and when it is determined that the score is above the threshold, classifying the patient as meeting protective condition.

[0009] In one aspect, extracting one or more features includes applying feature-specific extraction logic to the received medical information to extract the one or more features. In one aspect, applying the feature-specific extraction logic includes: selecting a procedure report from the received medical information; searching for one or more keywords in the selected procedure report; and extracting feature values ​​of specific keywords based on identification of the one or more keywords in the selected procedure report. In one aspect, the method further includes: identifying multiple keywords of the one or more keywords in the selected procedure report; and selecting specific keywords of the multiple keywords based on priority information associated with the multiple keywords in the feature-specific extraction logic, and extracting feature values ​​of the one or more features includes extracting the feature values ​​of the specific keywords. In one aspect, the method further includes: determining that the specific keyword is associated with an absolute feature value; and extracting the absolute feature value as the feature value. In one aspect, the method further includes: determining that the specific keyword is associated with a range of values; and extracting the feature value as an average from the range of values. In one aspect, the method further includes: determining that the particular keyword is associated with text; accessing a lookup table comprising mappings of terms to values; and extracting the feature value based at least in part on terms in the text associated with the particular keyword and the mapping in the lookup table.

[0010] In one aspect, the medical information of the patient is first medical information received at a first time and the method further includes: receiving second medical information of the patient at a second time after the first time; reclassifying the patient relative to the patient's eligibility for protected PCI based at least in part on the received second medical information to produce an updated patient classification; and outputting an indication of the updated patient classification. In one aspect, receiving the second medical information includes receiving the second medical information from the patient's electronic health record. In one aspect, receiving the second medical information includes receiving the second medical information via a user interface provided by a computer-implemented system. In one aspect, the second medical information includes at least one updated value of the one or more features extracted from the first medical information. In one aspect, the method further includes: extracting one or more updated features from the second medical information, and performing the reclassification based at least in part on the one or more updated features.

[0011] In one aspect, the method further includes: providing a user interface configured to display values ​​of the one or more characteristics; receiving user input via the user interface to change one or more of the values ​​of the one or more characteristics; simulating a classification of the patient relative to the patient's eligibility for protected PCI based at least in part on changing the one or more values ​​to produce a simulated patient classification; and displaying the simulated patient classification on the user interface.

[0012] In some embodiments, a computer-implemented system for identifying whether a patient is eligible for a protective percutaneous coronary intervention (PCI) is provided. The system includes at least one hardware computer processor and at least one non-transitory computer-readable medium encoded with a plurality of instructions that, when processed by the at least one hardware computer processor, perform a method. The method includes: extracting one or more features from the patient's medical information; determining whether the patient is eligible for a protective PCI based at least in part on the extracted one or more features; classifying the patient according to the eligibility of the patient to produce a patient classification; and outputting an indication of the patient classification.

[0013] In some embodiments, at least one non-transitory computer-readable medium is encoded with a plurality of instructions that, when processed by the at least one hardware computer processor, perform a method. The method includes: extracting one or more features from the medical information of the patient; determining a protective risk for the patient based at least in part on the extracted one or more features; classifying the patient according to the eligibility of the patient to produce a patient classification; and outputting an indication of the patient classification. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 Describe some embodiments of the present technology for predicting the patient's protective Flow chart of the qualification process;

[0015] Figure 2 schematically illustrates a number of features that may be used to generate a hemodynamic compromise score according to some embodiments of the present technology;

[0016] Figure 3 Describe some embodiments of the present technology for predicting a patient's protective Flow chart of the qualification process;

[0017] Figure 4 Describes some embodiments of the present technology for protecting patients from Flowchart of the process for triaging patients for eligibility;

[0018] Figure 5Schematically illustrating a method for protecting a patient from a Two classification techniques to categorize patients based on their eligibility;

[0019] Figure 6 Schematically illustrating a method for protecting a patient from a Two classification techniques to categorize patients based on their eligibility;

[0020] Figure 7 Schematically illustrating a method for protecting a patient from injury when working with an interventional cardiologist according to some embodiments of the present technology. Workflow to triage patients based on their eligibility;

[0021] Figure 8 Schematically illustrating a method for protecting a patient from a heart attack when working with a cardiologist according to some embodiments of the present technology. Workflow to triage patients based on their eligibility;

[0022] Fig. 9 Schematically illustrates how a model / algorithm for classifying patients according to some embodiments of the present technology may be updated based on a comparison of actual and predicted values ​​output from the model / algorithm;

[0023] Fig.10 A flow chart illustrating a process for extracting feature values ​​from electronic medical information according to some embodiments of the present technology; and

[0024] Fig.11 A flow chart illustrating a process for updating a patient classification in accordance with some embodiments of the present technology. DETAILED DESCRIPTION

[0025] As is known, percutaneous coronary intervention (PCI) can be used to open blocked coronary arteries in patients, such as those with coronary artery disease. Unfortunately, using conventional risk factor analysis, a large proportion of patients who would benefit from PCI are not eligible for even high-risk PCI due to major risk factors. The inventors have recognized and appreciated that patients may be eligible for PCI if, during the procedure, they receive mechanical circulatory support (e.g., via a percutaneous mechanical heart pump) to temporarily support the heart during the procedure and ensure that blood flow to critical organs is maintained. This procedure may be referred to as "protective PCI". ", because the heart pump is used to protect the patient's heart during PCI. To this end, some embodiments are directed to data-driven techniques to identify Predicting which patients would benefit from the use of a mechanical heart pump during PCI would enable those patients to benefit via PCI, thereby improving patient care and procedural outcomes.

[0026] Figure 1 Describes some embodiments of the present technology for identifying protective In act 110, it is determined whether the patient meets one or more inclusion and / or exclusion criteria to be considered a protected Any suitable inclusion / exclusion criteria, examples of which are provided herein, may be used. In some embodiments of the present technology, only the inclusion criteria are considered in act 110 and no exclusion criteria are considered. If it is determined in act 110 that the patient does not meet the inclusion / exclusion criteria, then process 100 proceeds to act 120, where it is determined that the patient is not a protective If it is determined in act 110 that the patient meets the inclusion / exclusion criteria, process 100 proceeds to act 130, where a hemodynamic compromise score is determined. In some embodiments, the hemodynamic compromise score may be determined using one or more trained models (e.g., one or more machine learning models) configured to take as input one or more values ​​or features extracted from medical information (e.g., electronic health records, laboratory reports, medical imaging reports, etc.) and output a hemodynamic compromise score. Figure 2 A non-limiting example of medical information that can be used to determine a hemodynamic compromise score is schematically shown in FIG. Figures 4 to 6 Additional types of medical information that may be used to determine a hemodynamic compromise score are described in further detail.Any suitable model may be used to determine a hemodynamic compromise score, and embodiments of the present technology are not limited in this respect.

[0027] Next, process 100 proceeds to act 140, where it is determined whether the determined hemodynamic compromise score is above a threshold. If it is determined in act 140 that the score is not above the threshold, then process 100 proceeds to act 120, where it is determined that the patient is not protective. If the score is determined to be above the threshold in act 140, process 100 proceeds to act 150, where the patient is identified as a protective If together with Figure 3 As described in the process 300 shown in FIG. 1 , when determining whether a patient is identified as a protective When selecting a candidate, other criteria besides determining whether the score is above a threshold may be considered.

[0028] In some embodiments, the protectiveness determined in act 150 Advice is provided to a healthcare professional (e.g., physician, such as a cardiologist or interventional cardiologist, medical assistant, and / or healthcare coordinator). Advice may be provided in any suitable manner. An indicator of the recommendation may be automatically included in the patient's electronic health record. In some embodiments, the indicator may include a text alert (e.g., "Protective PCI Recommended"). In other embodiments, the indicator may include a visual indicator, such as a visual indicator to provide a healthcare professional with a protective PCI recommendation. The proposed green-red indicator system, where “green” patients are protective good candidate for protection and “red” means the patient is not In some embodiments, the techniques described herein may be used to analyze medical information of multiple patients in a medical facility (e.g., a hospital) to identify and / or prioritize protective patients, and the most suitable A summary report of the patient is provided to a medical professional (e.g., a physician) to facilitate clinical decisions regarding the patient's care.

[0029] In some embodiments, one or more medical professionals may The feedback provided by the suggestion can be used to improve the accuracy of the model used to determine the hemodynamic compromise score. For example, if a medical professional agrees that the patient is protective good candidate for (or alternatively, not protective of If a recommendation is made that a patient is a good candidate for a procedure, the information can be used to update (e.g., retrain) the model used to determine the hemodynamic compromise score to further improve the accuracy of the model based on the feedback. In some examples, this feedback can be provided to the patient's EHR, which is configured to transmit the feedback to the system. In such examples, the EHR can also be configured to monitor whether the physician selected the patient for a follow-up, whether the follow-up occurred, whether the patient wished to wait, and / or whether the procedure occurred. Again, one or more of these parameters can be used to retrain the model. It can also be integrated into the score (see, for example, relative to Fig.11 In other examples, feedback may be provided to a computer-implemented (or mobile device-implemented) system that performs the classification. In such examples, the system may be configured to transmit this data to the patient's EHR.

[0030] Figure 3 Describes some embodiments of the present technology for identifying protective A flowchart of the process 300 for a patient. Figure 3In the example process shown in FIG. 1 , process 100 considers certain features and values ​​to determine whether a patient should be identified as protective . In act 310, the inclusion criteria may include a left ventricular ejection fraction (LVEF) less than or equal to 45% and having a diagnostic cardiac catheterization report in their electronic health record. No exclusion criteria are specified. If it is determined that the patient meets these inclusion criteria, then process 300 proceeds to act 320, where a hemodynamic compromise score for the patient is determined. As discussed with respect to process 100, the hemodynamic compromise score may be determined as an output of one or more models that take as input features or values ​​based on the patient's medical information. The input features or values ​​provided as input to the model may be related to the inclusion criteria considered in act 310 and / or may be unrelated to the inclusion criteria.

[0031] Next, process 300 proceeds to act 330, where it is determined whether the patient's LVEF is less than or equal to 35%. If it is determined in act 330 that the LVEF is less than or equal to 35%, then process 300 proceeds to act 360, where the patient is identified as protective. If it is determined in act 330 that the patient's LVEF is not less than or equal to 35% (i.e., the LVEF is 35% to 45%), then process 300 proceeds to act 340, where it is determined whether the hemodynamic compromise score is above threshold X. If it is determined in act 340 that the score is less than threshold X, then process 300 proceeds to act 350, where the patient is identified as not a protective If it is determined in act 340 that the score is greater than threshold X, then process 300 proceeds to act 360, where the patient is identified as a protective candidate.

[0032] Figure 4 According to some embodiments of the present technology, a method for classifying a patient as protective based on medical information is provided. Flowchart of process 400 for selecting good / bad candidates for a procedure. In action 410, electronic medical information of a patient is received. The electronic medical information may include, but is not limited to, electronic health records (EHRs), laboratory reports, medical procedure reports (e.g., electrocardiogram reports), physician prescriptions, and medical imaging reports. Next, process 400 proceeds to action 420, where one or more features are extracted from the received medical information. The extracted one or more features may include, but are not limited to, diagnostic information, cardiac function values ​​(e.g., LVEF, cardiac power), comorbidities (e.g., anemia, chronic obstructive pulmonary disease (COPD), hypertension), angiographic information, and cardiac disease descriptors (e.g., long calcified lesions and mitral insufficiency). The received medical information may include structured data (e.g., organized based on an ontology, e.g., using tags, fields, or other metadata associated with data that can be used for feature extraction) and / or unstructured data (e.g., electronically entered into a physician prescription from a text field).

[0033] In some embodiments of the present technology, at least some of the one or more features are extracted using natural language processing (NLP) techniques. Such NLP techniques may be used to analyze text in received medical information to infer information determined to be features. NLP may be used to analyze individual types of medical information (e.g., medical reports) and / or may be used to extract one or more features across multiple types of medical information. In some examples, a first set of features may be extracted using one or more manual techniques and a second set of features may be extracted using automatic (e.g., NLP) techniques. Fig.10 Automated techniques for extracting one or more features from a patient's electronic medical information (eg, electronic health records) are described in further detail.

[0034] Next, process 400 proceeds to act 430, where the patient is classified (e.g., as a protective The extracted features may be provided as input to, for example, a model that is trained to output a patient classification (e.g., a trained machine learning model), or may be provided as input to an algorithm that weights the features to determine a classification of the patient based on their scores. Next, process 400 proceeds to act 440, where the patient classification determined in act 430 is output. The patient classification may be output in any suitable manner, examples of which are described above in conjunction with Figure 1 4. For example, a visual indicator (e.g., red, yellow, green) may be associated with the patient to indicate the classification. Alternatively, process 400 may be performed for each of a plurality of patients in a medical facility, and the patient classified as most likely to benefit from protective therapy may be output in act 440. list of patients.

[0035] In some embodiments, a patient may be flagged for additional follow-up (e.g., if the patient is approaching the recommended time for protective As mentioned in this article together with Fig.11 As described, in some embodiments, a protective A patient may be reclassified as the patient's medical status changes over time. For example, a patient who was initially classified as not recommended for protective therapy may be reclassified as additional medical information associated with the patient becomes available (e.g., by input into the patient's electronic health record and / or by direct input into a computer-implemented (or mobile device-implemented) system configured to output the patient classification). Patients may be reclassified as recommended for protective therapy based on intervening medical data that may be considered during the reclassification period (e.g., additional cardiac catheterization laboratory reports, additional blood work data, etc.). In this way, the triage status of patients at a healthcare facility can be tracked over time to dynamically identify patients who may benefit from protective Procedure patients.

[0036] As will be appreciated, if a patient presents a case of concern (e.g., may be classified as a recommended protective The patient may also be flagged for additional follow-up if the physician needs additional information before recommending a procedure to their patient. As above, once the additional information has been received, the patient may be reclassified again (e.g., with a similar or different classification), and the physician may make recommendations to their patient based on the classification.

[0037] In some embodiments of the present technology, different classification techniques may be used for different healthcare systems and / or multiple classification techniques may be used in a single healthcare system. Figure 5 Two such techniques are schematically illustrated—“screener” triage techniques that are configured to primarily (or only) analyze electronic health records (EHRs) to identify patients at a health center for further manual screening to assess for protective and "algorithmic" classification techniques, which are more complex than filter classification techniques because a model or algorithm based on the extracted features is used to classify the patients, such as (for example) in conjunction with Figure 1 , 3and 4. The filter technique may be less complex than the algorithmic technique because one or more of the following may be true: the filter technique may operate on limited patient data (e.g., only EHR data); the filter technique may provide a simpler feature extraction process than the algorithmic technique; and the output of the filter technique may be less complex and / or less predictive than the output of the algorithmic technique, such that further follow-up (by a human or another classification process) may be required for the filter technique but not necessarily for the algorithmic technique.

[0038] Figure 6 Schematically illustrating that different healthcare systems (e.g., hospitals, medical clinics, etc.) may use one or more classification techniques to identify patients who would benefit from protective For example, continue Figure 5 Some healthcare systems may use the "filter" classification technique, other healthcare systems may use the "algorithm" classification technique; and other healthcare systems may use both techniques or a combination thereof. Figure 6 As shown in FIG, filter triage techniques may have simpler workflows and may be advantageous for use in healthcare systems with limited patient data (although their use is not limited thereto). For example, a rural clinic or other healthcare facility without a laboratory and / or medical imaging facility may be more suitable for using filter triage techniques. However, it should be appreciated that the use of less complex filter techniques is not limited. For example, a large healthcare system may employ filter triage techniques to identify patients who may benefit from protective The medical information of the subset of patients identified by the screener classification technique may then be further analyzed using an algorithmic classification technique (or some other classification technique) to refine the subset of patients to identify those who meet the protective criteria. It should be appreciated that some healthcare systems may use only one type of classification technique (eg, only filter techniques, algorithmic techniques, or some other technique not shown in the figure).

[0039] Figure 7 and 8 Describe the use of the techniques described in this article to classify patients as eligible or ineligible for protective Example workflow of the condition. Figure 7In the example workflow shown in , a care coordinator may work with an interventional cardiologist (IC). As an overview of the workflow, the results of the filter classification technique may be reviewed by a care coordinator from the IC's office. Based on the review, a subset of "qualified" cases may be submitted to the IC for review and thereafter reviewed by the IC. In some embodiments, the qualified cases may be determined based at least in part on automatic analysis of data extracted from the patient's electronic health record and / or other electronic medical information (an example of which is described herein). In some embodiments, automatically analyzing the extracted data includes associating one or more scores with a set of extracted data. For example, the extracted data may be associated with one or more categories and a score may be applied to each category of the extracted data. Non-limiting examples of categories associated with the extracted data include, but are not limited to, gender, age, family history of cardiac disease, LVEF value, chronology of LVEF, comorbidities (e.g., cardiac morbidity (e.g., successful resuscitation after a cardiac event), non-cardiac major comorbidities (e.g., end-stage renal disease (ESRD), peripheral vascular disease (PVD), other comorbidities), combination of comorbidities, presence of one or more diseases (e.g., coronary artery disease, left main coronary artery disease and / or chronic total occlusion), findings from ECHO (e.g., TTE, TEE, and stress), whether a cardiac surgeon or interventional cardiologist has been consulted, number of diagnostic catheterizations, number of follow-up visits for inpatient stays, other cardiac medications, or whether the patient has undergone prior coronary artery bypass graft surgery (CABG), a PCI procedure, an open heart procedure, and / or undergone a procedure to implant a cardiac device. In some embodiments, the score assigned to the category of the extracted data depends at least in part on the value of the extracted data. For example, for an extracted LV EF value, if LVEF <= 40%, then the first score can be used, and if the LVEF is between 41% and 50%, then the second score can be used. In some embodiments, the score associated with the extracted data can be selected to represent the level of risk associated with the specific data. For example, a higher score can be assigned to each category of data with a value corresponding to a higher risk factor for the patient. In some embodiments, a cumulative score (e.g., across multiple categories) can be provided for review. In some embodiments, the cumulative score can be determined by adding the scores associated with each category. In some embodiments, the data associated with each category can be evenly weighted so that the cumulative score is determined by adding the individual category scores. In other embodiments, data associated with one or more categories can be weighted higher than other categories so that the cumulative score represents the weighted sum of individual category scores. Accordingly, if the first category can be associated with a higher risk factor for the patient than the second category, the weight of the first category can be heavier than the second category.

[0040] Information related to the score may be provided to the care coordinator in any suitable manner. For example, information may be provided to the care coordinator in a user interface that provides an indication of the score and / or describes how the score is calculated based on the extracted data. For shortlisted cases, the IC may contact the patient or refer the identified case to an internist or cardiologist for patient outreach. Based on a review of the results of the filter classification technique, the user may interact with the user interface to change one or more aspects of the score, and such changes may reflect the shortlist of cases identified during the workflow. In some embodiments, the status assigned to a particular patient may be used additionally or alternatively to update the shortlist of cases identified during the workflow.

[0041] exist Figure 8 In the example workflow shown in , a medical assistant can work with a cardiologist. As an overview of the workflow, the results of the filter classification technique can be reviewed by a medical assistant from the cardiologist's clinic. Based on the review, a subset of "qualified" cases can be referred to the cardiologist for review and then reviewed by the cardiologist. Figure 7 In the workflow of , shortlisted cases may be determined based at least in part on automated analysis of data extracted from the patient's electronic health record and / or other electronic medical information (an example of which is described herein). For shortlisted cases, a cardiologist may contact the patient or refer the patient to an IC for further perspective and / or advice. Based on a review of the results of the filter classification technique, a user (e.g., a cardiologist) may interact with the user interface to change one or more aspects of the score, and such changes may be reflected in the shortlist of cases identified during the workflow. In some embodiments, the status assigned to a particular patient may be used additionally or alternatively to update the shortlist of cases identified during the workflow.

[0042] As you will understand, for Figure 7 and 8 In both workflows, in some rationales, patients can be classified as "borderline", such as relative to Fig.11 As described, and reclassified after obtaining additional information. In such examples, the classification can be updated after this additional information is available, and the new classification is forwarded to hospital staff.

[0043] As described herein, for embodiments of the present technology that employ a model or algorithm in which the extracted features may be weighted to determine a patient classification, the model / algorithm may be weighted based on whether the classification provided by the model / algorithm is consistent with whether the patient is eligible for protective The model / algorithm is updated (e.g., retrained or tuned) based on consistent or inconsistent feedback from healthcare professionals evaluating the eligibility of the model / algorithm. Fig. 9Schematic illustration of the comparison of the prediction or recommendation output by the model / algorithm with the actual value of accepting / not accepting protective measures based on published guidelines or physician labeling or patients who will / will not qualify. Fig. 9 Further illustrated are example ways in which models / algorithms can be tuned by applying feedback to mitigate false positives and false negatives.

[0044] As shown, when there are true positives or true negatives, the model / algorithm performs well (i.e., the output of the model / algorithm is consistent with the actual value). False negatives (patients receiving or eligible for protective therapy) can occur when the features that determine the most association are not sensitive enough (e.g., not weighted enough). , but the model / algorithm did not identify the patient as eligible for protective In such examples, the weights of the features may be adjusted accordingly to improve the predictions output from the model / algorithm. Other aspects of the model / algorithm may also be updated, such as Fig. 9 For example, if the model / algorithm is too sensitive to certain features (e.g., weights are too large), false positives (patients who do not receive or meet protective condition, but the model / algorithm identifies the patient as eligible for protective In such examples, the weights of the features may be adjusted accordingly to improve the predictions output from the model / algorithm.

[0045] As described herein (e.g., in conjunction with Figure 4 ), some embodiments may be about extracting one or more features from electronic medical information to facilitate patient classification. The inventors have recognized and appreciated that variability in how information is represented and described in electronic medical information may complicate the extraction of one or more features if, for example, a simple keyword search or extraction based on a medical task code is used. For example, a medical diagnosis of coronary artery disease (CAD) may not be consistently indicated in a patient's electronic health record (EHR). If an extraction technique for determining whether a patient has CAD is configured to search a patient's EHR only for the presence / absence of a specific medical task code corresponding to CAD, for example, some patients who have characteristics of CAD but are not clearly diagnosed using a specific task code in their EHR may be missed. Some embodiments herein may extract features (e.g., whether a patient has CAD) from electronic medical information by examining additional data elements (e.g., medications and / or procedures (e.g., procedures related to CAD) associated with the feature).

[0046] Fig.10A process 1000 for extracting one or more features from electronic medical information in a granular manner according to some embodiments is illustrated. In act 1010, electronic health information of a plurality of patients may be analyzed to divide the patients into a plurality of cohorts, an example of which is shown in Table 1.

[0047]

[0048] Table 1: Example cohorts of patient populations

[0049] As shown in the example cohorts of Table 1, for Cohort 3, where patients had low LEVF values ​​(e.g., <35%) and did not undergo a PCI procedure, only 1 / 3 of the patients (those in Cohort 3B) had a CAD diagnosis described in their electronic medical information, even though all patients in Cohort 3 could be considered protective due to their low LEVF values. Some embodiments include techniques for using additional information in a patient's electronic medical information (e.g., medication information, procedure information) to determine whether a patient is associated with a particular characteristic (e.g., whether the patient has coronary artery disease), whereas this association may not be explicit in the patient's electronic medical information. For example, in the example cohort shown in Table 1, additional electronic medical information (e.g., procedure reports) of 2,000 patients in Cohort 3A may be analyzed to determine whether some or all of the patients have CAD (and therefore may qualify for protective Conditions), even though there is no clear CAD diagnosis in their medical records. The additional electronic medical information may include, but is not limited to, electrocardiograms, transthoracic echocardiograms (TTE), cardiovascular stress echoes, nuclear stress tests, cardiovascular stress tests, Doppler ultrasound tests, coronary diagnostic angiograms, and cardiac catheterization reports. The additional electronic medical information may include structured data and / or unstructured data.

[0050] Returning to process 1000, after separating the patients into multiple cohorts, process 1000 can proceed to act 1020, where feature-specific extraction logic is used to extract one or more features of interest from the additional electronic medical information. For example, feature-specific extraction logic for the feature "LVEF" can search for the presence of TTE in the patient's electronic medical information, and if found, information associated with LVEF can be extracted from the TTE.

[0051] Information associated with a particular feature can be extracted from the patient's electronic medical information in any suitable manner. In some embodiments, natural language processing is used to perform extraction. For example, one or more reports or other files specified in the feature-specific logic may be searched for one or more keywords to identify information associated with the feature to be extracted. When the feature-specific logic is configured to search for multiple keywords, the feature-specific logic may assign priorities to multiple keywords so that if multiple keywords are present in the electronic medical information, the keywords assigned a higher priority will be selected for extracting their corresponding values. Therefore, process 1000 may proceed to action 1030, wherein it is determined whether the electronic medical information (e.g., TTE) contains multiple keywords. If it is determined in action 1030 that the electronic medical information contains multiple keywords, then process 1000 may proceed to action 1040, wherein specific keywords are selected based on priority information associated with multiple keywords. For example, as described above, keywords with higher priority may be selected. If it is determined in act 1030 that the electronic medical information does not contain multiple keywords, or after selecting a specific keyword in act 1040, process 1000 may proceed to act 1050, where it is determined whether the selected keyword is associated with an absolute value of a feature. If it is determined that the keyword is associated with an absolute value of a feature, then process 1000 may proceed to act 1060, where the value of the feature associated with the keyword is extracted as a feature value. Otherwise, process 1000 may proceed to act 1070, where it is determined whether the keyword is associated with a range of values. If it is determined in act 1070 that the keyword is associated with a range of values, then process 1000 may proceed to act 1080, where the feature value is determined as an average value from the range of values ​​associated with the keyword. Otherwise, process 1000 may proceed to act 1090, where a lookup table is used to determine the value of the feature. For example, the electronic medical information may contain one or more words (e.g., normal, excellent, lower limit of normal, poor, severe, abnormal, etc.) that qualitatively describe the value of the feature. The extracted value of the feature may be based on a lookup table that maps one or more of these terms to values ​​(eg, based on ranges specified in the medical literature).

[0052] Actions 1020 to 1090 may be repeated for multiple features of interest to extract feature values ​​for multiple features from the patient's electronic medical information. The extracted feature values ​​may then be used, at least in part, to classify the patient (e.g., as a protective patients), as in this article relative to Figure 4 The process 400 is described as action 430 in FIG.

[0053] The inventors have recognized and appreciated that the protective Patients who were later classified as recommended for protective therapy could be due to an intervening event between when the patient was initially classified and at a later time point. Thus, the inventors appreciate the benefit of a system in which the patient classification (e.g., whether the patient is a protected For example, a physician or other health care provider may enter additional medical information into a user interface associated with the patient's electronic health record, and the patient classification may be updated based on the additional medical information. In other examples, the physician may order one or more tests that may be performed and later added to the patient's electronic health record. In other examples, the physician or other health care provider may enter the additional information directly into the computer-implemented (or mobile device-implemented) system that performs the patient classification. In such examples, updating the patient classification over time as new information associated with the patient becomes available may enable longitudinal tracking of the patient's classification status. For example, a patient who was initially classified as not protective Patients who are “borderline” candidates for CT scans may have their status reassessed based on additional information to reclassify them as protective candidate.

[0054] Fig.11 A process 1100 for updating a patient classification based on additional information in accordance with some embodiments of the present technology is described. In act 1110, a patient may be classified (e.g., as a protective For example, based at least in part on features extracted from the patient's electronic health record, a patient may be classified as a protective bad candidates (an example of such a feature is described herein). Next, process 1100 may proceed to action 1112, where additional information associated with the patient is received. For example, a physician may interact with a user interface of a computer system configured to implement one or more classification techniques described herein (e.g., filter classification techniques, algorithm classification techniques) to input at least some additional information. Alternatively, at least some of the additional information may be input into the patient's electronic health record (EHR) and the additional information may be provided from the EHR as input to the classification technique. In some embodiments, one or more classification techniques described herein may be integrated with the EHR (e.g., as a module or plug-in process associated with the EHR) so that when additional information is input into the EHR, an updated classification may be generated automatically and / or in response to a user request to generate a patient classification. In such embodiments, receiving additional information in action 1112 of process 1100 may be performed simultaneously with receiving the additional information when the additional information is input into the EHR. Act 1112 may also be performed concurrently with other acts of process 1100 (eg, acts 1114 and 1116, as described below).

[0055] In examples where the classification system is implemented as part of an EHR, it should be appreciated that the plug-in process can also be configured to perform calculations after a certain specified time period (e.g., every 5, 10, 15, 20 minutes) after new patient information is added to the patient record.

[0056] After receiving the additional information in act 1112, process 1100 may proceed to act 1114, where an updated patient classification may be determined based at least in part on the additional information. For example, the additional information may be provided as input to one or more of the classification techniques described herein to determine an updated patient classification. The additional information may be considered by the classification technique in any suitable manner. For example, the additional information may be used to replace some of the information used to generate an initial patient classification (e.g., the patient classification determined in act 1110). As a specific example, an updated LVEF value for a patient may be extracted from a new TTE that was not available when determining the initial patient classification, and the updated LVEF value for the patient may be used to replace the LVEF value used during the determination of the initial patient classification. In some embodiments, the additional information may enhance the data and / or features used in the initial patient classification data without replacing any particular value. Next, process 1100 may proceed to act 1116, where the updated patient classification may be output. As shown in conjunction with Figure 4 As discussed in process 400 of FIG. 1 , the updated patient classification may be output in any suitable manner, examples of which are described above in conjunction with Figure 1 100 is described in action 150 of process 100 shown in . For example, a visual indicator (e.g., red, yellow, green) can be associated with the patient to indicate the classification. As described in other processes herein, it should be understood that process 1100 can be performed for each of a plurality of patients in a medical facility, and in action 1116, the patient classified as most likely to benefit from protective In this way, all or a subset of patients at a health care facility can be tracked longitudinally to identify patients who may benefit from protective A current list of patients at a healthcare facility as new information about patients at the healthcare facility becomes available for consideration by the classification technology.

[0057] In some embodiments, a computer-implemented system configured to perform one or more of the patient classification techniques described herein may provide a user interface that enables a physician or other healthcare provider to test "what-if" situations by adjusting the values ​​of one or more features used to generate a patient classification. For example, the user interface may display the values ​​of multiple features extracted from the patient's EHR used to generate the patient's current patient classification. The healthcare provider may then interact with the user interface to change one or more values ​​displayed on the user interface (e.g., by typing or otherwise entering new values ​​into a field of the user interface), and may reclassify the patient based at least in part on the changed values ​​(e.g., as a simulation). In some embodiments, the user interface may present a slider element to represent the value of one or more of the features, and the healthcare provider may change the value by interacting with the slider element. By enabling the healthcare provider to simulate how changes in the values ​​of various features affect patient classification, the healthcare provider may gain a better understanding of how different features contribute to the determination of patient classification, and if the change may result in a recommendation that the patient receive protective , then can provide insights into specific features to be monitored in different patients.

[0058] Having described several aspects and embodiments of the technology described in this disclosure, it should be understood that a person skilled in the art will easily think of various substitutions, modifications and improvements. Such changes, modifications, improvements are expected to be within the spirit and scope of the technology described herein. For example, a person skilled in the art will easily envision a variety of other components and / or structures for performing functions and / or obtaining results and / or one or more of the advantages described herein, and each of such changes and / or modifications is considered to be within the scope of the embodiments described herein. A person skilled in the art will recognize, or be able to determine using no more than routine experiments, many equivalents of the specific embodiments described herein. Therefore, it should be understood that the aforementioned embodiments are presented only by way of example and within the scope of the attached claims and their equivalents, in addition to specific descriptions, creative embodiments can be practiced. In addition, if any combination of two or more features, systems, articles, materials, kits and / or methods described herein is consistent with each other, then such features, systems, articles, materials, kits and / or methods are included within the scope of this disclosure.

[0059] The above embodiments may be implemented in any of a variety of ways. One or more aspects and embodiments of the present disclosure relating to the performance of a process or method may utilize program instructions executable by a device (e.g., a computer, a processor, or other device) to perform or control the performance of a process or method. In this regard, various creative concepts may be embodied as computer-readable storage media (or multiple computer-readable storage media) (e.g., computer memory, one or more floppy disks, optical disks, optical disks, tapes, flash memories, circuit configurations in field programmable gate arrays or other semiconductor devices, or other tangible computer storage media) encoded using one or more programs, when executed on one or more computers or other processors, the one or more programs perform methods implementing one or more of the various embodiments described above. The computer-readable medium may be transportable so that the program stored thereon may be loaded into one or more different computers or other processors to implement the various aspects described above. In some embodiments, the computer-readable medium may be a non-transitory medium.

[0060] The above-described embodiments of the present technology may be implemented in any of a variety of ways. For example, embodiments may be implemented using hardware, software, or a combination thereof. When implemented in software, the software code may be executed on any suitable processor or set of processors, whether provided in a single computer or distributed among multiple computers. It should be understood that any component or set of components that perform the above-described functions may be generally considered to be a controller that controls the above-described functions. The controller may be implemented in a variety of ways, such as using dedicated hardware or using general-purpose hardware (e.g., one or more processors) that is programmed using microcode or software to perform the above-described functions, and may be implemented in a combination of a variety of ways when the controller corresponds to multiple components of the system.

[0061] Furthermore, it should be appreciated that the computer may be implemented in any of a variety of forms, such as a rack-mounted computer, a desktop computer, a laptop computer, or a tablet computer as non-limiting examples. Additionally, the computer may be embedded in a device not generally regarded as a computer but with appropriate processing capabilities, including a personal digital assistant (PDA), a smart phone, or any other suitable portable or fixed electronic device.

[0062] In addition, a computer may have one or more input and output devices. These devices may be used, among other things, to present a user interface. Examples of output devices that may be used to provide a user interface include a printer or display screen for visual presentation of output and a speaker or other sound generating device for audible presentation of output. Examples of input devices that may be used for a user interface include a keyboard and a pointing device, such as a mouse, a touch pad, and a digitized tablet computer. As another example, a computer may receive input information through speech recognition or in other audible formats.

[0063] Such computers may be interconnected by one or more networks in any suitable form, including a local area network or a wide area network, such as an enterprise network, an intelligent network (IN) or the Internet. Such networks may be based on any suitable technology and may operate according to any suitable protocol and may include wireless networks, wired networks or fiber optic networks.

[0064] In addition, as described, some aspects may be embodied as one or more methods. The actions performed as part of a method may be ordered in any suitable manner. Thus, embodiments may be constructed in which the actions are performed in an order different from that illustrated in the figures, which may include performing some actions simultaneously, even though shown as sequential actions in illustrative embodiments.

[0065] 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.

[0066] Unless explicitly indicated to the contrary, the indefinite articles "a" and "an" as used herein in the specification and claims should be understood to mean "at least one".

[0067] As used herein in the specification and claims, the phrase "and / or" 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 by the "and / or" clause, other elements may optionally be present, whether or not such elements are related to the elements specifically identified. Thus, as a non-limiting example, in an embodiment, when used in conjunction with open language such as "comprising," "reference to A and / or B" may reference only A (optionally including elements other than B); in another embodiment, reference only B (optionally including elements other than A); in yet another embodiment, reference to both A and B (optionally including other elements); etc.

[0068] As used herein in the specification and claims, the phrase "at least one" 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 of each and every element specifically listed in the list of elements and not excluding any combination of elements in the list of elements. This definition also allows that elements may optionally be present in addition to the elements specifically identified in the list of elements to which the phrase "at least one" refers, whether related or unrelated to the elements specifically identified. Thus, as a non-limiting example, in an embodiment, "at least one of A and B" (or equivalently, "at least one of A or B", or equivalently, "at least one of A and / or B") may refer to at least one, optionally including more than one A, in which B is not present (and optionally including elements other than B); in another embodiment, to at least one, optionally including more than one B, in which A is not present (and optionally including elements other than A); in yet another embodiment, to at least one (optionally including more than one A) and at least one (optionally including more than one B) (and optionally including other elements); and so on.

[0069] In addition, the words and terms used herein are for descriptive purposes only and should not be considered limiting. The use of "including," "comprising," or "having," "containing," "involving," and variations thereof herein is intended to encompass the items listed below and their equivalents as well as additional items.

[0070] In the claims and the foregoing specification, all transitional phrases (e.g., "comprising," "including," "carrying," "having," "containing," "involving," "having," "consisting of," and the like) shall be construed as open-ended (i.e., meaning including but not limited to). Only the transitional phrases "consisting of" and "consisting essentially of" shall be closed or semi-closed transitional phrases, respectively.

[0071] The use of ordinal terms such as "first", "second" and "third" in the claims to modify claim elements does not in itself imply any priority, precedence or order of one claim element over another claim element or the temporal order of the acts of performing a method therein, but serves merely as a label to distinguish one claim element having a particular name from another element having the same name (but for the use of ordinal terms) to distinguish claim elements.

Claims

1. A method for identifying whether a patient is eligible for protected percutaneous coronary intervention (PCI), the method comprising: Receive medical information from patients; extracting one or more features from the received medical information; classifying the patient with respect to the patient's eligibility for protected PCI based at least in part on the extracted one or more features to produce a patient classification; and An indication of the patient classification is output. 2 . The method of claim 1 , wherein the medical information of the patient comprises one or more of an electronic health record, a laboratory report, an electrocardiogram report, and a medical imaging report.

3. The method of claim 1, wherein the medical information comprises structured data and unstructured data. 4 . The method of claim 3 , wherein extracting one or more features comprises extracting at least some of the one or more features from the unstructured data using natural language processing. The method of claim 1 , wherein extracting one or more features comprises using natural language processing to extract at least some of the one or more features.

6. The method of claim 4 or 5, wherein using natural language processing to extract at least some of the one or more features comprises performing natural language processing across multiple types of the medical information.

7. The method of claim 1, wherein the one or more features include left ventricular ejection fraction and / or values ​​associated with one or more comorbidities of the patient.

8. The method of claim 7, wherein the one or more features further include one or more of diagnostic information.

9. The method of claim 8, wherein the one or more features further comprise one or more of at least one cardiac value, one or more angiographic values, and one or more features of a heart disease.

10. The method according to claim 1, further comprising: determining whether the patient meets one or more inclusion criteria and / or one or more exclusion criteria, and wherein Categorizing the patient to generate a patient classification includes generating the patient classification based at least in part on whether the patient satisfies the one or more inclusion criteria and / or the one or more exclusion criteria.

11. The method of claim 10, wherein classifying the patient comprises determining that the patient is not eligible for protected PCI when the patient does not meet at least one of the one or more inclusion criteria and / or when the patient meets at least one of the one or more exclusion criteria.

12. The method of claim 10, wherein at least one of the one or more inclusion criteria is based at least in part on the extracted one or more features.

13. The method of claim 12, wherein the one or more inclusion criteria include at least one criterion based on left ventricular ejection fraction.

14. The method of claim 1, wherein classifying the patient comprises: The extracted one or more features are provided as input to at least one model, wherein the patient classification is generated based at least in part on an output of the at least one model.

15. The method of claim 14, wherein the at least one model is a trained statistical model.

16. The method according to claim 14, further comprising: receiving data indicating whether the patient received or will be eligible to receive protected PCI; and The at least one model is updated based at least in part on a comparison of the received data and the generated patient classification.

17. The method of claim 14, wherein the at least one model is configured to output a score, and wherein the patient classification is generated based at least in part on the score output from the at least one model.

18. The method according to claim 17, further comprising: determining whether the score output from the at least one model is above a threshold; and When the score is determined to be above the threshold, the patient is classified as eligible for protective PCI.

19. The method according to claim 1, wherein the medical information of the patient is first medical information received at a first time, the method further comprising: receiving second medical information of the patient at a second time after the first time; reclassifying the patient with respect to the patient's eligibility for protected PCI based at least in part on the received second medical information to produce an updated patient classification; and An indication of the updated patient classification is output.

20. The method of claim 19, wherein receiving the second medical information comprises receiving the second medical information from an electronic health record of the patient.

21. The method of claim 19, wherein receiving the second medical information comprises receiving the second medical information via a user interface provided by a computer-implemented system.

22. The method of claim 19, wherein the second medical information includes at least one updated value of the one or more features extracted from the first medical information.

23. The method of claim 19, further comprising: extracting one or more updated features from the second medical information, Wherein the reclassification is performed based at least in part on the one or more updated features.

24. The method of claim 23, wherein extracting one or more features comprises: Feature specific extraction logic is applied to the received medical information to extract the one or more features.

25. The method of claim 24, wherein applying feature specific extraction logic comprises: selecting a procedural report from said received medical information; searching for one or more keywords in the selected program report; and A feature value for a specific keyword is extracted based on the identification of the one or more keywords in the selected program report.

26. The method of claim 25, further comprising: identifying a plurality of the one or more keywords in the selected program report; and selecting a specific keyword from the plurality of keywords based on priority information associated with the plurality of keywords in the feature-specific extraction logic, The step of extracting the feature value of the one or more features includes extracting the feature value of the specific keyword.

27. The method of claim 25 or claim 26, further comprising: Determining that the specific keyword is associated with an absolute feature value; and The absolute eigenvalue is extracted as the eigenvalue.

28. The method of claim 25 or claim 26, further comprising: determining that the particular keyword is associated with a range of values; and The characteristic value is extracted from the range of values ​​as an average value.

29. The method of claim 25 or claim 26, further comprising: determining that the specific keyword is associated with the text; Accessing a lookup table containing mappings of terms to values; and The feature value is extracted based at least in part on words in the text associated with the particular keyword and the mapping in the lookup table.

30. The method of claim 1, further comprising: providing a user interface configured to display values ​​of the one or more characteristics; receiving user input via the user interface to change one or more of the values ​​of the one or more features; simulating a classification of the patient relative to the patient's eligibility for protected PCI based at least in part on the altered one or more values ​​to produce a simulated patient classification; and The simulated patient classification is displayed on the user interface.

31. A computer-implemented system for identifying whether a patient is eligible for protected percutaneous coronary intervention (PCI), the system comprising: at least one hardware computer processor; and at least one non-transitory computer-readable medium encoded with a plurality of instructions that, when processed by the at least one hardware computer processor, perform a method comprising: extracting one or more features from the patient's medical information; classifying the patient with respect to the patient's eligibility for protected PCI based at least in part on the extracted one or more features to produce a patient classification; and An indication of the patient classification is output.

32. At least one non-transitory computer-readable medium encoded with a plurality of instructions that, when processed by the at least one hardware computer processor, perform a method comprising: extracting one or more features from the patient's medical information; classifying the patient with respect to the patient's eligibility for protected PCI based at least in part on the extracted one or more features to produce a patient classification; and An indication of the patient classification is output.

Images