Risk monitoring scores

A user interface for clinical personnel provides selectable views of a plurality of medical risk scores. Questions whose answers are needed for calculation of those risk scores are asked in a question and answer area of the user interface, which allows some questions to be answered based on real time patient physiological data streams that are overridable by user provided answers. Where multiple risk score calculations require answers to the same question, the user provided answer may be supplied as an answer to the corresponding question for each risk score, rather than requiring the user to answer multiple times. Sparklines may be provided with the displayed risk scores to show trends in the risk score values, and may be updated in real time based on real time physiological data streams. The display of risk scores may visually distinguish between risk scores that have been validated and those are based on unvalidated answers to the questions.

TECHNICAL FIELD

The present invention relates to the field of healthcare, and in particular to displaying a user-selectable plurality of medical risk scores.

BACKGROUND ART

In recent years, medical care units have become more data driven, using calculated evidence-based tools to help physicians and other clinical personnel. One of the better known commercial products is the Rothman Index, which captures data found in a hospital's electronic health record (EHR) and generates a graph that synthesizes routine vital signs, nursing assessments, and lab results, producing a single value, a risk score that can be used to track patient progress and detect subtle declines in health. Other risk scores have been devised for the medical community, such as a well-known collection of calculators freely available at mdcalc.com. These calculators are independently generated, with no synergism available when using multiple calculators. A better approach to presenting risk scores has been desired.

DESCRIPTION OF EMBODIMENTS

Although some of the following description is written in terms that relate to software or firmware, embodiments can implement the features and functionality described herein in software, firmware, or hardware as desired, including any combination of software, firmware, and hardware. References to daemons, drivers, engines, modules, or routines should not be considered as suggesting a limitation of the embodiment to any type of implementation.

The terms “a,” “an,” and “the” are not intended to refer to a singular entity unless explicitly so defined, but include the general class of which a specific example may be used for illustration. The use of the terms “a” or “an” may therefore mean any number that is at least one, including “one,” “one or more,” “at least one,” and “one or more than one.”

The term “or” means any of the alternatives and any combination of the alternatives, including all of the alternatives, unless the alternatives are explicitly indicated as mutually exclusive.

The phrase “at least one of” when combined with a list of items, means a single item from the list or any combination of items in the list. The phrase does not require all of the listed items unless explicitly so defined.

As used herein, the term “a computer system” can refer to a single computer or a plurality of computers working together to perform the function described as being performed on or by a computer system.

As used herein, the term “processing element” can refer to a single hardware processing element or a plurality of hardware processing elements that together may be programmed to perform the indicated actions. The hardware processing elements may be implemented as virtual hardware processing elements of a virtual programmable device hosted on a physical hardware device. Instructions that when executed program the processing element to perform an action may program any or all of the processing elements to perform the indicated action. Where the processing element is one or more multi-core processors, instructions that when executed program the processing element to perform an action may program any or all of the multiple cores to perform the indicated action.

As used herein, the term “medium” can refer to a single physical medium or a plurality of media that together store the information described as being stored on the medium.

As used herein, the term “memory” can refer to a single memory device or a plurality of memory devices that together store the information described as being stored on the medium. The memory may be any type of storage device, including random access memory, read-only memory, optical and electromechanical disk drives, etc.

A web-based user interface that relies upon an underlying vendor-agnostic platform provides a platform for a generalized risk score presentation interface. In one embodiment, the underlying vendor-agnostic platform is the SICKBAY™ platform from Medical Informatics Corp. (SICKBAY is a trademark of Medical Informatics Corp.) By allowing the platform to instantiate a web-based application that provides for a configurable monitoring station that can monitor risk scores from any number of patients from beds and facilities with equipment from any vendor, the deficiencies of central monitoring stations can be overcome. Because the risk score monitoring application is web-based, the risk score monitoring application can be used on nearly any type of device that can support web-based applications and display a graphical user interface, which includes fixed installations as well as mobile devices. Because the underlying platform can transform vendor-specific patient data into vendor-agnostic patient data, the configurable risk score monitoring application user interface can allow monitor watchers and care providers the ability to be more flexible in what they monitor.

FIG.1is a block diagram illustrating a graphical user interface (GUI)100for presenting a plurality of risk scores according to one embodiment. The GUI100allows presentation and display of a user-selectable collection of risk scores for a patient. In some embodiments, spark lines can be provided as a view showing trends in the risk scores. The GUI100patient data illustrated inFIG.1is illustrative and by way of example only, does not display actual patient information, and is not intended to display accurate medical conditions.

The arrangement and look of the GUI100is also illustrative and by way of example only. Any desired arrangement and presentation of the GUI elements may be used except as specifically set forth below and additional elements may be deployed in the GUI100as desired.

In this example, a patient information area110may be included, displaying any desired patient identifying information, such as, but not limited to, the patient's name, location in the clinical facility such as a bed number, a patient identifier, etc. The collection of risk scores available for display in the GUI100may be access in the element120, illustrated in this example as a pull-down menu element. In such an embodiment, a user wishing to see a plurality of risk scores for the patient would select one or more items from the pull-down menu to add to the display. Other techniques for selecting the plurality of risk scores for display can be used, using techniques well-known in the GUI arts, for example check boxes.

As a risk score is added to the GUI100, a question and answer area130may be displayed to allow the user to answer the questions that provide the values needed to compute the risk score. In the current example, three questions132are provided, along with three areas for answering those questions133. The questions132asked vary with the risk score, and different risk score calculations may require any number of questions, depending upon the calculations performed to generate the risk score. The questions132generally relate to medical factors corresponding to the patient, such as age, physiological data values, etc., and may require subjective analysis by the user. For example, a HEART Score for Major Cardiac Events available on mdcalc.com includes the following questions:History: slightly suspicious, moderately suspicious, or highly suspiciousEKG: normal, Non-specific repolarization disturbance, or significant ST depressionAge: <45, 45-64, or ≥65Risk factors: no known risk factors, 1-2 risk factors, or ≥3 risk factorsInitial troponin: ≤normal limit, 1-2× normal limit, or >2× normal limit

Although described herein as a question, each question132may be simply a data element related to the particular risk score, and may be presented in any desired way, using any desired type of GUI element for presenting the data element and allowing the user to provide an appropriate value for that data element, including typing a value, selecting a value from a list, etc.

In some embodiments, one or more of the questions associated with the risk score may be answered by providing real-time patient physiological data streams available from the underlying platform (described below in the discussion ofFIG.3), instead of the user typing or otherwise entering the value directly in an answer area. In some embodiments, the user may choose to accept the real time physiological sensor data values or may choose to enter an alternate value based on the user's consideration of the patient. If the user supplies a value, that value overrides the corresponding value supplied by the real-time patient physiological data stream.

Depending on the risk score calculation, more questions132may be needed for the calculation than there is room in the question and answer area130. In such a situation, scrolling or other techniques may be used to navigate through the questions132.

In one embodiment, after all of the questions132are answered, the user interacts with a user interaction element135(as illustrated inFIG.1, a Submit button135) to submit the answers133to the risk score calculator. This provides an indication that the user has validated the answers133, including any of the answer133that may be provided by real time sensor data. The user interaction element135may be any desired type of user interaction element and labeled with any desired label indicating its purpose.

The plurality of selected risk score blocks150may be presented in the GUI100in a risk score area140separate from the question and answer area130. In some embodiments, the question and answer area130may be visible only when the user has selected one of the risk scores, and be removed from the GUI100once the user has submitted the answer133using the question and answer area130.

InFIG.1, four risk score blocks150A-150D are visible, but that number is illustrative and by way of example only, and any desired number of risk score blocks150may be displayed, subject to limits imposed by the GUI100. Some embodiments may allow inclusion of more risk scores than may be simultaneously displayable on the display, and may provide means for navigating the risk score area140, such as by the use of scroll bars (not shown inFIG.1). Technique for allowing a user to navigate across an area that is larger than the display are well known in the art and need not be described in detail herein.

Each of the risk score blocks150typically includes an identifier for the risk score (“SCORE 1,” “SCORE 2,” “SCORE 3,” and “SCORE 4” inFIG.1, for example) and a numerical value for the risk score152. In some embodiments, sparklines154may be included in the risk score blocks150to show the trend of that numerical value for the risk score152.

As stated above, some risk scores may be calculated based at least in part on real time sensor data that produces real-time patient physiological data streams. Embodiments may automatically update the numerical value of the risk score152based on the updated real-time patient physiological data streams. This may occur without user interaction, so that the numerical value of the risk score152changes automatically, or may only change the presented numerical value of the risk score152when the user selects that risk score block150.

Because data provided real-time patient physiological data streams may be changing automatically, without user review, embodiments may visually indicate that the numerical value of the risk score152is unvalidated information by use of color, shading, or some other type of GUI attribute, and that the numerical value of the risk score152is validated by similar use of color, shading, or some other type of GUI attribute if the user has submitted the risk score answer133by interacting with the submit button135.

In some embodiments, the sparklines154may also include both validated and unvalidated data, including data based on real-time patient physiological data streams, and may include indications that at least some of the data in the sparklines154is unvalidated using color, shading, or some other type of GUI attribute. In some embodiments, portions of the sparkline154that correspond to validated risk score numerical values may be shown with one attribute and other portions of the sparkline154that correspond to unvalidated risk score numerical values may be shown with another attribute.

In some embodiments, the calculation of the risk scores152is performed in the browser that displays the GUI100in one of the personal devices395described in the discussion ofFIG.3below. In other embodiments, the calculation of the risk scores152may be performed in a server, such as one of the servers380-390described below in the discussion ofFIG.3. In the server-calculated embodiments, risk scores152that are calculated at least in part from real time patient physiological data streams may be further compared against alarm thresholds and alarms generated in the underlying platform system.

FIG.2is a flowchart200illustrating a technique for updating the GUI100according to one embodiment with a plurality of risk scores. In block210the GUI100may be presented for display. In some embodiments, the GUI100may be displayed on a display of the computer system generating the risk scores, but in other embodiments, the GUI100is a web-based GUI that can be displayed on any display using a browser, with a web server providing the GUI100for display in a browser of another device communicatively coupled to the web server, such as the personal devices395ofFIG.6communicating with the servers380-390, described below.

In block220, a check is made whether the user has viewed the risk score display previously. If so, then in block230the GUI100may be repopulated with the risk score blocks150from the most recent use of the GUI100, avoiding the need for the user to select each of the risk scores again. If the risk scores152displayed by those risk score blocks150are calculated at least in part on real time sensor data, unvalidated numerical scores and sparklines may be instantiated for those risk scores152.

If the user has not previously used the GUI100then in block240the user may use the available score area120to select risk score blocks150to be shown in the risk scores area140. If the risk scores area140is repopulated from previous usage, the user may make modifications in block240by rearranging, adding, or deleting the risk score blocks150for current desires.

In block250, the user may select one of the displayed risk score blocks150, allowing the user to enter the answers133to questions132in the question and answer area130for that risk score, with the questions asked in block260and the answers received in block270. An advantage of collecting multiple risk scores in a single GUI100is that multiple risk scores may use the same questions. For example, two different risk scores may request a current heart rate or some other factor. In that situation, the user does not have to answer the corresponding question132multiple times, but the answers may be reused, reducing the need for user interaction with the GUI100. Once the answers133have been received (including by copying from questions asked for other risk scores), the risk score may be recalculated in block280and displayed in the GUI100in block290. In some embodiments, questions132that are duplicated in the calculation of multiple risk scores may be re-asked if the question132was previously answered more than a threshold amount of time in the past, rather than using the old answer133in the calculation of a different risk score.

Because different risk score calculators may use different language when asking essentially the same question, a mapping feature may be used to map similar questions132to each other, so that mere wording changes would not prevent the questions132from being recognized as the same question, and allowing reuse of the answers133.

FIG.3is a block diagram illustrating a system300for collecting, archiving, and processing arbitrary data in a healthcare environment that can deploy a GUI100as described above, according to one embodiment.

As illustrated, there are five types of servers: the data acquisition (DAQ) server387, the informatics server(s)380, the database server385, the Health Level 7 (HL7) server383, and the web server(s)390. Any number of any of the types of servers may be deployed as desired. All of the servers380-390connect to each other and the bedside monitors via one or more hospital networks330. Although illustrated as a single hospital Ethernet network330, any number of interconnected networks may be used, using any desired networking protocols and techniques.

Also connected to the hospital network330are a number of bedside monitors for monitoring physiological data for a patient in bed310. These bedside monitors may include network connected monitors320A, which can deliver digital physiological data to the hospital network330, serial devices320B, which produce digital data but are not directly connected to a network, and analog devices320C, which produce analog data and are not directly connected to a network. Communication boxes340A and340B allow connecting the serial devices320B and analog devices320C, respectively, to the hospital network330, typically through a network switch350. In addition, a sub-station360may be also connected to the network330via the network switch350for performing data manipulation and time synchronization as described below. Any number of bedside monitor devices320may be used as determined advisable by physicians and other clinical staff for the patient in bed310.

Although as illustrated inFIG.3the bedside monitors and associated communication devices are connected directly or indirectly to the hospital network330, remote bedside monitoring devices may be used as part of the system300, such as home monitoring devices, connected to the hospital network330indirectly through the Internet or through other communication techniques.

Additionally, one or more research computers370may be connected, directly or indirectly, to the hospital network330, allowing researchers to access aggregated data collected from bedside monitors320for performing analytics and development.

The web servers390are configured for communicating with personal devices such as laptop395A, tablet395B, or smart phone395C via a web browser interface using HyperText Transport Protocol (HTTP). The designation “personal devices” is not intended to be limiting, and the personal devices395may be any device capable of using a browser interface for displaying data. In one embodiment, the system300is a Sickbay Platform provided by Medical Informatics Corp. of Houston, Tex. More detail about the system300can be found in U.S. Pat. Pub. No. 2015/0142475A1, “Distributed Grid-Computing Platform for Collecting, Archiving, and Processing Arbitrary Data in a Healthcare Environment,” U.S. patent application Ser. No. 14/548,433, filed Nov. 20, 2014, which is incorporated herein by reference in its entirety for all purposes.

Referring now toFIG.4, an example computer400for use as one of the servers380-390or personal devices395is illustrated in block diagram form. Example computer400comprises a system unit410which may be optionally connected to an input device or system460(e.g., keyboard, mouse, touch screen, etc.) and display470. A program storage device (PSD)480(sometimes referred to as a hard disc) is included with the system unit410. Also included with system unit410is a network interface440for communication via a network with other computing and corporate infrastructure devices (not shown). Network interface440may be included within system unit410or be external to system unit410. In either case, system unit410will be communicatively coupled to network interface440. Program storage device480represents any form of non-volatile storage including, but not limited to, all forms of optical and magnetic, including solid-state, storage elements, including removable media, and may be included within system unit410or be external to system unit410. Program storage device480may be used for storage of software to control system unit410, data for use by the computer400, or both.

System unit410may be programmed to perform methods in accordance with this disclosure. System unit410comprises a processor unit (PU)420, input-output (I/O) interface450and memory430. Processor unit420may include any programmable controller device, such as microprocessors available from Intel Corp. and other manufacturers. Memory430may include one or more memory modules and comprise random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), programmable read-write memory, and solid-state memory. One of ordinary skill in the art will also recognize that PU420may also include some internal memory including, for example, cache memory.

Embodiments, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms. Modules may be hardware, software, or firmware communicatively coupled to one or more processing elements in order to carry out the operations described herein. Modules may be hardware modules, and as such, modules may be considered tangible entities capable of performing specified operations and may be configured or arranged in a certain manner. Circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. The whole or part of one or more programmable devices (e.g., a standalone client or server computer system) or one or more hardware processing elements may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. The software may reside on a computer readable medium. The software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations. Accordingly, the term hardware module is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. Where modules are temporarily configured, each of the modules need not be instantiated at any one moment in time. For example, where the modules comprise a general-purpose hardware processing element configured using software; the general-purpose hardware processing element may be configured as respective different modules at different times. Software may accordingly program a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time. Modules may also be software or firmware modules, which operate to perform the methodologies described herein.

While certain exemplary embodiments have been described in details and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not devised without departing from the basic scope thereof, which is determined by the claims that follow.