Patent Application
20230317222
Aspects of the present disclosure relate to artificial intelligence and healthcare, and more specifically, to predicting electronic health record data using machine learning (ML).
As part of patient care, patient caregivers (e.g., people tasked with providing in-home and clinical healthcare to patients) frequently update a patient's electronic health record. For example, caregivers record patient symptoms, patient diagnoses, patient rehabilitation progress, and numerous other data points. Some data is entered in a structured manner, through checkboxes, drop-downs, and other structured user interface (UI) elements. But other data is entered as free text by the caregiver.
Textual data added by a caregiver to a patient's electronic health record is vitally important, but can be prone to mistakes, and is challenging to analyze and reconcile with the rest of the patient's health record. For example, caregivers with limited time may make mistakes in entering data. Caregivers may enter incorrect information, make typographical errors, or incorrectly enter data for the wrong patient. As another example, caregivers may enter data that reflects a change in the patient's health status or treatment status, but may not update corresponding separate aspects of the patient's health record necessary to implement the changes. Both of these can result in significant drawbacks, including detriments to patient care and inaccurate or inefficient electronic recordkeeping. What is needed are improved techniques to accurately, and computationally efficiently, maintain and update electronic health records.
Embodiments include a method. The method includes determining a plurality of attributes of a textual description of a patient medical examination, including detecting the plurality of attributes based on analyzing the textual description using a first machine learning (ML) model trained to parse patient textual descriptions. The method further includes predicting a change to an electronic health record for the patient, including: providing to a second ML model the plurality of attributes of the textual description and patient medical data for the patient, where the second ML model is trained to predict changes to patient electronic health records based on attributes of textual data relating to the patient and patient medical data. The predicted change is provided to an electronic system to change the electronic health record and affect medical treatment for the patient.
Embodiments further include an apparatus, including a memory, and a hardware processor communicatively coupled to the memory, the hardware processor configured to perform operations. The operations include determining a plurality of attributes of a textual description of a patient medical examination, including: detecting the plurality of attributes based on analyzing the textual description using a first ML model trained to parse patient textual descriptions. The operations further include predicting a change to an electronic health record for the patient, including: providing to a second ML model the plurality of attributes of the textual description and patient medical data for the patient, where the second ML model is trained to predict changes to patient electronic health records based on attributes of textual data relating to the patient and patient medical data. The predicted change is provided to an electronic system to change the electronic health record and affect medical treatment for the patient.
Embodiments further include a non-transitory computer-readable medium including instructions that, when executed by a processor, cause the processor to perform operations. The operations include determining a plurality of attributes of a textual description of a patient medical examination, including: detecting the plurality of attributes based on analyzing the textual description using a first ML model trained to parse patient textual descriptions. The operations further include predicting a change to an electronic health record for the patient, including: providing to a second ML model the plurality of attributes of the textual description and patient medical data for the patient, where the second ML model is trained to predict changes to patient electronic health records based on attributes of textual data relating to the patient and patient medical data. The predicted change is provided to an electronic system to change the electronic health record and affect medical treatment for the patient.
The following description and the related drawings set forth in detail certain illustrative features of one or more embodiments.
The appended figures depict certain aspects of the one or more embodiments and are therefore not to be considered limiting of the scope of this disclosure.
To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the drawings. It is contemplated that elements and features of one embodiment may be beneficially incorporated in other embodiments without further recitation.
Aspects of the present disclosure provide apparatuses, methods, processing systems, and computer-readable mediums for improved prediction of electronic health record changes. As discussed above, maintaining accurate, and consistent, electronic health records is a challenging, and important, problem. Inaccurate health records can be highly detrimental to patient treatment. Further, it can be extremely difficult to maintain accurate records in electronic health recordkeeping systems.
In aspects described herein, changes to electronic health records stemming from textual data relating to the patient (e.g., patient progress notes entered by a caregiver) can be predicted automatically, using a trained ML model. For example, an ML model can be trained to use natural language processing (NLP) to parse textual patient data and identify attributes of the data. The parsed attributes can then be provided to one or more additional ML models, which can use the attributes and other patient medical data to predict changes to electronic health records. This can include predicting changes to the initial textual data (e.g., the patient progress notes) or to other patient health records (e.g., patient care plans or diagnoses). As used herein changes to electronic health records can refer to revisions to existing electronic health records, additions to electronic health records, removal of electronic health records, and any other suitable changes.
Aspects described herein provide significant advantages over conventional systems. For example, predicting changes to patient textual data (e.g., patient progress notes) and other aspects of a patient's electronic health record records (e.g., patient care plans or diagnoses), significantly improves patient treatment outcomes. Errors in progress notes, or progress notes assigned to the wrong patient, can lead to incorrect treatments for a patient. Further, changes reflected in progress notes, but not propagated to care plans or diagnoses, can lead to outdated and incorrect treatment for a patient. Predicting changes to patient textual data (e.g., patient progress notes) and other aspects of the patient's electronic health records can ensure that patients have accurate, and up to date, care at all times.
Using a trained ML model to perform these predictions also provides a significant technical advantage. For example, in an embodiment some aspects of record inconsistencies could potentially be analyzed using a specific rubric or algorithm with pre-defined rules. But this may be computationally expensive, because a very large number of rules would be needed and parsing and following the rules is computationally expensive. Further, using pre-defined rules would require this computationally expensive analysis be done at the time of the prediction, when a rapid response is likely to be needed (e.g., so that patient records can be kept up to date). Predicting changes to electronic health records automatically using a trained ML model, by contrast, is significantly less computationally expensive at the time the prediction generated. For example, the ML model can be trained during an offline training phase, when rapid response is not necessary and computational resources are readily available. The trained ML model can then be used to rapidly, and computationally cheaply, during an online inference phase to perform the prediction(s).
As another example, automatically predicting changes to electronic health records stemming from textual data relating to the patient (e.g., patient progress notes entered by a caregiver) using a trained ML model provides for a more accurate and well-defined result. In an embodiment, a care provider could manually review the textual data and the patient's electronic health record. But this leaves the risk of human error, and a lack of certainty in the accuracy of the review. Predicting changes to electronic health records using a trained ML model can both lessen the risk of human error, and provide more certainty in the level of accuracy of the prediction. Further, the prediction can itself be reviewed and refined by a care provider. This provides a starting point for the care provider with a more certain level of accuracy, and reduces the burden on the care provider to generate the prediction themselves. This is especially true because the care provider will almost certainly not have access or knowledge of all of the historical data, described further below, that can be considered at instant using one or more of the ML techniques described below.
As another example, one or more techniques described below provide an improvement to electronic health record systems. As noted above, maintaining accurate electronic health records is difficult. For example, manual review of changes to electronic health records tends to result in inaccurate records, because of the burden and difficulty of manual review. These inaccurate electronic health records can require repeated review and analysis (e.g., by caregivers or other employees of care providers). This can be computationally expensive and time-consuming. One or more techniques described herein improve this, by predicting changes to electronic health records stemming from textual data relating to the patient (e.g., patient progress notes entered by a caregiver), using a trained ML model. As described below, in an embodiment the predicted changes can be automatically provided to an electronic health record system (e.g., for a care provider or healthcare facility) and used to maintain the accuracy of the records and reduce the need for repeated review and analysis.
In an embodiment, the captured patient progress notes 102 are provided to the parsing layer 110 using a suitable communication network. For example, the patient progress notes 102 can be captured from a caregiver through a suitable user interface (e.g., a keyboard, keypad, touch sensitive interface, voice interface, or any other suitable user interface) using a suitable computing device (e.g., a smartphone, tablet, wearable device, laptop computer, desktop computer, special purpose computing device, or any other suitable comping device). The computing device can use any suitable communication network, including the Internet, a wide area network, a local area network, or a cellular network, and can use any suitable wired or wireless communication technique (e.g., WiFi or cellular communication). This is merely one example, and the captured patient progress notes 102 can be captured by a computing device and provided to the parsing layer 110 using any suitable technique (e.g., using storage medium or through a wired or wireless transmission from the camera to the computing device).
The parsing layer 110 includes a note parsing service 112, which includes a note parsing ML model 114. In an embodiment, the note parsing service 112 facilitates parsing of incoming patient data (e.g., the patient progress notes 102). As one example, the note parsing service 112 can facilitate NLP parsing of the patient progress notes 102. In this example, the note parsing ML model 114 can be a suitable NLP ML model (e.g., a deep neural network (DNN), transformer model, support vector machine (SVM), Bayesian network, maximum entropy model, conditional random field model, or any other suitable ML model).
In an embodiment, the note parsing ML model 114 can be trained to receive the patient progress notes 102, and to parse the patient progress notes 102 to identify key components of the patient progress notes. These can include patient characteristics (e.g., demographics, medications, assessments), patient medical history (e.g., past patient diagnoses and treatments), current patient diagnoses, and current patient treatments. For example, the note parsing service 112 can use the note parsing ML model 114 to categorize and classify the patient progress notes 102, tokenize the patient progress notes 102 (e.g., divide the patient progress notes text into smaller token unites), identify parts of speech in the patient progress notes 102, identify named entities in the patient progress notes 102 (e.g., patient and caregiver names, names of diagnoses, names of medications and other treatments, and other suitable named entities), identify sentiment in the patient progress notes 102, and perform any other suitable parsing of the patient progress notes. This is discussed further below with regard to
In an embodiment, the patient progress notes 102 is merely one example of patient data that can be analyzed using the parsing layer 110 (e.g., using the note parsing service 112 and the note parsing ML model 114). For example, other text data 104 can be provided to the parsing layer 110. In an embodiment, the other text data 104 includes other textual data captured as part of a patient's electronic health record. For example, the other text data 104 can include text data received from other interactions with a caregiver (e.g., other free form text data received from unstructured UI), scanned copies of paper documents (e.g., paper charts or notes scanned and processed using optical character recognition (OCR)), and any other suitable text data.
In an embodiment, the note parsing service 112 can further facilitate analysis of the other text data 104. For example, the note parsing service 112 can use a note parsing ML model 114 to parse the other text data 104. Further, in an embodiment, the note parsing ML model 114 can include multiple ML models trained to parse textual data. For example, one ML model could be trained to use NLP to parse the patient progress notes 102, another ML model could be trained to parse the other text data 104 (or different ML models could be used for various other text data 104). This is merely an example, and the note parsing ML model 114 could instead be trained to use data from multiple sources (e.g., the patient progress notes 102 and other text data 104), together, to parse the text data.
In an embodiment, the parsing layer 110 provides parsed text data to a prediction layer 120. For example, the note parsing service 112 can use the note parsing ML model 114 to parse the patient progress notes 102, the other text data 104, or both. The parsing layer 110 can provide these parsed characteristics to the prediction layer 120.
The prediction layer 120 includes an EHR data prediction service 122 and an EHR data prediction ML model 124. In an embodiment, the EHR data prediction service 122 facilitates prediction of electronic health record data for the patient (e.g., using the parsed text data received from the parsing layer 110 and patient medical data 130). For example, the EHR data prediction service 122 can use the EHR data prediction ML model 124 to determine an EHR data prediction 150. In an embodiment, the EHR data prediction 150 identifies predicted progress note changes (e.g., predicted changes to the patient progress notes 102), predicted changes to other systems (e.g., predicted changes to the patient medical data 130), or both. This is discussed further below with regard to
As discussed below with regard to
As discussed above, the prediction layer 120 uses the parsed characteristics of the patient text data (e.g., the output from the parsing layer 110) to predict the patient electronic health record data. In an embodiment, however, the parsed characteristics of the patient text data detected by the parsing layer 110 are not sufficient to allow the prediction layer 120 to accurately predict the patient electronic health record data. For example, merely parsing the patient progress notes 102, themselves, may not be sufficient to identify predicted EHR data.
In an embodiment, the prediction layer 120 can further receive patient medical data 130 and historical progress notes data 140. For example, the patient medical data 130 can include patient characteristics 132 and patient medical history 134. In an embodiment, the patient characteristics 132 can include patient demographics (e.g., age, height, weight), patient medications (e.g., a listing of medications for the patient), patient assessment data (e.g., intake assessment data, discharge assessment data, activities of daily living (ADL) assessment data), or any other suitable patient characteristics. This is discussed further below with regard to
In an embodiment, the historical progress notes data 140 can include data about matched progress notes 142, for various patients and various caregivers. For example, the historical progress notes data 140 can include parsed note attributes (e.g., parsed from free text progress notes or other text data) and patient medical data, matched with identified note changes and other changes. The matched progress notes 142 can include historical note changes (e.g., changes to progress notes) and historical changes to other systems (e.g., changes to other patient medical data), and any other suitable historical progress notes data. In an embodiment, the patient medical data 130 provides data about the particular patient being examined, while the historical progress notes data 140 provides data about historical progress notes and matching changes. Further, in an embodiment, the historical progress notes data 140 has had any personally identifying patient information removed.
In an embodiment, the patient medical data 130 and the historical progress notes data 140 are provided to the prediction layer 120 using a suitable communication network. For example, the patient medical data 130 and the historical progress notes 140 can be stored in one or more suitable electronic databases (e.g., a relational database, a graph database, or any other suitable database) or other electronic repositories (e.g., a cloud storage location, an on-premises network storage location, or any other suitable electronic repository). The patient medical data 130 and the historical progress notes data 140 can be provided from the respective electronic repositories to the prediction layer 120 using any suitable communication network, including the Internet, a wide area network, a local area network, or a cellular network, and can use any suitable wired or wireless communication technique (e.g., WiFi or cellular communication).
As discussed above, in an embodiment, the EHR data prediction service 122 uses the EHR data prediction ML model 124 to predict changes to progress notes, and other patient systems. For example, the EHR data prediction ML model 124 can be a suitable supervised ML model (e.g., a DNN or a transformer model) trained to generate an EHR data prediction 150 (e.g., a prediction of changes to progress notes or other patient systems) for the patient from a combination of parsed characteristics of text data (e.g., output from the parsing layer 110), patient medical data 130 and historical progress notes data 140. This is discussed further below with regard to
For example, the EHR data prediction ML model 124 can predict changes to the patient progress notes 102 (e.g., corrections to likely errors or inconsistencies in the progress notes 102). This is one example of an EHR data prediction 150. As another example, the EHR data prediction ML model 124 can predict changes to other patient systems (e.g., changes to the patient medical data 130). This is another example of an EHR data prediction 150.
In an embodiment, the EHR data prediction 150 can be provided to an EHR system 160 (e.g., an EHR system for a medical facility or care provider. Further, in an embodiment, the EHR data prediction 150 can be provided directly to the patient's medical care provider. This is discussed further below with regard to
In an embodiment, the EHR data prediction 150 is used to identify EHR changes that can be used by care providers to treat the patient. For example, the EHR data prediction 150 can be a prediction of changes to patient progress notes 102. These changes can improve the accuracy of the patient progress notes 102, improving the accuracy of treatment for the patient by a caregiver and improving treatment outcomes. As another example, the EHR data prediction 150 can be a prediction of changes to a patient's medical diagnosis or care plan (e.g., included in patient medical data 130). The EHR data prediction 150 can reflect a new or changed diagnosis for the patient identified from the patient progress notes 102, a new or changed treatment for the patient identified from the patient progress notes 102, or any other suitable change. This can be used to improve diagnosis and treatment for the patient, and improve patient outcomes. In either instance care providers can use the EHR data prediction 150 to treat the patient.
In an embodiment, ongoing progress note data 170 can be gathered and provided to the parsing layer 110, the prediction layer 120, or both. For example, the ongoing progress note data 170 can include additional progress notes (or other text data) for the patient, and can be gathered and maintained in suitable repository (e.g., an electronic database for the EHR system 160). This data can be used for ongoing training of the note parsing ML model or the EHR data prediction ML model (e.g., depending on the data). This data, and all training data, can be stripped of any personally identifying patient information.
In an embodiment, this ongoing progress note data 170 can be used to refine the EHR data prediction 150. For example, additional patient progress notes can be provided to the parsing layer 110 and analyzed in the same way as the patient progress notes 102 and the other text data 104 (e.g., to identify additional changes to patient medical data 130). The ongoing progress note data 170 can reflect actual changes to progress notes (e.g., made by caregivers) or additional related progress notes (e.g., stemming from a similar medical examination to the patient progress notes 102). The ongoing progress note data 170 can be assumed to be accurate, and used to refine the EHR data prediction ML model 124.
The network components 220 include the components necessary for the controller 200 to interface with a suitable communication network (e.g., a communication network interconnecting various components of the computing environment 100 illustrated in
The memory 210 generally includes program code for performing various functions related to use of the prediction controller 200. The program code is generally described as various functional “applications” or “modules” within the memory 210, although alternate implementations may have different functions and/or combinations of functions. Within the memory 210, the note parsing service 112 facilitates parsing incoming patient text data (e.g., NLP parsing of the patient progress notes and other patient text data), using the note parsing ML model 114. This is discussed further below with regard to
While the controller 200 is illustrated as a single entity, in an embodiment, the various components can be implemented using any suitable combination of physical compute systems, cloud compute nodes and storage locations, or any other suitable implementation. For example, the controller 200 could be implemented using a server or cluster of servers. As another example, the controller 200 can be implemented using a combination of compute nodes and storage locations in a suitable cloud environment. For example, one or more of the components of the controller 200 can be implemented using a public cloud, a private cloud, a hybrid cloud, or any other suitable implementation.
Although
At block 304, the note parsing service parses the text data using NLP (e.g., using the note parsing ML model 114 illustrated in
At block 306, a prediction service (e.g., the EHR data prediction service 122 illustrated in
In an embodiment, the prediction service can further receive the historical progress notes data 140 illustrated in
At block 308, the prediction service generates an EHR data prediction (e.g., the EHR data prediction 150 illustrated in
In an embodiment, the EHR data prediction includes changes to the textual data. This can include identifying mistakes in the textual data (e.g., errors from input by the caregiver), identifying mis-matched patients and textual data (e.g., stemming from a caregiver selecting the wrong patient), and identifying any other suitable changes. For example, a wrong patient could be identified based on multiple inconsistencies between the textual data and other patient medical data. If the number of inconsistencies exceeds a threshold value, the EHR data prediction could indicate a likely wrong patient. In an embodiment the threshold can be pre-determined, or could be identified dynamically (e.g., using the prediction service).
In an embodiment, the EHR data prediction further includes other changes (e.g., changes to other patient data). This can include identifying other aspects of the patient's electronic health record (e.g., demographic data, diagnoses, medications, other treatments and care plans, or any other suitable data), and identifying changes or additions to those portions of the patient's electronic health record. In an embodiment the EHR data prediction both identifies the text to be changed, and the corresponding proposed change(s). This is merely an example, and the EHR data prediction can identify only the text to be changed or only the proposed changes.
In an embodiment the EHR data prediction ML model uses the parsed textual data, the patient medical data, and the historical progress notes data to generate the EHR data prediction. But this is merely an example. Alternatively, or in addition, the EHR data prediction ML model can use any subset of this data (e.g., where some of this data is unavailable for a given patient). For example, the EHR data prediction ML model can use the parsed textual data and patient medical data, without historical progress notes data. In an embodiment this may result in a slight loss of accuracy in the EHR data prediction, but the EHR data prediction is still significantly improved over prior techniques (e.g., manual prediction).
In an embodiment, the prediction service can further identify a prophylactic treatment task for the patient (e.g., a treatment task intended to quickly prevent further disease or issues for the patient). For example, the prediction service can use the parsed textual data, the patient medical data, including but not limited to specific health related data associated with one or more patients, such as age, weight, medical conditions, demographics, or other such data, or both to identify a high priority treatment task needed based on the textual data. This could be done, for example, using an additional ML model trained to use the same (or similar) inputs to the EHR data prediction model to generate a different output: a high priority treatment task, instead of an EHR data prediction. As one example, a patient progress note could identify an urgent change in medication not otherwise reflected in the patient's electronic health record. The prediction service can transmit an alert (e.g., an e-mail, SMS message, telephone call, or another form of electronic message) describing the change in medication to a care provider for the patient (e.g., to another care provider other than the care provider entering the progress notes) or to the patient themselves. The care provider or patient can then immediately implement the urgent change in medication.
As another example, a patient progress note could identify symptoms of a medical condition potentially requiring immediate medical attention (e.g., a cardiac issue). If the caregiver entering the progress note fails to provide an immediate treatment or examination, the prediction service can transmit an alert describing the potential illness to a care provider for the patient or to the patient themselves. The care provider or patient can then immediately take action to respond to the medical condition (e.g., examining the patient or seeking urgent medical care). In an embodiment, the prediction service can identify this treatment task prior to completing the EHR data prediction. For example, the prediction service can identify a high priority treatment task while generating the EHR data prediction, and can transmit the alert prior to completing EHR data prediction. In an embodiment this allows for a rapid alert for the treatment task, without waiting for complete the EHR data prediction.
At block 310, the prediction service transmits the EHR data prediction to electronic patient systems. For example, the prediction service can transmit predicted changes to the progress notes to an electronic repository (e.g., an electronic database) that maintains the progress notes. The predicted changes to the progress notes can be used to change the progress notes. As another example, the prediction service can transmit predicted other changes to an electronic system that maintains the patient's electronic health record (e.g., a care provider system). The predicted other changes can be used to change the patient's electronic health record. This is discussed further, below, with regard to
In an embodiment, the note parsing service 112 uses the note parsing ML model 114 to parse the progress notes 102 and generate one or more parsed progress notes 410. For example, the note parsing ML model can use NLP techniques, described further below, to parse text in the progress notes 102 (e.g., unstructured text) and generate one or more parsed progress note data elements (e.g., a parsed progress note 802 as illustrated in
Examples may be instructive. A progress note could include the text: “RT reminded pt to watch for signs of chest tightness, chest pain, increased work of breathing & increased heart rate.” This could have been entered by a caregiver to express that a respiratory therapist (RT) reminded a patient (PT) to watch for signs of chest tightness, chest pain, increased work of breathing, and increased heartrate. The note parsing service 112 could use the note parsing ML model 114 to parse this text, and generate a parsed progress note with symptom attributes reflecting observation for chest tightness, chest pain, increased work of breathing, and increased heartrate. The parsed progress note could be, for example, a parsed progress note data element (e.g., the parsed progress note 802 illustrated below with regard to
As another example, a progress note could include the text “No cough noted and pt reports sometimes coughs at night time, non-productive. Continues to keep head elevated at all times to aid in breathing.” The note parsing service 112 could use the note parsing ML model 114 to parse this text, and generate a parsed progress note with symptom attributes reflecting that the patient sometimes coughs at night, non-productive, and with treatment attributes reflecting that the patient continues to keep their head elevated at all times to aid in breathing. The parsed progress note could be, for example, a parsed progress note data element (e.g., the parsed progress note 802 illustrated below with regard to
As a final example, a progress note could include the text “Pt has made an overall improvement with respiratory status since admission, speaks in full complete sentences without noticeable dyspnea.” The note parsing service 112 could use the note parsing ML model 114 to parse this text, and generate a parsed progress note with a diagnosis attribute reflecting that the patient has made an overall improvement with respiratory status since admission. The parsed progress note could be, for example, a parsed progress note data element (e.g., the parsed progress note 802 illustrated below with regard to
In an embodiment, the note parsing ML model 114 can be any suitable ML model used for NLP. In an embodiment, the note parsing ML model 114 can identify any, or all, of semantic, syntax, and context information, can implement tokenization, part of speech tagging, named entity recognition, and any other suitable NLP technique, and can be used to categorize and classify the input text (e.g., the progress notes 102) to generate the parsed progress notes 410.
Further, in an embodiment the note parsing ML model 114 can be combined with one or more static rules or conditions (e.g., NLP rules or conditions that do not use an ML mode), or additional unsupervised or supervised ML models, to parse the input text. For example, the note parsing ML model 114 can be a suitable supervised ML model, and can work in concert with additional static NLP rules and conditions and one or more unsupervised ML models (e.g., using latent semantic analysis or any other suitable technique). As another example, the note parsing ML model 114 could use an annotated dictionary identifying abbreviations and common terms used in patient text (e.g., progress notes). This dictionary, to be used in concert with the ML model, could be pre-generated, generated during a training phase for the note parsing ML model 114, dynamically generated during inference of the note parsing ML model 114, or any combination thereof.
In an embodiment, the progress notes 102 can be pre-processed before being parsed using the note parsing ML model 114, or as part of being processed by the note parsing ML model. For example, the text can normalized, stemming can be used to reduce words to stem form and lemmatization can be used to derive the root form of words. These are merely examples, and any suitable pre-processing can be used.
Each row further includes a time at which the progress note was recorded (e.g., describing the time in hours, minutes, and seconds, and describing the day in month, day, and year), and a text of a progress note. For example, after a progress note is entered by a caregiver, it can be recorded in a row in the table 500. In an embodiment, the progress note text is parsed (e.g., as described above in relation to
At block 602, a training service (e.g., a human administrator or a software or hardware service) collects historical progress note data. For example, a note parsing service (e.g., the note parsing service 112 illustrated in
At block 606, the training service (or other suitable service) pre-processes the collected historical progress note data. For example, the training service can create feature vectors reflecting the values of various features, for each collected matched progress note. These features can include the parsed progress note attributes illustrated in relation to
In an embodiment, at block 604 the training service also collects additional data (e.g., data reflecting dictionary entries for the progress note data or additional analysis of the progress note data). At block 606, the training service can also pre-process this additional data. For example, the feature vectors corresponding to the historical progress note data can be further annotated using the additional data. Alternatively, or in addition, additional feature vectors corresponding to the additional data can be created. At block 608, the training service uses the pre-processed additional data during training to generate the trained note parsing ML model 114.
In an embodiment, while a variety of suitable data is available for the training service (e.g., the historical progress note data discussed with regard to block 602 and the additional data discussed with regard to block 604), a subset of this data is selected to use for training of the note parsing ML model. That is, as part of model design the training data is selected from an available universe of training data. Further, the note parsing ML model can then use the same, or similar, data types or fields for inference for inference (e.g., as discussed above with regard to
In an embodiment, the pre-processing and training can be done as batch training. In this embodiment, all data is pre-processed at once (e.g., all historical progress note data and additional data), and provided to the training service at block 608. Alternatively, the pre-processing and training can be done in a streaming manner. In this embodiment, the data is streaming, and is continuously pre-processed and provided to the training service. For example, it can be desirable to take a streaming approach for scalability. The set of training data may be very large, so it may be desirable to pre-process the data, and provide it to the training service, in a streaming manner (e.g., to avoid computation and storage limitations). Further, in an embodiment, a federated learning approach could be used in which multiple healthcare entities contribute to training a shared model.
In an embodiment,
In an embodiment, the EHR data prediction service 122 uses multiple types of data to generate the predicted progress note changes 720 and predicted changes to other systems 730, using the EHR data prediction ML model 124. For example, the EHR data prediction service 122 can use one or more parsed progress note attributes 702. In an embodiment, as illustrated above in relation to
In addition, the EHR data prediction service 122 can use patient characteristics 132 (e.g., as discussed above in relation to
Further, the EHR data prediction service 122 can use a patient medical history 134 (e.g., as discussed above in relation to
The EHR data prediction service 122 can further use historical progress note data 140 (e.g., as discussed above in relation to
In an embodiment, the EHR data prediction service 122 uses the historical EHR data prediction data for ongoing training of the EHR data prediction ML model 124. For example, because training the EHR data prediction ML model 124 may be computationally expensive, the EHR data prediction service can train the EHR data prediction ML model 124 at suitable intervals (e.g., hourly, daily, weekly) or based on triggering events (e.g., after a threshold number of new observations are received, upon request from an administrator, or at any other suitable interval). Alternatively, the EHR data prediction service 122 does not receive the historical progress notes data 140. In this example, the historical progress notes data 140 is used to train the EHR data prediction ML model 124 (e.g., as discussed below in relation to
In an embodiment, the predicted progress note changes 720 include a description of predicted changes to a progress note (e.g., the progress note used to generate the parsed progress note attributes 702). For example, the predicted progress note changes 720 can identify possible errors made by the caregiver entering the progress note (e.g., incorrect medications or other treatments, incorrect symptom descriptions, incorrect observational descriptions, incorrect diagnoses, or any other suitable possible error). As one example, a caregiver may include in the progress note text describing the patient's ongoing tolerance of a medication, but may incorrectly identify the medication. The predicted progress note changes 720 can identify the possible error and the likely correct medication (e.g., using the patient characteristics 132 and patient medical history 134 provided as input to the EHR data prediction ML model). As another example, a caregiver may enter progress notes for the wrong patient (e.g., using the patient characteristics 132 and patient medical history 134). The predicted progress note changes 720 can identify the potential patient mismatch, so that the progress note can be moved to the correct patient. In an embodiment, the predicted progress note changes 720 are provided automatically to an electronic patient care system, and are used to automatically change the progress notes.
In an embodiment, the predicted changes to other systems 730 include description of predicted changes to other aspects of the patient's electronic health record. For example, the parsed progress note attributes 702 may reflect a new, or different, symptom, than has been previously identified for the patient. The predicted changes to other systems 730 could identify this symptom as new, and could suggest adding the symptom to another part of the patient's electronic health record (e.g., the patient medical history 134). As another example, the parsed progress note attributes may reflect a new diagnosis, or a resolution of a previous diagnosis. The predicted changes to other systems 730 could identify this new, or resolved, diagnosis, and could suggest changes to the patient's electronic health record to reflect the change. In an embodiment, the predicted changes to other systems are provided automatically to an electronic patient care system, and are used to automatically change the patient's electronic health record.
In an embodiment, each parsed progress notes 802 can include patient attributes 810. The patient attributes 810 can include demographic information for the patient, including one or more of an age 812, a height 814, and a weight 816. These are merely examples, and the parsed progress note 802 can include any suitable patient attributes, or no patient attributes at all (e.g., where a progress note does not describe patient attributes).
In an embodiment, each parsed progress notes 802 can further include symptom attributes 820. The symptom attributes 820 can include attributes of one or more symptoms 822A-N experienced by the patient and described in the progress note. These are merely examples, and the parsed progress note 802 can include any suitable symptom attributes, or no symptom attributes at all (e.g., where a progress note does not describe patient symptoms).
In an embodiment, each parsed progress notes 802 can further include one or more diagnosis attributes 830. The diagnosis attributes 830 can include a diagnosis 832 (e.g., a label or description for the diagnosis), an onset description 834 (e.g., a date of onset or textual description), a treatment 836 (e.g., a treatment history for the diagnosed medical condition), and a resolution 838 (e.g., a date of resolution or a notation that the diagnosed medical condition is ongoing). These are merely examples, and the parsed progress note 802 can include any suitable diagnosis attributes, or no diagnosis attributes at all (e.g., where a progress note does not describe a patient diagnosis).
In an embodiment, each parsed progress notes 802 can further include one or more treatment attributes 840. The treatment attributes 840 can include a medication 842 (e.g., a label or description for the medication), an intervention description 846 (e.g., a textual description of medical procedures or interventions performed as part of treatment), and one or more observations (e.g., descriptions of observations of treatment). In an embodiment, the treatment attributes 840 provide additional detail for a treatment 836 included in a diagnosis attribute 830. Alternatively, or in addition, the treatment attributes 840 are separate from the diagnosis attributes 830. These are merely examples, and the parsed progress note 802 can include any suitable treatment attributes, or no treatment attributes at all (e.g., where a progress note does not describe a patient treatment).
The patient 902 can further include patient medications 920. In an embodiment, the patient medications 920 include one or more medications 922A-N. These are merely examples, and the patient medications 920 can include any suitable data.
Further, the patient 902 can include one or more patient assessments 930 (e.g., a patient assessment 930 corresponding to each healthcare facility to which the patient has been admitted). In an embodiment, the patient assessment 930 includes an intake assessment 932. For example, an intake assessment can be performed for the patient upon intake to a healthcare facility (e.g., performed by a suitable healthcare professional, using a suitable automated assessment system, or both). The intake assessment can be memorialized as the intake assessment 932.
In an embodiment, the patient assessment 930 further includes a discharge assessment 934. For example, a discharge assessment can be performed for the patient upon discharge from a healthcare facility (e.g., performed by a suitable healthcare professional, using a suitable automated assessment system, or both). The discharge assessment can be memorialized as the discharge assessment 934.
The patient assessment 930 can further include an activities of daily living (ADL) assessment 936. For example, the ADL assessment can memorialize the patient's ability to dress, feed, ambulate, toilet, and perform their own hygiene. The ADL assessment can be memorialized as the ADL assessment 936. These are merely examples, and the patient assessment 930 can include any suitable data. Further, the patient demographics 910, patient medications 920, and patient assessment 930 are merely examples. The patient 902 can include any suitable patient data, organized in any suitable fashion.
A patient 1002 includes one or more medical conditions 1010A-N. Each medical condition includes a respective diagnosis 1012A-N, a respective onset description 1014A-N (e.g., a date or textual description), a respective treatment 1016A-N (e.g., a treatment history for the medical condition), and a respective resolution 1018A-N (e.g., a date of resolution or a notation that the medical condition is ongoing). These are merely examples, and each medical condition 1010A-N can include any suitable data. Further, the medical conditions 1010A-N are merely examples, and the patient 1002 can include any suitable medical history data.
In an embodiment, the historical EHR data prediction 1102 further includes note changes 1110. For example, the note changes 1110 can include one more note changes 1112A-N made to a progress note (e.g., the progress note corresponding to the parsed progress note 802). For example, the note changes 1112A-N can describe historical progress note changes made to the progress note based on the parsed progress note 802, patient characteristics 902, and patient medical history 1000. These are merely examples, and the historical EHR data prediction 1102 can include any suitable note changes, or no note changes at all (e.g., where no changes were made to the progress note).
In an embodiment, the historical EHR data prediction 1102 further includes other changes 1120. For example, the other changes 1120 can include one more other changes 1122A-N made to a patient's electronic health record. For example, the other changes 1122A-N can describe historical changes made to the patient's electronic health record based on the parsed progress note 802, patient characteristics 902, and patient medical history 1000. These are merely examples, and the historical EHR data prediction 1102 can include any suitable other changes, or no other changes at all (e.g., where no changes were made to the electronic health record). In an embodiment, as discussed above, an EHR data prediction ML model can include multiple ML models. For example, one ML model can be trained to generate progress note changes (e.g., reflected in the note changes 1110) and another ML model can be trained to generate other changes (e.g., reflected in the other changes 1120).
At block 1206, the training service (or other suitable service) pre-processes the collected historical EHR data prediction data. For example, the training service can create feature vectors reflecting the values of various features, for each historical EHR data prediction. At block 1208, the training service receives the feature vectors and uses them to train the note parsing ML model 114.
In an embodiment, at block 1204 the training service also collects additional data (e.g., data reflecting additional observations or data about the patient). At block 1206, the training service can also pre-process this additional data. For example, the feature vectors corresponding to the historical EHR data prediction data can be further annotated using the additional data. Alternatively, or in addition, additional feature vectors corresponding to the additional data can be created. At block 1208, the training service uses the pre-processed additional data during training to generate the trained EHR data prediction ML model 124.
In an embodiment, as discussed above in relation to
For example, the EHR data prediction service can use parsed progress note attributes, generated using a note parsing service (e.g., the note parsing service 112 illustrated in
In an embodiment, the prediction controller 1310 transmits the predicted note changes 1320, the predicted other changes 1322, or both, over a communication network 1330 to any, or all, of a patient 1340, a care provider 1350, and a healthcare facility 1360. The communication network 1330 can be any suitable communication network.
In an embodiment, any, or all, of the care provider 1350 and the healthcare facility 1360 receive the predicted note changes 1320, the predicted other changes 1322, or both. The predicted note changes 1320, the predicted other changes 1322, or both, can then be used to treat the patient. For example, the predicted changes can be used to ensure that the patient receives the correct treatment, ensure that the patient is correctly monitored for symptoms, and otherwise treat the patient.
In an embodiment, the prediction controller 1310 can interact directly with a care provider 1350 or healthcare facility 1360 to apply the predicted note changes 1320, the predicted other changes 1322, or both. For example, the prediction controller 1310 can interact directly with electronic systems of a care provider 1350 or healthcare facility 1360 (e.g., using a suitable application programming interface (API), web interface, or other electronic interface) to implement predicted changes. This can include updating the patient's electronic health record to reflect the changes, and providing suitable alerts to the patient or caregiver reflecting the changes. In one embodiment, the care provider 1350 or healthcare facility 1360 implements some, or all, of the predicted note changes 1320 and predicted other changes 1322 automatically. Alternatively, or in addition, the care provider 1350 or healthcare facility 1360 provides the predicted changes to a suitable caregiver, for consideration and implementation.
As another example, the patient 1340 can receive predicted other changes 1322 (e.g., a change to the patient's medication or care plan) at a suitable electronic device (e.g., a smartphone, tablet, laptop computer, desktop computer, or any other suitable device). The patient 1340 can use the predicted other changes 1322 to select or improve treatment (e.g., using a mobile application or local application running on the patient device, or accessing the predicted other changes 1322 over the communication network 1330).
In an embodiment, any, or all, of patient 1340, the care provider 1350, and the healthcare facility 1360 store the predicted note changes 1320 and predicted other changes 1322. For example, this can allow the recipient to access the predicted note changes 1320 and predicted other changes 1322 without requiring a continuous network connection.
Further, in an embodiment, the prediction controller 1310 can transmit an alert to the healthcare facility 1360, care provider 1350, or patient 1340. For example, as described above in relation to
The preceding description is provided to enable any person skilled in the art to practice the various embodiments described herein. The examples discussed herein are not limiting of the scope, applicability, or embodiments set forth in the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments. For example, changes may be made in the function and arrangement of elements discussed without departing from the scope of the disclosure. Various examples may omit, substitute, or add various procedures or components as appropriate. For instance, the methods described may be performed in an order different from that described, and various steps may be added, omitted, or combined. Also, features described with respect to some examples may be combined in some other examples. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects set forth herein. In addition, the scope of the disclosure is intended to cover such an apparatus or method that is practiced using other structure, functionality, or structure and functionality in addition to, or other than, the various aspects of the disclosure set forth herein. It should be understood that any aspect of the disclosure disclosed herein may be embodied by one or more elements of a claim.
As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects.
As used herein, a phrase referring to “at least one of” a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiples of the same element (e.g., a-a, a-a-a, a-a-b, a-a-c, a-b-b, a-c-c, b-b, b-b-b, b-b-c, c-c, and c-c-c or any other ordering of a, b, and c).
As used herein, the term “determining” encompasses a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Also, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Also, “determining” may include resolving, selecting, choosing, establishing and the like.
The methods disclosed herein comprise one or more steps or actions for achieving the methods. The method steps and/or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims. Further, the various operations of methods described above may be performed by any suitable means capable of performing the corresponding functions. The means may include various hardware and/or software component(s) and/or module(s), including, but not limited to a circuit, an application specific integrated circuit (ASIC), or processor. Generally, where there are operations illustrated in figures, those operations may have corresponding counterpart means-plus-function components with similar numbering.
The following claims are not intended to be limited to the embodiments shown herein, but are to be accorded the full scope consistent with the language of the claims. Within a claim, reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. No claim element is to be construed under the provisions of 35 U.S.C. § 112(f) unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for.” All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims.
This application claims priority to U.S. Provisional Patent Application No. 63/325,964, filed Mar. 31, 2022, the entire content of which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63325964 | Mar 2022 | US |
