The present invention relates generally to software and information technology systems, and the human-machine interfaces useful thereto.
More specifically, the present invention relates to software solutions in the healthcare field, and in particular the health information technology and healthcare informatics fields. The present invention relates to systems for improving the communication of health-related information, such as clinical data, health risks, health conditions, and actual or potential medical events, to healthcare professionals in order to improve patient outcomes.
The present invention further relates to software for augmenting user interfaces, such as those associated with electronic health records (EHRs), in order to improve the interface experience for medical professionals who use EHRs.
According to government and other sources, preventable medical errors may account for as many as 98,000 hospital deaths each year, most of which may be attributed to faulty processes, systems, and hospital conditions that may lead to mistakes being made. The mandated use of EHRs in hospitals nationwide is one approach hospitals have taken to reduce those mistakes. Even so, it is recognized that current EHRs have not achieved their full potential in reducing mistakes, due to several implementation problems.
EHRs are digital versions of individual patient paper charts. They are used to improve or enhance the quality of patient care, patient safety, healthcare delivery efficiency, and healthcare coordination, as well as reduce communications errors and health disparities. EHRs comprise patient-centered electronic data that is generally updated in real-time. They make information available instantly and securely to authorized users, such as a patient's healthcare providers. While EHRs contain a patient's medical and treatment history, they can also be used to develop and present a broader view of a patient's care. Mandated by law, EHRs are widely used in the U.S. healthcare industry. They are implemented at hospitals, primary care facilities, and clinics.
Companies that provide EHR software solutions include MEDITECH, Cerner, McKesson, Epic Systems, Siemens, CPSI, and General Electric.
In a survey of healthcare information technology professionals working mainly in hospitals (Frost & Sullivan, 2014), problems identified with using existing EHRs include time-consuming data entry tasks and significant difficulties in finding and reviewing data and information in EHRs, both of which result in significant loss of productivity for clinician end-users as well as potential risks to patient safety. Indeed, it is estimate that 10-25 pages of EHR data are generated per patient per nurse shift. In a setting where there are 5-6 nurses working each shift, a nurse arriving for a later shift would have to read 50-300 pages of data at the start of his or her shift simply to know what has happened in the last 12 hours at that facility.
It has been recognized that existing EHR software lacks standardization across systems and organizations that implement them, as most of the software solutions involve different user interfaces and other customized features.
It has further been recognized that EHRs provide opportunities for nurses to integrate data analyses (analytics) into their practices, but the process of recording, retrieving, and analyzing EHR data presents communications difficulties, such as interpreting and drawing conclusions from vast amounts of data, especially when different organizations implemented different software solutions having different interfaces (including widely differing inputs and outputs).
Moreover, existing EHRs software solutions generally lack a natural language query interface. In fact, many EHRs software solutions use interfaces that require nurses to enter information in a specific way, utilizing specific forms and the like, without the flexibility of entering and processing natural language queries.
Existing EHRs often use fixed and inflexible user interfaces (graphical user interfaces), or interfaces that do not take into account the specific manner in which a nurse might access data and information in EHRs. For example, depending on the situation, it may be difficult for nurses to sift through large amounts of heterogeneous data available in EHRs to identify useful information.
In addition to EHRs as a source of patient-centered data, many hospitals rely on verbal shift change reports, which are the recorded spoken words of nurses, prepared at the time of a shift change, concerning one or more patients under those nurses' care. Shift change reports generally summarize data already in a patient's EHR, but may include supplemental patient information that may not have made its way into a particular EHR.
What is needed, therefore, is a clinical event management system for use by nurses and other healthcare practitioners, in which a hardware and software solution augments any one of the existing software solutions with interface tools that enhance communication of data and information from EHRs (and verbal shift change reports, as needed). Such as system would have an interface that allows nurses to write their observations using natural language, which can be interpreted and correlated and understood in relation to “hard data” such as patients' vital measurements contained in EHRs. The interface should function on both desktop or tablet computers, as well as smartphones and dedicated handheld devices. Moreover, the graphical user interface should ease the cognitive burden on nurse users, for example by automatically generating useful graphs to help anticipate, predict, address, assess, remediate, and/or prevent adverse patient events and related outcomes.
Others have sought to address some of these needs. For example, in US2005/0020886, a patient monitoring method using specific rule-based algorithms is identified, in which real-time physiologic data received from patents is input into algorithms and a response is outputted. The reference states that responses may include alarms, possible causes associated with abnormal conditions, and actions for addressing abnormal conditions. The rule-based algorithms may be adjusted by clinicians and subject matter experts as needed, and may include specific variables, such as those for heart rate and blood oxygen content, or multiple sets of rules each with their own variables, such as combinations of variables associated with cardiovascular disease events. Moreover, multiple rule-based algorithms, which may be downloaded from a website, may be applied simultaneously to output either a unique response or multiple responses. The reference further states that the output may be generated on a display or input to a person's medical file.
Unlike the present invention, however, the above and other references do not involve, among other features of the present invention, the combined use of natural language inputs to and queries of a patient's EHR by nursing staff using an augmented user interface, and simultaneous real-time event assessment based on machine-learning and artificial intelligence algorithms used to generate graphics for simplified, rapid, and effective communication of event information to nursing staff.
Clinical events are subtle changes in patient condition that have high risk towards failure to rescue (i.e. patient code) and are manifested by fever, pain, bleeding, changes in respiratory status, changes in output, and level of consciousness. Clinical events may be thought of as findings that ostensibly are unsurprising or lack distinction; however, they may lead to a sentinel event and thus are precursors of death. That is, clinical events are subtle changes that if not taken seriously have potential to spiral to crisis and unexpected death.
The present clinical event management system uses an augmented EHR interface for use with EHR software to enhance nurse decision-making and communications of patient clinical events and other information. The invention is effective at preventing cognitive overload by giving nurses an automated visual representation (such as, for example, in the form of bar charts, line graphs, and other diagrams) of a patient's vital signs, while providing patient event identification and likely clinical outcomes information.
The invention provides a means for nurses to enter their observations into the EHRs via the interface using natural language, and the software will automatically couple nurse observations with the related vital signs using color codes and other visual cues. The invention provides a means for nurses to enter their summaries in a verbal shift change report, and the software will automatically convert the speech into text which can then be added to the EHRs.
The present invention may be used to improve nurse communication about individual patients.
The present invention may be used to improve healthcare efficiency by enhancing communication between medical professionals, and by improving data collection and analysis processes involved in EHRs systems.
The present invention may be used to help nurses and doctors quickly evaluate and understand patients' data through visualization tools and natural language processing capabilities.
The present invention provides an EHRs software interface allowing nurses to enter observations using natural language. Healthcare providers can search the EHRs data and information with natural language inputs. For example, the software may receives a natural language query such as “How many patients have X symptoms?” and can return a response via the software's interface, including providing suitable graphics via the generated graphical user interface as needed.
One aspect of the present invention is its ability to predict a patient's likelihood for experiencing certain clinical events using predictive algorithms, thereby improving healthcare efficiency.
Another aspect of the invention is its ability to streamline and improve the efficiency of nurses who use EHRs to document and predict patient outcomes. The interface of the present invention may help nurses know what they should be looking for, and which clinical outcomes are most likely to occur.
Another aspect of the invention is improving data support for hospitals. Certain legislation (e.g., The American Recovery and Reinvestment Act of 2009) incentivizes hospitals to demonstrate meaningful use of EHRs. By allowing personnel to enter information using natural language (something as simple as “patient has a fever”), nurses can focus more on providing care to patients instead of filling out EHRs using inflexible user interfaces.
The natural language algorithms of the present invention would also be useful in the automation of a wide variety of tasks. For example, the present invention may be adapted so doctors and nurses could run searches of EHRs using natural language commands, such as “Has the patient had a fever since they were admitted?” and “How many patients have shown symptoms consistent with Valley Fever infection this year?” The interface tools of the present invention are also useful in interfacing with non EHRs software used in other industries, including interfacing with electronic batch records (EBRs), which contain data and information concerning different drug batches. Natural language algorithms may be useful in fields like biomedical text mining, in which text mining is used to collate information about proteins or other biological entities. There is possible utility for the invention anywhere that human interaction with computers can be better facilitated by graphical representation of complex data.
The present invention may be implemented at a single facility, such as a single hospital, or across multiple related or unrelated facilities, such as a hospital and community private practice healthcare providers that access the same hospital EHRs of their patients.
With those and other objects, advantages, and features of the invention that may become hereinafter apparent, the nature of the invention may be more clearly understood by reference to the following detailed description of a preferred embodiment of the invention, the appended claims and to the several drawings attached hereto.
Several preferred embodiments of the invention are described for illustrative purposes, it being understood that the invention may be embodied in other forms not specifically described below and/or shown in the drawings.
Turning first to
The hardware 102 features of the present invention include client computers, servers, storage devices, and network components, as better described with reference to
The EHRs that may be useful in connection with the present invention are of the kind well known to persons of ordinary skill in the art, several of which have been previously described and identified.
The software 106 feature of the present invention, described in more detail below, include a software subsystem that interfaces with an existing EHR software application. Some of the software 106 inputs include, for example, user-entered natural language statements or notes, clinical data, lab results, device-generated data, observations, codes, criteria, patient data, insurance information, a taxonomy of words and/or phrases, indications of events, indications of risks, variables, values, and manifestations descriptions, among others.
Some of the software 106 outputs include, for example, patient-focused GUI charts, graphs, information, and reports; visual and audible alarms; event information; potential risks; and potential outcomes, among others.
The software 106 may include necessary authentication tools for authenticating users' access to the system 100. The software 106 may be downloadable from a remote server and installed on an existing computing system at a health care delivery facility. The software 106 may be installed as a web application, as a stand-alone software application, as an “app” application, and/or it may deployed as a software as a service product. As a possible commercial product, the software 106 may be provided with an accompanying end user licensing agreement, other user license requirements, and purchasable or licensable after payment of fees, such as a time-based subscription or user fee.
Turning next to
The one or more networks 202 may be, for example, intranets or extranets at a hospital, and may include wired and wireless components.
The one or more servers 204 may include web servers, data servers, load balancers, communications servers, as well as related storage devices (not shown), such as database storage device. The one or more servers 204 and associated storage devices may store EHRs associated with
The one or more computers 206 may be, for example, a laptop or other computing device, such as those found within a hospital (or other healthcare facility) where nurses and doctors access various software application, and may include a display device 206a with a display 206c, internal storage device 206b, and input device (keyboard) 206d.
The one or more portable devices 208 may include, for example, a tablet computer, smartphone, persona data assistant, and the like.
It is to be understood that the above-described embodiment of the present invention, as well as the invention in all of its forms, may be embodied and implemented in hardware, software, firmware, special purpose computing devices, or a combination thereof.
With regard to the software 106, the present invention may be implemented as a program tangibly embodied on a program storage device. The software 106, as a program or program elements, may be uploaded to, and executed by, a machine comprising any suitable architecture, either centrally executed or executed on distributed devices networked to each other.
Preferably, the particular machine or machines executing the software 106 is/are implemented on a computer having hardware including one or more central processing units, one or more memory devices (such as a random access memory), and one or more input/output interface devices, such as peripheral device interfaces. The computer may also include an operating system and microinstruction code.
The various software-implemented processes and functions of the invention as described herein may either be part of the aforementioned microinstruction code or part of the software 106 program (or a combination thereof) which is executed via the operating system running on the computer.
In addition to the specific peripheral devices described above, the invention may encompass various other peripheral devices that are connected or networked to the computer. These include additional integral or external data storage devices, printing devices, and various sensors, including biological/physiological, environmental, and/or other sensors (and their associated hardware and software).
Also, because some of the constituent system components and associated or different methods for their use, as depicted in the accompanying figures, are preferably implemented in software, the actual connections between the components (or the method/process steps) may differ depending upon the manner in which the present invention is programmed.
Turning now to
In step 302, the EHRs records 104 are updated in real-time or near real-time with data and information inputted from various sources as shown in, for example,
In step 304, the software 106 reads all EHRs 104 according to rules 108 defining, among other things, the frequency and scope of reviews, and may index the information identified to facilitate identifying changes in the EHRs 104 from previous reviews.
The purpose of the reviews is to look for specific words, phrases, sentences, paragraphs, and other text, according to initial or pre-determined rules 108 developed in the course of “training” the software 106 following machine learning principles well known in the art. The aforementioned rules, variables, values, manifestations, etc. 108 may further be developed from, for example, a taxonomic or ontological list based on words regularly used by nurses, or found in or associated with vital signs, used in EHR and other records. The software 106 may look for specific words or phrases or combinations of words/phrases in particular portions of EHRs 104, a frequency of words/phrases in a particular location in a particular EHR 104, a proximity of words/phrases relative to the same or other words/phrases, etc. The software 106 “training” may be include decomposing existing knowledge base textual sources relevant to the healthcare field (e.g., science and medical dictionaries, treatises, etc.).
The result of the software 106 training (which is dynamic), is the ability of the software 106 to answer written or anticipated (predicted by the software) queries with the best possible answer or explanation, or several next best answers and explanations. Where necessary, the trained software 106 outputs are confined to, for example, acceptable ranges of values for specific variables, known and acceptable written manifestations for particular conditions or events, or other restrictions used to ensure the software 106 produces outputs that are bounded within acceptable norms. This might be useful, for example, to ensure incorrectly inputted values or misspelled or incorrect terms used in natural language inputs are handled appropriately, or to limit responses to queries prior to sufficient data available to the software 106 to perform statistical and other analyses.
The software 106 algorithms employed in the clinical event computations noted above may rely on sets of variables and associated values or descriptions of manifestations for each of several clinical event management categories. Those categories are described in more detail below, beginning with “fever,” which may be defined using number values and specific descriptive manifestations, and by the interventions shown in Table 1, which are also available to the software 106 as possible rules, variables, values, manifestations, etc. 108.
“Pain” may be defined for use in the software 106 as provided in Table 2, and may be associated with a range from type (e.g., “tenderness”) to a pain score to more severe, changes in vital signs, and reduced comfort of the patient.
The clinical event “bleeding” can be used by the software 106 in the form of a range based on observational evidence in dressings and drains to subtle bleeding that is nearly invisible, while internal bleeding, for example, may be observed as bruising increase in diameter of extremity or abdomen that are entered in the EHRs 104. Specific manifestations are shown in Table 3.
“Change in respiratory status” is a clinical event management category concerned with subtle changes in the patient's ability to breathe and exchange oxygen and carbon dioxide. The changes in condition can begin with problems that lead to changes in breathing to signs of difficulty breathing, as reflected in Table 4.
“Change in level of consciousness” (LOC) is a clinical event management category that relies on an assessment of findings rather than hemodynamic changes, as reflected in Table 5.
“Change in output” is a clinical event management category involving several body systems: renal, gastric, and cardiac. Change in output includes not only increase in output but also decrease in output. Change in output can also occur when a high or low output is expected but does not occur, as reflected in Table 6.
As noted previously, the software 106 algorithms may also take into account multiple clinical event categories. It has been found that clinical events may present in two forms, a single clinical event (as listed above), or as multiple clinical events (or also in a cluster of clinical events). A single clinical event is one where the patient experiences any one of the clinical events identified above. Multiple or cluster clinical events may be evidence of an increase in severity and threat to the patient's safety. Evidence of a clinical event may also reflect another clinical event.
In the case of a single clinical event category, when evidence of one of the clinical events is apparent without evidence of a second clinical event, the software 106 may determine that a single clinical event category is appropriate for assessing potential events and managing the clinical event. For example, the patient will exhibit only fever, pain, bleeding, changes in respiratory status, level of consciousness, or output (Tables 1-6).
In the case of multiple or cluster clinical events, the evidence of more than one clinical event, for example, fever and pain, may be exhibited. For example, the patient may have a recorded fever and also states they are experiencing pain or has a recorded pain scale value. Additional examples of multiple clinical event categories that the present software 106 may assess are provided in Table 7, which is for illustrative purposes and is not an exhaustive list of manifestations of multiple or cluster clinical events.
The software 106 algorithms may also take into account overlapping clinical event categories in the cases where the clinical event categories may share common, similar, of indistinguishable manifestations, such as those highlighted with asterisks in Table 8, which is for illustrative purposes and is not an exhaustive list of overlapping values or manifestations.
Turning back to
In step 310, the software 106 displays a summary graphical user interface, which includes customized and clickable data and information, as shown in, for example,
In step 312, the software 106 receives a click input from the graphical user interface displayed in step 310.
In step 314, the software 106 displays a new graphical user interface populated with additional clickable data and information. This is a “drilling down” process in which more detailed information is presented in case the user wishes to have more data and information than is presented in the summary graphical user interface of step 310.
Turning now to
Turning now to
The time-series risk indicia overview chart 404 also provides navigation capabilities by permitting a user to click or highlight a portion of the chart 504; and when clicked, a specific section of the chart data may be viewed. For example, the user may wish to view a few consecutive hours of risk fluctuations. Once the highlighted portion of the chart 504 is selected, the data will zoom in and focus only on those risk details, as described below.
The time-series risk indicia focus chart 406 displays the selected portion 504 in the time-series risk indicia overview chart 404. Each risk indicia 502 (e.g., dumbbell) can reflect a combined assessment of the six clinical event categories: fever, pain, bleeding, changes in respiratory status, changes in output, and level of consciousness. The combined risks are computed, as described herein, by the software 106 using the various system inputs and system information 108 as depicted in
The clinical event category-specific risk indicia chart 408 is displayed at the top of the screen because it provides the most comprehensive overview and details of risk of a patient that a nurse or other practitioner needs to see on a real-time basis. If a user clicks on one of the depicted clinical event management categories, such as “output,” then the panel on the right with the patient assessment chart 410 (as shown if
Turning now to
Turning now to
In the top row of displayed information of the chart 702, a risk line 708 is displayed (in this case, a broken line), above which is considered a “high risk” condition or state, and below which is considered a “low risk” condition or state. Additional or different textual labels or icons could be used to indicate the relative risk associated with being above or below the risk line 708, and more than one risk line could be displayed between the rows of information. For example, “low,” “medium,” and “high” risk lines could be displayed instead of a single line, and those lines may be solid and a different color than that shown in the chart 702.
In the second row of information (below the top row) of the chart 702, six columns are provided across the width of the display thereby forming six cells for displaying information. As shown in
As discussed previously, the software 106 may be provided with initial pre-determined criteria (e.g., a single default value, an average value, a range of values, etc.) (not shown) in which to compare actual clinical data and observations. The criteria are input into the system as described herein. Based on the comparison, the software 106 then selects an appropriate color and size for the graphic bars 706a through 706f. For example, the software 106 may use initial pre-determined body temperature criteria that are used to compare to actual patient body temperature values, input by, for example, a nurse, into the patient's EHR 104 at an emergency room. The comparison may indicate that the patient has a temperature condition that is 50% of a “high risk” condition. A green-colored bar with a height approximately one-half the distance to the “high risk” line on the chart 702 is caused to be displayed in the appropriate cell of the second row of information.
In the third row of the displayed chart 702, six columns are provided across the width of the display thereby forming six cells for displaying information. As shown in
In the fourth (bottom) row of the chart 702, six columns are provided across the width of the display thereby forming six cells for displaying information corresponding to the six cells in the second and third rows described above. As shown in
Turning to
As shown in
Turning now to
By way of example, if the user clicks on the “Obliterative bronchiolitis (12%)” (804a) link in
Below that health event title is a list 906 containing each of the conditions or the state of the patient identified by the software 106 as contributing to the 99% risk value, i.e. “abdominal pain,” “elevated temperature,” and “elevated respiration.”
To give the user additional insight into the data used by the software 106 in selecting the “Obliterative bronchiolitis” health event and the “99%” calculated the risk value, a table 908 is provided on the graphical user interface 902 with actual data inputted into the patient's EHR by nurses or automatically by connected sensors (i.e., sensors connected to the EHR). The rows of data are shown associated with different physiological parameters that are being monitored, along with a timeline 904 when the data were obtained. For example, during the 5:00-5:10 am time period, the patient had a respiration value of “22” and an abdominal pain value of “5/10,” both of which are indicated as being elevated (by the software 106 comparing the entered values to pre-determined criteria).
Below the table 908 on the graphical user interface 902 are displayed textual remarks 910, which may be entered by a nurse or other healthcare practitioner in the patient's EHR. For example, during the time period 12:00-12:10 am, the textual remark “Patient is experiencing abdominal pain” was entered, and is thus displayed. The software 106 evaluates textual remarks to identify the presence of health event-related terms (e.g., “abdominal pain”). A pre-determined list of such terms (and obvious variations of the terms) is provided to the software 106.
In the graphical user interface 1002 example shown, detailed textual remarks 1004 are displayed below a particular time entry (here, 12:00 am). The textual remarks 1004 may be a compilation of previously entered remarks made by nurses during the most recent shift (thus, the complication of remarks 1004 may be those made by nursing staff after all or a portion of the most recent shift ending at 12:00 am).
Once clicked, the software 106 causes the browser to display, for example, the list 906 containing each of the conditions or the state of the patient identified by the software 106 as contributing to the 92% risk value for “Cerebral hypoperfusion.” Here, the list 906 identifies (generically) “symptom 3,” “symptom 4,” etc., for illustrative purposes.
The software 106 also causes the browser to display, for example, the table 908 with actual data inputted into the patient's EHR by nurses or automatically by connected sensors (i.e., sensors connected to the EHR). The rows of data are shown associated with different physiological parameters that are being monitored, along with a timeline 904 when the data were obtained. For example, during the 2:01-2:10 am time period, the patient exhibited below normal (or expected) blood pressure (“BP”) and temperature (“Temp”) values (as determined by the software 106 by comparing the entered values to pre-determined criteria for the “Cerebral hypoperfusion” health event).
The graphical user interface 1002 is also used to display the textual remarks 910 entered by a nurse or other healthcare practitioner in the patient's EHR. The software 106 evaluates textual remarks to identify the presence of health event-related terms 1104. A pre-determined list of such terms (and obvious variations of the terms) is provided to the software 106 for the “Cerebral hypoperfusion” health event.
By way of a further brief example of the use of the present invention, and with reference to the event “change in output” event shown in
A nurse or other user may then click on the red “output” bar 704, which causes additional details to be displayed on the same or a different graphical user interface page. That page may itself have links to even greater detailed information, all of which is helpful to the nurse/user understand why the software 106 indicates the patients' “output” places the patient in a “high risk” clinical event condition.
As noted above, the software 106 identifies statistical data reflecting average, median, and range values for various monitored physiological parameters on a per-patient or patient population basis, including values for typical symptoms monitored by nursing staff (e.g., temperature, blood pressure, etc.). The software 106 is initially provided with default values, but as more patient data is received, the system updates the statistical average, median, and range values so that it can identify what is “normal” or “abnormal” patient physiology, make appropriate decisions about the likely event that is or will be occurring, and provide more accurate responses to user-entered natural language queries.
Those skilled in the relevant art will appreciate that terms and phrases used herein to describe aspects, advantages, objects, and features of the invention are not to be construed as necessarily definitional or implying a specific definition. In general, the terms and phrases used to describe and claim the present invention should not be construed to limit the invention to any particular disclosed embodiment. Instead, the invention encompasses specific described embodiments, as well as equivalent aspects, advantages, objects, features, and ways of practicing or implementing the present invention.
Although certain presently preferred embodiments of the disclosed invention have been specifically described herein, it will be apparent to those skilled in the art to which the invention pertains that variations and modifications of the various embodiments shown and described herein may be made without departing from the spirit and scope of the invention. Accordingly, it is intended that the invention be limited only to the extent required by the appended claims and the applicable rules of law.
This application is related to and claims the benefit of the filing date of U.S. Provisional Application No. 62/365,834, entitled “Clinical Event Management and Communications System,” filed on Jul. 22, 2016, the disclosure and contents of which are incorporated by reference herein in their entirety.
This work was made with government under Grant No. R01 EB020395, awarded by NIH. The government has certain rights in the invention.
Number | Date | Country | |
---|---|---|---|
62365834 | Jul 2016 | US |