Systems and methods for customized clinical scoring

Abstract

A system for generating clinical guidance includes a patient-monitor defibrillator, a sensor configured to measure patient physiologic data for a patient, a mobile device communicatively coupled to the defibrillator and including a display, and a storage medium having stored thereon instructions configured to cause a processor to receive the patient physiologic data from the defibrillator, retrieve a specified clinical scoring configuration, and implement the specified clinical scoring configuration to control a user interface (UI) at the display to display a user interactive scoring control, receive a user selection of the user interactive scoring control, receive score inputs, the score inputs including a value of a physiologic parameter represented in the patient physiologic data, generate score outputs based on the score inputs, display the score outputs, and store the score outputs in a patient encounter file associated with the defibrillator.

Description

SYSTEMS AND METHODS FOR CUSTOMIZED CLINICAL SCORINGCROSS-REFERENCE TO RELATED APPLICATIONSThis application claims priority under 35 U.S.C. § 119(e) to U.S. Provisional Patent Application 63 / 560,183 titled SYSTEMS AND METHODS FOR CUSTOMIZED CLINICAL SCORING, filed on March 1, 2024, the contents of which are incorporated herein by reference in its entirety for all purposes.BACKGROUND

[0001] In a pre-hospital and / or acute care treatment setting, medical responders are often tasked with providing interventions for emergency conditions such as respiratory distress, cardiac arrest, and / or trauma in a treatment environment that is often noisy, crowded, and chaotic. Examples of such environments include the scene of an automobile collision, a hospital emergency room, and the scene of a patient in cardiac arrest. In many cases, medical responders are encountering the patient for the first time without knowledge of medical history and may have to perform immediate interventions to prevent the patient from dying before the patient can be transported to a hospital or before advanced diagnostic test results are available. In such settings, even well-trained paramedics, nurses, or physicians often have difficulty in rapidly assessing and recognizing patient conditions and in identifying and providing the most effective immediate interventions. In some cases, a first responder may have limited training for interventions for a particular medical condition or injury.

[0002] In order to aid and facilitate effective care in the difficult situations described above, responders and clinicians calculate various clinical scores, sometimes referred to as early warning scores, to facilitate a recognition of clinical deterioration or improvement in early stages. These scores often assign numeric values to various physiologic parameters (e.g., systolic blood pressure, heart rate, oxygen saturation, respiratory rate, level of consciousness, etc.). These physiologic parameters may be measured with a device and / or observed by a clinician. The various parameters are typically weighted and then evaluated to derive a composite score. Where the composite score is available from an automated system, such a system may provide automated and potentially life-saving guidance for immediate medical care. However, to be effective, such tool should provide this information without distracting caregivers and without creating extraneous administrative or recordation tasks.SUMMARY

[0003] The foregoing general description of the illustrative implementations and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.

[0004] An example of a system for generating clinical guidance for a patient encounter may include a medical device that is a patient monitor-defibrillator having a medical device display and at least one sensor configured to measure patient physiologic data for a patient during the patient encounter, and a mobile device communicatively coupled to the medical device and including a mobile device display, and at least one non-transitory, processor- readable storage medium having stored thereon first processor-readable instructions. The first processor-readable instructions may be configured to cause at least one processor to receive at least a portion of the patient physiologic data from the medical device, retrieve at least one specified clinical scoring configuration from a resource manager communicatively coupled to the at least one processor, implement the at least one specified clinical scoring configuration to control at least a portion of a user interface (UI) at the mobile device display to display at least one user interactive scoring control at the UI, and receive a user selection of the at least one user interactive scoring control, receive score inputs based on the user selection, the score inputs including a value of a physiologic parameter represented in the at least the portion of the patient physiologic data, generate one or more score outputs based on the score inputs, control the at least the portion of the UI to display the one or more score outputs, and store the one or more score outputs in a patient encounter file associated with the medical device.

[0005] Implementations of such a system may include one or more of the following features. The medical device may be configured to store the patient physiologic data measured for the patient in the patient encounter file. The medical device may be an only medical device communicatively coupled to the mobile device during the patient encounter. The first processor-readable instructions may be configured to cause the at least one processor to implement the at least one specified clinical scoring configuration to generate a severity index for a respective score output of the one or more score outputs, control the at least the portion of the UI to display the severity index, and store the severity index in the patient encounter file with the respective score output. The severity index may include a display graphic for the respective score output having a color indicative of a relative severity of a patient condition indicated by the respective score output. The first processor-readable instructions may be configured to cause the at least one processor to implement the at leastone specified clinical scoring configuration to generate a time stamp for a respective score output of the one or more score outputs, control the at least the portion of the UI to display the time stamp, and store the time stamp in the patient encounter file with the respective score output. The system may include at least one non-transitory, processor-readable storage medium having stored thereon second processor-readable instructions and the second processor-readable instructions may be configured to cause at least one additional processor may provide a clinical score configuration UI, receive user specifications at the clinical score configuration UI for a plurality of configuration fields configured to capture the score inputs, generate the at least one specified clinical score configuration based on the user specifications, and export the at least one specified clinical score configuration to the resource manager. The first processor-readable instructions may be configured to cause the at least one processor to retrieve a plurality of specified clinical scoring configurations from the resource manager, and implement the plurality of specified clinical scoring configurations to control at least the portion of the UI to display a plurality of user interactive scoring controls at the UI, each user interactive scoring control corresponding to a respective clinical score. The user selection of the at least one user interactive scoring control may be a selection from the plurality of user interactive scoring controls. A first user selection of the at least one user interactive scoring control may cause the at least one processor to generate an initial score output, an initial severity index, and a first associated time stamp. A second user selection of the at least one user interactive scoring control subsequent to the first user selection may cause the at least one processor to generate an updated score output, an updated severity index, and a second associated time stamp, and replace a display of the initial score output, the initial severity index, and the first associated time stamp with a display of the updated score output, the updated severity index, and the second associated time stamp. The at least one score output may include a textual caregiver recommendation for patient treatment. The at least one score output may include a numeric value. The at least one processor may be configured to implement the at least one specified clinical scoring configuration to control at least the portion of the UI to provide one or more prompts for the score inputs and capture at least a portion of the score inputs from user entries at the UI in response to the one or more prompts. The score output may require a plurality of score inputs and the user responses to the one or more prompts may provide all of the plurality of score inputs. The one or more prompts may include at least one of a prompt for user entry of the patient physiologic data or a prompt for user entry of a patient evaluation by a caregiver. The respective score outputmay include at least one of a Glasgow Coma Scale (GCS) score, a quick Sequential Organ Failure Assessment (qSOFA) score, a Modified Early Warning (MEWS) score, a National Early Warning (NEWS) score, or a National Early Warning 2 (NEWS2) score. The respective score output may include a stroke score. The stroke score may include at least one of a Los Angeles Motor Scale (LAMS) score, a Functional Assessment Staging Tool (FAST) score, or a Vision Aphasia Neglect (VAN) score. The one or more score outputs may require a plurality of score inputs and the at least one processor may be configured to implement the at least one specified clinical scoring configuration to receive at least a portion of the plurality of score inputs from the medical device. The one or more score outputs may include a trauma score. The trauma score may include at least one of a Compensatory Reserve Index (CRI) score, a Community Resiliency Model (CRM) score, or an Automated Processing of the Physiological Registry for Assessment of Injury Severity (APPRAISE) score. The one or more score outputs may include an Amplitude Spectrum Area (AMSA) score. The one or more score outputs may include a shock advisory based on the AMSA score. The one or more score outputs may include a cardiopulmonary resuscitation score calculated by an assignment of points to ranges of compression depth, compression rate, ventilation volume, and ventilation rate. The at least one processor may be configured to implement the at least one specified clinical scoring configuration to receive all of the plurality of score inputs from the medical device. The portion of the plurality of score inputs may be a first portion and the at least one processor may be configured to implement the at least one specified clinical scoring configuration to provide one or more prompts for the score inputs at the UI, and capture at least a second portion of the plurality of score inputs from user entries at the UI in response to the one or more prompts. The portion of the plurality of score inputs from the medical device may include physiologic parameters of a patient detected by the medical device. The UI may include a connected devices control configured to identify the medical device communicatively coupled to the mobile device. The connected devices control may be configured to provide one or more device selection controls configured to initiate a communicative coupling between the mobile device and the medical device. The at least one processor may be configured to implement the at least one specified clinical scoring configuration to control at least the portion of the UI to provide at least one guidance request control and, in response to a user selection of the at least one guidance request control, provide score input instructions including one or more of text instructions or graphic instructions. The at least one processor may be configured to apply an analytic operation to atleast one score input, generate a derived parameter from the at least one score input based on the analytic operation, and generate the one or more score outputs based on the derived parameter. The analytic operation may include a trend calculation for the at least one score input. The at least one processor may be configured to apply the analytic operation in realtime to the at least one score input based on an event marker automatically generated by the medical device. The at least one processor may be configured to filter the one or more score outputs based on at least one of a caregiver skill level or a clinical category. The at least one processor may be configured to adjust at least one severity index associated with at least one of the one or more score outputs based on at least one of the caregiver skill level or the clinical category. The at least one processor may be configured to control the at least the portion of the UI to display at least one measured physiological parameter in a graphical form substantially similar to the one or more score outputs. The at least one processor may be configured to control the at least the portion of the UI to display two or more workflow elements in a graphical form substantially similar to the one or more score outputs. The two or more workflow elements correspond to a MARCH (massive hemorrhage, airway, respiratory, circulation, head injury, hypothermia) workflow. The first processor-readable instructions may be configured to cause the at least one processor to integrate the at least one specified clinical scoring configuration with patient monitoring application implemented at a computing device and the patient monitoring application may be configured to provide a visual representation in real-time at the mobile device display of at least a portion of patient information provided at the medical device display during the patient encounter. The patient monitoring application may be configured to provide at least a medical device view tab and a patient status tab and the first processor-readable instructions may be configured to cause the at least one processor to, in response to a selection of the medical device view tab, display the one or more score outputs with the visual representation of the at least the portion of patient information provided at the medical device display and, in response to a selection of the patient status tab, display the at least one user interactive scoring control. The UI may include a clinical guidance UI configured to provide caregiver guidance based on an encoded clinical guidance protocol that incorporates the at least one specified clinical scoring configuration. The at least one processor may be configured to receive caregiver input from a caregiver, generate the caregiver guidance based on the caregiver input and the at least a portion of the patient physiologic data received from the medical device, and provide the caregiver guidance with the one or more score outputs.

[0006] An example of a system for generating clinical early warning score guidance for a patient encounter may include at least one non-transitory, processor-readable storage medium having stored thereon first processor-readable instructions. The first processor-readable instructions may be configured to cause at least one processor to retrieve at least one specified clinical scoring configuration from a resource manager communicatively coupled to the at least one processor, implement the at least one specified clinical scoring configuration to control at least a portion of a user interface (UI) for a user application to display at least one user interactive scoring control at the UI, receive a user selection of the at least one user interactive scoring control, capture score inputs based on the user selection, generate one or more score outputs based on the score inputs, control the at least the portion of the UI to display the one or more score outputs, and store the one or more score outputs in a patient encounter file associated with the user application.

[0007] Implementations of such a system may include one or more of the following features. The first processor-readable instructions may be configured to cause the at least one processor to implement the at least one specified clinical scoring configuration to generate a severity index for a respective score output of the one or more score outputs, control the at least the portion of the UI to display the severity index, and store the severity index in the patient encounter file with the respective score output. The severity index may include a display graphic for the respective score output having a color indicative of a relative severity of a patient condition indicated by the respective score output. The first processor-readable instructions may be configured to cause the at least one processor to implement the at least one specified clinical scoring configuration to generate a time stamp for a respective score output of the one or more score outputs, control the at least the portion of the UI to display the time stamp, and store the time stamp in the patient encounter file with the respective score output. The system may include at least one non-transitory, processor-readable storage medium having stored thereon second processor-readable instructions and the second processor-readable instructions may be configured to cause at least one additional processor to provide a clinical score configuration UI, receive user specifications at the clinical score configuration UI for a plurality of configuration fields configured to capture the score inputs, generate the at least one specified clinical score configuration based on the user specifications, and export the at least one specified clinical score configuration to the resource manager. The first processor-readable instructions may be configured to cause the at least one processor to retrieve a plurality of specified clinical scoring configurations from theresource manager, and implement the plurality of specified clinical scoring configurations to control at least the portion of the UI for the user application to display a plurality of user interactive scoring controls at the UI, each user interactive scoring control corresponding to a respective clinical score. The user selection of the at least one user interactive scoring control may be a selection from the plurality of user interactive scoring controls. A first user selection of the at least one user interactive scoring control may cause the at least one processor to generate an initial score output, an initial severity index, and a first associated time stamp and a second user selection of the at least one user interactive scoring control subsequent to the first user selection may cause the at least one processor to generate an updated score output, an updated severity index, and a second associated time stamp, and replace a display of the initial score output, the initial severity index, and the first associated time stamp with a display of the updated score output, the updated severity index, and the second associated time stamp. The at least one score output may include a textual caregiver recommendation for patient treatment. The at least one score output may include a numeric value. The at least one processor may be configured to implement the at least one specified clinical scoring configuration to control at least the portion of the UI for the user application to provide one or more prompts for the score inputs and capture at least a portion of the score inputs from user entries at the UI in response to the one or more prompts. The one or more score outputs may require a plurality of score inputs and the user responses to the one or more prompts may provide all of the plurality of score inputs. The one or more prompts may include at least one of a prompt for user entry of the patient physiologic data or a prompt for user entry of a patient evaluation by a caregiver. The one or more score outputs output may include at least one of a Glasgow Coma Scale (GCS) score, a quick Sequential Organ Failure Assessment (qSOFA) score, a Modified Early Warning (MEWS) score, a National Early Warning (NEWS) score, or a National Early Warning 2 (NEWS2) score. The one or more score outputs may include a stroke score. The stroke score may include at least one of a Los Angeles Motor Scale (LAMS) score, a Functional Assessment Staging Tool (FAST) score, or a Vision Aphasia Neglect (VAN) score. The one or more score outputs may require a plurality of score inputs and the at least one processor may be configured to implement the at least one specified clinical scoring configuration to receive at least a portion of the plurality of score inputs from one or more of at least one medical device or at least one patient charting device communicatively coupled to a device providing the user application. The one or more score outputs may include a trauma score. The trauma score may include at least one of aCompensatory Reserve Index (CRI) score, a Community Resiliency Model (CRM) score, or an Automated Processing of the Physiological Registry for Assessment of Injury Severity (APPRAISE) score. The one or more score outputs may include an Amplitude Spectrum Area (AMSA) score a shock advisory based on the AMSA score. The one or more score outputs may include a cardiopulmonary resuscitation score calculated by an assignment of points to ranges of compression depth, compression rate, ventilation volume, and ventilation rate. The at least one processor may be configured to implement the at least one specified clinical scoring configuration to receive all of the plurality of score inputs from the one or more of the at least one medical device or the at least one patient charting device communicatively coupled to the device providing the user application. The portion of the plurality of score inputs may be a first portion and the at least one processor may be configured to implement the at least one specified clinical scoring configuration to provide one or more prompts for the score inputs at the UI, and capture at least a second portion of the plurality of score inputs from user entries at the UI in response to the one or more prompts. The portion of the plurality of score inputs from the medical device may include physiologic parameters of a patient detected by the at least one medical device. The UI may include a connected devices control configured to identify the one or more of the at least one medical device or the at least one patient charting device communicatively coupled to the device providing the user application. The connected devices control may be configured to provide one or more device selection controls configured to initiate a communicative coupling between the device providing the user application and a medical device or patient charting device corresponding to a respective device selection control of the one or more device selection controls. The at least one processor may be configured to implement the at least one specified clinical scoring configuration to control at least the portion of the UI for the user application to provide at least one guidance request control and, in response to a user selection of the at least one guidance request control, provide score input instructions including one or more of text instructions or graphic instructions. The at least one processor may be configured to apply an analytic operation to at least one score input, generate a derived parameter from the at least one score input based on the analytic operation, and generate the one or more score outputs based on the derived parameter. The analytic operation may include a trend calculation for the at least one score input. The at least one processor may be configured to apply the analytic operation in real-time to the at least one score input based on an event marker automatically generated by a medical device. The at least one processor may be configured tofilter the one or more score outputs based on at least one of a caregiver skill level or a clinical category. The at least one processor may be configured to adjust at least one severity index associated with at least one of the one or more score outputs based on at least one of the caregiver skill level or the clinical category. The at least one processor may be configured to control the at least the portion of the UI to display at least one measured physiological parameter in a graphical form substantially similar to the one or more score outputs. The at least one processor may be configured to control the at least the portion of the UI to display two or more workflow elements in a graphical form substantially similar to the one or more score outputs. The two or more workflow elements correspond to a MARCH (massive hemorrhage, airway, respiratory, circulation, head injury, hypothermia) workflow. The user application may include a patient charting application and the first processor-readable instructions may be configured to cause the at least one processor to integrate the at least one specified clinical scoring configuration with a patient charting UI for the patient charting application. The patient charting application may include a pre-hospital charting application and the patient charting UI may include user entry controls for clinical scoring based on the at least one specified clinical scoring configuration, and dispatch information and the patient charting application may be configured to store the dispatch information in the patient encounter file. The patient charting UI may include user entry controls for clinical scoring based on the at least one specified clinical scoring configuration, and first time- stamped log entries that mark caregiver treatment events that occur during the patient encounter. The patient charting application may be configured to establish a communicative connection with at least one medical device, receive second time- stamped log entries that mark medical device events that occur during the patient encounter, and present during the patient encounter a single consolidated event log via the patient charting UI that may include the one or more score outputs, an associated time stamp, the first time-stamped log entries, and the second time-stamped log entries. The patient charting application may be configured to store the first time-stamped log entries and the second time-stamped log entries in the patient encounter file. The first processor-readable instructions may be configured to cause the at least one processor to integrate the at least one specified clinical scoring configuration with a post-case review application. The post-case review application may be configured to provide a trend report for the one or more score outputs. The first processor-readable instructions may be configured to cause the at least one processor to integrate the at least one specified clinical scoring configuration with patient monitoring application implemented at a computing deviceand the patient monitoring application may be configured to provide a visual representation at a first display of the computing device of at least a portion of patient information provided at a second display at a medical device when the computing device and the medical device may be communicatively coupled. The patient monitoring application may be configured to provide at least a medical device view tab and a warning score tab and the first processor- readable instructions may be configured to cause the at least one processor to display the one or more score outputs in a scrollable list in a first portion of the UI that may be separate from a second portion of the UI that may include one or more physiologic waveforms in response to a selection of the medical device view tab and display the at least one user interactive scoring control in response to a selection of the warning score tab. The first processor- readable instructions may be configured to cause the at least one processor to integrate the at least one specified clinical scoring configuration with therapy delivery device UI. The UI may include a clinical guidance UI configured to provide caregiver guidance based on an encoded clinical guidance protocol that incorporates the at least one specified clinical scoring configuration. The at least one processor may be configured to receive caregiver input from a caregiver and physiologic data from at least one medical device, generate the caregiver guidance based on the caregiver input and the physiologic data, and provide the caregiver guidance with the one or more score outputs.

[0008] An example of a system for generating clinical early warning score configurations for caregiver guidance in a patient encounter may include a clinical score configuration user interface (UI), and at least one non-transitory, processor-readable storage medium having stored thereon first processor-readable instructions. The first processor-readable instructions may be configured to cause at least one first processor to receive a user selection at the clinical score configuration UI of an unspecified clinical score configuration including a plurality of configuration fields configured to capture score inputs via an end-user application device, receive user specifications at the clinical score configuration UI for the plurality of configuration fields, convert the unspecified clinical score configuration to a specified clinical score configuration based on the user specifications, and export the specified clinical score configuration to at least one resource manager. The specified clinical score configuration may include second processor-readable instructions configured to cause at least one second processor at the end-user application device to retrieve the at least one specified clinical scoring configuration from a resource manager, and implement the specified clinical score configuration to control at least a portion of a user application UI to display at least oneuser interactive scoring control at the user application UI, and receive a user selection of the at least one user interactive scoring control, capture the score inputs based the plurality of configuration fields, generate a score output based on the score inputs, control the at least the portion of the user application UI to display the score output, store the score output in a patient encounter file associated with the user application UI, generate a severity index based on the score output, control the at least the portion of the UI to display the score output, the severity index, and an associated time stamp, and store the score output, the severity index, and the associated time stamp in the patient encounter file associated with the user application.

[0009] Implementations of such a system may include one or more of the following features. The second processor-readable instructions may be configured to cause the at least one second processor to implement the specified clinical score configuration to generate a severity index based on the score output, control the at least the portion of the UI to display the severity index, and store the severity index in the patient encounter file with the score output. The second processor-readable instructions may be configured to cause the at least one second processor to implement the specified clinical score configuration to generate a time stamp for the score output, control the at least the portion of the UI to display the time stamp, and store the time stamp in the patient encounter file with the score output. The second processor-readable instructions may be configured to cause the at least one second processor to implement the specified clinical score configuration to generate the score output as a time trend, control the at least the portion of the UI to display the time trend, and store the time trend in the patient encounter file. The second processor-readable instructions may be configured to cause the at least one second processor to implement the specified clinical score configuration to generate the score output based on one or more parameter analytics. The one or more parameter analytics each may include one of a change in a physiologic parameter, a slope of a change of a physiologic parameter over time, an average of a physiologic parameter over time, a maximum value of a physiologic parameter over time, or a minimum value of a physiologic parameter over time. The second processor-readable instructions may be configured to cause the at least one second processor to communicatively couple to a patient charting device, receive patient history information from the patient charting device, and implement the specified clinical score configuration to adjust a score calculation based on the patient history information. The system may include a score configuration fine-tuning GUI, and at least one non-transitory, processor-readable firststorage medium having stored thereon third processor-readable instructions, the third processor-readable instructions being configured to cause at least one third processor to receive a user selection at the score configuration fine-tuning GUI of a specified score configuration including at least one configuration field, receive user selections at the score configuration fine-tuning GUI for the at least one configuration field, convert the specified clinical score configuration to a fine-tuned specified clinical score configuration based on the user selections, and export the fine-tuned specified clinical score configuration to the at least one resource manager. The at least one third processor may be disposed at the end-user application device. The plurality of configuration fields may include parameter fields, question fields, and score range fields. The plurality of configuration fields may include point assignment fields. The plurality of configuration fields may include parameter operations fields configured to define a generated parameter based on a measured physiologic parameter. The parameter operations fields specify one or more of a metric applied to the measured physiologic parameter, a time interval for the metric, and a point assignment for the generated parameter. The plurality of configuration fields may include at least one of a caregiver skill level designation or a clinical category designation. The plurality of configuration fields may include a severity index based on at least one of the caregiver skill level designation or the clinical category designation. The plurality of configuration fields may include configuration fields for at least one measured physiological parameter. The plurality of configuration fields may include configuration fields for steps in a workflow. The plurality of configuration fields may include a workflow grouping configuration field. The plurality of configuration fields may include caregiver guidance fields. The plurality of configuration fields may include at least one browsing control configured to retrieve a caregiver guidance image from a library of the at least one resource manager and the specified clinical score configuration may be configured to cause the at least one second processor to control at least the portion of the user application UI to display the caregiver guidance image. The library may include one of an instructional library, a medication library, a physiological indications library, a medical device library, or a protocol and score configuration library. The plurality of configuration fields may be configured to capture instructions for a caregiver and the specified clinical score configuration may be configured to cause the at least one second processor to control at least the portion of the user application UI to display the instructions for the caregiver. The plurality of configuration fields may include severity index fields. The severity index fields may be configured to capture a userinput of a severity index for a value or range of a clinical score. The severity index may include a color. The plurality of configuration fields may be user editable graphic fields. The at least one resource manager may include at least one of a platform resource manager, a local resource manager, or an agency resource manager. The at least one resource manager may include the platform resource manager and at least one of the local resource manager or the agency resource manager and the local resource manager and the agency resource manager may be configured to synchronize with the platform resource manager. The specified clinical score configuration may be associated with user account information and the at least one first processor may be configured to store the specified clinical score configuration in the at least one resource manager according to the user account information. The first processor-readable instructions may be configured to cause the at least one first processor to provide the specified clinical score configuration to a clinical guidance protocol platform configured to generate an encoded clinical guidance protocol including the specified clinical score configuration and at least one sequencing link between the specified clinical score configuration and one or more protocol blocks. The at least one sequencing link specifies a workflow sequency that may include a calculation of a clinical score. The one or more protocol blocks may include user- specified triggers for the specified clinical score configuration. The one or more protocol blocks may include user-specified caregiver tasks.

[0010] Other capabilities may be provided and not every implementation according to the disclosure must provide any, let alone all, of the capabilities discussed. Further, it may be possible for an effect noted above to be achieved by means other than that noted, and a noted item / technique may not necessarily yield the noted effect.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments. The accompanying drawings have not necessarily been drawn to scale. Any values and / or dimensions illustrated in the accompanying graphs and figures are for illustration purposes only and may or may not represent actual or preferred values or dimensions. Where applicable, some or all features may not be illustrated to assist in the description of underlying features.

[0012] FIG. 1A shows an example of a system for generating and implementing a specified clinical scoring configuration.

[0013] FIG. IB shows an example of a method of generating clinical early warning score guidance.

[0014] FIG. 1C shows an example of a method of generating early warning score guidance for a patient encounter.

[0015] FIG. 2 shows examples of devices and user applications associated with a user application user interface (UI).

[0016] FIG. 3 shows an example of a clinical score configuration UI.

[0017] FIG. 4A shows an example of a parameter specification page for a clinical score configuration UI.

[0018] FIG. 4B shows an example of a parameter specification page for parameter operations and embedded scores.

[0019] FIG. 4C shows an example of a parameter specification page.

[0020] FIG. 5 shows examples of question configuration fields and caregiver guidance specification fields for a clinical score configuration UI.

[0021] FIG. 6 shows an example of a severity index configuration page for a clinical score configuration UI.

[0022] FIG. 7 shows an example of user editable graphic page for a clinical score configuration UI.

[0023] FIG. 8 shows an example of a scoring interface provided at a user application UI.

[0024] FIG. 9A shows examples of scoring prompts for a caregiver.

[0025] FIG. 9B shows examples of scoring inputs from a charting tool and / or a medical device.

[0026] FIG. 10A shows an example of a score configuration window.

[0027] FIG. 10B shows an example of a scoring interface generated by the score configuration window in FIG. 10A.

[0028] FIG. 11 shows examples of medical devices and patient interface devices.

[0029] FIG. 12 shows an example of a mobile device providing a secondary display of a medical device UI with an integrated early warning score interface.

[0030] FIG. 13A shows an example of an early warning score interface integrated with a secondary display application for a medical device.

[0031] FIG. 13B shows another example of an early warning score interface integrated with a secondary display application for a medical device.

[0032] FIG. 14A shows an example of a connected devices window.

[0033] FIG. 14B shows an example of a communications network for a scoring tool implementation engine.

[0034] FIG. 15 shows an example of a scoring interface integrated with a pre-hospital charting application.

[0035] FIG. 16 shows an example of a scoring interface integrated with an event log application installed on a mobile computing device.

[0036] FIG. 17 shows an example of a scoring data provided with a post-case review application.

[0037] FIG. 18A shows an example of a scoring interface integrated into an operational interface of a patient monitor / defibrillator.

[0038] FIG. 18B shows an example of a parameter specification page for a CPR early warning score.

[0039] FIG. 19 shows various examples of export operations for specified clinical score configurations.

[0040] FIG. 20 shows an example of a scoring tool implementation engine implemented within a clinical guidance engine.

[0041] FIG. 21 shows an example of a UI for generating an encoded clinical guidance protocol.

[0042] FIG. 22 shows an example of an encoded clinical guidance protocol with an embedded specified clinical score configuration.

[0043] FIG. 23 shows an example of a system for fine-tuning a specified clinical score configuration.

[0044] FIG. 24 shows an example of a resource manager for an early warning score configuration generation and implementation system.DETAILED DESCRIPTION

[0045] The description set forth below in connection with the appended drawings is intended to be a description of various, illustrative embodiments or implementations of the disclosed subject matter. Specific features and functionalities are described in connection with each illustrative embodiment or implementation; however, it will be apparent to those skilled in the art that the disclosed embodiments and implementations may be practiced without each of those specific features and functionalities.

[0046] Reference throughout the specification to “one embodiment,” “an embodiment,” or “an implementation” means that a particular feature, structure, or characteristic described in connection with an embodiment or implementation is included in at least one embodiment or implementation of the subject matter disclosed. Thus, the appearance of the phrases “in one embodiment” or “in an embodiment” or “in an implementation” in various places throughout the specification is not necessarily referring to the same embodiment or implementation. Further, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments or implementations. Further, it is intended that embodiments and implementations of the disclosed subject matter cover modifications and variations thereof.

[0047] It must be noted that, as used in the specification and the appended claims, the singular forms “a,” “an,” and “the” include plural referents unless the context expressly dictates otherwise. That is, unless expressly specified otherwise, as used herein the words “a,” “an,” “the,” and the like carry the meaning of “one or more.” Additionally, it is to be understood that terms such as “left,” “right,” “top,” “bottom,” “front,” “rear,” “side,” “height,” “length,” “width,” “upper,” “lower,” “interior,” “exterior,” “inner,” “outer,” and the like that may be used herein merely describe points of reference and do not necessarily limit embodiments of the present disclosure to any particular orientation or configuration. Furthermore, terms such as “first,” “second,” “third,” etc., merely identify one of a number of portions, components, steps, operations, functions, and / or points of reference as disclosed herein, and likewise do not necessarily limit embodiments of the present disclosure to any particular configuration or orientation. The terms “workflow” and “protocol” are used interchangeably.

[0048] Furthermore, the terms “approximately,” “about,” “proximate,” “minor variation,” and similar terms generally refer to ranges that include the identified value within a margin of 20%, 10%, or preferably 5% in certain embodiments, and any values there between.

[0049] All of the functionalities described in connection with one embodiment or implementation are intended to be applicable to the additional embodiments and implementations described below except where expressly stated or where the feature or function is incompatible with the additional embodiments and implementations. For example, where a given feature or function is expressly described in connection with one embodiment or implementation but not expressly mentioned in connection with an alternative embodiment or implementation, it should be understood that that feature or function may bedeployed, utilized or implemented in connection with the alternative embodiment or implementation unless the feature or function is incompatible with the alternative embodiment or implementation.

[0050] Aspects of the present disclosure are directed to systems and methods for generating clinical scoring configurations for use in various systems including clinical guidance, patient charting, post-case review, and medical device data displays.

[0051] In general, early warning scores are a clinical tool for evaluating multiple patient indicators as a single metric in order to rapidly identify deteriorations or improvements in a patient’s status. The selection of the patient indicators to include in a score varies between medical facilities, agencies, and practitioners. This selection depends to some extent on factors such as the training of the caregiver, the medical equipment available to the caregiver, the typical patient population for a caregiver, regional standards of care, and implemented medical protocols. Additionally, the meaning attached to a particular score varies as well. In other words, in addition to the parameters constituting a score, there is variation in the thresholds for these parameters with regard to how much weight a particular parameter should receive and the interpretation of the score with respect to a patient state.

[0052] For example, a commonly referred to score is the Modified Early Warning Score (MEWS). Like most scores, MEWS assigns point weights to various physiological indicators to calculate an overall score. The point weights and the included physiological indicators vary extensively. The system described herein enables a medical director to establish a protocol for a score configuration and disseminate that configuration uniformly across an agency or across devices.

[0053] The three tables below show three examples of MEWS score calculations. “AVPU” refers to an assessment of alertness, voice, pain, and unresponsiveness for the patient. As can be seen from these tables, MEWS is not a standard metric. The parameters included vary between these examples as do the ranges of a parameter assigned to a point bucket.

[0054]

[0055]

[0056]

[0057] In some cases, a medical organization may have access to a particular parameter and / or have evidence that a particular parameter is more or less effective at correlating a patient’s condition with the score. For example, for a quick Sequential Organ Failure Assessment (qSOFA), some organizations add a lactate measurement. Some agencies create their own scores for parameters that they find through practice have predictive value, such as, for example, a ratio between saturated oxygen and a fraction of inspired oxygen. The system described herein enables these medical organizations to specify, standardize, automate, and customize their particular preferences regarding included parameters, point values, and score types.

[0058] In order to provide sufficiently adaptable early warning scores, a clinical scoring configuration system may provide a capability for a medical director or other clinicians or medical care providers with limited and minimal knowledge of computer programming, and certainly without any expertise in this field, to readily generate a computer-implemented early warning score tool. As described herein, such a user may manipulate tools on a user- friendly and intuitive graphical user interface (GUI) to design and specify an early warning score configuration. A backend of this user interface (UI) encodes the specified early warning score configuration such that a computer processor can generate, interpret, and provide earlywarning scores according to the specified clinical score configuration in real time during patient care. Such an interface enables the medical personnel to personally design, specify, adjust, and create a computer-implementable early warning score tool without working through a third-party programmer. Without such an interface, medical personnel would have to describe their needs to a programmer and iteratively prototype and test the results in a long, indirect, and relatively expensive process. The system described herein bypasses such a process. A medical expert can arrange and specify their early warning score configuration according to their needs and preferences without working through a third-party computer programming expert. Furthermore, the system described herein enables the early warning score configuration to be automatically tested and validated without trial runs during patient care and enables such a tool to operate with or without network connectivity.

[0059] The system described herein generates clinical guidance protocols specifically designed for use in the medical care situations described above. The encoded early warning score configurations best enhance patient outcomes when such configurations provide instructions and guidance in a manner that may minimize or alleviate caregiver distraction and confusion. The system described herein accomplishes this in part due to a capability to instruct or control medical devices to obtain score inputs without requiring user data entry. For example, the generated configurations may enable information requests from the medical devices, information storage at the medical devices, inventory of available devices, and clinical guidance tailored to specific medical devices available during patient care.

[0060] In general, and in one or more embodiments described herein, the specified clinical score configurations each represent one or more instructions that, once exported, are configured to provide for control of one or more medical devices, for control of one or more clinical guidance UIs, or for control of a combination of one or more medical devices and one or more clinical guidance UIs. The one or more medical devices may provide the scoring interface. In other examples, a computing device may be configured to provide the scoring interface and may be communicatively coupled with the one or more medical devices and / or other computing devices. For example, the specified clinical score configurations may enable one or more information requests from the one or more medical devices such as from one or more sensors or electrodes of the one or more medical devices; information storage at the one or more medical devices; determination of inventory of one or more medical devices or other available devices; displaying guidance and / or feedback to a user of the one or more medical devices; requesting information from a user of the one or more medical devices via thescoring interface; and providing clinical guidance tailored to a specific medical device of the one or more medical devices available during patient care. Accordingly, in one or more examples, the systems for generating and implementing clinical early warning score configurations described herein may be configured to enable the generation of different encoded early warning score configurations based on the user selection, the user specification, and the user indications for the configuration fields and tailored to an intended use-case for the one or more medical devices and / or one or more scoring interfaces that are to be controlled by the exported specified clinical score configuration. Further, in one or more examples, the systems for generating and implementing clinical early warning score guidance described herein may be provided in combination with one or more of a plurality of medical devices, user applications, and / or computing devices configured to receive different exported specified clinical score configurations generated by the system. This may provide an advantage that a medical organization having a fleet of medical devices and / or computing devices may provide and / or update specified score configurations to all or selected portions of the fleet of medical devices and / or computing devices from a central location and thus cause devices to operate according to a uniform care standard as defined by the specified score configurations. Alternatively, this may provide the advantage of enabling centralized control of score configurations customized to a particular environment in which the medical device and / or computing device is located. In either case, the solution provided herein alleviates the risk of lack of adherence to agency or organizational protocols, procedures, and guidelines created when scoring configurations must be loaded or specified at each individual device.

[0061] Referring to FIG. 1A, an example of a system for generating and implementing a specified clinical scoring configuration is shown. A quantity of each component in these figures is an example only and other quantities of each, or any, component could be used.

[0062] The system 100 includes a score configuration engine 110 and a scoring tool implementation engine 135. Other components of the system 100 are illustrated as supporting configuration or implementation. Although illustrated as separate engines herein, in some examples, the score configuration engine 110 and the scoring tool implementation engine 135 may be a single engine that combines the described functions of these two engines.

[0063] The various engines described herein may include hardware logic and / or software logic provided by one or more processors and / or memory to implement logic instructions to perform one or more tasks at one or more computing devices and / or at one or more medicaldevices. In some examples, the actions performed by engines may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, etc., or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the tasks may be stored in a non- transitory processor-readable medium such as a storage medium. Processors may perform the described tasks. In various implementations, the engines described herein may be or may include at least one processor and at least one non-transitory processor-readable storage medium having stored thereon processor-readable instructions configured to cause the at least one processor to perform actions according to the processor-readable instructions. The storage media and / or the processor(s) may be components of a computing device and / or a medical device.

[0064] The score configuration engine 110 includes hardware logic and / or software logic (e.g., as provided by a processor, a memory, and associated circuitry) that enables the score configuration engine 110 to provide and implement a score configuration UI 120 at a display device 103. The score configuration UI 120 enables a user (e.g., the first user 20) to create a graphical representation 122 of a clinical score configuration. The score configuration engine 110 further includes hardware logic and / or software logic that enables the score configuration engine 110 to generate a specified clinical score configuration 125 that encodes the graphical representation 122. The system 100 enables a user-friendly modality for the user of the score configuration UI 120 to edit, change, modify, and rearrange the specified clinical score configuration 125 before storage in a resource manager 130 and subsequent export to or retrieval by clinician devices. Although one encoded clinical guidance protocol is illustrated in FIG. 1A for simplicity, the score configuration engine 110 may generate multiple specified clinical score configurations 125 at the score configuration UI 120.

[0065] The scoring tool implementation engine 135 includes hardware logic and / or software logic (e.g., as provided by a processor, a memory, and associated circuitry) that enables the scoring tool implementation engine 135 to provide and implement a scoring interface 152 within a user application UI 150. The scoring tool implementation engine 135 is communicatively coupled with the resource manager 130 in order to retrieve a specified clinical score configuration 125 for implementation. The scoring interface 152 provides values of configured scores. In an implementation, the scoring interface 152 may provide a severity index for the scores. The severity index serves as an alarm, interpretation, or warning for a user 21 of the scoring interface 152. For example, a background color 105 of a scoreand / or a particular icon, audio signal, or visual effect (e.g., flashing or font size) may indicate the severity index. The severity index may indicate a state of the patient based on the score, such as, for example, a normal state, a borderline state, a warning state, a critical state, etc.

[0066] The scoring tool implementation engine 135 further includes hardware logic and / or software logic (e.g., as provided by a processor, a memory, and associated circuitry) that enables the scoring tool implementation engine 135 to receive and evaluate data from medical devices, provide instructions to medical devices, receive and evaluate caregiver input, and provide caregiver guidance at the user application UI 150, all according to the specified clinical score configuration 125. The specified clinical score configuration 125 is configured to enable the scoring tool implementation engine 135 to implement and / or execute the specified clinical score configuration 125. In other words, the specified clinical score configuration 125 and the scoring tool implementation engine 135 are mutually compatible so as to enable implementation and / or execution of the specified clinical score configuration 125. As an engine configured to implement the specified clinical score configuration 125, the scoring tool implementation engine 135 may function as an interpreter of the specified clinical score configuration 125.

[0067] The scoring tool implementation engine 135 may receive data entry from one or more of several sources in order to determine an early warning score according to the retrieved specified clinical score configuration 125. For example, a user 21 of the UI 150 may provide score input 106a through the user application UI 150.

[0068] As another example, the scoring tool implementation engine 135 may be communicatively coupled to one or more medical device(s) 195 or charting device(s) 190. The scoring tool implementation engine 135 may receive the score input 106b from one or both of the charting device(s) 190 and the medical device(s) 195. The medical device(s) 195 may be one or more of the medical device(s) 1110 shown, for example, in FIG. 11. The medical device(s) 195 may provide data collected via one or more sensors such as, for example, the patient interface devices 1150 shown in FIG. 11.

[0069] In an implementation, the score input 106a and / or 106b (e.g., user entries to the scoring interface 152 and / or data provided to the scoring tool implementation engine 135 by the charting device[s] 190 and / or medical device[s] 195) may provide patient history information. For example, the patient history information may include gender, age, weight, occupation, or other demographics and / or a health history such as, for example, a history of asthma, chronic obstructive pulmonary disease, smoking, illegal drug use, medications,previous injuries or conditions, etc. The specified clinical score configuration 125 may include instructions for the scoring tool implementation engine 135 to automatically adjust score determinations based on one or more items of the patient history information.

[0070] The score input 106b may include physiologic data from the medical device(s) 195. For example, the scoring tool implementation engine 135 may receive the physiologic data from the medical device(s) 195, medical device status information, and / or requests for information from the medical device(s) 195. In an implementation, the scoring tool implementation engine 135 may set prioritization schemes for inputs from the medical device(s) 195. For example, the scoring tool implementation engine 135 may receive a particular type of input from multiple sources. For example, two or more of the patient monitor / defibrillator 1182, the ventilation system 1180, and the SpO2 sensor 1154 equipped with a Bluetooth® sensor may provide an SpO2 measurement to the scoring tool implementation engine 135. Given these two or more inputs, the scoring tool implementation engine 135 may pre-determine a prioritization amongst these sources. This prioritization may be customized based on the specified clinical score configuration 125. Additionally or alternatively, the prioritization may account for real-time relative signal quality between signal sources and / or risk mitigation. In an implementation, the scoring tool implementation engine 135 may select from amongst these signals based on a signal quality assessment and select the highest quality signal (e.g., a high signal / noise ratio, few gaps in the signal, etc.). The scoring tool implementation engine 135 may also prioritize a physiological parameter value based on a signal from a device under closed-loop control rather than from another source. For example, if the scoring tool implementation engine 135 receives an SpO2 signal from both a patient monitor and a ventilation system and is running the ventilation system under closed loop control, then the scoring tool implementation engine 135 may prioritize the SpO2 signal originating from the ventilation system. One example of an advantage of such prioritization is that if there is loss of signal connectivity with the patient monitor, this loss would not affect the control of the ventilation system.

[0071] In an implementation, the scoring tool implementation engine 135 may instruct the medical device(s) 195 to perform a particular process or procedure, provide information for recordation and / or display at the medical device(s) 195, send instructions to record and / or display the information, request particular medical data, etc. The requests for medical data may originate from the specified clinical score configuration 125 implemented by the scoring tool implementation engine 135. For example, a configuration field in a specified clinicalscore configuration 125 may require a value of a particular physiological parameter. In an implementation, the scoring tool implementation engine 135 may recognize this request for a physiological parameter and determine if an appropriate sensor is communicatively coupled (e.g., by evaluating the network 1480 shown in FIG. 14B) and / or if a value of the physiological parameter is available from a patient charting tool (e.g., through a query of the patient charting device[s] 190). If so, the scoring tool implementation engine 135 may automatically obtain the value from the sensor or from a patient record. However, if this value is not available from either of these resources, then the scoring tool implementation engine 135 may generate a UI control at the scoring interface 152 to either prompt the second user 21 to enter the value and / or to connect the appropriate sensor. For example, to obtain a patient’s temperature, the scoring interface 152 may prompt the user to enter a measured temperature, may provide guidance on how to obtain a temperature, and / or or may prompt the user to use a temperature sensor that can communicatively couple to the scoring tool implementation engine 135. As described below, the implemented protocol may include a protocol block that the scoring tool implementation engine 135 may implement to determine if a sensor is coupled or if a manual entry is needed at the scoring interface 152.

[0072] In an implementation, the instructions to the medical device(s) 195 to perform a particular process or procedure may cause the medical device(s) 195 to automatically perform the particular process or procedure. In such an implementation, the instructions may function as a control signal. Instructions sent to the medical device(s) 195 may include instructions to perform an intervention, parameters of the intervention, and / or instructions to record information about an intervention.

[0073] Based on the score input 106a and / or 106b, the scoring tool implementation engine 135 may implement the specified clinical scoring configuration 125 to generate score output 108 (for example, score output 108a). The scoring tool implementation engine 135 may provide the score output 108 to a user application UI 150 for use by the caregiver (e.g., the user 21). In an implementation, the scoring tool implementation engine 135 may provide the score output 108 to user application database 140 for storage in the patient encounter file 145. As illustrated in FIG. 1A, the scoring tool implementation engine 135 may provide the score output 108 to the patient encounter file 145 via a communicative coupling 109 between the scoring tool implementation engine 135 and the user application database 140. Additionally or alternatively, the scoring tool implementation engine 135 may provide the score output 108 to the patient encounter file 145 via the user application providing the user application UI150. Although shown as separate devices in FIG. 1A for clarity, one or more of the charting device(s) 190 and / or the medical device(s) 195 may provide the user application UI 150 and the scoring interface 152. Thus, the communication between the scoring tool implementation engine 135 and one or more of the charting device(s) 190 and the medical device(s) 195 may be bidirectional such that the scoring tool implementation engine 135 can receive score input 106b from these devices and provide these devices with score output 108 and other communications. In an implementation, the medical device(s) 195 may store measured or sensed physiologic data in the patient encounter file 145. The sensed physiologic data may include time stamps.

[0074] The charting device(s) 190 may be a computing device provisioned with a patient charting application. The patient charting application may include one or more of an electronic patient care report (ePCR) application or an electronic medical record (EMR) application. The ePCR application may provide charting tools and records for an EMS agency, and the EMR application may provide charting tools and records for a hospital, physician, and / or another medical practitioner. The ePCR itself may be associated with and include information for a single encounter for a single patient (e.g., only one encounter with EMS) whereas the EMR may be associated multiple encounters with multiple practitioners (e.g., medical visits over a period of weeks, months, or years) for a single patient. The ePCR may exist in an established data format for ambulance-based care organizations which may be a different data format from the EMR. In an implementation, the scoring tool implementation engine 135 may determine whether to prompt a user for input at the user application UI 150 based on the availability of the charting device(s) 190. For example, a scoring configuration may require the age of the patient. The scoring tool implementation engine 135 may determine if this value has been previously entered at the user application UI 150 for the current encounter with the patient or may query the charting device(s) 190 for this information. In an implementation, the scoring tool implementation engine 135 may generate a UI control at the scoring interface 152 to prompt a user for entry of the required information, such as the age, only if such information is otherwise unavailable (e.g., has not been previously entered at the scoring interface 152 and / or is not available from the charting device[s] 190).

[0075] The charting device(s) 190 may send patient charting data provided to the patient charting application to the scoring tool implementation engine 135. For example, the patient charting data may include demographic data (e.g., age, gender, ethnicity, etc.), medicalhistory data (e.g., chronic medical conditions, allergies, medications, etc.), current clinical data (e.g., vital signs, electrocardiograms [ECGs], test results, etc.), and / or current caregiver observations (e.g., pupil dilation, skin color, wound descriptions, cause of injury, etc.).

[0076] Although FIG. 1A shows the score configuration UI 120 at a separate device from the user application UI 150, in some examples, these two interfaces could be provided at a single device. Thus, the first user 20 and the second user 21 may be a same user with the ability to both generate and utilize specified clinical score configurations 125 at a same display device (e.g., the display device 103 or the display device 155).

[0077] Referring to FIG. IB, an example of a method 101 of generating clinical early warning score guidance is shown. The method 101 is, however, an example only and not limiting. The method 101 can be altered, e.g., by having stages added, removed, rearranged, combined, and / or performed concurrently. For example, the score configuration engine 110 may perform the method 101.

[0078] At stage 160, the score configuration engine 110 may provide a clinical score configuration UI, for example, the score configuration UI 120.

[0079] At stage 162, the score configuration engine 110 may receive a user selection at the clinical score configuration UI of an unspecified score configuration including a plurality of configuration fields configured to capture score inputs via an end-user application device.

[0080] Referring to FIG. 3, an example of a clinical score configuration UI is shown. A quantity of each component in this figure is an example only and other quantities of each, or any, component could be used.

[0081] The clinical score configuration UI (such as the score configuration UI 120) may include a first control 33a to open a previously saved clinical score configuration, a second control 33b to locally save a clinical score configuration in progress, a third control 33c to edit a clinical score configuration opened with the first control 33a, a fourth control 33d to generate a new clinical score configuration, a fifth control 33e to export a generated clinical score configuration to a resource manager, and a sixth control 33f to log out of a clinical score configuration generation session.

[0082] The configuration fields for the unspecified score configuration may include one or more of parameter fields, question fields, and score range fields. The clinical score configuration UI 120 may include controls to select and specify these fields. For example, the clinical score configuration UI (such as the score configuration UI 120) may include a parameter selection control 320, a question selection control 330, and / or a severity index 1editing control 340. Additionally, the clinical score configuration UI (such as the score configuration UI 120) may include a user editable score name field 310.

[0083] Referring again to FIG. IB, at stage 164, the score configuration engine 110 may receive user specifications at the clinical score configuration UI for the plurality of configuration fields. The configuration fields are data entry fields for data used to determine an early warning score. For example, the user specifications may define constituent score elements for the score calculation, define features of the score elements such as limits, ranges, input sources, etc., define caregiver guidance associated with the score calculations, define UI features for the scoring interface 152, define severity determination for the score, and define caregiver guidance for responding to the score.

[0084] Referring to FIG. 4A, an example of a parameter specification page for a clinical score configuration UI is shown. A quantity of each component in this figure is an example only and other quantities of each, or any, component could be used.

[0085] In the example of FIG. 4A, a parameter specification page 400 for an early warning score “NewScore” is shown. The score configuration engine 110 may generate this page in response to a selection by the user 20 of the parameter selection control 320.

[0086] In various examples, the parameter specification page 400 may include a clinical category selection menu 499. The clinical category selection menu 499 enables the user 20 to associate a score or parameter with one or more clinical categories. The clinical categories may include trauma, burns, traumatic brain injury (TBI), respiratory, cardiac, etc., to name a few examples. As shown below in FIG. 13B, the scoring interface 152 at the user application UI 150 may enable the user 21 to filter or select scores and / or parameters associated with the clinical categories selected from the clinical category selection menu 499. In an implementation, a severity index and / or interpretation (e.g., as shown in FIG. 4C) associated with a particular score or parameter may vary based on an associated clinical category.

[0087] For example, the severity of a particular physiologic indicator may vary depending on whether the primary concern for the patient is trauma, bums, respiratory, circulatory, etc. Also, the order of care operations may vary and thus determine the severity index with the deadliest physical threats receiving the highest severity index relative to other conditions. Thus, the severity of a particular condition may not be fixed and constant but may vary depending on the underlying sources of injury. For example, for a patient with cardiac arrest but no trauma, the most important initial intervention may be to receive chest compressions in order to maintain blood flow at least until a defibrillation shock restores an effective heartrhythm. However, if there is trauma with possible blood loss, chest compressions may exacerbate the loss of blood. Therefore, the most important initial intervention may be to apply a tourniquet to stop blood loss before beginning chest compressions. This difference in workflow may affect the relative severity of physical indicators of cardiac arrest and blood loss. This may be of particular importance in emergency or military medical care where there may be limited caregivers available (possibly only one or two caregivers and possibly multiple patients) and a relatively chaotic care environment (for example, a scene of a car accident or a battlefield). In these situations, it is of particular importance to minimize caregiver distraction and provide streamlined alerts and guidance dynamically tailored to the patient’s immediate and changing needs, the caregiver skills, and / or the available medical equipment.

[0088] Although shown with the parameter specification page 400 as an example, one or more of the pages 120, 401, 402, 500, 600, and 700 as shown in FIG. 3, FIG. 4B, FIG. 4C, FIG. 5, FIG. 6, and FIG. 7, respectively, may include the clinical category selection menu 499. This association of clinical categories enables a user 21 to quickly and efficiently zero in on scores and / or parameters that are relevant to the particular patient. Such efficiency and reduction of distraction is of particular importance in an emergency environment where seconds or minutes of delay may make a difference between life and death, where the environment is often chaotic, and where there may be a limitation on the number of available personnel.

[0089] The parameter specification page 400 may further include one or more parameter fields. Two parameter fields 420a and 420b are shown in this example. The user 20 may add additional parameter fields with the parameter selection control 320. Alternatively, the user 20 may remove parameter fields with a deletion control 490. For each parameter field, a parameter menu control 405 enables the user 20 to view a scrollable menu (e.g., menus 410a and 410b) of available parameters. In this example, the parameter 420a is “age” and the parameter 420b is “smoker” as selected from the respective scrollable menus.

[0090] The configuration fields in the parameter specification page 400 may include point assignment fields (e.g., fields 450, 452a, 452b). For each parameter, the user 20 may assign scoring point values associated with a condition of the parameter. The condition may be a numerical limit or an existence of the parameter (e.g., as indicated by a true / false designation). Upon implementation of the specified clinical score configuration 125 by the scoring tool implementation engine 135, the scoring tool implementation engine 135 maygenerate a score associated with the configuration 125 based on the assigned points. For example, the scoring tool implementation engine 135 may operate mathematically on the assigned points to calculate the score. The mathematical operation may include arithmetic operations (e.g., addition, subtraction, multiplication, division), statistical operations (e.g., average, standard deviation, etc.), and / or assignment of configurable weights to various parameter elements of the score. In various examples, scoring points may be positive, negative, whole numbers, decimals, or fractions.

[0091] The parameter 420a provides an example of a parameter subject to numerical limits. The user 20 may specify a minimum numerical value for the parameter in a field 430, a maximum numerical value for the parameter in a field 432, parameter units in a field 434, and a display format for the parameter in a field 436. A score range field 440 enables the user 20 to assign scoring point values 450 to various ranges of the parameter as indicated by a lower limit field 442 and an upper limit field 444. The user 20 may add additional ranges with an additional field control 495 and / or remove ranges with a deletion control 490.

[0092] The parameter 420b provides an example of a parameter subject to an existence condition. The user may assign scoring point values 452a and 452b based on the parameter being true 453a or false 453b in regard to the patient. For example, if the patient smokes, the parameter “smoker” is true. As another example, if the patient is not pregnant, the parameter “pregnant” is false.

[0093] Referring to FIG. 4B, an example of a parameter specification page for parameter operations and embedded scores is shown. A quantity of each component in this figure is an example only and other quantities of each, or any, component could be used. In an implementation, the score configuration engine 110 may provide a parameter operations page 401.

[0094] In various examples, the parameter operations page 401 may include a clinical skill selection menu 463. The clinical skill selection menu 463 enables the user 20 to associate a score or parameter with one or more clinical skill categories. The clinical skill categories may include first responder 462a, basic life support (BLS) 462b, advanced life support (ALS) 462c, etc., to name a few examples. As shown below in FIG. 13B, the scoring interface 152 at the user application UI 150 may enable the user 21 to filter or select scores and / or parameters associated with the clinical skill categories selected from the clinical skill selection menu 463. This ability to filter or select scores and / or parameters associated with the clinical skill categories allows the users 20 and 21 to dynamically tailor the scoringinterface 152 and / or the patient status interface 1370 to the particular training and certification level of the user 21. Furthermore, such a filtered interface may reduce distraction and confusion for the user 21 and may enable a faster and more efficient transfer of a patient to a higher level of care.

[0095] The scoring tool implementation engine 135 may provide a filtered interface, such as a first responder filtered interface, a BLS filtered interface, or an ALS filtered interface. These filtered interfaces may filter out score, parameter, and / or workflow tiles that require skills above a particular certification level. Thus, this clinical skill selection menu 463 may also enable the scoring tool implementation engine 135 to limit score, parameter, or workflow element tiles provided at the scoring interface 152 and / or the patient status interface 1370 to tiles that align with the medical devices and / or other equipment that will be available for a particular skill level. For example, a first responder may not be certified to perform intubation or to use an ALS defibrillator (they may be limited to an automated external defibrillator [AED]). Thus, scores that require inputs not available from an AED (for example, pulse oximetry or capnography data) may not be available to the first responder filtered interface. Also, a workflow that requires an intubation may not be available to the first responder filtered interface. Thus, clinical measurements and / or procedures that are beyond the training and certification level of the user 21 may not appear at the scoring interface 152 and / or the scoring interface 152 may provide additional guidance based on the training and certification level. As another example, the scoring tool implementation engine 135 may request caregiver input for a pulse oximetry value from a BLS provider because such a provider may only have access to a manually applied pulse oximetry device and not have access to a patient monitor-defibrillator. However, for an ALS provider, the scoring tool implementation engine 135 may look first, or prioritize, a pulse oximetry signal automatically received at a patient monitor-defibrillator.

[0096] Additionally, these filtered interfaces may add material for a more advanced skill level. For example, instructions may vary so that “opening an airway” may be limited to instructions to tip a patient’s head back and depress the tongue to look for obstruction for a first responder but not include any intubation instructions. However, the same “opening an airway” step may add intubation instructions and scores available for an intubated patient for the ALS provider.

[0097] In an implementation, a severity index associated with a particular score or parameter may vary based on an associated skill level. For example, the severity index for a firstresponder may be more sensitive than for a BLS provider, and may be more sensitive for a BLS provider than for an ALS provider. This may help encourage a first responder to seek additional help more urgently. For example, as soon as the patient status requires a higher level of care than a first responder is able to provide, the severity index may show as “critical” rather than “warning” or “okay” whereas the same state may be only “warning” for the ALS provider because the ALS provider will be able to immediately handle a degradation in the patient state. The variation in severity index may help each level of caregiver efficiently triage patients based on the need, or lack of need, for more advanced care.

[0098] Although shown with the parameter specification page 401 as an example, one or more of the pages 120, 400, 402, 500, 600, and 700 as shown in FIG. 3, FIG. 4A, FIG. 4C, FIG. 5, FIG. 6, and FIG. 7, respectively, may include the clinical skill selection menu 463.

[0099] The parameter operations page 401 further enables a user 20 to specify score parameters generated from an operation applied to a score input by the scoring tool implementation engine 135. The scoring tool implementation engine 135 may apply the analytic operation to the score input to generate a derived parameter and determine the score output based on the derived parameter. For example, the score input may be a physiologic measurement or event. The generated score parameter may be a value derived from or calculated from the physiologic measurement or event. For instance, a generated score parameter may be a duration of an arrythmia or a length of time that an SpO2 measurement has indicated hypoxia. In these examples, the ECG indicating an arrythmia is the physiologic measurement but the duration of the arrythmia is derived from that measurement. Similarly, the SpO2 measurement is the physiologic measurement but the length of time that this measurement is indicative of hypoxia is derived from that measurement. As other examples, the generated score parameter may be a change, or delta, of a parameter over time, a trend slope, and / or a direction of parameter progression. Thus, the score configuration engine 110 may enable a user 20 to configure a score based on a parameter analysis rather than the parameter itself. For example, the parameter analysis may include the change, or delta, in a particular physiologic parameter, a slope of a trend for a particular physiologic parameter, an average over time, a maximum, a minimum, a standard deviation, etc., to name some examples. For instance, a degree of change in blood pressure may be heavily weighted as an indicator of sepsis, and a ratio of heart rate to systolic blood pressure may be weighted (i.e., assigned point values) as a relative measure of hypotension.

[0100] As another example, a degree of change in a computation of amplitude spectrum area (AMSA) may inform a score block that indicates shock recommended or no shock recommended. This shock recommendation score block may supplement the shock evaluation based purely on an ECG. The ECG determines whether an abnormal heart rhythm can be resolved with a defibrillation shock (i.e., a shockable rhythm) or will not be resolved with a defibrillation shock (i.e., a non- shockable rhythm). Ventricular fibrillation (VF) and pulseless ventricular tachycardia (VT) are examples of shockable rhythms. Pulseless electrical activity (PEA) and asystole are examples of non-shockable rhythms. However, AMSA may indicate that even though a shockable rhythm is identified based on the ECG and shock is recommended by a defibrillator algorithm based on the ECG, there may be a more favorable outcome for the patient if the shock is given sooner than indicated by just the ECG analysis or delayed or not delivered in a particular time period. Thus, the shock / no shock score block may supplement a shock indicator based on an ECG that is built into a defibrillator. It is difficult to re-program or customize a defibrillator algorithm to reflect clinical trends, changes, and / or agency preferences in the application of AMSA scoring. However, a supplemental scoring tool as described herein can be readily re-programmed and / or customized to reflect these trends, changes, and agency preferences.

[0101] People undergoing VF can be more receptive to a defibrillating shock in some instances compared to others. For example, research has determined that an indication of whether a shock that is delivered would likely result in successful defibrillation can be obtained using the AMSA computation, or other computational methods that use either timebased or spectrum-based analytic methods to calculate, from an ECG, a prediction of defibrillation shock success. Thus, an AMSA score may determine a likelihood that a defibrillation shock applied to a patient with VF, for example, at a particular time during resuscitative care, will be successful in resolving the fibrillation and restoring a regular heart rhythm.

[0102] Values from a spectral analysis such as AMSA can be used in determining the appropriate treatment therapy for a patient at any given time. However, trends in values output from the spectral analysis can also be used as an additional factor in making the treatment determination. In various examples, changes or trends in spectral frequency (e.g., AMSA, Fast Fourier Transform [FFT]) may be used in evaluating the likelihood that an electrical shock will lead to a successful therapeutic result (e.g., defibrillation). For example, when the AMSA or other frequency-based data is greater than a certain threshold, thepercentage of shock success can be sufficiently high such that a caregiver or medical apparatus can make a decision to administer an electrical shock. Alternatively, for relatively low values of AMSA or other frequency-based data, observed changes in frequency-based data can be a substantial contributor to the overall percentage of shock success. Changes in a spectral frequency of an ECG can provide further information (in addition to the actual values of the spectral frequency analysis), which can beneficially lead to a therapeutic shock at an earlier time, for example, as compared to a case where only the actual values of the spectral frequency are taken into account.

[0103] By using this additional information (e.g., considering changes in the spectral analysis in addition to absolute values output from the analysis) in calculating the probability of shock success, suitable therapeutic intervention(s) (e.g., electric shock in place of cardiopulmonary resuscitation [CPR]) can be administered sooner than later. Such determinations can be used to guide a person (e.g., a physician, emergency medical technician [EMT], or lay rescuer) who is performing rescue operations on the person suffering from VF (also referred to here as a patient or victim). The guidance can include a recommendation that a shock should or should not be provided, or that chest compressions of a particular type should be given instead of a shock. The shock recommendation score may also take into account success or lack of success in prior attempts to defibrillate the person (e.g., where there has been recurrent or refractory VF, that is, where recurrent VF results after a successful prior defibrillating shock and refractory VF results after an unsuccessful prior defibrillating shock), among other factors, such as a current AMSA value for the person and trans-thoracic impedance level of the person. The AMSA value may be a current AMSA value, an AMSA value over a different period of time, a trend in AMSA value over time, a change of AMSA value, a change rate of AMSA value, and / or a myocardial viability indicator for recommending chest compressions or deliverance of a defibrillation shock. AMSA is a value calculated by taking an FFT of the VF waveform. While FFTs are generally premised on an assumption of an infinitely long time series, relatively short time series (e.g., less than 4 seconds or close to 1 second) can be better for predicting a likelihood of defibrillation. Short windows are generally improper for the operation of an FFT but a tapered window, such as a Tukey window, can be used to lessen edge effects from the windowing of ECG data that is collected for performing the AMSA calculation, which can permit the relative benefits of using a smaller window while lessening the dis-benefits of using the smaller window. In an implementation, an AMSA analyzer can be programmed to perform the analysis of the ECG,and perhaps other inputs so as to maximize the predictive value of the AMSA value, whether by affecting inputs to the AMSA determination, and / or by making an AMSA determination and then adjusting the AMSA value that is generated from that determination. As one example, the size of the window from which ECG data is taken in performing the calculation can be set to maximize the predictive value, such as by being about 1 second to about 1.5 seconds long. As another example, the shape of the window can be tapered, such as by being in the form of the Tukey or a Hann window, rather than having vertical edges like a boxcar window. Similarly, coefficients for the window, such as Chi2 and p, can be set to maximize the expected predictive value of the calculation. The AMSA analyzer can also be programmed to change such values dynamically over the course of a particular VF incident, either by moving the values progressively as time elapses so as to make the values match expected values for maximizing the predictive effect of the calculation, or to respond to particular readings, e.g., to use particular window length, form, or coefficients when an AMSA value is in a pre-defined range.

[0104] As one example of using AMSA values to make a determination of the likelihood that a currently-delivered shock will result in successful defibrillation, a threshold AMSA value can be set, at which level the shocking ability of a defibrillator is made available to a rescuer, or at which level a likelihood of success that is displayed to the rescuer can change (e.g., AMSA values between X and Y can show a likelihood of m percent, while AMSA values between Y and Z can show a likelihood value of n percent) based on whether prior successful defibrillating shocks that have been given to a patient have been successful. For example, the relevant AMSA threshold for generating a particular output or action of a defibrillator (such as the display to the user just mentioned) can be adjusted based on determinations about the success of prior shocks and on a trans-thoracic impedance. Thus, for example, an AMSA value or values can be computed from incoming ECG signals from the patient, and decisions can be made by comparing the computed AMSA value to stored thresholds, where the thresholds can change based on other factors, or the AMSA value can be adjusted using other factors and then be compared to thresholds that do not change.

[0105] The parameter operations page 401 shows an example of configuration field entries for parameter operations or analytics. Two parameter fields 420c and 420d are shown in this example. The user 20 may add additional parameter fields with the parameter selection control 320. Alternatively, the user 20 may remove parameter fields with the deletion control490. For each parameter field, the parameter menu control 405 enables the user 20 to view a scrollable menu (e.g., the menus 410a and 410b) of available parameters.

[0106] In this example, the parameter 420c is “heart rate” and the parameter 420d is “SpO2” as selected from the respective scrollable menus. The configuration fields may include an operation, or analytic, specification field 470. This field defines the operation, or metric, applied to the parameter. In the example of FIG. 4B, the user 20 has defined a slope metric such that the score using “Parameter 1” will include as the slope of the heart rate trend over time as a score parameter. A time range configuration field 472 enables a user to define an interval of time relevant to the operation specification field 470. This interval may be based on an event marker configuration field 474 and / or a clock interval configuration field 476. For example, event markers may be time-stamped markers of sub-events during a patient encounter (e.g., connection of a medical device to a patient, medication administration, defibrillation shock administration, onset of arrythmia, beginning and / or end of chest compressions, ventilation administration, onset of a physiologic condition such as hypoxia, elevated body temperature, elevated blood pressure, etc.). These event markers may be entered manually by a caregiver to the medical device(s) 195, the charting device(s) 190, and / or the patient encounter file 145 and / or may be automatically generated and recorded by the medical device(s) 195 and / or the charting device(s) 190. Where the event markers are automatically generated and recorded by the medical device(s) 195 and / or the charting device(s) 190, the time stamps associated with these event markers may not be provided to or accessible by the caregiver during the medical event as they may be part of a voluminous patient encounter file 145. In an implementation, the caregiver may only access these markers in a post-case analysis. Thus, a caregiver may not be able to generate an analytic operation based on an event marker in real time. However, based on communication links between the medical device(s) 195 and / or the charting device(s) 190 and the scoring tool implementation engine 135, the scoring tool implementation engine 135 is able to access and utilize these event markers in real time. In an implementation, the event marker configuration field 474 enables a user to define a parameter metric or operation relative to an event marker (e.g., time since an onset of arrythmia, time with hypoxia, etc.). The clock interval configuration field 476 enables a user to define a parameter metric or operation relative to a clock time or time interval. A range configuration field 441 enables a user to define one or more ranges for the parameter analytic. For example, first points may be applied to a first slope of heart rate change between a first lower limit and first upper limit and second points may be applied to asecond slope of heart rate change between a second lower limit and second upper limit. The resulting score reflects these ranges of slope that are derived from the heart rate measurements themselves. Points 451 are applied to the value derived from the parameter (e.g., the slope of the heart rate over the specified time range) and not the parameter measurement itself.

[0107] As another example, the parameter 420d is “SpO2” (i.e., blood oxygen concentration as determined by pulse oximetry). A metric field 480 indicates the particular metric applied to this parameter subject to an evaluation field 482. In this example, the metric field 480 and the evaluation field 482 together indicate that the scoring tool implementation engine 135 should evaluate the period of time that the parameter “SpO2” is within an evaluated range as specified by the evaluation block 446. Points 452 are assigned in a range configuration field 447 as applied to the metric configuration field 480. In other words, the points 450 apply to the value derived from the parameter (e.g., time that SpO2 indicates hypoxia) and not the parameter measurement itself.

[0108] The parameter operations page 401 represents a capability of the scoring tool implementation engine 135 to determine and provide scores that are prohibitively complex for a caregiver. In an automated, accurate, and repeatable fashion, the scoring tool implementation engine 135 can perform background calculations and operations to generate complex parameter inputs without causing any reduction in time that a caregiver or caregiver team is fully available to a patient. In addition, given that patient care is often occurring over a short time frame of seconds or minutes in an emergency care situation (e.g., cardiac arrest, drug overdose, blunt trauma, etc.), a caregiver cannot collect and analyze data fast enough to generate usable derived metrics as inputs for an early warning score. If these scores are not available in a timely manner relative to a patient’s often rapidly deteriorating condition, they become irrelevant and clinically ineffective.

[0109] As a further example, in an implementation, a previously generated first specified score configuration may be an input to a second specified score configuration. As illustrated in FIG. 4B, the parameter 420e is “score B” as selected from the drop down menu 410c. The drop down menu may include previously generated specified score configurations and / or available patient parameters. In this manner, a previously generated specified score configuration may be embedded into a second score configuration. As shown in the range configuration block 448, a lower limit, upper limit, and point assignment may be specified for the score parameter input in a similar manner to other parameter inputs for scoring. In animplementation, the score configuration engine 110 may retrieve a previously generated score configuration 125 from the resource manager 130 and embed it in a second specified score configuration in order to enable one score to function as an input for another score. Alternatively, the scoring tool implementation engine 135 may retrieve a score from the patient encounter file 145 in response to a parameter request in a specified score configuration 125 to utilize a first score value as an input to a second score calculation or determination.

[0110] Referring to FIG. 4C, an example of a parameter specification page is shown. A quantity of each component in this figure is an example only and other quantities of each, or any, component could be used.

[0111] In addition to constituent parameters of an early warning score, the score configuration UI 120 may additionally provide a parameter specification page 455 to enable configuration of individual parameters and / or of parameter groups. The score blocks of the scoring interface 152 may include scores and / or parameters. The parameters may be individual parameters (such as a heart rate display 1382, as shown in FIG. 13B) and / or may be constituent elements of a workflow (such as the workflow elements 1388a- 1388f, as shown in FIG. 13B). Thus, although referred to herein as a “scoring interface,” the scoring interface 152 may not be limited to providing scores and may include individual parameters and / or workflow groupings in addition to and / or in lieu of scores.

[0112] The user 20 may indicate with a grouping control 461 that one or more parameters and / or scores should appear together at the scoring interface 152. For example, the parameter groups may be one or more parameters that form a common protocol. The scoring interface 152 may provide the one or more parameters as a designated protocol group. In some examples, the score configuration UI 120 may enable configuration of parameter-score groupings so that the scoring interface 152 provides one or more scores and one or more parameters together as a designated protocol group 498. The grouping control 461 may open a protocol grouping menu that enables the user 20 to select previously configured scores and / or parameters and flag them as part of the designated protocol group 498. Although shown with the parameter specification page 402 as an example, one or more of the pages 120, 400, 401, 500, 600, and 700 as shown in FIG. 3, FIG. 4A, FIG. 4B, FIG. 5, FIG. 6, and FIG. 7, respectively, may include the grouping control 461.

[0113] As an example, a designated protocol group 498 may include the MARCH protocol group that may be used in a military clinical setting. “MARCH” is an acronym for Massivehemorrhage, Airway, Respiratory, Circulation, Head injury, and Hypothermia. The MARCH protocol group provides a set of parameters that a medical responder (e.g., the user 21) should look at to evaluate a patient. For example, the parameter page 402 may include a scrollable menu 410c that provides various parameters 497a and / or previously configured scores 497b that the user 20 may select to include in the designated protocol group 498. In the example of FIG. 4C, the user 20 has selected “massive hemorrhage” as a first parameter 456a and “GCS” (Glasgow Coma Score) as a second parameter 456b for the designated protocol group 498. For each selected parameter, or score, the user 20 may indicate one or more ranges 460a, 460b as characterized by a lower limit 442 and an upper limit 444. The user 20 may also designate points and a severity index based on points (e.g., as similarly described in regard to FIG. 6 below) and / or may directly designate a severity index for each respective range. For example, severity index controls 457a and 457b may generate a severity index designation window as described below with regard to FIG. 6 that associates a certain color or other alarm with each severity indication. In an implementation, each range designation may also include a guidance control 459. The guidance control 459 may generate a guidance window (e.g., the guidance window 465a) and / or an interpretation window (e.g., the interpretation window 465b) in which the user 20 may provide guidance, interpretation, or other information associated with a severity index and / or a range for display at the scoring interface 152. The guidance control 459 may be similar to or the same as an add guidance control 530 described below in regard to FIG. 5 and may generate features 535, 540, 543, 546, 550a, and 550n as also described below in regard to FIG. 5.

[0114] Referring to FIG. 5, examples of question configuration fields and caregiver guidance specification fields for a clinical score configuration UI are shown. A quantity of each component in this figure is an example only and other quantities of each, or any, component could be used.

[0115] In the example of FIG. 5, a question configuration page 500 for an early warning score “NewScore” is shown. The score configuration engine 110 may generate this page in response to a selection by the user 20 of the question selection control 330. The question configuration page 500 may include one or more question configuration fields (e.g., fields 510, 520, 523a, 523b, 526a, 526b). The question configuration fields may capture instructions for a caregiver (e.g., the user 21). These fields enable the scoring tool implementation engine 135 to control at least a portion of a user application UI 150 to display or otherwise provide instructions to the caregiver. The user 20 may add additional question fields with the questionselection control 330. Alternatively, the user 20 may remove question fields with the deletion control 490. The question configuration fields may include a title field 510, a question text field 515, and one or more response option fields 520. A particular score may require questions about several different aspects of the patient, and the user 20 may label each aspect in the title field 510. The user may enter the question text in the question text field 515.

[0116] The user 20 may provide one or more response options in the response option fields 520. Each response option field 520 may include a text field (e.g., the fields 523a and 523b) and point assignment fields (e.g., the fields 526a and 526b). The user 20 may add additional response options with the additional field control 495 and / or remove ranges with the deletion control 490.

[0117] Optionally, the score configuration engine 110 may provide guidance configuration controls at any or all of the configuration pages (e.g., pages 400, 500, 600, and / or 700). Here, the guidance configuration control 530 is shown within the question configuration page 500 as an example.

[0118] In response to a selection of the guidance configuration control 530, the score configuration engine 110 may provide one or more guidance configuration fields that enable the scoring tool implementation engine 135 to provide a caregiver with guidance at the scoring interface 152. The guidance configuration fields include one or more of a title field 535, an image selection field 540, and one or more instruction fields 550a-550n. The title field 535 indicates a category of guidance related to a particular question.

[0119] The image selection field 540 enables a user 20 to select one or more images, videos, drawings, etc. The images, videos, drawings, etc. may include graphics and / or texts. In an implementation, these images may provide a link to a live or delayed feed with a person and / or a robot. For example, the link may open a teleconference consultation including voice and / or image data and / or a chat site. Image position controls 546 enable the user 20 to specify a location of the images at the scoring interface 152. Based on this specification, the scoring tool implementation engine 135 may provide the images as foreground images, background images, or in a designated image area such as a window. The window may be a pop-up window, a banner, an insert, etc.

[0120] In an implementation, the image selection field 540 may include at least one browsing control 543. In response to a selection of the browsing control 543, the score configuration engine 110 may retrieve a caregiver guidance image or link from a database. For example, the database may be the resource manager 130. The score configuration engine 110 mayretrieve the image or link from a library of the resource manager 130. The library may include one or more of an instructional library, a medication library, a physiological indications library, a medical device library, or a protocol and score configuration library.

[0121] Referring to FIG. 6, an example of a severity index configuration page for a clinical score configuration UI is shown. A quantity of each component in this figure is an example only and other quantities of each, or any, component could be used.

[0122] In the example of FIG. 6, a severity index configuration page 600 for an early warning score “NewScore” is shown. The score configuration engine 110 may provide this page in response to a selection by the user 20 of the severity index editing control 340. The severity index configuration page 600 allows the user 20 to configure a textual, graphic (e.g., a color, a font, an icon, etc.), and / or audible severity index or return to the parameter page 400 via an edits control 610. The user 20 may add additional severity ranges with the additional field control 495 and / or remove severity ranges with the deletion control 490. The severity index may be indicative of a relative severity of a patient’s condition as indicated by the score output.

[0123] The user 20 may assign a severity index to score ranges between a lower limit 640 and an upper limit 650 for a particular score 310. The severity index may correspond to a caregiver indicator 660 such as a color, an icon, a sound, etc. The scoring tool implementation engine 135 may provide a caregiver indicator at the user application UI 150 with the scoring interface 152. For example, the caregiver indicator may be a color, as represented by shaded circles 662a, 662b, 662c, 662d. When the score is between the lower limit 640 and the upper limit 650, the scoring tool implementation engine 135 may provide the score at the scoring interface 152 in a graphic display that includes the designated color as the background color (e.g., the background color 105 shown in FIG. 1A). In the example of FIG. 6, the user 20 designated a value between x-y as normal and assigned a first color (e.g., the shaded circle 662d). The user 20 designated a value between w-z as critical and assigned a second color (e.g., the shaded circle 662a).

[0124] A score range field 620 enables the user 20 to designate a point score range for the overall score. The point score range depends on the various combinations of parameters and assigned point values. Labeling fields 632 enable the user to assign a nomenclature (e.g., severity name 630) to the severity index associated with a particular selected color. Range fields 642 and 652 enable the user 20 to assign numeric values to the lower limit 640 and upper limit 650.

[0125] In an implementation, the severity index may correspond to a state name 630 such as normal, borderline, warning, critical, etc. If the specified clinical score configuration 125 is incorporated into an encoded clinical guidance protocol 2030 (e.g., as discussed below in regard to FIG. 20), then the state name 630 may provide a parameter to a concurrent and / or subsequent protocol block and enable a decision and / or other protocol action based on the state name 630. For example, in the encoded clinical guidance protocol 2200 shown in FIG. 22, the score calculation block 2152 may assign a state name to the calculated qSOFA score, and then the protocol block 2220 may evaluate that state name in lieu of or in addition to the score itself. As a result, the encoded protocol may, for example, provide one action if the state name is “warning” and another action if the state name is “normal.”

[0126] The page 600 may include one or more graphics editor controls 670. For example, in an implementation, the page 600 may provide a graphics editor control 670 with each instance of a severity range field set. Selection of the graphics editor control 670 may open a set of user editable graphic fields for a clinical score configuration UI as discussed below in regard to FIG. 7.

[0127] Referring to FIG. 7, an example of a user editable graphic field page for a clinical score configuration UI is shown. A quantity of each component in this figure is an example only and other quantities of each, or any, component could be used.

[0128] As shown in FIG. 7, the score configuration engine 110 may provide the configuration fields discussed above as user editable graphic fields, for example, in a graphic field page 700. A back control 790 allows the user 20 to exit the graphic field page 700 and return to the main page 400 or another page of the score configuration UI 120. The user editable graphic fields are configuration fields that enable the score configuration engine 110 to capture the same information as the configuration fields discussed above. The difference between these is the presentation to the user 20. The configuration fields discussed above may appear in a list or other linear format without demonstrating the appearance of the scoring interface 152. In contrast, the graphic field page 700 simulates the appearance of the scoring interface 152 and enables the user 20 to specify the score in a format more similar to the scoring interface 152.

[0129] Thus, each graphic field in FIG. 7 corresponds to a configuration field discussed above. A score name block 710 repeats the score name configuration field 310 and shows how the score name will appear at the scoring interface 152. A score range 720 enables a user to provide the same information as the score range configuration block 620. An edit title field730 corresponds to the field 510 in FIG. 5 and an edit text field 740 corresponds to the field 515 in FIG. 5. Similarly, an edit title field 750 corresponds to the field 535 in FIG. 5 and edit instruction fields 755a and 755b correspond to the fields 550a and 550n in FIG. 5. In an implementation, one or more of the graphic fields shown in FIG. 7 may include suggested or default text or numerical content that the user 20 may edit or accept to specify the clinical score configuration. A parameter field 760 corresponds to the parameter field 420a (or 420b), a points field 770 corresponds to the points field 450, and a range field 780 corresponds to the range configuration 440.

[0130] Returning to FIG. IB, at stage 166, the score configuration engine 110 may generate a specified clinical score configuration 125 based on the user specifications provided in the various configuration interfaces as discussed above. The specified clinical score configuration 125 encodes the user specifications and provides processor-executable instructions for the scoring tool implementation engine 135. The scoring tool implementation engine 135 can implement the specified clinical score configuration 125 to generate the scoring interface 152 within the user application UI 150.

[0131] At stage 168, the score configuration engine 110 may export the specified clinical score configuration to the resource manager 130. In an implementation, the score configuration engine 110 may receive a user selection of the export control 33d (e.g., as shown in FIG. 3) and export the generated scoring configuration.

[0132] The resource manager 130 is configured to be communicatively coupled with the scoring tool implementation engine 135. In an implementation, the specified clinical score configuration 125 may be, for example, a data interchange format file (e.g., a JavaScript Object Notation [JSON] file, a data serialization file, a protocol buffer file, an encrypted binary file, etc.) that the scoring tool implementation engine 135 is configured to interpret and parse in order to provide the user application UI 150 and to perform background tasks in support of and to supplement the user application UI 150. This data interchange format file supports a system that may run without Internet connectivity. As another example, the specified clinical score configuration 125 may be a web application code file (e.g., using a client-side scripting language such as, but not limited to, JavaScript) that enables the scoring tool implementation engine 135 to run as a web application to provide the user application UI 150. As a further example, the specified clinical score configuration 125 may be an executable image file.

[0133] In an implementation, the score configuration engine 110 may validate the specified clinical score configuration 125 prior to export. This validation may occur on an entry-by- entry basis as the user 20 provides user specifications for the various configuration fields. Alternatively or additionally, the score configuration engine 110 may validate the clinical score configuration 125 upon completion. An export request may trigger a validation by the score configuration engine 110. For any user specifications that fail to satisfy validation, the score configuration engine 110 may provide an invalid entry notification and a corrective action. For example, the score configuration engine 110 may provide an error message that provides the notification and the corrective action. The score configuration engine 110 may provide the error message at the score configuration UI 120. In an implementation, the score configuration engine 110 may report one error at a time and then look for an export request to repeat the validation. Alternatively, the score configuration engine 110 may provide a batch report of all errors found during the validation. In an implementation, the score configuration engine 110 may perform validations as possible in real time during generation of the specified clinical score configuration 125. The score configuration engine 110 may provide error messages and may provide corrective actions as the user populates the graphical representation 122. In an implementation, the score configuration engine 110 may provide a GUI control that enables a user to request a validation and report at any time prior to an automated validation at export.

[0134] The score configuration engine 110 may be configured to validate the generated specified clinical score configuration 125 in a variety of ways. For example, the score configuration engine 110 may confirm that a user specification is in a proper format (e.g., numeric format for a numeric parameter rather than a text string). This validation may also flag user specifications that are impossible (e.g., a condition that a patient’s age is less than zero). As a further example, the score configuration engine 110 may confirm that a user specification for a particular protocol block is actionable and physiologically valid. For example, a user specification including an SpO2 value in excess of 100% is not physiologically valid. Therefore, this condition would always fail during scoring configuration implementation. As another example, a protocol block may request medical device data that is unavailable. In an implementation, the resource manager 130 may include various libraries (e.g., as shown in FIG. 24) and the score configuration engine 110 may reference these libraries during validation. For example, the score configuration engine 110 may validate the generated specified clinical score configuration 125 based on validationinformation retrieved from one or more of an instructional library, a medication library, a physiological indications library, a medical device library, a protocol library, or a user account information library. The validation information may be information that the score configuration engine 110 retrieves from the respective library to use as a comparison with user specifications. If the retrieved information contradicts or conflicts with the protocol, then the score configuration engine 110 validation process may generate an error message or a corrective action. For example, if the user specification provides a drug dosage, a sequence of medical steps, medical equipment instructions, user account information, etc. in a protocol and this information conflicts with the library information, then the score configuration engine 110 validation process may generate the error message.

[0135] In an implementation, the score configuration engine 110 may invoke the resource manager 130 to confirm that the medical device(s) 195 provided for in a score parameter that is pulling data directly from the medical device(s) 195 is available to the user 20 of the scoring configuration 125 (e.g., based on account and / or agency identification information). The validation may include a check that the demographics, such as age, gender, and / or medical history as evidenced by data from the patient charting device(s) 190 allow for use of particular equipment. The validation may further evaluate geographical guidelines, such as legal guidelines regarding the use of equipment and / or procedures (e.g., based on account and / or agency identification information). In an implementation, the score configuration engine 110 may recommend that the scoring configuration 125 include time-based options for repeating a score calculation and / or for providing various scoring data.

[0136] If the specified clinical score configuration 125 is embedded in a larger protocol (e.g., as described below with regard to FIGS. 20-22), the validation may also include a test that a sequencing link provides for a sequence of protocol blocks that include a score configuration 125 where the sequence indicated is actionable and physiologically valid. For example, the score configuration engine 110 may verify that a subsequent protocol block does not indicate an action in the scoring configuration 125 that is contradictory to and / or precluded by a preceding protocol block. As yet another example, the score configuration engine 110 may inspect the specified clinical score configuration 125 for self-consistency. Such selfconsistency validation may flag contradictory conditions and / or settings between prior and subsequent steps within the score calculation. For example, if a score configuration is initiated based on a patient being a pediatric patient, a step within the calculation would beflagged as invalid if a user specification required that the age of the patient be greater than eighty years of age.

[0137] Referring to FIG. 1C, an example of a method of generating early warning score guidance for a patient encounter is shown. The method 102 is, however, an example only and not limiting. The method 102 can be altered, e.g., by having stages added, removed, rearranged, combined, and / or performed concurrently. For example, the scoring tool implementation engine 135 may perform the method 102.

[0138] At stage 170, the scoring tool implementation engine 135 may retrieve at least one specified clinical scoring configuration 125 from the resource manager 130.

[0139] At stage 172, the scoring tool implementation engine 135 may implement the at least one specified clinical scoring configuration 125 to control at least a portion of the UI for a user application. In various examples, and as discussed below in regard to FIG. 2 and FIGS. 11-17, the user application may be a patient charting application, a post-case review application, a secondary display application, or a clinical guidance application. As a further example, and as discussed below in regard to FIG. 2 and FIG. 18, the user application may be an application that generates a UI for a therapy delivery device.

[0140] At stage 174, the scoring tool implementation engine 135 may display at least one user interactive scoring control at the UI. At stage 176, the scoring tool implementation engine 135 may receive a user selection of the at least one user interactive scoring control. The scoring tool implementation engine 135 may control a portion of the UI for a user application to provide the scoring interface 152. The scoring interface 152 may include the at least one user interactive scoring control.

[0141] Referring to FIG. 8, an example of a scoring interface provided at a user application UI is shown. A quantity of each component in this figure is an example only and other quantities of each, or any, component could be used.

[0142] A device 155 may provide the user application UI 150 and implement the user application associated with the user application UI 150. The user application may invoke or include the instructions implemented by the scoring tool implementation engine 135 so that the scoring interface 152 is incorporated into and displayed as a part of the user application UI 150.

[0143] With regard to the device 155, this device 155 may include a mobile computing device, a medical device, and / or another UI device such as, for example, but not limited to, an audio device, a haptic devices, a virtual reality device, and / or an augmented reality device.A display on the device 155 may provide UI controls and information as directed by the scoring tool implementation engine 135 according to the specified clinical score configuration 125. For example, UI controls and information may include caregiver entry prompts, caregiver instructions, alerts, etc. Additionally, the scoring tool implementation engine 135 may implement portions of the specified clinical score configuration 125 as background tasks without generating UI controls or information. For example, the background tasks may include receiving and evaluating data from the charting device(s) 190 and / or the one or more medical device(s) 195 coupled to the patient. In this manner, the scoring tool implementation engine 135 may minimize or alleviate caregiver distraction and confusion and limit the UI controls or information to that necessary for user data entry or user guidance.

[0144] The scoring interface 800 provides an example of the scoring interface 152. The scoring interface 800 includes an early warning score control 810. In an implementation, a user application (e.g., the applications discussed below in regard to FIG. 2) may include the early warning score control 810. Selection of this control 810 by the user 21 may cause the user application to display the scoring interface 152. Alternatively or additionally, the user application may automatically display the scoring interface 152 based on an instruction from the scoring tool implementation engine 135 but without providing the early warning score control 810 and / or without a selection of the early warning score control 810 by the user 21.

[0145] To generate the scoring interface 800, the scoring tool implementation engine 135 may retrieve multiple specified clinical scoring configurations 125 from the resource manager 130. Each specified clinical scoring configuration 125 may provide instructions for displaying and generating a particular clinical scoring block.

[0146] Early warning score display blocks 820a, 820b, 820c, 820d, 820e, and 820f provide examples of the presentation of early warning score information at the scoring interface 152. However, these are examples only and other scores, other quantities of scores, and other graphical arrangements and presentations of the scores are within the scope of the disclosure. Each display block may include a user interactive scoring control 830. Selection of this control by the user 21 may cause the scoring tool implementation engine 135 to provide score input prompts and / or retrieve data from the charting device(s) 190 or medical device(s) 195 according to a specified clinical score configuration 125 corresponding to the score block. For example, selection of the scoring control 830 in the block 820a will cause the scoring tool implementation engine 135 to provide score input prompts according to the specified clinicalscore configuration 125 for Glasgow Coma Score (GCS). Initially, and prior to receiving score inputs from any of the user 21, the medical device(s) 195, and / or the charting device(s) 190, the score block will appear as shown in the block 820e. Each block includes a score value window (e.g., one of windows 840a, 840b, 840c, 840d, 840e, and 840f) and a time stamp window (e.g., one of windows 850a, 850b, 850c, 850d, 850e, and 850f). As shown in the block 820e, both the score value window 840e and the time stamp window 850e are initially blank or populated with placeholder icons indicating a lack of a score for that block.

[0147] In an implementation, the scoring tool implementation engine 135 may provide prompts and / or retrieve score input from the charting device(s) 190 or medical device(s) 195 automatically without a user selection of the scoring control 830. For example, if the specified clinical score configuration 125 is incorporated into an encoded clinical guidance protocol 2030 (e.g., as discussed below in regard to FIG. 20), the encoded clinical guidance protocol 2030 may include a protocol block that triggers a score generation without a user selection of the scoring control 830.

[0148] Referring again to FIG. 1C, at stage 178, the scoring tool implementation engine 135 may provide at least one prompt for score inputs. At stage 180, the scoring tool implementation engine 135 may capture score inputs. The score inputs may include a user entry in response to the at least one prompt as described below with regard to FIG. 9A. Additionally or alternatively, the score inputs may include inputs from the charting device(s) 190 and / or medical device(s) 195 as described below with regard to FIG. 9B.

[0149] Referring to FIG. 9A, examples of scoring prompts for a caregiver are shown. A quantity of each component in this figure is an example only and other quantities of each, or any, component could be used.

[0150] A system 900 in FIG. 9A shows an example of the scoring tool implementation engine 135 generating a score based on score inputs from user entries at the scoring interface 152 in response to the prompts. A scoring block 910 for MEWS is an example of a scoring block prior to score inputs to the scoring tool implementation engine 135. Here, the score value window 840b and the time stamp window 850b are populated with placeholder icons indicating a lack of MEWS calculation. In response to a user selection of the user interactive scoring control 830, the scoring tool implementation engine 135 provides the scoring interface 152. Fields 930 provide an example of user prompts provided at the scoring interface 152 according to the specified clinical score configuration 125 for MEWS. The user may enter information (e.g., values and a multiple-choice selection) in response to theprompts. In an implementation, the scoring tool implementation engine 135 may capture all of the score inputs from user responses to prompts or may capture a portion of the score inputs from user responses. The prompts for user entries may be prompts for patient physiologic data (e.g., data measured by a sensor such as temperature, heart rate, respiratory rate, etc.) and / or prompts for patient evaluation data. The patient evaluation data may be caregiver observations such as level of consciousness, skin color, pupil dilation, location of wounds, mental state, etc.

[0151] Alternatively, at the stage 178 in FIG. 1C, in addition to or in lieu of user entries, the scoring tool implementation engine may receive all or a portion of the score inputs from one or more of the charting device(s) 190 or medical device(s) 195.

[0152] Referring to FIG. 9B, examples of scoring inputs from a charting tool and / or medical device are shown. A quantity of each component in this figure is an example only and other quantities of each, or any, component could be used. As shown in a system 950, for calculation of MEWS, data inputs for temperature, heart rate (HR), respiratory rate (RR), and non-invasive blood pressure (NIBP) from the charting device(s) 190 and / or the medical device(s) 195 replace the user entries for these values. The level of consciousness multiple choice prompt shown in FIG. 9B provides an example of the user entries 930. In some examples, the score input from the charting device(s) 190 and / or the medical device(s) 195 may occur automatically without requiring any user intervention. In some cases, one or more medical device(s) 195 may provide all score inputs without any user prompted entries. The AMSA calculation is an example of a score calculated based on score inputs from a medical device 195.

[0153] Referring again to FIG. 1C, at stage 182, the scoring tool implementation engine 135 may generate a score output 108a based on the score inputs (e.g., the score inputs 106a and 106b). Once the scoring tool implementation engine 135 has the score inputs required by the specified clinical score configuration 125, scoring tool implementation engine 135 may implement instructions in the specified clinical score configuration 125 to generate the score output.

[0154] At stage 184, the scoring tool implementation engine 135 may control at least the portion of the user application UI 150 to display the score output 108a and an associated time stamp. As illustrated in the examples of FIGS. 9 A and 9B, a scoring block 920 for MEWS shows the scoring block 910 subsequent to score generation by the scoring tool implementation engine 135. Here, the score value window 840b and the time stamp window850b are populated, respectively, with the result of the MEWS calculation and a time stamp for this calculation.

[0155] In addition to the score value and time stamp, the scoring tool implementation engine 135 may generate a severity index, and the scoring block 920 may display the severity index. In an example, the severity index may be a background color of the scoring block 920 according to the specified clinical score configuration 125. As shown in FIG. 6, the specified clinical score configuration 125 may include a user specification of the severity index.

[0156] In various examples, the scoring tool implementation engine 135 may repeat a score generation. For example, the user 21 may select the scoring control 830 a first time to generate a particular score, and / or the scoring tool implementation engine 135 may automatically generate a particular score. This first generation may produce an initial score output which may include an initial severity index and / or a first or initial associated time stamp. If the user selects the scoring control 830 a second, third, or other subsequent time and / or the scoring tool implementation engine 135 automatically generates the particular score a second, third, or other subsequent time, this subsequent generation may produce an updated or second score output which may include an updated or second severity index and / or an updated or a second time stamp. The scoring tool implementation engine 135 may store one or more second or subsequent score outputs, severity indices, and / or time stamps in the patient encounter file 145.

[0157] As shown in FIG. 8, the scoring tool implementation engine provides the scores as numeric values or textual information. For example, the GCS in the block 820a, the MEWS in the block 820b, the AMSA score in the block 820c, and the qSOFA score in the block 820d all provide examples of scores represented as a numeric value score output from a score calculation based on the point assignment fields shown in FIGS. 4, 5, 6, and 7. Other examples of scores include, but are not limited to, a National Early Warning (NEWS) score, a National Early Warning 2 (NEWS2) score, a trauma score, such as a Compensatory Reserve Index (CRI) score, a Community Resiliency Model (CRM) score, or a hemorrhage risk score such as an Automated Processing of the Physiological Registry for Assessment of Injury Severity (APPRAISE) score.

[0158] The score examples listed above have some inputs that are typically used. However, as the examples in Tables 1-3 above demonstrate, there is significant variability in the inputs and the evaluation of those inputs. Thus, the scoring tool described herein enables the customization and personalization of these scores so that they are not limited to those inputsfound in published examples of these scores. For example, the MEWS score inputs may be respiratory rate, oxygen saturation, temperature, systolic blood pressure, pulse rate, and AVPU in an instance shown in Table 1. Moreover, in another example as shown in Table 2, the inputs may further include urine output and, as a third example as shown in Table 3, the inputs may further include alertness and fraction inspired oxygen but exclude AVPU. Thus, although certain references may define and describe a “MEWS” score, this is not a singular score with a singular definition for at least the purposes of this disclosure. Regardless of the particular inputs, the MEWS score is used to quickly evaluate a patient’s physiological state based on relatively easily available vital signs. However, within that consistent purpose, the particulars of the MEWS score can be as varied as the number of practitioners, agencies, or medical facilities utilizing such a score to evaluate patients. The scoring tool described herein enables each practitioner, agency, or medical facility to define, distribute, and centrally manage their particular version of a score. The other scores mentioned herein (e.g., GCS, qSOFA, AMSA, NEWS, NEWS2, CRI, CRM, APPRAISE, etc.) are provided only as examples to demonstrate that the scoring tool is compatible with customizing and defining the particulars of a wide range of scores used for clinical evaluations and is not limited to those examples. The scoring tool can implement any score defined, specified, and configured by a user of the score configuration engine 110, whether that score is a variation of a recognized score (e.g., such as a MEWS score variation) or a completely new and custom score.

[0159] The shock advisory block 820f provides an example of an early warning score output provided as text. Here, the early warning score functions, and may be referred to, as an early warning advisory. The score output for this block is a textual caregiver recommendation for patient treatment. Thus, a specified clinical score configuration 125 for this type of score may be referred to as a specified clinical advisory configuration. The shock advisory provides a text instruction derived from a numerical score. For example, the AMSA calculation is an example of a score from which a shock advisory may be derived. Additionally, AMSA is calculated based on score inputs from a medical device 195 without user input.

[0160] One common way to treat VF is through the use of an electrical defibrillator that delivers a relatively high voltage shock to the heart in order to force it back to a normal, consistent, and strong rhythm. People undergoing VF may be more receptive to a defibrillating shock in some instances compared to others. For example, research has determined that AMSA, or other computational methods that use either time-based orspectrum-based analytic methods on ECG data to calculate a prediction of defibrillation shock success, may indicate whether a shock that is delivered to a person will likely result in successful defibrillation or will instead likely fail. Often the calculation of AMSA involves complex computation like an FFT, which is not a calculation that is possible in real time during the treatment of a patient without a computer processor. In general, evaluation of AMSA values and AMSA value trends during treatment of cardiac arrest enables a caregiver to tailor the intervention to a particular patient state rather than applying a global standard of care for the intervention that cannot take into account the patient state.

[0161] The response to an AMSA score with regard to a shock decision varies across medical agencies and medical equipment. For example, in some cases, if an AMSA value is less than 4.5 mVHz, the shock recommendation is to delay an application of a shock. In other cases, the shock recommendation depends on multiple factors such as the current AMSA value, the change in AMSA over a particular period of time, and the AMSA slope. Because the AMSA evaluation provides information to a practitioner that may be different with regard to shock delivery than the shock recommendation coded into a defibrillator, the scoring tool provides a way for a medical director to apply and adjust guidelines across an organization without altering the defibrillator software or hardware. For example, with a scoring tool implementation engine 135 on a secondary display for a defibrillator, the caregiver may receive shock delivery guidance that differs from and overrides the recommendation of the defibrillator device itself where the defibrillator may not evaluate AMSA.

[0162] Evaluating AMSA during clinical guidance for chest compressions, ventilation, and defibrillation in response to cardiac arrest enables delivery of a shock only when the likelihood exceeds some clinically determined threshold value at which the benefit of likely defibrillation outweighs the dis-benefits of harming the patient. Trends in the AMSA values may also indicate the state of a victim over the course of a VF episode. The general phases of cardiac arrest or VF may be identified, in one representation, as three separate phases (though there may be some overlap at the edges of the phases): electrical, circulatory, and metabolic. The electrical phase includes the first several minutes of an event and marks a period during which electric shock can be particularly effective in defibrillating the victim's heart and returning the victim to a relative satisfactory condition. The circulatory phase appears to mark a decrease in effectiveness for electric shock in defibrillating the victim, particularly in the absence of chest compressions performed on the victim. As a result, the appropriate clinical guidance may be to stop advising shocks during such a phase (or to advise a shock only whenother determinations indicate that a shock would be particularly likely to be effective) and instead to advise forceful CPR chest compressions. Such forceful compressions may maximize blood flow through the heart tissue and other parts of the body so as to extend the time that the victim may survive without lasting or substantial damage. In the metabolic phase, chest compressions may be relatively ineffective as compared to the circulatory phase. For example, where tissue has become ischemic, such as in the circulatory phase, the tissue may react favorably to the circulation of blood containing some oxygen, but where tissue has become severely ischemic, such as in the metabolic phase, the introduction of too much oxygen may be harmful to the tissue. As a result, more gentle compressions for a first period, such as 30 seconds, may need to be advised in the metabolic phase before compressions are provided with full force. Other treatments that may be useful in the metabolic phase include extracorporeal circulation and cooling either alone or in combination with each other or in combination with other pharmacological treatments. In any event, observation of elapsed time since an event has begun, and / or observation of the phase in which a victim is in, may be used to control a device or instruct a rescuer to switch from a first mode of providing care to a second mode of providing care in which the parameters of the provided care differ (e.g., speed or depth of chest compressions may change, temperature-based therapy may be provided or stopped, or pharmaceuticals may be administered).

[0163] Referring again to FIG. 1C, at stage 186, the scoring tool implementation engine 135 may store the score output 108a and the associated time stamp in the patient encounter file 145 associated with the user application as shown in FIG. 1A. The scoring tool implementation engine 135 may be communicatively coupled to the user application database 140. Alternatively or additionally, the user application may receive the score output 108 from the scoring tool implementation engine 135 and store the score output 108 in the patient encounter file 145 along with other data gathered by the user application for the patient encounter. In an implementation, the scoring tool implementation engine 135 may store the severity index with the score output 108 in the patient encounter file 145. In an implementation, the scoring tool implementation engine 135 may store one or more of the score outputs 108, the time stamp, or the severity index at the resource manager 130.

[0164] In some examples, the display device 155 may provide all or a portion of the user application UI 150. In some examples, other devices, such as audio, haptic, augmented reality, and / or virtual reality devices, and / or combinations thereof including combinations with a display device, may provide the user application UI 150. In an implementation, thedisplay device 155 may be a mobile device such as, for example, a computer tablet or a smartphone. In an implementation, at least one of the medical device(s) 195 may include a display screen (e.g., a display screen 1810 shown in FIG. 18A) that provides the user application UI 150.

[0165] The user of the score configuration UI 120 (e.g., the first user 20) may be, for example, a medical device equipment manufacturer or a medical protocol governing body that may generate the specified clinical score configuration 125 for use by a caregiver. In contrast, the user (e.g., the second user 21) of the user application UI 150 may be a caregiver for whom the user application UI 150 provides real-time clinical guidance during a patient encounter. The protocol generation may occur in a different time and / or place than the protocol utilization and, therefore, the user 20 of the score configuration UI 120 may not be the user 21 of the user application UI 150 and vice versa. The protocol must be generated prior to being implemented by the scoring tool implementation engine 135 and the protocol generation process does not occur in real time during a patient encounter.

[0166] Referring to FIG. 10A, an example of a score configuration window is shown. A quantity of each component in this figure is an example only and other quantities of each, or any, component could be used.

[0167] A score configuration window 1000 is an example of the question configuration page 500 for a Los Angeles Motor Scale (LAMS) score used to evaluate stroke. In this example, fields 1010a and 1010b provide examples of the title field 510. Field 1010a addresses the facial droop component of LAMS and field 1010b addresses the arm drift component of LAMS. As indicated by the ellipses, the user 20 may specify additional LAMS components not shown in FIG. 10A. A question text field 1015 is an example of the question text field 515. Response options 1020 are examples of the response options 520 and assign various numbers of points to each of the response options 1020. For example, an indication of “no facial symmetry” as provided in a text field 1023a corresponds to 10 points as shown in a point assignment field 1026a and an indication of “partial or complete droop” in a text field 1023b corresponds to 20 points as shown in a point assignment field 1026b.

[0168] The caregiver guidance provides for assistance with facial droop evaluation as shown in a title field 1035. An image selection field 1040 provides an example of the image selection field 540. In this example, the user has selected an image file “facialdroop.pdf” from materials available at the resource manager 130. The image position controls 546 indicate a selection of a designated image area. Instruction fields 1050a, 1050b, and 1050cprovide a list of instructions for the caregiver in order to evaluate facial droop and are examples of the instruction fields 550a to 550n.

[0169] Referring to FIG. 10B, an example of a scoring interface generated by the score configuration window 1000 in FIG. 10A is shown. A quantity of each component in these figures is an example only and other quantities of each, or any, component could be used.

[0170] A system 1090 illustrates an example of a scoring interface 1092 generated by the scoring tool implementation engine 135 based on the score configuration window 1000. The scoring interface 1092 is an example of the scoring interface 152. The scoring interface 152 may alternate between a display of the scoring blocks and a display of the user input fields and / or caregiver guidance. Alternatively, the scoring interface 152 may provide scoring blocks in a first portion of the display and provide user input fields and / or caregiver guidance in a second portion. A score display block 1060 illustrates the block appearance prior to score determination with placeholder icons in a score value window 1062 and a time stamp window 1064. Additionally, a background 1068 of the score display block 1060 lacks any color indicative of the severity index. In contrast, a score block 1070 illustrates the block appearance after score determination. A score value window 1072 includes a numerical score and a time stamp window 1074 includes a time stamp. Additionally, a background 1078 of the score block 1070 includes shading representing a color indicative of the severity index.

[0171] A scoring interface 1092 includes a representation 1080 of the title field 1010a, a representation 1082 of the question text field 1015, and representations 1084 and 1086 of the response options 1023a and 1023b. In this example, the user 21 of the interface 1092 has selected “partial or complete droop” as indicated by a selection button 1087. The response option fields 1020 generate instructions for the scoring tool implementation engine 135 to provide selection buttons for each response option. The scoring interface 1092 further includes a guidance request control 1096. In response to a selection of the guidance request control 1096, the scoring tool implementation engine 135 provides graphic contents 1088 of the image selection file “facialdroop.pdf” indicated in the image selection field 1040.Additionally, in response to the selection of the guidance request control 1096, the scoring tool implementation engine 135 provides an instruction set 1094 as provided in the instruction fields 1050a, 1050b, and 1050c. An arrow 1098 indicates that once the user 21 has selected the selection button 1087 based on the observations of the patient along with the provided guidance, the scoring tool implementation engine 135 will move to the next question 1010b as provided in the score configuration window 1000.

[0172] Referring to FIG. 2, examples of devices and user applications associated with the user application UI are shown. A quantity of each component in these figures is an example only and other quantities of each, or any, component could be used.

[0173] As illustrated in FIG. 2, the user application UI 150 that provides the scoring interface 152 may be a patient charting UI 150a, a post-case review UI 150b, a secondary display UI 150c, a clinical guidance UI 150d, and / or a therapy delivery device UI 250. Detailed examples of these interfaces are discussed below in regard to FIGS. 12-18 and FIG. 20. Notably, in the case of the patient charting UI 150a, the charting device(s) 190 and the display device 155 shown in FIG. 1A are a same device. Similarly, in the case of the therapy delivery device UI 250, the medical device(s) 195 and the display device 155 shown in FIG. 1A are a same device. In an implementation, the user application may be a patient charting application that generates the patient charting UI 150a. Examples of the patient charting UI 150a are shown in FIGS. 15 and 16. In an implementation, the user application may be a post-case review application that generates the post-case review UI 150b. An example of the post-case review UI 150b is shown in FIG. 17. In an implementation, the user application may be a secondary display application that generates the secondary display UI 150c. An example of the secondary display UI 150c is discussed with regard to FIGS. 12, 13A, 13B, 14A, and 14B. In an implementation, the user application may be a clinical guidance application that generates the clinical guidance UI 150d. An example of the clinical guidance UI 150d is shown in FIG. 20. In an implementation, the user application may be an application that generates a therapy delivery device UI 250. An example of the therapy delivery device UI 250 is shown in FIG. 18. In various examples, the scoring tool implementation engine 135 may provide the scoring interface 152 at the therapy delivery device UI 250, and the secondary display UI 150d may receive score information from a therapy delivery device. Alternatively, the scoring tool implementation engine 135 may provide the scoring interface 152 at the secondary display UI 150d, and the therapy delivery device UI 250 may receive score information from a secondary display device. Additionally or alternatively, the scoring tool implementation engine 135 may provide the scoring interface 152 at both the secondary display UI 150d and the therapy delivery device UI 250.

[0174] The scoring tool implementation engine 135 may control at least a portion of a respective UI to display the score output. Further, the scoring tool implementation engine 135 may store the score output in the patient encounter file 145 associated with the respective UI. The UI 150a, 150b, 150c, 150d, and / or 250 may generate the patient encounter file 145 thatincludes some or all of the data provided at the corresponding UI. The scoring tool implementation engine 135 may store the score output in the same patient encounter file 145 as the rest of the data from the corresponding UI.

[0175] Referring to FIG. 11, examples of medical devices and patient interface devices are shown. A quantity of each component in FIG. 11 is an example only and other quantities of each, or any, component could be used. Medical device(s) 1110 may include a ventilation system 1180, a patient monitor / defibrillator 1182, and / or a trauma kit 1184. Patient interface devices 1150 may be coupled to a patient 1195 attended by a caregiver 1190. The patient interface devices 1150 may include one or more sensors, intervention or treatment delivery devices, and / or medical supplies. For example, the patient interface devices 1150 may include one or more of a compression sensor 1151 (e.g., a motion and / or force sensor configured to detect chest compressions), a drug delivery device 1152, an SpO2 sensor 1154, a CO2 sensor 1156, a non-invasive blood pressure (NIBP) sensor 1158, electrodes 1160, an airway pressure sensor 1162, a pneumotachometer 1164, a temperature sensor 1166, an invasive blood pressure (IBP) sensor 1168, an intubation tube 1170, a mask 1172, a nasal cannula 1174, and / or a spirometer 1176. The electrodes 1160 may sense the heart rate and the electrical activity of the victim’s heart and / or may deliver electrotherapy (e.g., defibrillation shock and / or pacing) to the patient 1195. The electrodes 1160 may include 12-lead electrodes.

[0176] Referring to FIG. 12, an example of a mobile device providing a secondary display of a medical device UI with an integrated early warning score interface is shown. A quantity of each component in these figures is an example only and other quantities of each, or any, component could be used.

[0177] In an example, a caregiver may deploy one or more medical device(s) 195, for example, a patient monitor / defibrillator, to treat a patient. The one or more medical device(s) 195 may include a display screen configured to display medical device data in real time for the care of the patient. This display screen may be the operational interface for the medical device(s) 195 as the caregiver may control the medical device(s) 195 from this operational interface. Additionally, the medical device(s) 195 may be communicatively coupled with a mobile device 1200 such as a tablet or smartphone. In an implementation, the mobile device 1200 may provide one or more medical device view windows. For example, in response to a selection of a medical device view tab 1210, the mobile device 1200 may display windows 1230 and 1240. These windows 1230, 1240 provide a real-time display of at least a portion ofa plurality of physiological parameters in a visual reproduction of a display format provided on a respective medical device 195 at the operational interface of that respective medical device 195. The mobile device 1200 may receive at least a portion of the physiologic data measured or sensed from a patient during a patient encounter. This physiologic data may include one or more physiological parameters. These physiological parameters may include, but not limited to, for example, waveforms (e.g., one or more ECG waveforms 1235a, a pulse oximetry waveform 1235b, an end tidal CO2 waveform 1235c, etc.) and discrete data (e.g., a heart rate 1245a, end tidal CO2 1245b, pulse oximetry 1245c, etc.). A clinical scoring configuration 125 may specify the use of at least one of these physiological parameters in the calculation or configuration of a score. In an implementation, the secondary display may be a mobile device display on the mobile device 1200, such as a tablet or a smartphone. The mobile device 1200 and the medical device(s) 195 may have a singular relationship such that during the patient encounter, the mobile device 1200 is communicatively coupled to only one medical device 195. The mobile device 1200 may be communicatively coupled to other computing devices but to only one medical device 195 configured to sense patient data and / or provide therapy to the patient.

[0178] This operational interface on the secondary display allows additional medical team members to participate in patient treatment without having to be immediately proximate to the medical treatment device. For example, a rescue team supervisor who oversees and coordinates patient treatment during a critical patient care event (e.g., chest pain, cardiac arrest, traumatic brain injury [TBI], RD, or critical care monitoring) can view, in real time, the same waveforms and patient data displayed at the medical treatment device. This allows supervisors or other medical team members to observe both rescuer treatment actions and patient data simultaneously so that the supervisors can provide recommendations to further enhance patient treatment and coordinate treatment by multiple rescuers. In some examples, the operational interface displays a visual reproduction of case information displayed at the medical treatment device.

[0179] The scoring tool implementation engine 135 may integrate at least one specified clinical scoring configuration 125 with the patient monitoring application providing the representation of the operational interface. This integration may cause the scoring tool implementation engine 135 to display one or more score outputs in a first portion 1250 of the operational interface that is separate from one or more second portions (e.g., 1230 and 1240) of the operational interface that includes the physiologic data in response to a selection of themedical device view tab 1210. In an implementation, the score outputs may be provided with a scroll tab 1270 to expand the amount of data available on the mobile device screen. A selection of the early warning score tab 1220 may transition the secondary display to a scoring interface 152.

[0180] Referring to FIG. 13 A, an example of an early warning score interface integrated with a secondary display application for a medical device is shown. A quantity of each component in these figures is an example only and other quantities of each, or any, component could be used.

[0181] Upon selection of the early warning score tab 1220, the scoring tool implementation engine 135 may cause the mobile device 1200 to provide the scoring interface 152. A scoring interface 1352 shown in FIG. 13A is an example of the scoring interface 152. In this example, scoring blocks 1310 and 1320 include a score name, a score value, a time stamp, and a background color severity index. Additionally, the scoring interface 1352 provides an example of the scoring blocks 1310, 1320 in a first portion of the secondary display and user input fields and / or caregiver guidance in a second portion 1360. This scoring interface 1352 may further include user interactive scoring controls 830 to trigger score calculations.

[0182] Referring to FIG. 13B, another example of an early warning score interface integrated with a secondary display application for a medical device is shown. A quantity of each component in these figures is an example only and other quantities of each, or any, component could be used.

[0183] In addition to or as an alternative to an early warning score interface 152 or 1352, the scoring tool implementation engine 135 may provide any or all of the information described herein as associated with the early warning score interface 152 or 1352 as a patient status interface 1370. The patient status interface 1370 may include one or more individual parameters 1382, one or more parameter groupings 1374, early warning scores 1376, a skill filter 1383, a clinical category filter 1384, an interpretation and guidance window 1378, and / or a parameter entry window 1380. The user 20 may configure one or more of these features at the score configuration UI 120 as described above at least in regard to FIGS. 4A, 4B, and 4C. Each block provided may include a recalculation or refresh control 1386 configured to recalculate a score or parameter, request user input, and / or provide a reminder or other instructions to a caregiver in response to a selection of the control 1386.

[0184] In addition to or as an alternative to the early warning score tab 1220 described above, the operational interface at the mobile device 1200 may include a patient status tab 1372.Upon selection of the patient status tab 1372, the scoring tool implementation engine 135 may cause the mobile device 1200 to provide the patient status interface 1370. The patient status interface 1370 shown in FIG. 13B is another example of the scoring interface 152. In this example, the tiles for the parameter grouping 1374, the early warning scores 1376, and / or the individual parameters 1382 include a score name or parameter name, a score value or parameter value, a background color severity index, and, optionally, a time stamp. The time stamp is not illustrated in FIG. 13B for simplicity but may be implemented as described herein, for example, in regard to FIG. 13 A.

[0185] In an implementation, tiles of patient status interface 1370 may include scores, as exemplified by the tile for the early warning scores 1376. Alternatively or additionally, tiles of the patient status interface 1370 may include individual measured or sensed parameters, such as, for example, the individual parameter tile 1382 shown in FIG. 13B as a heart rate. The scoring tool implementation engine 135 may receive an individually measured or sensed parameter value automatically from a communicatively coupled medical device 195. Additionally or alternatively, the scoring tool implementation engine 135 may request entry from the user 21, for example, with the parameter entry window 1380. In an implementation, the scoring tool implementation engine 135 may receive or retrieve parameter data from an electronic patient care record being populated in a same patient encounter.

[0186] In an implementation, tiles of the patient status interface 1370 may include a parameter grouping 1374. The parameter grouping 1374 may include calculated scores, measured or sensed parameters, and / or workflow element tiles such as, for example, workflow element tiles 1388a, 1388b, 1388c, 1388d, 1388e, and 1388f . In the example of FIG. 13B, the workflow tiles correspond to elements of a “MARCH” protocol as configured at the score configuration UI 120. However, this is an example only, and other workflows are within the scope of the disclosure. Other examples include an “ABC” workflow (airway, breathing, circulation), an “AVPU” workflow (alert, verbal, painful, unresponsive), or another workflow configuration according to a customization for a particular agency. In an implementation, in response to the selection of a control 1387 for a workflow tile, the scoring tool implementation engine 135 may provide guidance and / or interpretation notes in the interpretation and guidance window 1378 corresponding to the workflow tile and the measured parameters associated with that workflow tile. In the example shown in FIG. 13B, the guidance and interpretation block 1378 includes notes relevant to the circulationworkflow element tile 1388d. The user 20 may specify the guidance and / or interpretation notes, for example, in the blocks 465a, 465b as shown in FIG. 4C.

[0187] The user 21 may select one or more of the skill filter 1383 and the clinical category filter 1384 to filter the displayed tiles to those designated for a particular skill level and / or clinical category by the user 20 as discussed above in regard to the clinical category selection menu 499 shown in 4A and the clinical skill selection menu 463 shown in FIG. 4B. The clinical category filter 1384 may act as quick action buttons or softkeys that tailor offerings at the patient status interface 1470 to one or more clinical categories selected from the filter menu 1384. In an implementation, the caregiver may select two or more conditions from the clinical category filter 1384 based on a state of the patient. The relationship between two or more conditions may cause the scoring tool implementation engine 135 to provide a different interface than for any of the conditions on their own. For example, as discussed above, a cardiac arrest response may be different with and without accompanying trauma. As yet another example, the transport of a patient may be different with or without a potential spine injury (where without such an injury the transport may be faster and without a backboard than with the potential spine injury). The scoring tool implementation engine 135 may implement a specified clinical score configuration 125 to dynamically adjust the tiles provided at the patient status interface 1370 according to configuration customization instructions from the user 20 at the score configuration UI 120 in response to the skill filter and / or clinical category filter selections at the skill filterl 383 and / or clinical category filter 1384. Additionally or alternatively, the scoring tool implementation engine 135 may dynamically adjust severity index determinations, medical device data sources, guidance, and / or interpretations in response to the skill filter and / or clinical category filter selections at the skill filter 1383 and / or clinical category filter 1384.

[0188] As shown in FIGS. 12, 13 A, and 13B, the secondary display may include a connected devices window 1260. The connected devices window 1260 is discussed in detail with regard to FIGS. 14A and 14B.

[0189] Referring to FIG. 14A, an example of a connected devices window is shown. A quantity of each component in these figures is an example only and other quantities of each, or any, component could be used.

[0190] The connected devices window 1260 is an example of the connected devices window 1420 shown in FIG. 14A. Although the connected devices window 1260 is shown with the secondary display application, one or more of the charting device(s) 190 shown in FIGS. 15and 16 and / or the medical device(s) 195shown in FIG. 18A may also include the connected devices window 1420 or an equivalent control configured to provide an equivalent function. In an implementation, a primary device (e.g., a medical device and / or computing device) having the connected devices window functionality may be coupled with one or more additional devices (e.g., medical devices and / or computing devices). The primary device may include the user application integrated with the scoring tool implementation engine 135. The connected devices window 1420 may enable control and / or tracking of the various device connections between the primary device and the one or more additional devices. These connected devices may automatically provide score input to the scoring tool implementation engine 135. The specified clinical score configuration 125 may include instructions for the scoring tool implementation engine 135 to retrieve score input values from the connected devices. The score configuration UI 120 may allow the user 20 to define a score that uses score input data that is available from another communicatively coupled device. Additionally or alternatively, where a specified clinical score configuration 125 is embedded in an encoded clinical guidance protocol 2030 (as discussed with regard to FIG. 20), the encoded clinical guidance protocol 2030 may include a protocol block to trigger an automatic collection of score input from a communicatively coupled device.

[0191] The connected devices window 1420 may include a device status window 1422, a device search control 1426, and / or a device verification control 1424. The device status window 1422 may display an amount of battery life, connection status, and a unique name for each of the additional devices. A paired device verification input selector of the device verification control 1424 may enable the primary device to cause an indicator to flash and / or sound at the one or more additional devices to confirm and identify a connection.

[0192] In certain embodiments, the primary device and additional devices may be configured to detect that they are within communication range of one another and automatically initiate a communications link. This may be of use to caregivers because rather than requiring a user to potentially spend significant amounts of time in manually configuring the system of each device or accessing a screen to view and then select from possible device connections, device(s) located at the emergency scene may be pre-configured to dynamically join and / or leave a secure network.

[0193] For example, the mobile device 1200 may provide a user selectable list of preconfigured wireless communication links that are available for the mobile device to connect to peripheral devices (e.g., medical device[s] 195 and / or 1110 and / or charting device[s] 190).The user can also view other available networks that have not been pre-configured for connection. In some examples, the mobile device 1200 may be pre-configured for pairing to other medical treatment devices, and those pre-configured networks can also be displayed on the mobile device 1200. The connected devices window 1420 may display the connected devices.

[0194] In an implementation, the connected devices window 1420 may provide manual device connection controls. For example, a selection of the device search control 1426 by the caregiver, or another control provided by the connected devices window 1420, may cause the primary device to show a connected devices menu 1485 that shows the currently connected devices and provides an add control 1484. Selection of the add control 1484 may generate a menu 1488 of available devices. Each item in the menu 1488 may include a selection control 1489. The caregiver may manually select one or more of the available medical devices in the menu 1488. The menu 1488 may include one or more of the medical equipment, medical supplies, and computing resources (which may include one or more mobile computing devices). Once the caregiver has completed their selection, the primary device will be communicatively coupled with the selected devices.

[0195] Referring to FIG. 14B, an example of a communications network for the scoring tool implementation engine is shown. A quantity of each component in FIG. 14B is an example only and other quantities of each, or any, component could be used. In an implementation, one or more of the ventilation system 1180, the patient monitor / defibrillator 1182, and the trauma kit 1184 may be communicatively coupled to one another as part of a network 1480. These medical devices are examples only and other types of medical devices may join the network 1480. Additionally or alternatively, one or more of the ventilation system 1180, the patient monitor / defibrillator 1182, and the trauma kit 1184 may be communicatively coupled to one or more of the secondary display 1200, the charting device(s) 190 and the scoring tool implementation engine 135. As such, the various devices and the engine shown in FIG. 14B may share resources such as UI, data management, external communication, processing of diagnostic / treatment algorithms, and / or processing and / or provision of various physiological signals. The communicative couplings in FIG. 14B may be wired and / or wireless communications links. The various devices and the engine shown in FIG. 14B may include and / or be coupled to a network interface configured to be coupled to the network 1480 which may be a local network, a wide area network, or a combination thereof. For example, the network interface may enable a short-range wireless network (e.g., a personal area connection[PAN] connection, such as a BLUETOOTH connection, or a local area network [LAN] connection, such as a WIFI connection) and / or a long-range wireless connection (e.g., a wide area network [WAN] connection, such as a Code-division Multiple Access [CDMA] connection or Global System for Mobile Communication [GSM] connection). The network may include a cellular network and / or a computer network such as the Internet. In an implementation, the devices and engine may be pre-configured to be communicatively coupled together so as to streamline wireless communication pairing without having to undergo a time-consuming inquiry and response negotiation for a secure connection to be established. The various devices and the engine shown in FIG. 1480 are local devices (i.e., devices located in proximity to a caregiver and a patient) as opposed to remote devices such as a cloud server (e.g., a cloud server 1970 shown in FIG. 19), a hospital server, or an EMS agency server (e.g., an agency server 1995 shown in FIG. 19).

[0196] In an implementation, the network 1480 may include an edge server 1498. The edge server 1498 may be a computing device configured to execute processor intensive operations that are sometimes involved when executing operations of the scoring tool implementation engine 135 and / or a clinical guidance engine 2010 shown in FIG. 20. In an implementation, the edge server 1498 may include the scoring tool implementation engine 135 and a local resource manager 1930 shown in FIG. 19. Some implementations of the edge server 1498 include, for example, one or more GPUs that are capable of efficiently executing matrix operations and substantial cache or other high-speed memory to service the GPUs. In some examples, the edge server 1498 is a separate, ruggedized physical device that travels with EMS personnel in the field. In some examples, the edge server 1498 is incorporated into other EMS field equipment such as a medical device and / or may be located in the EMS vehicle and / or may be located within a carrying case for a medical device. In an implementation, the display device 155 may provide the edge server 1498 if the processing capability of the display device 155 is sufficient to provide computing services associated with an external edge server 1498. The edge server 1498 moves more computing capability into the local environment so that the computation intensive clinical guidance can run accurately and efficiently even in the absence of a connection with a remote server.

[0197] Referring to FIG. 15, an example of a scoring interface integrated with a pre-hospital charting application is shown. A quantity of each component in FIG. 15 is an example only and other quantities of each, or any, component could be used.

[0198] A patient charting application may be a pre-hospital charting application for a mobile device 1500 that includes user entry control for clinical scoring based on at least one specified clinical scoring configuration 125, dispatch information, and clinical records for the patient encounter. The pre-hospital charting application may be an ePCR. The patient charting application or the scoring tool implementation engine 135 may store the clinical scoring results in the patient encounter file 145. Additionally, the patient charting application may store the dispatch information and the clinical records in the patient encounter file 145 with the clinical scoring results.

[0199] To provide a complete and accurate record of each encounter that includes patient and encounter information and provides comprehensive and adapted caregiver guidance, as described above, an EMS caregiver may complete an ePCR. ePCRs include data fields configured to store a comprehensive set of patient and encounter information according to a schema that controls the structure of the data provided to the digital record. In some examples, the schema may be a multi-agency standard that provides a compliance architecture to allow transfer of data and data interoperability between individual agency systems and enables entry of data in a centralized database. An example of such a standard is the National Emergency Medical Services Information Standard (NEMSIS) for emergency care medical record data collection. Additionally, the schema may utilize standardized data formatting that enables communication between medical record systems. For example, the HL7®FHIR® (Health Level Seven Fast Healthcare Interoperability Resources) standard defines how healthcare information can be exchanged between different computer systems such as those servicing emergency care and those servicing hospitals. Other examples of standards include, but are not limited to, an HL7 version 2, version 3, or CDA standard, an Electronic Data Interchange (EDI) Healthcare including, 270, 271, 276, 277, 278, 820, 834, 835, 837P and 8371 standards, a SNOMED CT standard, a diagnosis classification ICD standard, and procedure code HCPCS and CPT standards.

[0200] In certain examples, the ePCR may include an EMS digital assistant 1520 configured to recognize and respond to human language communications. In these examples, the EMS digital assistant 1520 can execute a variety of helpful operations without requiring the caregiver’s attention - e.g., by detecting, recognizing, and acting on human language communications that naturally occur within a patient encounter. In addition, in situations where an EMS caregiver opts to interact with the EMS digital assistant directly, such interactions can be carried out verbally and without the need to manually navigate one ormore UI screens, thereby increasing efficiency. Thus, the natural language processing features of the EMS digital assistant 1520 allow the EMS caregiver to complete the ePCR as a record of a patient interaction while maintaining focus on patient treatment rather than device interaction. The EMS digital assistant 1520 may enable voice activation of the scoring control 830.

[0201] The organizational structure of the ePCR may include data field sections organized according to medical procedure categories and / or medical condition categories. The data field sections may include one or more of a timeline 1515 for vital signs and interventions, a dispatch section 1501, a patient demographic section 1503, a patient assessment section 1507 (e.g., vital signs, interventions, a chief complaint, injury details, a narrative, etc.), a billing and insurance section 1505, and an early warning score section 1509.

[0202] The dispatch section may include transportation details regarding the medical staff, the staffing level (e.g., basic life support, advanced life support, paramedics, emergency medical technicians, etc.), shift information, dispatch priority (e.g., lights and sirens or quiet approach), a designation of scheduled or unscheduled transport. An ePCR requires transport information as a pre-hospital record unlike, for example, a hospital care record or code event log, which does not include any transport information. Examples of trip information in the dispatch section 1501 include EMS unit information (e.g., assigned personnel and staffing levels indicative of training, such as BLS or ALS), shift information, dispatch priority such as an indication that lights and sirens were deployed, and a type of service (e.g., scheduled, emergency, unscheduled, patient care, non-patient care, etc.) provided by the dispatched unit.

[0203] The ePCR may further include the early warning score section 1509 based on an integration of the scoring tool implementation engine 135 with the ePCR application.Selection of this section 1509 may generate a scoring interface 1552. Although shown in this example with scoring blocks only, the scoring interface 1552 may additionally provide user entry prompts, for example, in a manner similar to that shown in an interface 1652 in FIG. 16.

[0204] The ePCR application may store all logged data from the patient encounter in the patient encounter file 145. Additionally, the ePCR application and / or the scoring tool implementation engine 135 may store the clinical scoring results in the patient encounter file 145 with the remainder of the logged data from the patient encounter. Thus, the patient encounter file 145 for the ePCR application may include the dispatch information along with clinical storing information generated by the scoring tool implementation engine 135.

[0205] Referring to FIG. 16, an example of a scoring interface integrated with an event log application installed on a mobile computing device is shown. A quantity of each component in FIG. 16 is an example only and other quantities of each, or any, component could be used.

[0206] Within the context of a hospital, a code blue refers to an event in which a patient has suffered cardiopulmonary arrest and requires immediate treatment. Many hospitals staff code teams whose responsibility is to respond to a code blue by rushing to the patient and running an advanced cardiac life support code focused on the patient. Each of the individuals who make up the code team is a highly skilled healthcare provider, and each typically has a specific role to play during the code. Given that timeliness and accuracy of diagnosis and intervention are of the essence to achieve a successful outcome in response to the code blue, code teams work with a high degree of speed and urgency. Unfortunately, the complex UIs provided by electronic hospital record endpoints are often not well suited to match the speed and urgency with which code teams work and further are not conducive to accurate diagnosis, treatment, or recording of diagnosis and treatment information.

[0207] In many cases, a rapid response team (RRT), also known as a medical emergency team (MET), medical emergency response team (MERT), and high acuity response team (HART), may utilize the event log application. This is a team of healthcare providers that responds to hospitalized patients with either early signs of deterioration or an elevated risk of a medical premonitory event (MPE) to prevent respiratory or cardiac arrest. The healthcare providers are trained in respiratory therapy, early resuscitation interventions, and advanced life support and may include a physician, nurse, pharmacist, or respiratory therapist. The RRT, MET, MERT, HART, or critical care outreach team (CCOT) are all different forms of the response component of a rapid response system. As is the case with code teams, electronic hospital record interfaces are often ill-suited for use by RRTs to acquire accurate diagnosis and treatment information.

[0208] A patient charting application may be an event log application configured to provide a set of UI screens that are tailored to easily, quickly, conveniently, and accurately record events and sometimes determine additional event details encountered during the emergency medical treatment. These UI screens can be provided, for example, via a touchscreen of a mobile computing device executing the event log application. In some examples, the event log application is configured to provide UI screens including controls (e.g., controls 1610a, 1610b, 1610c, 1610d, 1610e, 1610f, 1610g, 1610h, 1610i shown, for example, in FIG. 16) that are labeled and associated with events commonly encountered during emergency medicaltreatment. For instance, events such as administration of CPR, epinephrine (EPI), and / or electrotherapeutic shocks are commonly encountered while running a code blue. Examples directed toward documenting a code blue have controls dedicated to recording these events. Many of these processes culminate in the storage of a date / time- stamped entry in the patient encounter file 145 that documents occurrences of specific events in an event log. The event log, in turn, documents the treatment provided to a patient and / or events that have occurred during the course of patient care. Rapid response or emergency medical teams are called upon to provide urgent medical care to deteriorating patients in order to prevent cardiopulmonary arrests from occurring.

[0209] In an implementation, the UI screen may include an early warning score control 16 lOi. Selection of this control 16 lOi may enable the scoring tool implementation engine 135 integrated with an event log application charting tool to provide a scoring interface 1652. The scoring interface 1652 may include user input prompts 1620 and / or scoring blocks (e.g., scoring blocks 1630a and 1630b).

[0210] The event log application may include user entry controls for clinical scoring based on at least one specified clinical scoring configuration 125. Additionally, the event log application may provide user entry controls for time- stamped log entries that mark caregiver treatment events occuring during the patient encounter. Furthermore, the event log application may be communicatively coupled with at least one medical device 195 and receive time- stamped log entries that mark medical device events occuring during the patient encounter. These events may include an administration of a defibrillation shock. The event log application may generate a single consolidated event log that includes the score outputs, the associated time stamp, the time-stamped log entries that mark caregiver treatment events, and the time-stamped log entries that mark medical device events.

[0211] In some examples, to further ease treatment documentation in specific situations, the event log application is configured to provide controls that enable a healthcare provider to change the documentation mode of the event log application to either an adult mode 1640 or a pediatric mode 1650. While operating in the adult mode 1640, the event log application alters features of certain screens and controls to facilitate entries that mark events directed to events encountered when treating an adult. For instance, controls associated and labeled with approaches to CPR that are only available to adults are visible only while the event log application is operating in the adult mode 1640. Conversely, while operating in the pediatric mode 1650, the event log application alters features of certain screens and controls tofacilitate entries that mark events directed to events encountered when treating a child. For instance, controls associated with approaches to CPR that are only available to children are visible only while the event log application is operating in the pediatric mode 1650. As another example, the scoring tool implementation engine 135 may retrieve and / or implement specified clinical score configurations 125 based on the pediatric mode 1650 or adult mode 1640. Further, the specified clinical score configuration 125 may include instructions so that the scoring tool implementation engine 135 validates entries and determines severity indices based on the pediatric mode 1650 or adult mode 1640.

[0212] An expanded code log 1660 may include a log list of early warning scores (“EWS”) 1665 in addition to a log list of clinical events. Selection of the expansion control 1666 may enable a user (e.g., the user 20 or user 21) to view granular details of the warning score calculations, guidance, etc.

[0213] Referring to FIG. 17, an example of scoring data provided with a post-case review application is shown. A quantity of each component in FIG. 17 is an example only and other quantities of each, or any, component could be used.

[0214] A post-case review application may enable a review of data gathered about a patient during an encounter and, in particular, a review of CPR metrics. CPR metrics may include metrics regarding chest compressions, ventilations, and / or defibrillation shocks. Not all patients treated for a cardiac event with chest compressions and ventilation receive defibrillation shocks as the efficacy of a shock depends on the electrical state of the patient’s heart as a result of the cardiac event. A post-case review application may provide statistical metrics for data recorded in the patient encounter file 145 for CPR and for clinical scoring.

[0215] As shown in FIG. 17, the post-case review application may provide the clinical scoring as a trend report 1710. Any or all of the scores provided at the scoring interface 152 and stored in the patient encounter file 145 may be provided in the trend report 1710. The scoring tool implementation engine 135 may store each instance of the score calculation with a time stamp and thus enable a post-case review application to generate the trend report 1710. For score calculations repeated over the course of a patient encounter, the trend report 1710 may be a useful tool for determining the effect of other data in the patient encounter file 145 on the scores and may provide a tool for adjusting score components or calculations to better reflect a patient’s state and trajectory. The post-case review application may utilize the time stamps saved with the score calculations to align the scores in time with other events in the patient encounter. For example, FIG. 17 shows a defibrillation shock icon 1720 and agranular graph of compression rate 1730. Additionally, the post-case review application may include data filters 1750 and statistical summaries 1740 regarding compressions, ventilations, and timing of these relative to shocks.

[0216] Together, the filters 1750 and statistical summaries 1740 provide a CPR performance trend report 1710 that may be organized according to various temporal intervals. In some examples, the CPR performance trend report 1710 including the scoring trend information may be for one patient while, in some examples, these metrics may be aggregated over multiple patient encounters. This may permit a quality assurance person or other user to observe whether certain CPR performance metrics and protocols for early warning scores are being met over particular periods of time or across certain sets of cases (e.g. cases filtered by a criteria), and / or to see trends in CPR performance and scoring metrics over time.

[0217] Referring to FIG. 18 A, an example of a scoring interface integrated into an operational interface of a patient monitor / defibrillator is shown. A quantity of each component in FIG. 18A is an example only and other quantities of each, or any, component could be used.

[0218] A medical device 1800 shown in FIG. 18A as a patient monitor / defibrillator 1182 is an example only. In various implementations, the medical device 1800 may be a defibrillator, patient monitor, defibrillator / monitor, an automated compression device, a therapeutic cooling device, an extracorporeal membrane oxygenation (ECMO) device, a ventilation device 1180, a trauma kit 1184, combinations thereof, or another type of medical device configured to be coupled to one or more therapy delivery components to provide therapy to the patient. In an implementation, the medical device 1800 may be an integrated therapy delivery / monitoring device that includes a single housing 1805. The single housing 1805 may surround, at least in part, the therapy delivery components and the monitoring components. In an implementation, the medical device 1800 may be a modular therapy delivery / monitoring device with therapy components in a first housing and monitoring components in a second housing.

[0219] The medical device 1800 may include one or more output or input / output devices, for example, a display screen 1810. The display screen 1810 may provide an operational interface for the medical device 1800. The operational interface may provide patient data received by the medical device 1800 from the patient interface device(s) 1815 (e.g., therapy delivery component[s] and / or sensor[s] such as those shown in FIG. 11). The operational interface may provide the patient data in real time as the signals are received and processedby the medical device 1800. The medical device 1800 may be an example of the medical device(s) 195.

[0220] The medical device 1800 may be configured to collect data during a patient encounter and save the data in the patient encounter file 145. A portion or all of the data provided at the display screen 1810 may be stored in the patient encounter file 145 along with the time- stamped scoring outputs 108. The data may include patient data which characterizes a status and / or condition of the patient (e.g., physiologic data such as ECG, heart rate, pulse oximetry, non-invasive hemoglobin parameters, capnography, oxygen and CO2 concentrations in the airway, invasive and non-invasive blood pressures, tissue pH, tissue oxygenation, near infrared spectroscopy, etc.). Additionally or alternatively, the data may characterize the delivery of therapy (e.g., chest compression data such as compression depth, compression rate, etc.) and / or may characterize a status and / or condition of the medical equipment used to treat the patient (e.g., device data such as shock time, shock duration, attachment of electrodes, power- on, etc.).

[0221] In addition to the display screen 1810, the medical device 1800 may include one or more other output devices such as, for example, a speaker 1820. The medical device 1800 may be configured to control the speaker 1820 to provide audible instructions, a metronome (e.g., a chest compression metronome), feedback, and / or physiological information for a user of the medical device 1800. This information may include audible alarms and notifications. Such alarms and notifications may include score outputs 108 and / or severity index information.

[0222] The display screen 1810 may include a scoring interface 1825. The scoring interface 1825 may include one or more of scoring blocks and / or user data entry fields. A processor of the medical device 1800 may include the scoring tool implementation engine 135 thus enabling the medical device 1800 to provide the scoring interface 1825.

[0223] The display 1810 may provide discrete physiological measurements 1830 that correspond to a particular point in time. The discrete physiological measurements 1830 may include, for example, blood pressure (e.g., non-invasive blood pressure [NIBP] and / or invasive blood pressure [IBP]), heart rate, respiration rate, temperature, oxygen saturation (e.g., SpO2), end tidal CO2 (e.g., EtCO2), Near Infrared Spectroscopy (NIRS) measurements, and / or other physiological parameters. Additionally or alternatively, the display 1810 may provide physiological waveforms 1835 and / or time trend data 1840. The time trend data 1840 may include, for example, score output time trends, body temperature time trends, heart ratetime trends, respiration rate time trends, and / or other time trends. The waveforms 1835 may correspond to physiological sensor data received substantially continuously as a function of time, such as an ECG. The time trends 1840 may correspond to score calculations and / or sensor data calculated, measured, or otherwise acquired at discrete time intervals and displayed as a function of time. In an implementation, the display may include CPR performance data 1845. The CPR performance data 1845 may include, for example, a chest compression depth, a chest compression rate, a chest release indicator, a perfusion performance indicator, and a CPR time indicator. In an implementation, the CPR performance data may include blood pressure data and / or blood flow data. These examples of patient data are not limiting the present disclosure as other types of data corresponding to various therapeutic medical devices are within the scope of the present disclosure.

[0224] Although shown in FIG. 18A on a medical device display, in other examples, the scoring tool implementation engine 135 may generate and display time trend information for a score on other interfaces described herein that include the scoring interface 152 or examples thereof. Because the scores are calculated with a time stamp and recorded, the time trend information is available and readily generated. In addition to time trend information, the scoring tool implementation engine 135 may apply statistical analyses to the scores as collected. In some cases, a change or trend in a score is another score in itself.

[0225] Additionally, the score configuration engine may enable a user 20 to configure a score based on a parameter analysis rather than the parameter itself. For example, the parameter analysis may include a change, or delta, in a particular physiological parameter, a slope of a trend for a particular physiological parameter, an average over time, a maximum, a minimum, a standard deviation, etc., to name some examples. For instance, a degree of change in AMS A may determine a shock / no shock score, a degree of change in blood pressure may be heavily weighted as an indicator of sepsis, and a ratio of heart rate to systolic blood pressure may be weighted (i.e., assigned point values) as a relative measure of hypotension.

[0226] Referring to FIG. 18B, an example of a parameter specification page for a CPR early warning score is shown. A quantity of each component in FIG. 18B is an example only and other quantities of each, or any, component could be used.

[0227] A parameter specification page 1860 indicates a possible configuration for a CPR early warning score. This early warning score would provide immediate feedback as to the overall performance of a caregiver in providing chest compressions and ventilations. Although ECG is a metric of heart health, this metric applies to the electrical function of theheart and not to the blood perfusion or oxygenation. Thus, a CPR early warning score is critical for evaluating these factors. As shown in FIG. 18B, a CPR early warning score may assign point values 1865 to various ranges for a compression depth 1870a, a compression rate 1870b, a ventilation volume 1870c, and breaths per minute (or delivered ventilations per minute) 1870d.

[0228] One or more additional parameters could be added to the parameters 1870a-1870d for the CPR early warning score. For example, an end-tidal CO2 parameter could be added. In an example, points for the end-tidal CO2 parameter may be 0 for 0-10 mmHg, 1 for 10-20 mmHg, 2 for 20-30 mmHg, and 3 for anything over 30 mmHg.

[0229] With access to a device that provides CPR metrics, the score configuration engine 110 enables an agency or facility to configure and implement a score tailored to the CPR skills of the personnel in the agency. For example, points may be assigned to ranges for the compression depth, compression rate, ventilation volume, and ventilation rate. Proper ventilation during CPR is notoriously difficult. Therefore, depending on the skill level of the agency, a CPR score may give higher or lower weight to the ventilation rate. A higher weight will better flag deterioration in delivered ventilation. In some cases, the CPR score could also take into account end-tidal CO2 with point assignments to various ranges. In some examples, the post-case review application may provide insights into the score behavior as correlated with CPR metrics. A medical director may use these insights to easily adjust and disseminate a CPR early warning score using the scoring system described herein. Additionally, the specified clinical score configuration 125 may automatically adjust the score generation for pediatric CPR as opposed to adult CPR. The weights via point assignments and / or the parameters may vary between these two patient populations.

[0230] Referring to FIG. 19, various examples of export operations for the specified clinical score configurations are shown. A quantity of each component in FIG. 19 is an example only and other quantities of each, or any, component could be used.

[0231] As discussed in regard to FIGS. 1A and IB, the score configuration engine 110 may export the specified clinical score configuration 125. For example, the score configuration engine 110 may export the specified clinical score configuration 125 to a resource manager 130 configured for access by the scoring tool implementation engine 135. As shown in FIG. 19, in a system 1900, the resource manager 130 may be one or more of a local resource manager 1930, a platform resource manager 1940, or an agency resource manager 1980. In various implementations, the score configuration engine 110 may be configured to export thespecified clinical score configuration 125 to one or more of the local resource manager 1930, the platform resource manager 1940, or the agency resource manager 1980 for storage and use by the scoring tool implementation engine 135. The scoring tool implementation engine 135 may be communicatively coupled to one or more of the local resource manager 1930, the platform resource manager 1940, or the agency resource manager 1980.

[0232] In some examples, the platform resource manager 1940 may be communicatively coupled to one or more of the local resource manager 1930 and / or the agency resource manager 1980. Additionally, in an implementation, the local resource manager 1930 may be communicatively coupled to the agency resource manager 1980. The local resource manager 1930 and / or the agency resource manager 1980 may be communicatively coupled to one or more of the score configuration engine 110 and / or the scoring tool implementation engine 135.

[0233] In an implementation, the score configuration engine 110 may be locally implemented at a computing device 1904. In such a local implementation, the score configuration engine 110 may include software and / or library resources downloaded from a score configuration platform 1902. The local resource manager 1930 may enable the scoring tool implementation engine 135 to run in an off-line mode at the display device 155. This may enable the scoring tool implementation engine 135 to operate effectively in emergency care environments that often lack network connectivity (e.g., parking garages, remote rural locations, interior spaces, military field locations, etc.). In an implementation, where network connectivity is available, the protocol blocks that require information from the resource managers may acquire that data from the local, agency, or platform resource managers. This may enable a smaller amount of information to be maintained at the local resource manager 1930 and reduce the computational load on the display device 155 providing the local resource manager 260.

[0234] The score configuration engine 110 may store information including the encoded clinical guidance protocol in one or more of the resource managers 1930, 1940, and 1980. The score configuration engine 110 may store the encoded clinical guidance protocol according to account information associated with the protocol. In this manner, an agency, hospital, or other caregiving organization may access protocols associated with their account.

[0235] In an implementation, the score configuration engine 110 may be provided by the score configuration platform 1902 hosted, for example, at a cloud server 1970. The score configuration engine 110 may host a score configuration application 1906 at the computing device 1904 that includes or provides the display device 103. The score configurationplatform 1902 may further include the platform resource manager 1940. The platform resource manager 1940 may include various libraries with information available to the score configuration engine 110 for generating the specified clinical score configurations 125 and to the scoring tool implementation engine 135 for implementing the specified clinical score configurations 125. In some implementations, the scoring tool implementation engine 135 may only access the platform resource manager 1940 to update various elements of the local 1930 or agency resource managers 1980 (e.g., new medical device instructions, driver updates, etc.).

[0236] In an implementation, an agency server 1995 may provide the agency resource manager 1980. The agency server 1995 may be associated with an EMS agency, an EMS agency system, a hospital, a hospital system, and / or another medical care facility or system of facilities. The agency server 1995 may be an on-premises server or a cloud server but is separate from and distinct from the cloud server 1970. The agency server 1995 may communicate with the cloud server 1970 in order to access the platform resource manager 1940.

[0237] The local resource manager 1930 and the agency resource manager 1980 may include various libraries with information available to the scoring tool implementation engine 135 for specified clinical score configuration implementation. In various examples, the local resource manager 1930 and the agency resource manager 1980 may include all or some of the libraries and specified clinical score configurations 125 stored at and provided by the platform resource manager 1940. In an implementation, the platform resource manager 1940 may store all specified clinical score configurations 125 and libraries available for any user of the score configuration platform 1902, which may include a plurality of EMS agencies, hospitals, and / or other health care providers. The agency resource manager 1980 may be associated with the agency server 1995 and may store a subset of the specified clinical score configurations 125 and libraries available at the platform resource manager 1940. The subset may include specified clinical score configurations 125 and / or libraries that are specific to and / or customized for a particular EMS agency, hospital, and / or other health care providers. The local resource manager 1930 may be associated with a device used by an individual health care provider or a specific team of health care providers (e.g., the display device 155) to access the user application UI 150. The local resource manager 1930 may include a subset of the specified clinical score configurations 125 and / or libraries available at the platform resource manager 1940 and / or at the agency resource manager 1980. In an implementation,the subset of specified clinical score configurations 125 and / or libraries of the local resource manager 1930 may be tailored to a specific type of care provided by the individual or team. For example, if an individual provider or team is BLS certified but not (ALS certified, then the specified clinical score configurations 125 and / or libraries available at the local resource manager 1930 associated with that individual’s display device 155 may be limited to BLS specified clinical score configurations and / or libraries.

[0238] Each example of the resource manager 130 may include all of the same resources or may include some common resources and some distinct resources. In an implementation, the platform resource manager 1940 may include resources associated with multiple user accounts associated with multiple agencies, hospitals, and other caregiving organizations. The resources may be designated according to the corresponding account. In an implementation, the agency resource manager 1980 and the local resource manager 1930 may include only resources associated with one or more specific accounts associated with a particular agency, hospital, or other caregiving organization. In some examples, the local resource manager 1930 may include only resources associated with a specific caregiving individual or team within an account. In an implementation, the platform resource manager 1940, the local resource manager 260, and the agency resource manager 1980 may be configured to synchronize with one another periodically to align and update common resources.

[0239] While a specified clinical score configuration 125 is under construction and / or prior to export by the score configuration engine 110, the score configuration engine 110 may store the incomplete and / or pre-export specified clinical score configurations (e.g., a configuration- in-progress 1927) in a local storage 1912. The scoring tool implementation engine 135 may not access, utilize, or otherwise implement the configuration-in-progress 1927 stored in the local storage 1912. These protocols may not yet be in a format that the scoring tool implementation engine 135 can interpret and implement. For example, the configuration-in- progress 1927 may include information relevant to the score configuration UI 120 that enables compatibility and interoperability between the configuration-in-progress and the score configuration UI 120 during score configuration construction. The scoring tool implementation engine 135 may not be configured to parse or execute these instructions. The score configuration engine 110 may strip these instructions upon export of a completed specified clinical score configuration 125. Additionally, these score configurations may contain errors prior to validation and / or may be missing steps and / or specifications becausethey are still being edited and / or under construction. Once complete, the score configuration engine 110 may export the specified clinical score configuration 125 to the platform resource manager 1940 and / or may export the specified clinical score configuration 125 to the local resource manager 1930.

[0240] The scoring tool implementation engine 135 may be communicatively coupled to the charting device(s) 190 and / or the medical device(s) 195. The scoring tool implementation engine 135 may operate in a real-time mode during implementation of a generated clinical score configuration 125 at the user application UI 150 during care of a patient (e.g., care provided by the second user 21). The scoring tool implementation engine 135 may exchange information with and / or manage and control interactions with the charting device(s) 190 and / or the medical device(s) 195. For example, the scoring tool implementation engine 135 may access device drivers in a resource manager 1930, 1940, and / or 1980 in order to communicate with and receive data from and / or exchange data with the charting device(s) 190 and / or the medical device(s) 195.

[0241] In various examples, the scoring tool implementation engine 135 may be disposed at one of the cloud server 1970, the agency server 1995, the display device 155, at least one of the charting device(s) 190, and / or at least one of the medical device(s) 195, or a distributed resource across two or more of the cloud server 1970, the agency server 1995, the display device 155, at least one of the charting device(s) 190 and / or at least one of the medical device(s) 195.

[0242] Referring to FIG. 20, an example of a scoring tool implementation engine implemented within a clinical guidance engine is shown. A quantity of each component in FIG. 20 is an example only and other quantities of each, or any, component could be used.

[0243] A system 2000 includes a clinical guidance engine 2010 and the clinical guidance UI 150d provided at a display 2055. The clinical guidance UI 150d may include the scoring interface 152. The clinical guidance engine 2010 may implement an encoded clinical guidance protocol 2030 at the clinical guidance UI 150d. The encoded clinical guidance protocol 2030 may include one or more specified clinical score configuration(s) 125. The one or more specified clinical score configuration(s) 125 may enable the scoring tool implementation engine 135 to provide the scoring interface 152 as part of the clinical guidance UI 150d. Although illustrated as separate engines herein, in some examples, the scoring tool implementation engine 135 and the clinical guidance engine 2010 may be a single engine that combines the described functions of these two engines. The encodedclinical guidance protocol 2030 with the incorporated at least one specified clinical scoring configuration 125 can receive caregiver input and / or physiologic data from at least one medical device(s) 195. Based on this input and data, the scoring tool implementation engine 135 and / or the clinical guidance engine 2010 may generate caregiver guidance and provide this guidance with and / or based on the score outputs 108.

[0244] The clinical guidance engine 2010 includes hardware logic and / or software logic (e.g., as provided by a processor, a memory, and associated circuitry) that enables the clinical guidance engine 2010 to receive and evaluate data from medical device(s) 195, provide instructions to medical device(s) 195, receive and evaluate caregiver input, and provide caregiver guidance at the clinical guidance UI 150d, all according to the encoded clinical guidance protocol 2030. The encoded clinical guidance protocol 2030 is configured to enable the clinical guidance engine 2010 to implement and / or execute encoded protocol blocks within the encoded clinical guidance protocol 2030. The encoded clinical guidance protocol 2030 and the clinical guidance engine 2010 are mutually compatible so as to enable implementation and / or execution of the encoded clinical guidance protocol 2030. Configured to implement the encoded clinical guidance protocol 2030, the clinical guidance engine 2010 may function as an interpreter of the encoded clinical guidance protocol 2030. As discussed in further detail with regard to FIG. 21, the encoded clinical guidance protocol 2030 includes protocol blocks selected by a user at a clinical guidance protocol generation (CGPG) user interface. The encoded clinical guidance protocol further includes sequencing links between the protocol blocks. The sequencing links are user- selected so as to allow the user to define a progression through protocol blocks and the logic or conditions governing that progression. Implementation and / or execution of the protocol blocks of the encoded clinical guidance protocol 2030 may enable the provision of medical device instructions 2025, the provision of caregiver guidance 2035, the receipt of caregiver input 2037, and / or the receipt and evaluation of physiologic data 2020. Additionally or alternatively, the clinical guidance engine 2010 may receive clinical guidance information from and / or provide clinical guidance information to the charting device(s) 190.

[0245] In order to implement the encoded clinical guidance protocol 2030, the clinical guidance engine 2010 may exchange information with a caregiver 2090 (e.g., the second user 21) and / or the medical device(s) 195. The medical device(s) 195 may be configured to be coupled to a patient 2095 via the patient interface devices 1150. In various examples, theclinical guidance engine 2010 may be communicatively coupled to various patient charting device(s) 190.

[0246] The clinical guidance engine 2010 may receive various inputs and generate and send various outputs. The clinical guidance engine 2010 may receive the physiologic data 2020 from the medical device(s) 195 (e.g., as collected from the patient via the patient interface devices 1150). The clinical guidance engine 2010 may provide the medical device instructions 2025 to the medical device(s) 195. Furthermore, the clinical guidance engine 2010 may receive a caregiver input 2037 and may provide a caregiver guidance 2035. The communication of the caregiver guidance 2035 and the caregiver input 2037 may occur via the clinical guidance UI 150d. The clinical guidance UI 150d may be provided by one or more devices and may not be limited to a display. For example, the one or more devices may include one or more of an audio device (e.g., a combination of a speaker and a microphone), a haptic device, and / or a virtual reality, and / or an augmented reality display device.

[0247] Referring to FIG. 21, an example of a UI for generating an encoded clinical guidance protocol is shown. A quantity of each component in FIG. 21 is an example only and other quantities of each, or any, component could be used. For example, the CGPG engine 2190 may provide the CGPG UI 2120 at a display device of the computing device. The CGPG engine 2190 includes hardware logic and / or software logic (e.g., as provided by a processor, a memory, and associated circuitry) that enables a computing device to provide the CGPG UI 2120, generate the encoded clinical guidance protocol, and export the protocol to the resource manager 130. The resource manager 130 may store the encoded clinical guidance protocol 2030 generated via the CGPG UI 2120 for retrieval and implementation by the clinical guidance engine 2010.

[0248] The CGPG UI 2120 may provide a protocol block selection menu 2102, a graphic protocol display area 2104, and a user specification window 2106. The protocol block selection menu 2102 includes a foundation block menu 2110 and a workflow block menu 2115. The protocol block selection menu 2102 includes blocks that are available for selection by a user of the CGPG UI 2120. For example, the user may select one or more protocol blocks from the protocol block selection menu 2102 by clicking on a block and dragging it into the graphic protocol display area 2104. The user of the score configuration UI 120 may build the protocol in the graphic protocol display area 2104. The protocol generated at the CGPG UI 2120 is specified by a sequence of steps performed by the caregiver 2090, the medical device(s) 195, the charting device(s) 190, the clinical guidance engine 2010, theclinical guidance UI 150d, or a combination thereof. Each step in the generated protocol is encapsulated by a block provided at the CGPG UI 2120. The selection of a protocol block causes the CGPG UI 2120 to display a graphic representation of the selected protocol block in the graphic protocol display area 2104. The protocol under construction in FIG. 21 includes a protocol block 2150 and a workflow block 2154 along with a score configuration block 2132.

[0249] Foundation blocks 2110 may correspond to data objects in a data interchange format file, a set of processor-executable instructions such as web application code, a section of a processor-executable image file, or other processor-executable code. The foundation blocks 2110 define certain tasks that are implemented by the clinical guidance engine 2010. The foundation blocks 2110 may be sequenced at the CGPG UI 2120 to define the protocol.

[0250] The workflow blocks 2115 may include procedures for respiratory conditions, cardiac conditions, trauma, sepsis, and other patient conditions. The workflow blocks 2115 may function as stand-alone protocols or may be sub-protocols that are sequenced with the foundation blocks 2110 within a larger stand-alone protocol. The larger stand-alone protocol is an envelope protocol that may include multiple workflow blocks 2115. The envelope protocol may also be described as an envelope workflow that includes sub-sections in the form of smaller workflow blocks. When a workflow block 2115 is incorporated in a higher- level envelope protocol, the envelope protocol may specify when or under what conditions that higher level protocol triggers the built-in workflow. For example, for an acute respiratory failure (ARF) workflow, a condition evaluation protocol block may evaluate EtCO2 and SpO2 values and trigger the ARF workflow block based on the evaluation. As another example, a pediatric or geriatric workflow may require entry of a patient’s age in order to trigger implementation. The workflow blocks 2115 may enable a user to merely select a block and embed this block into a higher level, or envelope, protocol to utilize the block without having to determine, manipulate, and order the individual steps within the workflow block. In some examples, the workflow blocks 2115 may handle complex interactions or determinations such as a sensor prioritization scheme that instructs the clinical guidance engine 2010 and / or the scoring tool implementation engine 135 how to pick between sensor values and / or between sensor connection instructions if there is a conflict and / or if two or more sensors are requested concurrently by protocols implemented in parallel. As a further example of complexity, the workflow blocks 2115 may include code that provides the necessary logic for the clinical guidance engine 2010 and / or the scoring tool implementationengine 135 to query the network 1480 (e.g., as shown in FIG. 14B) to determine if a particular medical device 195 and / or sensor is communicatively coupled and thus able to automatically provide information to the clinical guidance engine 2010 and / or the scoring tool implementation engine 135. Such a work block 2115 may further include instructions configured to cause the clinical guidance engine 2010 and / or the scoring tool implementation engine 135 to prompt the caregiver 2090 for data entry because the medical device 195 and / or sensor is not communicatively coupled and therefore unable to automatically provide the necessary information. As yet another example of complexity, the workflow blocks 2115 may handle mathematical operations that are more complex than, for example, simple arithmetic like addition, subtraction, ratios, or multiplication of two or three values. Examples of more complex mathematical operations include integration, differentiation, statistical analysis, filtering, etc. Such operations require more complex programming than the simple arithmetic examples. Some of these more complex operations include, for example, but not limiting the present disclosure, peak detection for ECG, evaluations of maxima, minima, ranges, averages, medians, standard deviations for groups of data and / or for waveforms, spectral integrals (e.g., AMSA determinations for ECG in a VF treatment), Fourier transforms, etc. As yet a further example, the workflow blocks 2115 may include blocks that require user instructions for specific devices along with guidance and animations. For example, bi-level ventilation and ultrasound measurements may require such specific instructions. Ultrasound may be particularly complex as the workflow block 2115 may enable provision of instructions on how to connect the ultrasound probe, how to manipulate the probe to obtain an image, and how to analyze the image to determine a finding. In this example, a user of the CGPG UI 2120 may select an ultrasound block, possibly set one or more higher level parameters for the block, and insert the block into an envelope protocol.

[0251] In addition to selecting protocol blocks 2150, the score configuration UI 120 enables a user to indicate sequencing links 2122 in the graphic protocol display area 2104. Each sequencing link 2122 connects an input port 2130 or 2132 with an output port to define a progression between protocol blocks 2150. The protocol block 2150 includes the input port 2130 and three output ports 2124, 2126, and 2128. In general, the output ports 2124, 2126, and 2128 enable navigation to various branches of the generated protocol. The input port 2130 is an entry linkage port that allows a user of the CGPG UI 2120 to connect, or link, the protocol block 2150 with one or more preceding blocks by indicating a sequencing link 2122. In the example of FIG. 21, the user of the CGPG UI 2120 has indicated a sequencing link2122 from the output port 2124 to the input port 2132 of the score configuration block 2152. The CGPG UI 2120 is configured to display each sequencing link as a line connecting at least two protocol blocks (e.g., a first protocol block and a second protocol block). At the stage of protocol construction captured in FIG. 21, the output ports 2126 and 2128 are not linked to a subsequent protocol block. To complete the protocol generation, at least one output port for each protocol block is to be sequenced to at least one input port. In an implementation, an output port may be set to a null value to deactivate the output port. A CGPG engine 2190 does not require a user of the CGPG UI 2120 to link every output linkage port of a protocol block to an input port. During execution, the clinical guidance engine 2010 ignores the attribute of an output port that is not linked to an input port. For example, a condition evaluation protocol block 2150 may include an indeterminate value port (e.g., an “unknown” port 2128, an “value unavailable” port, an “unspecified” port, etc., as examples only and not limiting the present disclosure) to provide a sequencing path if the condition evaluated by the block 2150 is indeterminate. However, if the indeterminate value port is not linked to any other port, then the protocol has likely ensured that a value is available (e.g., by specifically setting a value that is provided to the condition evaluation block 2150) and the indeterminate value port is moot and causes no action by the clinical guidance engine 2010.

[0252] For a data interchange format file, the CGPG engine 2190 may encode a protocol block 2150 as step objects, such as, for example:

[0253] "type": "if”,

[0254] "Ihs": "SpO2",

[0255] " comparison": ">",

[0256] "rhs": 85

[0257] " transitions":

[0258] { "true": "node-1",

[0259] "false": "node-2",

[0260] "unknown": "node-3"}

[0261] This example would identify a type of foundation block operator (e.g., “if’) and then define the left- and right-hand sides of a comparison (e.g., a greater-than comparison). If the comparison is true then a first output port is invoked (e.g., “node-1”), if the comparison is false then a second output port is invoked (e.g., “node-2”), and if the comparison is unknown then a third output port is invoked (e.g., “node-3”). In the example of a data interchange format file, the CGPG engine 2190 may assign a unique identifier to every input node forevery protocol block. For example, the block 2150 may correspond to a first unique identifier, UI1, the block 2152 may correspond to a second unique identifier, UI2, a block 2154 may correspond to a third unique identifier, UI3, etc. When the sequencing links are provided graphically at the CGPG UI 2120, the CGPG engine 2190 assigns the unique identifier of the input port to the preceding and connected output port. For example, the CGPG engine 2190 would assign UI2 for the block 2152 to the port 2124 (e.g., node-l=UI2). Any time the user of the CGPG UI 2120 changes a sequencing link, the CGPG engine 2190 replicates that change by changing the unique identifier assignments. Thus, the sequencing links are not merely visual connectors but rather represent encoding the sequencing instructions to generate the encoded clinical guidance protocol 2030.

[0262] The types of output ports for a particular protocol block are determined by the operator. In general, each of the one or more output linkage ports is associated with a sequencing attribute. Examples of sequencing attributes include yes, no, next, guidance, unknown, etc. The sequencing attribute indicates a sequencing relationship between the linked protocol blocks.

[0263] The protocol block 2150 in the example of FIG. 21 includes a condition evaluation operator. Other examples of operators for protocol blocks may include, but are not limited to, a range check operator, a match evaluation operator, a condition evaluation operator, a value assignment operator, a timer operator, a computation operator, a delay operator, an alert operator, a check list operator, a multiple choice operator, a reference operator, a trend operator, a UI instruction operator, a UI user prompt operator, a medical administration operator, and a guidance operator. The condition evaluation operator causes the clinical guidance engine 2010 to evaluate one or more conditions that compare the left- and righthand sides of an expression according to the selected comparator and optionally subject to an and / or logic selection. The evaluation causes the clinical guidance engine 2010 to select an output port that leads to a subsequent protocol block as defined by the sequencing link connecting the output port and the input port of the subsequent protocol block. In the example of the block 2150, the output ports for the condition evaluation operator are a first output port if the one or more conditions are satisfied, a second output port if the one or more conditions are not satisfied, and the indeterminate value port.

[0264] As shown in FIG. 21, the protocol may begin with a start block 51 and end at a stop block 52. A user selection of a particular protocol block causes the CGPG UI 2120 to display the format of a user specification window 2106 corresponding to the operator 2129 of theselected protocol block. Additionally, a user selection of the particular protocol block enables the user to drag the block to a specific location within the display area 2104 and orient the block relative to other blocks.

[0265] The protocol blocks 2150 as selected from the menu are unspecified because they include a framework for defining the block 2150 but lack specifications. The CGPG UI 2120 may provide fillable fields corresponding to the selected and unspecified protocol block in the user specification window 2106. The user specification window 2106 provides fillable fields configured to receive entries of user specifications for the protocol blocks. The format of the user specification window 2106 is specific to the operator 2129 of the protocol block 2150. For example, if the operator 2129 is a condition evaluation operator (e.g., the “IF” operator shown in FIG. 21, as an example only and not limiting the present disclosure), then the user specification window 2106 provides fillable fields according to a format specific to the condition evaluation operator. These fillable fields enable a user to specify various aspects and features of the selected protocol block 2150. For example, as shown in FIG. 21, a selection of the “IF” foundation block 2150 causes the CGPG UI 2120 to display the block editor 2155 for the “IF” foundation block 2150 in the user specification window 2106. A user of the CGPG UI 2120 may enter specifications (e.g., values, logic operators, parameter names, etc.) into the fillable fields to specify the selected protocol block 2150. For example, as shown in FIG. 21, the parameters heart rate (“HR”) and respiratory rate (“RR”) are entered and compared to values of “90” and “20” respectively with logic operators of “>” and “AND.”

[0266] The CGPG UI 2120 may further include a control to open a previously saved protocol 53a, a control to locally save a protocol in progress 53b, a control to edit a protocol 53c opened with the control 53a, a control to generate a new protocol 53d, a control to export a generated protocol to a resource manager 53e, and a control to logout of a protocol generation session 53f. The CGPG UI 2120 may further include a score configuration control 53g to invoke the score configuration engine 110 to generate and embed a specified clinical score configuration 125 in the encoded clinical guidance protocol. Selection of the score configuration control 53g may cause the CGPG UI 2120 to provide the score configuration UI 120. For example, in response to selection of the score configuration control 53g, the user may generate and embed the qSOFA score calculation as shown in FIG. 21. Alternatively or additionally, selection of the score configuration control 53g may provide a menu 2180 of previously generated specified clinical score configurations 125 available from the resourcemanager 130. The user may select a previously generated specified clinical score configuration 125 from the menu 2180 and embed that configuration 215 in the protocol at the CGPG UI 2120.

[0267] Referring to FIG. 22, an example of an encoded clinical guidance protocol with an embedded specified clinical score configuration 125 is shown. A quantity of each component in FIG. 22 is an example only and other quantities of each, or any, component could be used.

[0268] A protocol 2200 includes the start block 51 and the stop block 52. The start block 51 and stop block 52 demarcate the start and end, respectively, of the protocol 2200. The start block 51 and the stop block 52 tell the clinical guidance engine 2010 where to start the invoked protocol 2200 and when to end the invoked protocol 2200. Without the start block 51, the clinical guidance engine 2010 would be unable to determine the initial block to execute to start the protocol 2200. This can be particularly true where the protocol 2200 is a set of looped steps and, without the start block 51, the initial step of the loop would be indeterminate. Without the stop block 52, the invoked protocol 2200 would remain active in the clinical guidance engine 2010. This may cause issues if downstream workflow blocks rely on a block ending or the block is generating values for variables or parameters that are no longer relevant at a downstream point in an envelope protocol. The active protocol block may also continue to generate unnecessary controls or other outputs at the clinical guidance UI 150d and / or continue to generate medical device instructions that are no longer relevant or, even worse, incorrect and running counter to a downstream invocation of that medical device 195.

[0269] The encoded protocol 2200 includes the protocol block 2150 and the score configuration block 2152. The output port 2210 of the score configuration block 2152 advances the encoded protocol 2200 to a subsequent block once the score calculation is complete. A protocol block 2220 encodes clinical guidance based on the calculated score. In the example of FIG. 22, the protocol block 2220 includes a conditional evaluation operator that provides a first output port 2224 based on a first range for the calculated score and a second output port 2226 based on a second range for the calculated score. The first output port 2224 ends the encoded protocol 2200 if the calculated score is below a particular value and the second output port 2226 proceeds to guidance protocol blocks 2234 and 2236 and a workflow block 2240 if the calculated score exceeds the particular value. The guidance protocol blocks 2234 and 2236 are configured to enable the clinical guidance engine 2010 toprovide caregiver guidance at the clinical guidance UI 150d in a manner similar to that discussed above with regard to FIGS. 10A and 10B.

[0270] Referring to FIG. 23, an example of a system for fine-tuning a specified clinical score configuration is shown. A quantity of each component in FIG. 23 is an example only and other quantities of each, or any, component could be used.

[0271] A system 2300 includes a score configuration fine-tuning engine 2310 in addition to the components of the system 100 in FIG. 1A. The score configuration fine-tuning engine 2310 includes hardware logic and / or software logic (e.g., as provided by a processor, a memory, and associated circuitry) that enables the score configuration fine-tuning engine 2310 to implement a score configuration fine-tuning UI 2320 at a display device 2303. The score configuration fine-tuning engine 2310 may retrieve the specified clinical score configuration(s) 125 generated by the score configuration engine 110 via the score configuration UI 120. For example, the score configuration fine-tuning engine 2310 may retrieve the specified clinical score configuration(s) 125 from the local resource manager 1930, the platform resource manager 1940, and / or the agency resource manager 1980. In an implementation, a third party (e.g., a third user 22), such as a medical director for a particular ambulance agency or hospital may fine-tune one or more specified clinical score configuration(s) 125 to create fine-tuned specified clinical score configuration(s) 2325. The fine-tuned configuration 2325 is customized by a first user who may be a first tier in a hierarchical care organization, such as a medical director for a large hospital system or for a large EMS agency that encompasses multiple geographic regions and / or jurisdictions and / or multiple types of provided care. In some implementations, a second tier user within such an organization may further customize, or fine-tune, such a fine-tuned configuration 2325 in order to reflect more localized preferences or protocols. Such more localized preferences or protocols may be specific to a particular geographic region, jurisdiction, and / or type of provided care. In some instances, the score configuration fine-tuning engine 2310 and / or the score configuration engine 110 may limit or restrict the configuration options available at the fine-tuning stage. Thus, all options available from the score configuration engine 110 may not be available to the third user 22 of the score configuration fine-tuning UI 2320. This may enable the first tier user to distinguish between allowed and disallowed configuration options on the second tier level. In some examples, the third user 22 may be a same user as the first user 20 and / or the second user 21. In some examples, the display device 2303 may be a same device as one or more of the display device 103 and the display device 155.

[0272] The score configuration fine-tuning engine 2310 may enable adjustments and / or modifications of various specific criteria of the specified clinical score configuration(s) 125, the addition or removal of score components, and / or combination of multiple specified clinical score configuration(s) 125. The fine-tuning may account for specific early warning score preferences of an agency, agency system, hospital, or hospital system. However, the fine-tuning engine 2310 may work within a pre-existing framework provided by a previously generated specified clinical score configuration(s) 125. In contrast, the score configuration engine 110 creates the specified clinical score configuration 125 that the score configuration fine-tuning engine 2310 may modify to fine-tune. In an implementation, the score configuration fine-tuning engine 2310 may provide the fine-tuned specified clinical score configuration(s) 2325 to one or more of the local resource manager 1930, the platform resource manager 1940, and / or the agency resource manager 1980, the scoring tool implementation engine 135, and / or the clinical guidance engine 2010. The clinical guidance engine 2010 and / or the scoring tool implementation engine 135 may provide clinical guidance and / or early warning score guidance for a caregiver at least in part at the clinical guidance UI 150d and / or at the user application UI 150 using the fine-tuned specified clinical score configuration(s) 2325, the specified clinical score configuration(s) 125, or a combination thereof.

[0273] Referring to FIG. 24, an example of a resource manager for an early warning score configuration generation and implementation system is shown. A quantity of each component in FIG. 24 is an example only and other quantities of each, or any, component could be used. As shown in FIG. 19, the resource manager 130 may be, for example, the local resource manager 1930, the platform resource manager 1940, or the agency resource manager 1980. The resource manager 130 may include an instructional library 2420, a medication library 2430, a physiological indication library 2440, a medical device library 2450, a protocol and score configuration library 2460, and / or an account information library 2470.

[0274] The instructional library 2420 may include an instructional image library 2422, an instructional animation library 2424, and / or an instructional text library 2426. The score configuration engine 110 may access the instructional library 2420 when a user invokes the browsing control 543 as shown in FIG. 5.

[0275] The medication library 2430 may include at least one of a medication indication library 2432 and a medication dosage library 2434. In an example, the score configuration engine 110 may be configured to retrieve medication specification guidelines from themedication library 2430 and provide the medication specification guidelines at the score configuration UI 120. This may enable a user of the score configuration UI 120 to modify the guidelines and / or select scoring parameters based on the guidelines. Additionally, during protocol generation, the score configuration engine 110 may validate a user specification of a medication based on information in the medication library 2430.

[0276] The physiological indication library 2440 may include one or more of a physiological parameter library 2442, a patient symptom and condition library 2444, or a threshold and ranges library 2446. In an example, the score configuration engine 110 may be configured to retrieve physiological parameter information from the physiological indication library 2440 and provide the physiological parameter information at the score configuration UI 120. The score configuration engine 110 may validate a user specification of a physiological parameter based on information in the physiological indication library 2440. Additionally or alternatively, the score configuration engine 110 may provide physiological parameter information at the score configuration UI 120.

[0277] The medical device library 2450 may include a medical device drivers library 2452 and / or a verified medical devices library 2454. In an implementation, medical device interaction protocol blocks may utilize device drivers to either provide instructions to the medical device(s) 195 and / or to retrieve information from the medical device(s) 195. Further, the medical device library 2450 may include the verified medical devices library 2454 to indicate which medical device(s) 195 are authorized to interact with the scoring tool implementation engine 135. In some examples, the medical device library 2450 may provide information that enables the scoring tool implementation engine 135 to initiate communications with a particular medical device 195 based on this information and / or search for such a medical device 195 in a local area network. In this manner, the scoring tool implementation engine 135 may tailor the guidance to medical device(s) 195 actually in use and be capable of communications with the scoring tool implementation engine 135. In various examples, the medical device interaction protocol blocks may cause the scoring tool implementation engine 135 to provide an instruction (e.g., one of the medical device instructions 2025) to at least one medical device(s) 195 based on information in the medical device library 2450. In an implementation, the scoring tool implementation engine 135 may retrieve information from the medical device library 2450 such as the make and model of a particular medical device 195. In an implementation, the score configuration engine 110 mayprovide medical device information, such as make, model, and / or operational specifications for a medical device 195 at the score configuration UI 120 for use during protocol generation.

[0278] The protocol and score configuration library 2460 includes encoded clinical guidance protocols 2030 generated for use by the clinical guidance engine 2010 in a generated protocols library 2462. Additionally, the protocol and score configuration library 2460 includes specified clinical score configurations 125 in a generated clinical score configurations library 2466. Once saved in the resource manager 130, the encoded clinical guidance protocols 2030 and specified clinical score configurations 125 may be further finetuned as described in regard to FIG. 23. For example, a second party, such as a medical director for a particular ambulance agency or hospital may retrieve and fine-tune a specified clinical score configuration 125 from the resource manager 1930, 1940, and / or 1980 to create the fine-tuned specified clinical score configuration 2325. The fine-tuned protocols 2030 and configurations 2325 are stored in a customized protocols library 2464 and a customized clinical score configurations library 2468, respectively.

[0279] The user account information library 2472 includes user account information associated with the generated 125 and / or fine-tuned specified clinical score configurations 2325 saved in the protocol and score configuration library 2460. Additionally, the user account information library 2472 may include account information associated with one or more of the instructional library 2420, the medication library 2430, the physiological indication library 2440, and the medical device library 2450. The user account information library 2472 may enable the scoring tool implementation engine 135 and / or the clinical guidance engine 2010 to access library resources specific to a particular user account. The user account may be associated with an agency, hospital, agency system, hospital system, and / or other caregiving organizations.

[0280] While certain embodiments have been described, these embodiments have been presented by way of example only and are not intended to limit the scope of the present disclosures. Indeed, the novel methods, apparatuses, and systems described herein can be embodied in a variety of other forms; furthermore, various omissions, substitutions, and changes in the form of the methods, apparatuses, and systems described herein can be made without departing from the spirit of the present disclosures. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the present disclosures.

Claims

WHAT IS CLAIMED IS:

1. A system for generating clinical guidance for a patient encounter, the system comprising: a medical device comprising a patient monitor-defibrillator having a medical device display and at least one sensor configured to measure patient physiologic data for a patient during the patient encounter; and a mobile device communicatively coupled to the medical device and comprising: a mobile device display, and at least one non-transitory, processor-readable storage medium having stored thereon first processor-readable instructions, the first processor-readable instructions being configured to cause at least one processor to: receive at least a portion of the patient physiologic data from the medical device, retrieve at least one specified clinical scoring configuration from a resource manager communicatively coupled to the at least one processor, and implement the at least one specified clinical scoring configuration to: control at least a portion of a user interface (UI) at the mobile device display to: display at least one user interactive scoring control at the UI, and receive a user selection of the at least one user interactive scoring control, receive score inputs based on the user selection, the score inputs comprising a value of a physiologic parameter represented in the at least the portion of the patient physiologic data from the medical device, generate one or more score outputs based on the score inputs, control the at least the portion of the UI to display the one or more score outputs, and store the one or more score outputs in a patient encounter file associated with the medical device.

2. The system of claim 1, wherein the medical device is configured to store the patient physiologic data measured for the patient in the patient encounter file.

3. The system of claim 1, wherein the medical device is an only medical device communicatively coupled to the mobile device during the patient encounter.

4. The system of claim 1, wherein the first processor-readable instructions are configured to cause the at least one processor to implement the at least one specified clinical scoring configuration to: generate a severity index for a respective score output of the one or more score outputs; control the at least the portion of the UI to display the severity index; and store the severity index in the patient encounter file with the respective score output.

5. The system of claim 4, wherein the severity index comprises a display graphic for the respective score output having a color indicative of a relative severity of a patient condition indicated by the respective score output.

6. The system of claim 1, wherein the first processor-readable instructions are configured to cause the at least one processor to implement the at least one specified clinical scoring configuration to: generate a time stamp for a respective score output of the one or more score outputs, control the at least the portion of the UI to display the time stamp, and store the time stamp in the patient encounter file with the respective score output.

7. The system of claim 1, comprising at least one non-transitory, processor-readable storage medium having stored thereon second processor-readable instructions, the second processor-readable instructions being configured to cause at least one additional processor to: provide a clinical score configuration UI, receive user specifications at the clinical score configuration UI for a plurality of configuration fields configured to capture the score inputs, generate the at least one specified clinical score configuration based on the user specifications, and export the at least one specified clinical score configuration to the resource manager.

8. The system of claim 1, wherein the first processor-readable instructions are configured to cause the at least one processor to: retrieve a plurality of specified clinical scoring configurations from the resource manager, and implement the plurality of specified clinical scoring configurations to control at least the portion of the UI to display a plurality of user interactive scoring controls at the UI, each user interactive scoring control corresponding to a respective clinical score, wherein the user selection of the at least one user interactive scoring control is a selection from the plurality of user interactive scoring controls.

9. The system of claim 8, wherein a first user selection of the at least one user interactive scoring control causes the at least one processor to generate an initial score output, an initial severity index, and a first associated time stamp, and wherein a second user selection of the at least one user interactive scoring control subsequent to the first user selection causes the at least one processor to: generate an updated score output, an updated severity index, and a second associated time stamp, and replace a display of the initial score output, the initial severity index, and the first associated time stamp with a display of the updated score output, the updated severity index, and the second associated time stamp.

10. The system of claim 1, wherein at least one score output of the one or more score outputs comprises a textual caregiver recommendation for patient treatment.

11. The system of claim 1, wherein at least one score output of the one or more score outputs comprises a numeric value.

12. The system of claim 1, wherein the at least one processor is configured to implement the at least one specified clinical scoring configuration to control at least the portion of the UI to: provide one or more prompts for the score inputs, andcapture at least a portion of the score inputs from user entries at the UI in response to the one or more prompts.

13. The system of claim 12, wherein a score output of the one or more score outputs requires a plurality of score inputs, and wherein user responses to the one or more prompts provide the plurality of score inputs.

14. The system of claim 12, wherein the one or more prompts comprise at least one of a prompt for user entry of the patient physiologic data or a prompt for user entry of a patient evaluation by a caregiver.

15. The system of claim 12, wherein a respective score output of the one or more score outputs comprises at least one of a Glasgow Coma Scale (GCS) score, a quick Sequential Organ Failure Assessment (qSOFA) score, a Modified Early Warning (MEWS) score, a National Early Warning (NEWS) score, or a National Early Warning 2 (NEWS2) score.

16. The system of claim 12, wherein a respective score output of the one or more score outputs comprises a stroke score.

17. The system of claim 16, wherein the stroke score comprises at least one of a Los Angeles Motor Scale (LAMS) score, a Functional Assessment Staging Tool (FAST) score, or a Vision Aphasia Neglect (VAN) score.

18. The system of claim 1, wherein the one or more score outputs require a plurality of score inputs, and wherein the at least one processor is configured to implement the at least one specified clinical scoring configuration to receive at least a portion of the plurality of score inputs from the medical device.

19. The system of claim 18, wherein the one or more score outputs comprises a trauma score.

20. The system of claim 19, wherein the trauma score comprises at least one of a Compensatory Reserve Index (CRI) score, a Community Resiliency Model (CRM) score, or an Automated Processing of the Physiological Registry for Assessment of Injury Severity (APPRAISE) score.

21. The system of claim 18, wherein the one or more score outputs comprises an Amplitude Spectrum Area (AMSA) score.

22. The system of claim 21, wherein the one or more score outputs further comprises a shock advisory based on the AMSA score.

23. The system of claim 18, wherein the one or more score outputs comprises a cardiopulmonary resuscitation score calculated based on an assignment of points to ranges of compression depth, compression rate, ventilation volume, and ventilation rate.

24. The system of claim 18, wherein the at least one processor is configured to implement the at least one specified clinical scoring configuration to receive the plurality of score inputs from the medical device.

25. The system of claim 18, wherein the portion of the plurality of score inputs is a first portion, and wherein the at least one processor is configured to implement the at least one specified clinical scoring configuration to: provide one or more prompts for the score inputs at the UI, and capture at least a second portion of the plurality of score inputs from user entries at the UI in response to the one or more prompts.

26. The system of claim 18, wherein the portion of the plurality of score inputs from the medical device comprise physiologic parameters of a patient detected by the medical device.

27. The system of claim 18, wherein the UI comprises a connected devices control configured to identify the medical device communicatively coupled to the mobile device.

28. The system of claim 27, wherein the connected devices control is configured to provide one or more device selection controls configured to initiate a communicative coupling between the mobile device and the medical device.

29. The system of claim 1, wherein the at least one processor is configured to implement the at least one specified clinical scoring configuration to control the at least the portion of the UI to: provide at least one guidance request control, and in response to a user selection of the at least one guidance request control, provide score input instructions comprising one or more of text instructions or graphic instructions.

30. The system of claim 1 wherein the at least one processor is configured to: apply an analytic operation to at least one score input of the one or more score outputs, generate a derived parameter from the at least one score input based on the analytic operation, and generate the one or more score outputs based on the derived parameter.

31. The system of claim 30, wherein the analytic operation comprises a trend calculation for the at least one score input.

32. The system of claim 31, wherein the at least one processor is configured to apply the analytic operation in real time to the at least one score input based on an event marker automatically generated by the medical device.

33. The system of claim 1, wherein the at least one processor is configured to filter the one or more score outputs based on at least one of a caregiver skill level or a clinical category.

34. The system of claim 33, wherein the at least one processor is configured to adjust at least one severity index associated with at least one of the one or more score outputs based on at least one of the caregiver skill level or the clinical category.

35. The system of claim 1, wherein the at least one processor is configured to control the at least the portion of the UI to display at least one measured physiological parameter in a graphical form substantially similar to the one or more score outputs.

36. The system of claim 1, wherein the at least one processor is configured to control the at least the portion of the UI to display two or more workflow elements in a graphical form substantially similar to the one or more score outputs.

37. The system of claim 36, wherein the two or more workflow elements correspond to a MARCH (massive hemorrhage, airway, respiratory, circulation, head injury, hypothermia) workflow.

38. The system of claim 1, wherein the first processor-readable instructions are configured to cause the at least one processor to integrate the at least one specified clinical scoring configuration with patient monitoring application implemented at a computing device, the patient monitoring application being configured to provide a visual representation, in real time at the mobile device display, of at least a portion of patient information provided at the medical device display during the patient encounter.

39. The system of claim 38, wherein the patient monitoring application is configured to provide at least a medical device view tab and a patient status tab, and wherein the first processor-readable instructions are configured to cause the at least one processor to: in response to a selection of the medical device view tab, display the one or more score outputs with the visual representation of the at least the portion of the patient information provided at the medical device display, and in response to a selection of the patient status tab, display the at least one user interactive scoring control.

40. The system of claim 1, wherein the UI comprises a clinical guidance UI configured to provide caregiver guidance based on an encoded clinical guidance protocol that incorporates the at least one specified clinical scoring configuration.

41. The system of claim 40, wherein the at least one processor is configured to: receive caregiver input from a caregiver, generate the caregiver guidance based on the caregiver input and the at least the portion of the patient physiologic data received from the medical device, and provide the caregiver guidance with the one or more score outputs.

42. A system for generating clinical early warning score guidance for a patient encounter, the system comprising: at least one non-transitory, processor-readable storage medium having stored thereon first processor-readable instructions, the first processor-readable instructions being configured to cause at least one processor to: retrieve at least one specified clinical scoring configuration from a resource manager communicatively coupled to the at least one processor, and implement the at least one specified clinical scoring configuration to: control at least a portion of a user interface (UI) for a user application to: display at least one user interactive scoring control at the UI, receive a user selection of the at least one user interactive scoring control, capture score inputs based on the user selection, generate one or more score outputs based on the score inputs, control the at least the portion of the UI to display the one or more score outputs, and store the one or more score outputs in a patient encounter file associated with the user application.

43. The system of claim 42, wherein the first processor-readable instructions are configured to cause the at least one processor to implement the at least one specified clinical scoring configuration to:generate a severity index for a respective score output of the one or more score outputs, control the at least the portion of the UI to display the severity index, and store the severity index in the patient encounter file with the respective score output.

44. The system of claim 43, wherein the severity index comprises a display graphic for the respective score output having a color indicative of a relative severity of a patient condition indicated by the respective score output.

45. The system of claim 42, wherein the first processor-readable instructions are configured to cause the at least one processor to implement the at least one specified clinical scoring configuration to: generate a time stamp for a respective score output of the one or more score outputs, control the at least the portion of the UI to display the time stamp, and store the time stamp in the patient encounter file with the respective score output.

46. The system of claim 42, comprising at least one non-transitory, processor-readable storage medium having stored thereon second processor-readable instructions, the second processor-readable instructions being configured to cause at least one additional processor to: provide a clinical score configuration UI, receive user specifications at the clinical score configuration UI for a plurality of configuration fields configured to capture the score inputs, generate the at least one specified clinical score configuration based on the user specifications, and export the at least one specified clinical score configuration to the resource manager.

47. The system of claim 42, wherein the first processor-readable instructions are configured to cause the at least one processor to: retrieve a plurality of specified clinical scoring configurations from the resource manager, and implement the plurality of specified clinical scoring configurations to control at least the portion of the UI for the user application to display a plurality of user interactive scoringcontrols at the UI, each user interactive scoring control corresponding to a respective clinical score, wherein the user selection of the at least one user interactive scoring control is a selection from the plurality of user interactive scoring controls.

48. The system of claim 47, wherein a first user selection of the at least one user interactive scoring control causes the at least one processor to generate an initial score output, an initial severity index, and a first associated time stamp, and wherein a second user selection of the at least one user interactive scoring control subsequent to the first user selection causes the at least one processor to: generate an updated score output, an updated severity index, and a second associated time stamp, and replace a display of the initial score output, the initial severity index, and the first associated time stamp with a display of the updated score output, the updated severity index, and the second associated time stamp.

49. The system of claim 42, wherein at least one score output of the one or more score outputs comprises a textual caregiver recommendation for patient treatment.

50. The system of claim 42, wherein at least one score output of the one or more score outputs comprises a numeric value.

51. The system of claim 42, wherein the at least one processor is configured to implement the at least one specified clinical scoring configuration to control the at least the portion of the UI for the user application to: provide one or more prompts for the score inputs, and capture at least a portion of the score inputs from user entries at the UI in response to the one or more prompts.

52. The system of claim 51, wherein the one or more score outputs require a plurality of score inputs, andwherein user responses to the one or more prompts provide the plurality of score inputs.

53. The system of claim 51, wherein the one or more prompts comprise at least one of a prompt for user entry of the patient physiologic data or a prompt for user entry of a patient evaluation by a caregiver.

54. The system of claim 51, wherein the one or more score outputs comprise at least one of a Glasgow Coma Scale (GCS) score, a quick Sequential Organ Failure Assessment (qSOFA) score, a Modified Early Warning (MEWS) score, a National Early Warning (NEWS) score, or a National Early Warning 2 (NEWS2) score.

55. The system of claim 51, wherein the one or more score outputs comprise a stroke score.

56. The system of claim 55, wherein the stroke score comprises at least one of a Los Angeles Motor Scale (LAMS) score, a Functional Assessment Staging Tool (FAST) score, or a Vision Aphasia Neglect (VAN) score.

57. The system of claim 42, wherein the one or more score outputs require a plurality of score inputs, and wherein the at least one processor is configured to implement the at least one specified clinical scoring configuration to receive at least a portion of the plurality of score inputs from one or more of at least one medical device or at least one patient charting device communicatively coupled to a device providing the user application.

58. The system of claim 57, wherein the one or more score outputs comprise a trauma score.

59. The system of claim 58, wherein the trauma score comprises at least one of a Compensatory Reserve Index (CRI) score, a Community Resiliency Model (CRM) score, or an Automated Processing of the Physiological Registry for Assessment of Injury Severity (APPRAISE) score.

60. The system of claim 57, wherein the one or more score outputs comprise comprises an Amplitude Spectrum Area (AMSA) score a shock advisory based on the AMSA score.

61. The system of claim 57, wherein the one or more score outputs comprise a cardiopulmonary resuscitation score calculated based on an assignment of points to ranges of compression depth, compression rate, ventilation volume, and ventilation rate.

62. The system of claim 57, wherein the at least one processor is configured to implement the at least one specified clinical scoring configuration to receive the plurality of score inputs from the one or more of the at least one medical device or the at least one patient charting device communicatively coupled to the device providing the user application.

63. The system of claim 57, wherein the portion of the plurality of score inputs is a first portion, and wherein the at least one processor is configured to implement the at least one specified clinical scoring configuration to: provide one or more prompts for the score inputs at the UI, and capture at least a second portion of the plurality of score inputs from user entries at the UI in response to the one or more prompts.

64. The system of claim 57, wherein the portion of the plurality of score inputs from the medical device comprise physiologic parameters of a patient detected by the at least one medical device.

65. The system of claim 57, wherein the UI comprises a connected devices control configured to identify the one or more of the at least one medical device or the at least one patient charting device communicatively coupled to the device providing the user application.

66. The system of claim 65, wherein the connected devices control is configured to provide one or more device selection controls configured to initiate a communicative coupling between the device providing the user application and a medical device or patientcharting device corresponding to a respective device selection control of the one or more device selection controls.

67. The system of claim 42, wherein the at least one processor is configured to implement the at least one specified clinical scoring configuration to control the at least the portion of the UI for the user application to: provide at least one guidance request control, and in response to a user selection of the at least one guidance request control, provide score input instructions comprising one or more of text instructions or graphic instructions.

68. The system of claim 42, wherein the at least one processor is configured to: apply an analytic operation to at least one score input, generate a derived parameter from the at least one score input based on the analytic operation, and generate the one or more score outputs based on the derived parameter.

69. The system of claim 68, wherein the analytic operation comprises a trend calculation for the at least one score input.

70. The system of claim 69, wherein the at least one processor is configured to apply the analytic operation in real time to the at least one score input based on an event marker automatically generated by a medical device.

71. The system of claim 42, wherein the at least one processor is configured to filter the one or more score outputs based on at least one of a caregiver skill level or a clinical category.

72. The system of claim 71, wherein the at least one processor is configured to: adjust at least one severity index associated with at least one of the one or more score outputs based on at least one of the caregiver skill level or the clinical category.

73. The system of claim 42, wherein the at least one processor is configured to control the at least the portion of the UI to display at least one measured physiological parameter in a graphical form substantially similar to the one or more score outputs.

74. The system of claim 42, wherein the at least one processor is configured to control the at least the portion of the UI to display two or more workflow elements in a graphical form substantially similar to the one or more score outputs.

75. The system of claim 74, wherein the two or more workflow elements correspond to a MARCH (massive hemorrhage, airway, respiratory, circulation, head injury, hypothermia) workflow.

76. The system of claim 42, wherein the user application comprises a patient charting application, and wherein the first processor-readable instructions are configured to cause the at least one processor to integrate the at least one specified clinical scoring configuration with a patient charting UI for the patient charting application.

77. The system of claim 76, wherein the patient charting application comprises a pre-hospital charting application and the patient charting UI comprises user entry controls for: a) clinical scoring based on the at least one specified clinical scoring configuration, and b) dispatch information, and wherein the patient charting application is configured to store the dispatch information in the patient encounter file.

78. The system of claim 76, wherein the patient charting UI comprises user entry controls for: a) clinical scoring based on the at least one specified clinical scoring configuration, and b) first time-stamped log entries that mark caregiver treatment events that occur during the patient encounter, andwherein the patient charting application is configured to: establish a communicative connection with at least one medical device, receive second time- stamped log entries that mark medical device events that occur during the patient encounter, and present during the patient encounter a single consolidated event log via the patient charting UI that comprises the one or more score outputs, an associated time stamp, the first time-stamped log entries, and the second time-stamped log entries.

79. The system of claim 78, wherein the patient charting application is configured to store the first time-stamped log entries and the second time-stamped log entries in the patient encounter file.

80. The system of claim 42, wherein the first processor-readable instructions are configured to cause the at least one processor to integrate the at least one specified clinical scoring configuration with a post-case review application.

81. The system of claim 80, wherein the post-case review application is configured to provide a trend report for the one or more score outputs.

82. The system of claim 42, wherein the first processor-readable instructions are configured to cause the at least one processor to integrate the at least one specified clinical scoring configuration with a patient monitoring application implemented at a computing device, the patient monitoring application being configured to provide a visual representation, at a first display of the computing device, of at least a portion of patient information provided at a second display at a medical device when the computing device and the medical device are communicatively coupled.

83. The system of claim 82, wherein the patient monitoring application is configured to provide at least a medical device view tab and a warning score tab, and wherein the first processor-readable instructions are configured to cause the at least one processor to:display the one or more score outputs in a scrollable list in a first portion of the UI that is separate from a second portion of the UI that includes one or more physiologic waveforms in response to a selection of the medical device view tab, and display the at least one user interactive scoring control in response to a selection of the warning score tab.

84. The system of claim 42, wherein the first processor-readable instructions are configured to cause the at least one processor to integrate the at least one specified clinical scoring configuration with a therapy delivery device UI.

85. The system of claim 42, wherein the UI comprises a clinical guidance UI configured to provide caregiver guidance based on an encoded clinical guidance protocol that incorporates the at least one specified clinical scoring configuration.

86. The system of claim 85, wherein the at least one processor is configured to: receive caregiver input from a caregiver and physiologic data from at least one medical device, generate the caregiver guidance based on the caregiver input and the physiologic data, and provide the caregiver guidance with the one or more score outputs.

87. A system for generating clinical early warning score configurations for caregiver guidance in a patient encounter, the system comprising: a clinical score configuration user interface (UI); and at least one non-transitory, processor-readable storage medium having stored thereon first processor-readable instructions, the first processor-readable instructions being configured to cause at least one first processor to: receive a user selection, at the clinical score configuration UI, of an unspecified clinical score configuration comprising a plurality of configuration fields configured to capture score inputs via an end-user application device, receive user specifications at the clinical score configuration UI for the plurality of configuration fields,convert the unspecified clinical score configuration to a specified clinical score configuration based on the user specifications, and export the specified clinical score configuration to at least one resource manager, wherein the specified clinical score configuration comprises second processor- readable instructions configured to cause at least one second processor at the end-user application device to: retrieve the at least one specified clinical scoring configuration from a resource manager, and implement the specified clinical score configuration to: control at least a portion of a user application UI to: display at least one user interactive scoring control at the user application UI, and receive a user selection of the at least one user interactive scoring control, capture the score inputs based on the plurality of configuration fields, generate a score output based on the score inputs, control the at least the portion of the user application UI to display the score output, store the score output in a patient encounter file associated with the user application UI, generate a severity index based on the score output, control the at least the portion of the UI to display the score output, the severity index, and an associated time stamp, and store the score output, the severity index, and the associated time stamp in the patient encounter file associated with the user application.

88. The system of claim 87, wherein the second processor-readable instructions are configured to cause the at least one second processor to implement the specified clinical score configuration to: generate a severity index based on the score output,control the at least the portion of the UI to display the severity index, and store the severity index in the patient encounter file with the score output.

89. The system of claim 87, wherein the second processor-readable instructions are configured to cause the at least one second processor to: implement the specified clinical score configuration to: generate a time stamp for the score output, control the at least the portion of the UI to display the time stamp, and store the time stamp in the patient encounter file with the score output.

90. The system of claim 87, wherein the second processor-readable instructions are configured to cause the at least one second processor to: implement the specified clinical score configuration to: generate the score output as a time trend, control the at least the portion of the UI to display the time trend, and store the time trend in the patient encounter file.

91. The system of claim 87, wherein the second processor-readable instructions are configured to cause the at least one second processor to implement the specified clinical score configuration to generate the score output based on one or more parameter analytics.

92. The system of claim 91, wherein the one or more parameter analytics each comprise one of a change in a physiologic parameter, a slope of a change of a physiologic parameter over time, an average of a physiologic parameter over time, a maximum value of a physiologic parameter over time, or a minimum value of a physiologic parameter over time.

93. The system of claim 87, wherein the second processor-readable instructions are configured to cause the at least one second processor to: communicatively couple to a patient charting device, receive patient history information from the patient charting device, and implement the specified clinical score configuration to adjust a score calculation based on the patient history information.

94. The system of claim 87, comprising: a score configuration fine-tuning GUI; and at least one non-transitory, processor-readable first storage medium having stored thereon third processor-readable instructions, the third processor-readable instructions being configured to cause at least one third processor to: receive a user selection, at the score configuration fine-tuning GUI, of a specified score configuration comprising at least one configuration field, receive user selections, at the score configuration fine-tuning GUI, for the at least one configuration field, convert the specified clinical score configuration to a fine-tuned specified clinical score configuration based on the user selections, and export the fine-tuned specified clinical score configuration to the at least one resource manager.

95. The system of claim 94, wherein the at least one third processor is disposed at the end-user application device.

96. The system of claim 87, wherein the plurality of configuration fields comprise parameter fields, question fields, and score range fields.

97. The system of claim 87, wherein the plurality of configuration fields comprise point assignment fields.

98. The system of claim 87, wherein the plurality of configuration fields comprise parameter operations fields configured to define a generated parameter based on a measured physiologic parameter.

99. The system of claim 98, wherein the parameter operations fields specify one or more of a metric applied to the measured physiologic parameter, a time interval for the metric, and a point assignment for the generated parameter.

100. The system of claim 87, wherein the plurality of configuration fields comprise at least one of a caregiver skill level designation or a clinical category designation.

101. The system of claim 100, wherein the plurality of configuration fields comprise a severity index based on at least one of the caregiver skill level designation or the clinical category designation.

102. The system of claim 87, wherein the plurality of configuration fields comprise configuration fields for at least one measured physiological parameter.

103. The system of claim 87, wherein the plurality of configuration fields comprise configuration fields for steps in a workflow.

104. The system of claim 103, wherein the plurality of configuration fields comprise a workflow grouping configuration field.

105. The system of claim 87, wherein the plurality of configuration fields comprise caregiver guidance fields.

106. The system of claim 105, wherein the plurality of configuration fields comprise at least one browsing control configured to retrieve a caregiver guidance image from a library of the at least one resource manager, and wherein the specified clinical score configuration is configured to cause the at least one second processor to control the at least the portion of the user application UI to display the caregiver guidance image.

107. The system of claim 106, wherein the library comprises one of an instructional library, a medication library, a physiological indications library, a medical device library, or a protocol and score configuration library.

108. The system of claim 105, wherein the plurality of configuration fields are configured to capture instructions for a caregiver, andwherein the specified clinical score configuration is configured to cause the at least one second processor to control the at least the portion of the user application UI to display the instructions for the caregiver.

109. The system of claim 87, wherein the plurality of configuration fields comprise severity index fields.

110. The system of claim 109, wherein the severity index fields are configured to capture a user input of a severity index for a value or range of a clinical score.

111. The system of claim 110, wherein the severity index comprises a color.

112. The system of claim 87, wherein the plurality of configuration fields are user editable graphic fields.

113. The system of claim 87, wherein the at least one resource manager comprises at least one of a platform resource manager, a local resource manager, or an agency resource manager.

114. The system of claim 113, wherein the at least one resource manager comprises the platform resource manager and at least one of the local resource manager or the agency resource manager, and wherein the local resource manager and the agency resource manager are configured to synchronize with the platform resource manager.

115. The system of claim 87, wherein the specified clinical score configuration is associated with user account information, and wherein the at least one first processor is configured to store the specified clinical score configuration in the at least one resource manager according to the user account information.

116. The system of claim 87, wherein the first processor-readable instructions are configured to cause the at least one first processor to provide the specified clinical score configuration to a clinical guidance protocol platform configured to generate an encoded clinical guidance protocol comprising the specified clinical score configuration and at least one sequencing link between the specified clinical score configuration and one or more protocol blocks.

117. The system of claim 116, wherein the at least one sequencing link specifies a workflow sequence that includes a calculation of a clinical score.

118. The system of claim 116, wherein the one or more protocol blocks comprise user- specified triggers for the specified clinical score configuration.

119. The system of claim 116, wherein the one or more protocol blocks comprise user- specified caregiver tasks.Il l

Images