Patent Application
20140058714
The present disclosure relates generally to computing technology used in patient monitoring and evaluation.
Clinicians often make decisions based on input from multiple sources and analysis of not only multiple patient parameters, but also of relationships between parameters and parameter changes over time. Often, such analysis involves determining whether parameters, parameter trends, and/or parameter relationships, which may have varying levels of significance to the analysis, satisfy conditions (e.g., thresholds, ranges, and the like). Protocols and procedures associated with such decisions are continually evolving as new research studies define and/or refine parameter relationships to improve patient outcomes. Some conventional medical devices such as, for example, multi-parameter patient monitors, are hardcoded to perform some of these analyses based on current values of parameters collected by the device. These conventional devices generally lack the ability to perform analysis of parameters from other sources or historical values of parameters and typically do not allow a clinician to update, configure or modify the analysis procedures.
Embodiments of the disclosure relate to technologies that facilitate determining a clinical status of a patient. Aspects of embodiments include creating a clinical status model that is at least partially configurable by a user. In embodiments, the clinical status model includes one or more conditions associated with one or more parameters. A condition may include a relationship between one or more parameters and one or more target values, thresholds, and/or ranges. Embodiments include receiving, from a database, one or more values corresponding to the parameters. The clinical status of the patient may be ascertained by determining whether one or more conditions are satisfied based on the parameter values. In embodiments, an indication of the clinical status is presented to the user.
Aspects of embodiments of the disclosure include a clinical decision support system that may provide enhanced situational awareness beyond existing patient monitoring capabilities by utilizing information from a greater diversity of data sources, thereby supporting a larger variety of parameter relationships. Embodiments of the disclosure may also contribute to improved clinical decisions and patient outcomes by providing clinicians the ability to configure parameter relationships of interest and configure alarming conditions. Embodiments of the disclosure may also facilitate improved assessment of changes in a patient's condition over time by providing an ability to specify and evaluate temporal relationships and trended parameter behaviors.
Certain embodiments of the disclosure may include some, all, or none of the above advantages. One or more other technical advantages may be readily apparent to those skilled in the art from the figures, descriptions, and claims included herein. Moreover, while specific advantages have been enumerated above, various embodiments may include all, some, or none of the enumerated advantages.
While the disclosed subject matter is amenable to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and are described in detail below. The intention, however, is not to limit the disclosure to the particular embodiments described. On the contrary, the disclosure is intended to cover all modifications, equivalents, and alternatives falling within the scope of the disclosure as defined by the appended claims.
The subject matter of embodiments of the disclosure is described with specificity to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different features or combinations of features similar to the ones described in this document, in conjunction with other technologies. Moreover, although aspects of methods according to embodiments are described with reference to “blocks,” the term “block” should not be interpreted as implying any particular order among or between various aspects unless the order of individual aspects is explicitly described.
User interface 110 may include a text and/or graphical user interface operable to present clinical status indications via a display device (e.g., display device 336 shown in
According to embodiments, data sources 114 may include, for example, databases, medical devices, electronic medical records, user interfaces, and the like. Medical devices may include therapy-providing devices (e.g., ventilators, infusion pumps, and the like), monitoring devices (e.g., pulse oximeters, capnography devices, multi-parameter patient monitors, ambulatory telemeters, and the like), or devices that combine therapy and monitoring functions. In embodiments, parameters may be received from any number of data sources.
Parameters may include physiological parameters, settings parameters, and derived parameters. Physiological parameters may include parameters measured, or otherwise obtained, by medical devices or clinicians; and settings parameters may include parameters corresponding to settings and/or protocols (e.g., monitoring protocols, treatement protocols, and the like) associated with medical devices. Exemplary physiological parameters include oxygen saturation (SpO2), pulse rate (PR), heart rate (HR), respiration rate (RR), exhaled minute volume (Ve), positive end-expiratory pressure (PEEP), tidal volume (Vt), and the like. Exemplary settings parameters include vent mode, inspiration pressure, target volume, flow pattern, spontaneous type, support pressure, sampling frequency, and the like. Derived parameters may include parameters that are calculated based on one or more physiological parameters, settings parameters, constants, and/or a combination of these. Exemplary derived parameters include tidal volume per ideal body weight (Vt/IBW), rapid shallow breathing index (RSBI), and the like.
In embodiments, the system 100 may facilitate creation of clinical status models. In embodiments, the clinical status models may be at least partially user-configurable, may be developed from published models, protocols, and the like. In embodiments, clinical status models may enable dynamic evaluation of multiple parameters and may support various mathematical functions (e.g., floor functions, statistical functions, and the like), evaluation of inequalities, multiple thresholds, and the like. Additionally, embodiments of the system 100 may facilitate evaluation of clinical status models using parameters that are indexed by time, evaluation of trend characteristics of one or more parameters, evaluation of time-determinant functions, and the like. According to embodiments, a clinical status model may correspond to a particular physiological process, treatment, monitoring procedure, or the like. Additionally, in embodiments, a clinical status model may correspond to multiple aspects, functions, procedures, and the like. For example, a clinical status model may correspond to an overall health and/or condition of a patient. Similarly, a clinical status of a patient may correspond to a single parameter, a general level of well-being, a particular output based on a protocol, an overall wellness measure, or the like.
Embodiments of the system 100 may facilitate evaluation of clinical statuses of multiple patients based on clinical status models that may include user-configurable conditions, multiple simultaneous conditions, and the like. In embodiments, a clinical status model may include one or more conditions, one or more protocols, settings associated with presenting clinical status indications, alarm settings, and the like. Evaluation of a clinical status model may include determining whether one or more of the conditions are satisfied. For example, a particular clinical status model might include three conditions. If all three conditions are satisfied, the clinical status might be a first clinical status; if none of the conditions are satisfied, the clinical status might be a second clinical status; if a first condition is satisfied, the clinical status might be a third clinical status; and so on. In embodiments, a clinical status model may facilitate determination of a number of clinical statuses of a patient.
In embodiments, various attributes may be associated with a clinical status model. Attributes may include, for example, a state, a priority or importance, a configurability level, a relationship with another clinical status model or models, and the like. For example, in embodiments a clinical status model in a first state might include a first set of conditions, protocols, or the like. Upon a determination (e.g., a determination that the patient has completed a particular stage of a breathing trial), the clinical status model may transition to a second state, in which the clinical status model includes a second set of conditions, protocols, or the like. In embodiments, a number of clinical status models may be ranked according to a clinical importance, prioritized, or the like. In embodiments, a clinical status model having a first configurability level may include conditions that cannot be configured or altered by a user, while a clinical status model having a second configurability level may include one or more conditions (or aspects of conditions or other features) that may be configured or altered. Additionally, in embodiments, a clinical status model may be related to one or more other clinical status models. For example, a first clinical status model might be instantiated based on a clinical status determination resulting from evaluation of a second clinical status model. As another example, a first clinical status model might transition from a first state to a second state based on a clinical status determination resulting from evaluation of a second clinical status model. In a further example, a number of clinical status models associated with different patients might be related to one another to facilitate performing an evaluation of patient care, monitoring, or other functions.
According to embodiments, a condition may include one or more relationships between one or more parameters and one or more thresholds and/or ranges. In embodiments, conditions may include, for example, mathematical expressions including one or more parameters, one or more operators, and one or more target values, thresholds and/or ranges. Operators may include Boolean operators, algebraic operators, arithmetic operators, statistical operators, and/or the like. For example, a condition may include an equality (i.e., equation) between a parameter and a target value (e.g., pulse rate equals 95). As another example, a condition may include an inequality between a parameter and a threshold and/or a range (e.g., pulse rate is less than 90; pulse rate is greater than 85 and less than 110, or the like). In embodiments, a condition may include a combination of equations and inequalities. Additionally, in embodiments, conditions may include other aspects such as temporal aspects (e.g., pulse rate is greater than 90 for at least three minutes), contextual aspects (e.g., pulse rate is greater than 90 when patient is at rest), relational aspects (e.g., pulse rate is greater than 90 while oxygen saturation is less than 85%), and/or the like. In embodiments, a condition may include a relationship between any number of parameters and any number of thresholds and/or ranges.
In embodiments, a patient may have, for example, a first clinical status if a condition is satisfied and a second clinical status if the condition is not satisfied. The determined clinical status or statuses of a patient or patients may be presented to a user, stored in a database, communicated to a remote device, and/or the like. Additionally, in embodiments, one or more alarms may be activated based on a clinical status. That is, in embodiments, an alarm might be activated in response to determining that the patient's clinical status is the first status. For instance, a condition might be satisfied when a patient's blood pressure exceeds a predetermined threshold at the same time that the patient's temperature exceeds another threshold. In that case, the patient's clinical status might be determined to be a first status, which may be associated with a label such as, for example, “critical” or “systemic failure,” and an alarm may be activated. In another example, a condition might be satisfied when a derived parameter (e.g., RSBI) is equal to a target value, is greater than a threshold, is less than a threshold, or is within a particular range. In further examples, a condition might be satisfied when a parameter first is equal to a target value, is greater than a threshold, is less than a threshold, or is within a particular range during a specified time period, when a parameter is equal to a target value, is greater than a threshold, is less than a threshold, or is within a particular range a specified number of times during a specified time period, when a parameter is equal to a target value, is greater than a threshold, is less than a threshold, or is within a particular range continuously for a specified time period, or the like.
In embodiments, a condition might be satisfied when values of one or more parameters are within one or more ranges of values. In embodiments, a condition might be satisfied, for example, when a value of a first parameter is within a first range and a value of a second parameter is within a second range. In embodiments, a condition might be satisfied when a set of parameters have values within a respective set of ranges, or the like. Any number of combinations of physiological parameters, derived parameters, parameters relationships, thresholds, ranges, and/or the like may be related to any number of conditions. Embodiments of the disclosure may facilitate user configuration of conditions, parameters, and the like. Embodiments may also facilitate user configuration of actions such as displaying indications of clinical status, activating alarms, and the like.
By providing dynamic, configurable, evaluation of multiple patients and parameters, embodiments of the system 100 may be used to facilitate identification of any number of various medical conditions and/or situations such as risk of lung injury (e.g., ventilator-induced lung damage), systemic failure (e.g., systemic inflammatory response syndrome, sepsis, and the like), a patient's readiness to be weaned off of a medical device such as a ventilator (e.g., by facilitating performance of a spontaneous breathing trial), and the like. Additionally, in embodiments, a user may select among various models during patient monitoring, thereby expanding the set of evaluation tools available to the user. For example, in embodiments, models may correspond to breathing stage protocols that can be selectively, successively, or simultaneously, evaluated during a spontaneous breathing trial.
Various components of the monitoring network 302 such as, for example, the medical devices 304 and 306, the monitoring service 308, and client devices 310 and 312, may be communicatively coupled according to any number of arrangements using networking technology. Such networking technology may include, for example, hardwired network communications, wireless network communications, or a combination thereof. In embodiments, a gateway 314 allows the monitoring service 308 to access other networks and systems such as, for example, an electronic medical records (EMR) system 316, a patient admit/discharge system (ADS) 318, hospital networks (not shown), the internet (not shown), and the like.
In embodiments, the monitoring service 308 may include one or more computing devices and can be implemented using distributed computing technologies, failover arrangements, and the like. As shown in
In embodiments, the data collector 320 may include translation mechanisms that facilitate storing received parameter values in a database 322, which is maintained in a memory 324. According to embodiments, the database 322 may be a relational database, one or more tables, a data cube or the like. The memory 324 may include one or more devices for storing data. The database 322 may support a query mechanism such as, for example, structured query language (SQL), online analytical processing (OLAP), or the like. In embodiments, the database 322 may include data received from other networks and systems such as, for example, an electronic medical records (EMR) system 316, a patient admit/discharge system (ADS) 318, and the like.
In embodiments, the monitoring service 308 includes a data server 326 that provides data services to the client devices 310 and 312. In embodiments, for example, the data server 326 may be a web server that provides a web page, an application server that hosts an application service, or a combination of these. In embodiments, the data server 326 may receive parameter values from the database 322 and provide the values to the client devices 310 and 312, for example, in response to requests from the client devices 310 and 312.
As illustrated, the data server 326 may also include a status model manager (SMM) 328. In embodiments, the SMM 328 facilitates determining a clinical status of a patient by facilitating the creation and evaluation of clinical status models. The SMM 328 may include software that may be hosted by the data server 326 or distributed between the data server 326 and the client devices 310 and 312. For example, in embodiments, the SMM 328 may include an application service having a server component executing on the data server 326 and a client component executing on a client device 310 and/or 312. In another embodiment, the SMM 328 may reside on a client device 310 or 312 and be configured to receive parameter values from the data server 326. In other embodiments, the SMM 328 may be hosted by any number of other computing devices in communication with the monitoring service 308 and/or the client devices 310 and 312.
In embodiments, the client devices 310 and 312 may be computing devices such as, for example, desktop computers, terminals, laptops, personal digital assistants (PDAs), mobile communications devices, or the like. In embodiments, a client device 310 may include a memory 330, a processor 332, an input device 334, and a display device 336. According to embodiments, the processor 332 (or processors) reads data from various entities such as a memory 330, the input device 334, and the like. In embodiments, the input device 334 may be used, for example, to receive input from a user such as clinical status model definitions, parameter values, commands, and the like. The display device 336 may be used, for example, to display clinical status indications, visual alarms, a user interface (e.g., the user interface 402 described below with reference to
In embodiments, the memory 324 and/or the memory 330 (or similar memory component associated with a computing device) can include computer-readable media. Computer-readable media include both volatile and non-volatile media, removable and nonremovable media, and contemplate media readable by a database, a processor, a router, and various other networked devices. By way of example, and not limitation, computer-readable media can include media implemented in any method or technology for storing information. Examples of stored information include computer-executable instructions, data structures, program modules, and other data representations. Media examples include, but are not limited to, Random Access Memory (RAM); Read Only Memory (ROM); Electronically Erasable Programmable Read Only Memory (EEPROM); flash memory or other memory technologies; Compact Disc Read-Only Memory (CD-ROM), digital versatile disks (DVDs) or other optical or holographic media; magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices; data transmissions; or any other medium that can be used to encode information and can be accessed by a computing device such as, for example, quantum state memory, and the like.
The illustrative patient monitoring system 300 shown in
Embodiments of the disclosed subject matter may be described in the general context of computer-executable instructions (e.g., software). Computer-executable instructions may include, for example, computer code, machine-useable instructions, and the like such as, for example, program components, capable of being executed by one or more processors associated with a computing device. For example, program components may include components of an operating environment such as, for example, the illustrative operating environment 400 described below with reference to
As shown in
The SMM 328 may also include a parsing component 412 that parses the clinical status model 406 (or portions thereof) to facilitate pre-processing and/or evaluation of the clinical status model 406. For example, in embodiments, the clinical status model 406 can be pre-processed to identify common terms throughout multiple equations, conditions, or the like. Additionally, pre-processing may include performing constant folding and other techniques for facilitating efficient calculation and evaluation. The parsing component 412 may also identify variables defined within the clinical status model 406 that correspond to parameters that may be stored in a database 322.
In embodiments, the SMM 328 may include, or interact with, a data access component 414, which facilitates access to the database 322. In embodiments, for example, the data access component 414 may provide data mappings between variables in a clinical status model 406 and parameter values stored in the database 322, thereby facilitating automatic and dynamic retrieval of parameter values during evaluation of the clinical status model 406. In embodiments, the data access component 414 locates parameter values in the database 322, maps those values to variables contained in a clinical status model 406, and, during evaluation of the clinical status model 406, facilitates retrieval of the values (e.g., most recent values, historical values, and the like). According to embodiments, the data access component 414 may facilitate access, by the SMM 328, to parameter values from other data sources such as, for example, the data collector 320, medical devices 304 and 306, the user interface 402, the EMR system 316, the ADS system 318, and/or the like.
In embodiments, parameter values may be stored in various tables 416, 418, and 420 contained in the database 322. The data access component 414 may, in embodiments, identify, based on data mappings, which tables 416, 418, and 420 to query during evaluation. In this manner, unnecessary querying of tables 416, 418, or 420 may be avoided. For example, in an embodiment, a clinical status model 406 might include a definition of a derived parameter “X” that is defined by a relationship between a first physiological parameter, “A,” and a second physiological parameter, “C” (e.g., A+C=X). In the example, as values of the first physiological parameter, “A,” are collected, they may be stored in a column 422 of table 416; and, as values of the physiological parameter, “C,” are collected, they may be stored in a column 424 of table 418. In this example, the data access component 414 identifies the tables 416 and 418 that include the patient parameters, “A” and “C,” and stores some indication (e.g., in the clinical status model 406, internally, or the like) of the tables 416 and 418 that contain values corresponding to the parameters, “A” and “C,” so that other tables 420 are not queried for these values during evaluation of the clinical status model 406.
In embodiments, the data access component 414 also may manage prioritizing data sources associated with physiological parameters. In embodiments, for example, two or more different medical devices may provide values for a particular physiological parameter. For example, values of a respiration rate parameter corresponding to a particular patient may be received from a ventilator and a pulse oximeter, but the values received from the ventilator may tend to be more accurate as they are a direct measurement of respiration rate, whereas the values obtained from the pulse oximeter are calculated based on a plethysmograph and, as such, are an indirect measurement. In embodiments, the data access component 414 may be configured to map a corresponding variable in a model 406 to the values for respiration rate obtained by the ventilator rather than the pulse oximeter. Additionally, in embodiments, the data access component 414 may be configured to maintain an order of preference for retrieving the values so that, if values for a parameter are not available from a first medical device (e.g., a preferred data source), such as in a case in which the first medical device is not providing values (e.g., is not connected to the patient, is offline, or the like), the data access component 414 may retrieve values collected from a second medical device. Any number of medical devices may be included in such an order of preference. In embodiments, the data access component 414 may configure an order of preference based on automatic default preferences, user preferences, or other factors such as, for example, consistency of value measurement, network connectivity, signal quality, and/or the like.
According to embodiments, the user interface 402, the definition component 404, the parsing component 412, and the data access component 414 may work together to create a configuration file 408 containing a clinical status model 406. In embodiments, the configuration file 408 may include various types of information. Exemplary information included in a configuration file 408 may include a file name, a clinical status model 406, parameter names, an identification of each database table corresponding to a variable (e.g., parameter), an identification of each database column corresponding to a variable (e.g., parameter), an identification of each database field corresponding to a variable, a data source preference order, definitions of constants, and the like.
As shown in
In operation, a user may instantiate a particular clinical status model 406 by providing an input to the user interface 402, thereby causing the SMM 328 to load the corresponding configuration file 408. In embodiments, the parsing component 412 may perform further parsing operations on the clinical status model 406 during runtime to further facilitate evaluation of the model 406. The evaluation component 426 receives parameter values corresponding to variables defined in the model (e.g., from the database 322, the user interface 402, and the like) and evaluates equations, conditions, and the like that are defined in the model 406. In embodiments, the user may configure, at runtime, the evaluation process by, for example, specifying time periods of interest, requesting trend information, modifying or selecting conditions and/or thresholds, specifying data sources, specifying presentation options for displaying status indicators, specifying alarm mechanisms, and the like.
According to embodiments, various components of the operating environment 400 can be implemented on one or more computing devices that are communicatively coupled to one or more other computing devices such as through a network 302. According to embodiments, a computing device can include any type of computing device suitable for implementing embodiments of the disclosed subject matter. Examples of computing devices include terminals, workstations, servers, laptops, desktops, tablet computers, hand-held devices, wearable devices, implantable devices, and the like, all of which are contemplated within the scope of
The illustrative operating environment 400 shown in
Embodiments of the method 500 include pre-processing equations (block 514) and creating data mappings (block 516) between variables and parameter value fields in a database (e.g., database 322). As shown in
In embodiments, the SMM receives parameter values (block 522), which may include physiological parameter values and/or settings parameter values. In embodiments, the parameter values may be received from any number of data sources such as, for example, a database, a medical device, a user, or the like. In embodiments, the parameter values can be used to calculate derived parameter values (block 524). According to embodiments of the method 500, the SMM uses the received (and/or calculated) parameter values to evaluate conditions defined in the clinical status model to determine a clinical status of the patient (block 526). For example, the clinical status may include a first status if a condition is satisfied and a second status if the condition is not satisfied. In embodiments, one or more conditions in a clinical status model may be weighted such that the clinical status determination is influenced to a greater or lesser degree based on the weighting. Additionally, in embodiments, evaluation of a clinical status model may provide information associated with a trend of one or more parameters. For example, the SMM may evaluate one or more conditions in relation to one or more sets of time-indexed values corresponding to one or more parameters. As is further shown in
The disclosure has been described in relation to particular embodiments, which are intended in all respects to be illustrative rather than restrictive. Alternative embodiments will become apparent to those of ordinary skill in the art to which the disclosed subject matter pertains without departing from its scope. It will be understood that certain features and subcombinations are of utility and may be employed without reference to other features and subcombinations. This is contemplated by and is within the scope of the claims.
