Patent Application
20210201240
As is well known, over the last two decades, the use of electronic health record technology has rapidly increased. Hospitals and other healthcare entities rapidly adopted the emerging electronic health record systems because of the advantages they provide over conventional paper-based systems. Moreover, the U.S. Congress spurred the rapid adoption of electronic health record systems by mandating many healthcare entities to switch from conventional paper-based systems to electronic health record systems.
This adoption, however, did not come without challenges. Early electronic systems came with many of the disadvantages and problems that the paper-based systems faced. For example, paper-based systems resulted in patient information being stored at different healthcare facilities and different departments within large healthcare facilities. Likewise, many early electronic health record systems were stored on different media at different healthcare facilities or different departments within a healthcare facility. As a result, efforts have been made to provide ways for medical personnel to quickly and easily review medical records via electronic health records (EHR). Making further use of such EHRs, visual tools such as clinical dashboards can display data, statistics, and key performance indicators (KPIs) using information pulled from EHRs, as illustrated in the prior art dashboard in
However, documented medical information is often scattered across different data types, and current dashboard solutions generally require users to navigate through different applications, tabs, or sections to get the needed information. Furthermore, dashboards for complicated orders, such as a typical radiology order, can comprise numerous KPIs, making such a dashboard cluttered, confusing, and difficult to utilize quickly and efficiently. For example, as depicted in
This summary is intended to introduce a selection of concepts in a simplified form that are further described below in the detailed description section of this disclosure. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
At a high level, aspects described herein relate to systems and methods for mapping data from electronic medical records (EMR), such as key performance indicators (KPIs) of various tasks, onto a graphical depiction of a workflow for a particular order type, a particular patient, and/or over a particular period of time. This allows tracking of tasks in a workflow in a way that provides context to the data or KPIs. This not only increases efficiency and assists in streamlining the workflow, but also reduces confusion and documentation errors among different departments and healthcare workers, thereby increasing patient safety.
Additional objects, advantages, and novel features of the technology will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following or learned by practice of the technology.
The present technology is described in detail below with reference to the attached drawing figures, wherein:
The drawing figures do not limit the present technology to the specific embodiments disclosed and described herein. The drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the invention.
The subject matter of the present technology is described with specificity herein to meet statutory requirements. However, the description itself is not intended to limit the scope of this disclosure. Rather, the inventors have contemplated that the claimed or disclosed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Moreover, although the terms “step” and/or “block” might be used herein to connote different elements of methods employed, the terms should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly stated.
With regard to the drawings in general, we show certain items in block-diagram form more for being able to reference something consistent with the nature of a patent rather than to imply that a certain component is or is not part of a certain device. Similarly, although some items are depicted in the singular form, plural items are contemplated as well (e.g., what is shown as one data store might really be multiple data stores distributed across multiple locations). But showing every variation of each item might obscure some embodiments. Thus for readability, we show and reference items in the singular (while fully contemplating, where applicable, the plural).
Turning now to
As noted above, each of these components may communicate through the network 110. The network 110 may include, without limitation, one or more local area networks (LANs) and/or wide area networks (WANs). In example implementations, the network 110 comprises the Internet and/or a cellular network, amongst any of a variety of possible public and/or private networks. Other wireless technologies for transferring data, such as Bluetooth, are contemplated as well. Though components of the operating environment 100 are shown communicating through the network 110, other arrangements are contemplated. For example, one or more of the components of the operating environment 100 may be in direct communication via a communication bus.
It will be understood that the operating environment 100 is provided only as an example of one embodiment suitable for practicing the technology. Other arrangements of elements (e.g., components, machines, interfaces, functions, orders, groupings of functions, etc.) can be used in addition to or instead of those shown, while some may be omitted from
The EHR system 102 may include one or more data stores of health records, which may be included in the storage 106, and may further include one or more computers or servers that facilitate the storing and retrieval of the health records. Although the storage 106 is depicted as a single data store component, the storage 106 may be embodied as one or more data stores or may be in the cloud. In some embodiments, the EHR system 102 may be implemented as a cloud-based platform or may be distributed across multiple physical locations and may be the same as or distinct from the storage 106. The EHR system 102 may further include record systems, which store real-time or near real-time patient (or user) information, such as wearable, bedside, or in-home patient monitors, for example, and may store patient EHRs. For example, the EHR system 102 may comprise one or a plurality of EHR systems such as hospital EHR systems, health information exchange EHR systems, ambulatory clinic EHR systems, or other systems having health-related records for one or more patients, and may be implemented in the computing device 108.
Generally, EHRs, sometimes referred to as electronic medical records (EMRs), may comprise electronic clinical documents such as images, clinical notes, orders, summaries, reports, analyses, dictations, transcriptions, information received from clinical applications and medical devices, or other types of electronic medical documentation relevant to a particular patient's condition and/or treatment. Electronic clinical documents may contain various types of information relevant to the condition and/or treatment of a particular patient and can include information relating to, for example, patient identification information, images (e.g., radiology imaging and x-rays), audio or video recordings, alert history, culture results, physical examinations, vital signs, past medical histories, surgical histories, family histories, histories of present illnesses, current and past medications, allergies, symptoms, past orders, completed orders, pending orders, tasks, transcripts, lab results, other test results, patient encounters and/or visits, immunizations, physician comments, nurse comments, other caretaker comments, clinician assignments, and a host of other relevant clinical information. The content and volume of such information in an EHR system are not intended to limit the scope of the present disclosure in any way.
The user interface 104 is also illustrated in the operating environment 100. An embodiment of the user interface 104 takes the form of a user interface operated by a software application or set of applications on a client computing device such as a personal computer, laptop, smartphone, or tablet computing device. In an embodiment, the application is a Web-based application or applet. Embodiments of the user interface 104 may facilitate accessing, receiving, and communicating information from a user or healthcare provider about a specific patient or population of patients, such as patient history; healthcare resource data; variables measurements, time series, and predictions (including plotting or displaying the determined outcome and/or issuing an alert); or other health-related information, and facilitates the display of results, recommendations, or orders. For example, the user interface 104 may communicate with the EHR system 102 through the network 110 to receive patient EMRs or any other information stored in the EHR system 102. In another example, the user interface 104 may communicate with sensors or other electronic input devices to receive any real-time or near real-time patient information.
In some embodiments, the user interface 104 may include a GUI for conveying visual information. The user interface 104 may take the form of a computer monitor, which may be in communication with a server to receive information and visually convey it using the GUI. For example, computer monitors may include stand-alone monitors that are independent of the processor and are in communication with the processor through a communication bus or through wireless technology. Such computer monitors may generally be any shape and size.
In some embodiments, the user interface 104 may be integrated with one or more other computer components, such as storage hardware or processors. For example, such computer systems may include laptops, tablets, smartphones, and the like. These systems may be considered mobile devices. User interfaces associated with mobile devices may be smaller than the computer monitors previously described. Some special mobile devices may have user interfaces that are greater than standard monitor sizes, while others may have user interfaces less than standard mobile devices. These special mobile devices are also contemplated within the scope of and may also be suitable for use with the present technology. Mobile devices may communicate with other technologies, such as other components of
In some aspects, the user interface 104 may be touch sensitive. In general, a touch sensitive user interface may receive a user input at the user interface 104. In some cases, the input received will be determined based on the visual information presented by the GUI of the user interface. For example, touch sensitive user interfaces may detect an input based on sensing electrical conductivity of another object, such as a finger or stylus; based on pressure applied to the user interface; or by determining a position of an object and associating its position with a location of the user interface 104. These types of touch sensitive user interfaces and others are known in the art and will not be described in detail here for the sake of clarity; however, they are contemplated for use in the present technology.
As illustrated in
With continued reference to
In some cases, services hosted by the operating system 120 are associated with one or more virtual assistant applications, services, or routines. For example, such applications, services, or routines may operate on one or more user devices and servers, such as the computing device 108, and may be shared or distributed across one or more user devices and servers, one or more other components, or be implemented in the cloud. Moreover, the functions performed, or services carried out by these functions, may be implemented at appropriate abstraction layer(s) such as the operating system layer, application layer, hardware layer, and the like of the computing system(s).
In some cases, the functions and/or the embodiments described herein can be performed, at least in part, by one or more logic components, which may be stored in the data storage 106. For example, and without limitation, illustrative types of logic components that can be used include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc. In general, the logic comprises rules, conditions, associations, classification or prediction models, pattern inference algorithms, or other criteria utilized by the operating system 120 to execute services. In some embodiments, the logic may utilize pattern recognition, fuzzy logic, neural network, finite-state machine, support vector machine, logistic regression, clustering, or machine learning techniques, similar statistical classification processes, or combinations of these processes.
An example of the computing device 108 is provided in
With reference to
With reference again to
The memory 312 includes computer storage media in the form of volatile and/or nonvolatile memory. The memory 312 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical-disc drives, etc. The computing device 108 includes one or more processors that read data from various entities such as the memory 312 or I/O components 320. The presentation component(s) 316 present data indications to a user or other device. Exemplary presentation components include a display device, speaker, printing component, vibrating component, the user interface 104, etc.
The I/O ports 318 allow computing device 108 to be logically coupled to other devices including the I/O components 320, some of which may be built in. Illustrative components include a microphone, joystick, game pad, satellite dish, scanner, printer, wireless device, etc. The I/O components 320 may provide a natural user interface (NUI) that processes air gestures, voice, or other physiological inputs generated by a user. In some instance, inputs may be transmitted to an appropriate network element for further processing. A NUI may implement any combination of speech recognition, touch and stylus recognition, facial recognition, biometric recognition, gesture recognition both on screen and adjacent to the screen, air gestures, head and eye-tracking, and touch recognition associated with displays on the computing device 108. The computing device 108 may be equipped with depth cameras, such as, stereoscopic camera systems, infrared camera systems, RGB camera systems, and combinations of these for gesture detection and recognition. Additionally, the computing device 108 may be equipped with accelerometers or gyroscopes that enable detection of motion.
As previously noted and illustrated in
In general, the receiver 122 receives information. In some aspects, the receiver 122 receives stored patient information, such as EHRs received from the EHR system 102. In some aspects, the receiver 122 may receive clinical documents or information as an input, for example, a lab assistant, nurse, or document specialist inputting patient information via an input associated with the computing device 108 and/or via the user interface 104. In some embodiments, the receiver 122 may also receive real time or near real time patient information, such as measured physiological parameters from sensors or the user interface 104. In some embodiments, the receiver 122 may receive order information and/or patient information. The receiver 122 may also store this order or patient information temporarily or permanently, such as in the storage 106.
Patient information may include historical clinical diagnoses, such as cancer, depression, hypothyroidism, diabetes, pregnancy, and the like. Other examples of patient information include medications taken by the patient and/or prescribed to the patient. More examples of patient information include stored measurements related to various physiological parameters, such as weight, body mass index (BMI), thyroxine (T4), Thyroglobulin (Tg), and thyrotropic hormone (TSH), and the like. Patient information may also include historical physiological measurements associated with the physiological parameters and determined at different times.
Order information may include information related to tasks for completion of a particular order or order type, such as key performance indicators (KPIs). The tasks may include: patient registration, placement of orders, examination of orders, filling of orders, scheduling of procedures, conducting an exam which may include testing or imaging of a patient, storing or printing of imaging or testing data, transmitting imaging or testing data to medical staff responsible for analysis or diagnosis, analyzing imaging or testing data by medical staff, reporting on analysis by medical staff based on the imaging or testing data, and transmitting of diagnosis report to patient and/or treating physician. The KPIs may include statistics or data regarding completion or turnaround time for any of the tasks, documentation of critical task-related information, task outcomes, task statistics, task comparisons, and task projections or predictions. More specifically, the KPIs may include any of the following statistics for a single patient, for a single order, and/or on average for a plurality of patients or orders: the amount of time a task takes to complete, patient arrival times (e.g., timeliness to an appointment), amount of time for a patient to be seen, image quality, repeat rates, percentage peer reviewed, turnaround time for transcribing, turnaround time for dictating, turnaround time for reporting results, turnaround time for signing a report, tracking information regarding documentation of critical information such as radiation dose and technical comments, and any other key performance indicators tracked by the medical facility for a given task. While only a few examples of tasks and related KPIs have been included in this description as examples, it will be recognized that these are only a few of many. Other examples are not included for the sake of brevity, but are intended to be within the scope of this disclosure.
In one specific example, as depicted in
The patient and order information received by the receiver 122 may also include, for example, a time stamp. For example, the order information stored in the EHR may be associated with time stamps, including when particular tasks within a workflow of a given order or order type are received and/or completed. Tasks may also be associated with time stamps when there are changes in the order regarding a particular task. In some cases, the time stamp may represent the time that the patient information was stored. In addition to or alternatively, the time stamp may represent the time that the patient information was collected. Furthermore, medication information may be associated with one or more start dates and end dates, which may also include time stamps for change in dosage or frequency of taking the medication. Another example of patient information having associated time stamps includes clinical diagnoses, which may also include one or more onset dates and termination dates.
The extractor 124 generally parses and extracts information from the raw patient or task-related information received by the receiver 122, and stores the extracted information in a useable format. For example, raw patient information may be received from and EHR stored on the storage 106. The extractor 124 may extract information within the EHR such as patient demographics, diagnoses information, medication information, and measured physiological parameter values. Additionally or alternatively, the extractor 124 may extract information regarding KPIs associated with various tasks for a particular order or particular type of order. Parsing the information may include determining the time stamp associated with each of the entries for the diagnoses, medication information, task completion, and the like, such as a time that a particular task or lab test was performed.
Continuing, parsing the received patient information may include determining date stamps from metadata associated with an entry. For example, a physician may have entered a particular diagnosis into the patient's EHR. The date the entry was input may be associated as metadata, which when parsed, may be included as an onset date for the diagnosis if one was not expressly input by the physician. Additionally or alternatively, parsing may include determining a therapeutic or drug class for a medication. Furthermore, imaging data may include a timestamp in metadata from when the image was taken. The extractor 124 may be configured to parse different file types or files having different forms and formats for storing KPIs, timestamps, and associated metadata.
Once parsed, in some embodiments, the extractor 124 may store the information in a useable format. For example, workflow tasks related to a particular order or order type and their statuses (e.g., completed, in progress, queued) may be stored corresponding to order types, start dates and times, end dates and times, and various KPIs associated with particular ones of the tasks. It will be appreciated that other KPIs and workflow tasks performed to obtain such information may be used in various order workflows. However, for the sake of brevity and to not obscure the disclosure of the present technology, not all KPI and workflow task information can be described. Thus, while certain patient information, KPIs, and workflow tasks may not be expressly described herein, it is contemplated by the inventors that receiver 122 may receive any electronically stored or real time patient information, while it is also contemplated that extractor 124 may parse any of the information from receiver 122, extract the parsed information, and temporarily or permanently store the parsed information in a usable format. Furthermore, in some embodiments, the data may be received in a usable format and the extractor may be omitted without departing from the scope of the technology described herein.
The GUI generator 126 generally dictates how to visually present an interactive digital workflow graphic 400 and KPIs associated with tasks on the workflow graphic 400 in a manner that provides context to the KPIs and may communicate the data for display by the user interface 104.
Specifically, the GUI generator 126 can access from any database described herein (such as the storage 106) the interactive digital workflow graphic 400 having graphical depictions of a plurality of tasks 402 to be completed for a particular medical order type, a particular patient, and/or a particular patient's particular medical order. In some embodiments, the interactive digital workflow graphic 400 may be one of a plurality of interactive digital workflow graphics for each of a plurality of order types. At least some of the tasks for the order can be graphically connected by linking graphics 404 indicating a required or desired completion sequence of the tasks 402 displayed in the workflow graphic 400, as depicted in
The mapping determiner 128 can use the information received from the receiver 122 and/or parsed by the extractor 124 to determine which content or data to link to dashboard elements 406 visually displayed on the workflow graphic 400. The dashboard elements 406, as depicted in
The mapping determiner 128 may map data to the dashboard elements 406 based on user-entered selections, such as filtering options described herein. Specifically, the interactive digital workflow graphic 400 can include selectable view options, such as an option to display a single-order view in which data or KPIs for a single patient and a single order is displayed as illustrated in
Furthermore, in some embodiments, the GUI generator 126 or the mapping determiner 128 may add additional linking graphics 414 to the workflow graphic 400 based on certain completed tasks, particular metadata, or user selections. For example, if at least some of the orders of a selected order type within a selected date range were flagged for vetting, included an add on, were replaced with another exam, or were being held for various reasons, as depicted in
The status determiner 130 may use data from the EHR system 102 or any other received status information to visually indicate which of the plurality of tasks is completed, is in progress, or is queued for a pre-defined threshold number or percentage of orders of the particular medical order type, as depicted in
In some embodiments, the status determiner 130 can mark one of the tasks 402 as completed based on receipt of a particular type of file or a particular type of data, based on user indication of completion such as with a signature or digital signature, or based on indication that a next task was started, particularly if the next task cannot proceed without the previous task. In some embodiments, any of the tasks 402 may be considered queued when a previous one of the tasks 402 is indicated complete and may be considered to be in progress when a start time is provided but no completion time or other indication of completion of the task is received.
With reference first to
The step 1202 of receiving a request for process flow data and KPIs may include a request for a particular order type within the EHR system 102 or other EHR databases at a particular medical facility over a selected period of time or for otherwise filtered information. For example, the particular order type may be a radiological exam, and the selectable order options may include replacing an order, adding onto an order, vetting an order, or holding an order. In some embodiments, the request may be for a specific order for a specific patient, to visually depict that order's workflow. The flow chart displayed in step 1204 may include any of the visual components noted above for the interactive digital workflow graphic 400, including depictions of the tasks 402 associated with a particular order type or a particular order, the linking graphics 404, and the dashboard elements 406 as described herein.
The linking graphics 404 may be arranged for visually indicating a required or desired sequence of completion of the tasks. In some embodiments, step 1204 of the method may further include displaying additional linking graphics 414 on the flow chart connecting additional tasks when a particular one of the selectable order options are selected by a user. For example, compare
Visually depicting the status of the tasks, as in step 1206, may include the color-coding described herein or other various methods. In some embodiments, where multiple orders are displayed on the flow chart, the statuses may be indicated for a pre-defined threshold number or percentage of orders of a particular order type within a selected time period. For example, a visual indication that a particular one of the tasks is completed may require 100% of the orders of that order type over the given date or time range to be completed. Likewise, a color indicating a blockage at a particular task may require only one of the orders to be stalled at a particular one of the tasks. Other thresholds may be used without departing from the scope of the technology described herein.
The dashboard elements 406 in step 1208 may depict the KPIs for at least one of the tasks displayed in the flow chart, either automatically on the dashboard elements 406 or overlaid on the flow chart when the dashboard element 406 is hovered over or selected by a cursor or other user interface selection tools. As earlier noted herein, the KPIs may include statistics or data regarding any of the following: completion or turnaround time for any of the tasks, documentation of critical task-related information, task outcomes, task statistics, task comparisons, and task projections or predictions.
With reference to
As noted above, the workflow graphic may be the interactive digital workflow graphic 400 described herein and may similarly include graphical depictions of tasks to be completed for a particular medical order type. Graphical depictions of the tasks may also be graphically connected by linking graphics indicating a required or desired completion sequence of the tasks. Furthermore, the workflow graphic 400 may be built based on the particular medical order type, facilities or departments involved with the order tasks, and sequences of the tasks within and between each of the facilities or departments for the particular medical order type.
The mapping of KPIs may be performed by indicating digital locations and/or file types of relevant electronic health records (EHRs) to be accessed by the workflow graphic 400 and determining which information within the EHRs should be linked to the dashboard elements 406. As in previous embodiments, the KPIs may be mapped to be displayed directly on the dashboard elements 406 or may be mapped to be displayed or overlaid onto the workflow graphic 400 in response to a cursor hovering over or selection one of the dashboard elements 406. However, other selection tools may be used without departing from the scope of the technology.
Visually indicating the status of the tasks on the workflow graphic 400 may include color-coding at least some of the depictions of the tasks or their linking graphics, as earlier described herein. Similar to previous embodiments, the method or computer program may include providing a selectable date format view which filters the KPIs mapped from the EHR database based on a selected period of times or dates, as well as a selectable individual order view in which the KPIs mapped from the EHR database may be filtered to display only KPIs associated with a single patient or a single order. In addition to other information described above, the KPIs may include any of the following: completion or turnaround time for any of the tasks, documentation of critical task-related information, task outcomes, task statistics, task comparisons, and task projections or predictions.
In use, the methods, computer programs, and systems described herein may be utilized by medical staff and management in a variety of ways. For example, as illustrated in
Finally, a hospital management associate may also use the technology herein to visualize KPIs for certain types of orders to determine ways to improve the workflow. For example, as depicted in
Many different arrangements of the various components depicted, as well as components not shown, are possible without departing from the spirit and scope of the present invention. Embodiments of the present invention have been described with the intent to be illustrative rather than restrictive. Alternative embodiments will become apparent to those skilled in the art that do not depart from its scope. A skilled artisan may develop alternative means of implementing the aforementioned improvements without departing from the scope of the present invention.
It will be understood that certain features and subcombinations are of utility and may be employed without reference to other features and subcombinations and are contemplated within the scope of the claims. Not all steps listed in the various figures need be carried out in the specific order described. Accordingly, the scope of the invention is intended to be limited only by the following claims.
