US10937545B2 - Method and system for centralized patient monitoring management - Google Patents

Method and system for centralized patient monitoring management Download PDF

Info

Publication number
US10937545B2
US10937545B2 US16/271,299 US201916271299A US10937545B2 US 10937545 B2 US10937545 B2 US 10937545B2 US 201916271299 A US201916271299 A US 201916271299A US 10937545 B2 US10937545 B2 US 10937545B2
Authority
US
United States
Prior art keywords
monitoring
technician
patient
alarm
station
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
US16/271,299
Other languages
English (en)
Other versions
US20200258624A1 (en
Inventor
Brian D. Janssen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GE Precision Healthcare LLC
Original Assignee
GE Precision Healthcare LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by GE Precision Healthcare LLC filed Critical GE Precision Healthcare LLC
Priority to US16/271,299 priority Critical patent/US10937545B2/en
Priority to CN202010078424.5A priority patent/CN111554396B/zh
Publication of US20200258624A1 publication Critical patent/US20200258624A1/en
Assigned to GE Precision Healthcare LLC reassignment GE Precision Healthcare LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: JANSSEN, BRIAN D.
Application granted granted Critical
Publication of US10937545B2 publication Critical patent/US10937545B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
    • G08B25/14—Central alarm receiver or annunciator arrangements
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/30—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for calculating health indices; for individual health risk assessment
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H80/00—ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring

Definitions

  • the present disclosure generally relates to patient monitoring, and more specifically to methods and systems for centralized patient monitoring management at a centralized monitoring unit (CMU) receiving patient monitoring data from patient monitoring devices for multiple different patients throughout a medical facility or throughout multiple medical facilities.
  • CMU centralized monitoring unit
  • care units use a variety of medical devices to monitor patients and/or to provide therapy to patients. These devices each generate alarms, which range from routine to critical in the severity of the event indicated.
  • Automated alarms can be beneficial to algorithmically determine when an event related to a patient monitoring device or a patient therapy device has occurred. These algorithms generally compare one or more parameters from the medical device to one or more predefined threshold settings, or otherwise conduct pattern matching or other waveform analysis to flag potential issues. Alarm algorithms may be threshold comparisons, but may also include logical combinations and using boolean and/or fuzzy logic and/or pattern matching. These automated alarms can be beneficial to draw clinician attention to the detection and/or occurrence of an event. Additionally, each monitoring, treatment, and/or support device or system may generate alarms regarding a technical problem with the monitoring and/or care delivery device or setup, i.e., a technical alarm. These technical alarms may indicate any of various technical problems, such as disconnection of a sensor device from the patient or from a monitoring device, a low battery, or some other technical issue with the device itself or the connection to the patient.
  • While each alarm may indicate a condition or event of some importance or relevance, a significant number of alarms can be generated during routine care and these alarms place a burden both on patients who may be bothered (e.g., woken up or concerned) by alarm events as well as on clinicians who must divert time and attention from other care tasks or activities to attend to these alarms.
  • a significant number of clinically irrelevant alarms can create alarm fatigue in clinicians whereby the attention to the large volume of alarms can slow recognition or response to alarms, including alarms indicating important or critical events.
  • a centralized monitoring unit (CMU) receiving patient monitoring data from multiple patient monitoring devices includes at least two monitoring technician stations and an assignment management module.
  • Each patient monitoring device provides patient monitoring data for one of multiple patients.
  • the patient monitoring data is received and displayed for each patient in a group of patients assigned to the monitoring technician station.
  • Each monitoring technician station is configured to present alarms for each patient in the group of patients to a CMU technician at the monitoring technician station.
  • the assignment management module is executable by a processing system to calculate a load index for each monitoring technician station based on alarms for patients in the group of patients assigned to the respective monitoring technician station.
  • the load index for each monitoring technician station is calculated based on at least one of a number of alarms at the monitoring technician station, an alarm type of each alarm at the monitoring technician station, a severity of each alarm at the monitoring technician station, and a duration of continuous alarming at the monitoring technician station. Assignment of the multiple patients amongst the at least two monitoring technician stations is then distributed based on the load indexes for each of the monitoring technician stations.
  • a method of centralized patient monitoring management at a CMU includes receiving patient monitoring data from multiple patient monitoring devices, each patient monitoring device providing patient monitoring data for one of multiple patients. Each of the multiple patients are assigned to one of at least two monitoring technician stations. A load index is calculated for each monitoring technician station based on alarms for patients in the group of patients assigned to the respective monitoring technician station. The load index for each monitoring technician station is calculated based on at least one of a number of alarms at the monitoring technician station, an alarm type of each alarm at the monitoring technician station, a severity of each alarm at the monitoring technician station, and a duration of continuous alarming at the monitoring technician station.
  • FIG. 2 is a block diagram representing a central computing system having an assignment management module executable to perform load management functions as described herein.
  • FIG. 3A illustrates an exemplary list of alarm activity over a period of time for an exemplary group of patients assigned to a CMU technician.
  • FIG. 3B illustrates exemplary schedules for calculation of burden values associated with alarm types and care activity types.
  • FIGS. 4-10 depict various embodiments of methods, or portions thereof, of centralized patient monitoring management at a CMU.
  • Medical device alarms are helpful to draw clinician attention to alarms, which may regard technical issues with the patient monitoring arrangement or devices or a physiological event detected in the physiological data recorded from that patient.
  • alarm response can overburden and overwhelm clinicians and present a barrier to effectively managing and responding to alarms, some of which are for critical health-related emergencies. If too many alarms are initiated, clinicians are likely to suffer from alarm fatigue and, if auditory alarms are generated, patients hearing the alarms are likely to become agitated.
  • a centralized monitoring unit receives patient monitoring data from multiple patient monitoring devices connected to multiple different patients and facilitates assessment of alarms for each patient by a CMU technician.
  • the CMU technician assesses the alarm, such as to determine whether the alarm warrants a visit from a clinician to the patient and then facilitates notification of the alarms to a responding clinician.
  • technicians may also become overburdened, especially where the CMU technician may be assigned to a group of patients that is generating an especially high number of alarms or especially burdensome or critical alarms. Accordingly, the inventor has recognized that systems and functions are needed for workload management amongst CMU technicians working at monitoring technician stations in a CMU, including workload estimation, resource assessment, and load balancing.
  • FIG. 1 depicts one exemplary embodiment of a centralized monitoring unit (CMU) 30 in communication with and receiving patient monitoring data, including alarm-related data, from multiple patient monitoring devices 16 .
  • the CMU 30 receives patient monitoring data from multiple patient monitoring devices 16 monitoring multiple different patients 3 at two medical facilities 18 a and 18 b .
  • the CMU 30 may be associated with and receiving patient monitoring data from patient monitoring devices 16 a - 16 c within one medical facility 18 , such as a hospital 18 a .
  • the CMU 30 may be located within the medical facility 18 or may be located remotely.
  • the CMU 30 may receive patient monitoring data from patient monitoring devices 16 at multiple medical facilities, such as from multiple hospitals, outpatient facilities, medical clinics, etc. within a hospital or provider network.
  • the patient monitoring devices 16 may be located in a plurality of medical care units.
  • Each medical care unit may be specific to a particular type of care.
  • Non-limiting examples of medical care units include, but are not limited to, medical telemetry units, step down units, emergency rooms, intensive care units, specialty intensive care units (e.g., cardiovascular ICU), neonatal and/or pediatric care units, post-operative care units, etc.
  • the CMU 30 includes two or more monitoring technician stations (MTSs) 32 (e.g., 32 a - 32 c ).
  • the CMU 30 may receive patient monitoring data from any number of two or more patient monitoring devices 16 a - 16 c collecting and monitoring physiological data from patients 3 a - 3 c .
  • Each patient 3 a - 3 c is assigned via the CMU 30 to one of the MTS 32 a - 32 c such that each MTS 32 a - 32 c has an assigned group of patients for which it facilitates monitoring by a respective CMU technician 36 a - 36 c .
  • a monitoring technician 36 may manually admit a patient to their station, such as seeing that a new patient needs assignment and manually accepting assignment to their respective MTS 32 a - 32 c .
  • the patient monitoring device 16 a - 16 c may be any device collecting and/or assessing physiological data from the patient 3 a - 3 c . Examples include an electrocardiograph (ECG), non-invasive blood pressure monitor (NIBP), invasive blood pressure monitor, Sp02 monitor, electroencephalograph (EEG), respiration monitor, or any other monitoring device capable of collecting physiological or other patient monitoring data.
  • ECG electrocardiograph
  • NIBP non-invasive blood pressure monitor
  • Sp02 monitor invasive blood pressure monitor
  • EEG electroencephalograph
  • respiration monitor or any other monitoring device capable of collecting physiological or other patient monitoring data.
  • multiple patient monitoring devices may be connected to each patient 3 a - 3 c .
  • the patient monitoring data from each patient monitoring device 16 a - 16 c is transmitted to the CMU 30 , such as via the computer network of the
  • a CMU technician 36 operates each MTS 32 in order to review patient monitoring data and assess alarms from multiple different patients (e.g., 3 a - 3 c ).
  • the CMU technician 36 assess the patient monitoring data from patient monitoring devices 16 for each patient 3 in a group of patients admitted or assigned to the CMU technician's MTS 32 .
  • the first MTS 32 a may be configured to receive and display patient monitoring data for each patient 3 a - 3 c in a group of patients 5 assigned thereto, and present alarms for each patient 3 a - 3 c in the group of patients 5 to the CMU technician 36 a .
  • the CMU technician 36 a then assesses the patient monitoring data associated with each alarm.
  • an alarm notification may also be sent automatically to the caregiver or care team via a secondary alarm notification system; however, in most cases, the technician 36 a will still need to conduct some level of assessment.
  • the CMU technician 36 a assesses the patient monitoring data to determine whether the alarm is one that needs to be responded to by a responding clinician or technician, or whether the alarm is a false alarm (e.g., caused by a noisy signal) or otherwise does not require a visit to the patient's location by a clinician (to physically assess and/or treat the patient) or technician (to assess the patient monitoring device and/or sensors attached to the patient).
  • the CMU 30 includes a central computing system 40 comprising an assignment management module 42 , which is a software module comprising computer executable instructions for managing workload assignments to the two or more monitoring technician stations 32 a - 32 c .
  • Each monitoring technician station (MTS) 32 a - 32 c comprises one or more display(s) 33 that visually present patient monitoring data for various patients to a CMU technician 36 a - 36 c .
  • Each MTS 32 a - 32 c further includes one or more user input devices 34 through which the CMU technician can input information and/or navigate the central monitoring user interface provided on the graphical display(s) 33 .
  • Each CMU technician 36 a - 36 c assesses the patient monitoring data relevant to each alarm and documents, where appropriate, the assessment via the user input devices at the MTS 32 , such as a mouse, keyboard, touchpad, touchscreen, voice recognition system, or any other standard or non-standard user input device or system.
  • the documentation could be conducted on paper.
  • each MTS 32 a - 32 c includes its own computing system that is communicatively connected to the central computing system 40 and runs the displays 33 and receives input from the user input devices 34 in order to facilitate the functions of the CMU technician 36 a - 36 c operating the respective MTS 32 a - 32 c .
  • each MTS 32 a - 32 c may operate on the central computing system 40 , which may be configured to run multiple instances of the centralized monitoring user interface—e.g., a cloud computing environment.
  • Each MTS 32 is configured to facilitate assignment of alarm response or other patient treatment or assessment to at least one responding clinician 8 , which may be a care team comprised of more than one clinician.
  • the CMU technician 36 may operate the centralized monitoring user interface provided at the MTS 32 to link a responding clinician 8 to an alarm for a patient.
  • the centralized monitoring user interface may facilitate communication between the CMU technician 36 and the responding clinician 8 , such as by allowing text and/or voice communication between each MTS and a clinician device 48 , such as a smart phone or other personal computing device.
  • each responding clinician assignment may stay with each patient, regardless of any transfer of patients or patient groupings among MTSs 32 a - 32 c .
  • the notifications for alarm responses for a particular patient may move with the patient automatically when the patient gets reassigned to a different MTS 32 a - 32 c such that the notifications continue to be routed to the same responding clinician or group of clinicians.
  • Each of the patient monitoring devices 16 are exemplarily communicatively connected by a local network which may be operated by a local server 20 which may exemplarily handle and process the data from each of the patient monitoring devices 16 in an area, such as in a hospital or care unit.
  • the local server 20 may be in direct communication with the central computing systems 40 .
  • a communications gateway 22 may communicatively connect the local server 20 to the central computing system 40 of the CMU 30 . As also illustrated in FIG.
  • Each patient 3 a - 3 c for which patient monitoring data is being received is assigned to one of the MTSs 32 a - 32 c for review by the respected CMU technician 36 a - 36 c manning that MTS.
  • each MTS 32 a - 32 c has a group of two or more patients 3 a - 3 c assigned thereto.
  • a representative group 5 of patients 3 a - 3 c is assigned to a first one of the MTSs 32 a
  • other groups of patients (not shown) are assigned to each of the other two MTSs 32 b - 32 c .
  • the assignment management module 42 operates as described herein to calculate a load index for each MTS 32 a - 32 c and redistribute patient assignments to the various MTS 32 a - 32 c based on the load indexes and the active alarms so as to efficiently and effectively distribute an overall alarm load for the CMU 30 across all of the MTSs 32 a - 32 c operated by a CMU technician 36 a - 36 c .
  • a patient may be initially assigned to a particular monitoring technician station 32 a - 32 c upon intake, that assignment may change over time based on the overall alarm load and/or based on loading at any particular MTS 32 a - 32 c .
  • a patient may be initially assigned to a monitoring technician station 32 a - 32 c that has the lowest load index at the time of assignment, such as upon intake of the patient or upon receipt of initial monitoring data for that new patient.
  • the initial assignment or admission may be based on the expertise of the monitoring technician 36 a - 36 c manning each respective MTS 32 a - 32 c .
  • the initial assignment of a new patient to an MTS 32 a - 32 c may be performed automatically by the assignment management module 42 , such as based on the current load indexes based on the current assignments, or suggest the MTP to which to assign the patient for confirmation by a system manager or administrator overseeing assignment prior to executing the assignment.
  • the continual monitoring for that patient over time may then be transferred to various MTSs 32 a - 32 c based on a load index for each MTS 32 a - 32 c , a forecasted load index for each MTS 32 a - 32 c , an overall alarm load for the CMU 30 , particular skill levels and/or expertise of CMU technicians 36 a - 36 c (who may change shifts, etc.), or any other various factors disclosed herein.
  • the CMU 30 houses an assignment management module 42 comprising computer executable instructions housed in software 202 and executable by one or more processors 44 comprised in a processing system 206 .
  • the assignment management module 42 is configured to receive patient monitoring data 50 and various other inputs and schedules and to calculate load indexes 72 , one for each MTS 32 of the CMU 30 , and to make MTS assignments 70 of patients 3 to each MTS 32 in order to distribute an alarm load for the CMU 30 .
  • the assignment management module 42 receives active alarm notifications 52 for each patient 3 being monitored at one of the MTSs 32 .
  • the active alarm notification 52 identifies one or more of the alarming device and type of alarm, and may also identify the physiological measurement values that triggered the alarm, especially for limit alarms (see FIG. 5B and associated discussion below).
  • the active alarm notification 52 may also identify a patient 3 a with which the alarm is related.
  • the assignment management module 42 then calculates a load index 72 for each MTS 32 based on the active alarms being handled there. In certain embodiments, the load index 72 for each MTS 32 may be calculated based further on technician response inputs 54 by the CMU technician at the respective MTS 32 .
  • the technician response inputs 54 may include acknowledgments of an active alarm and other inputs to the centralized monitoring user interface at the respective MTS 32 for assessment of an active alarm, such as to review patient monitoring data for the patient and/or patient health or other related information considered as part of the alarm assessment.
  • the technician response inputs 54 may include window or button selections, information input, etc. via the user input device(s) 34 at the MTS 32 . Such information may be tracked in order to determine what review and response actions have been taken by the CMU technician 36 .
  • the technician response inputs 54 may further include clinician communication, such as communication with a responding clinician 8 or responding technicians, and/or consultation with other clinicians, technicians, or subject matter experts. Such information may be considered when calculating the load index 72 , such as to determine an actual response time 78 —i.e., an actual amount of time that responding to a particular alarm has consumed. In certain embodiments, the load index 72 may also be calculated based on the total duration of continuous alarming experienced at the MTS 32 , which is the total time that alarms have been continuously handled by the CMU technician 36 without time therebetween or with less than a predetermined amount of time between alarms.
  • an expected response duration may be provided in one or more burden value schedules 58 .
  • Burden value schedules 58 (exemplified at FIG. 3B ) provide expected response information for each of various alarm types that could be generated by the patient monitoring devices 16 providing patient monitoring data 50 to the CMU 30 .
  • the burden value schedule 58 may provide an expected response duration for each alarm type listing an expected amount of time required to assess an active alarm, determine whether a clinician response is needed, and hand off the matter to a responding clinician 8 .
  • the burden value schedule 58 may further identify an expected complexity of an alarm type, such as to represent how much attention and energy will be required by the CMU technician 36 to assess and/or assign an active alarm of the particular alarm type. Additionally, the burden value schedule 58 may specify an expected documentation duration by alarm type, such as to specify a duration required to complete documentation of the technician's assessment and assignment and/or document any other information relevant to an alarm. For example, the expected documentation duration may represent the period of time required after assignment of an alarm to a responding clinician 8 and/or determination that no clinician response is necessary and silencing or termination an alarm condition.
  • the assignment management module 42 may consider the burden value schedule 58 when calculating the load index 72 for each MTS 32 , such as to determine a burden value for each active alarm being addressed at the MTS 32 , which is based on the type of each respective alarm and indicates the estimated burden on the CMU technician 36 caused by each respective alarm.
  • the assignment management module 42 may be configured to further assess a load threshold schedule 60 in determining the load index and/or determining a load threshold for each individual MTS 32 to which the respective load index should be compared.
  • the load threshold schedule 60 may list information regarding the skill level of the CMU technician 36 at the respective MTS 32 . The skill level information may be used in various ways.
  • the skill level information may be utilized to modify the information in the burden value schedule 58 .
  • a multiplier may be provided to information in the burden value schedule 58 based on the technician skill level to account for the varied abilities of the technicians (e.g., 36 a - 36 c ) who may be responding to alarms.
  • the technicians e.g., 36 a - 36 c
  • an inexperienced technician may take longer to assess and respond to an alarm and the complexity of their response may increase, such as due to the need to consult with another technician and/or a subject matter expert.
  • an experienced technician may be able to assess and respond to an alarm condition more quickly and efficiently.
  • the burden value calculated for an inexperienced technician may be higher than for an experienced technician for the same alarm type.
  • a patient burden value may be calculated for each patient, and the assignment management module 42 may then calculate the load index 72 for each MTS 32 as the total of the patient burden values for the patients assigned thereto.
  • FIG. 10 is a flow chart illustrating one such example where load index 72 is calculated based on patient-specific values.
  • a patient burden value is calculated for each patient at step 180 .
  • the patient burden value may be calculated based on an alarm burden schedule as described herein. Referencing FIG. 3A as an example, a burden value may be calculated for each patient (e.g., patient 234 , patient 345 , etc.) based on the listed activity for that patient and using appropriate burden schedules.
  • a load index is calculated at step 184 .
  • the load index 72 for a respective MTS 32 is determined based on the patient burden values, such as the sum of the patient burden values for the group of patients 5 assigned to a particular MTS 32 .
  • the load index 72 is then compared to a threshold at step 186 to identify whether there are any overloaded MTSs 32 .
  • the assignment management manager may then determine and provide, through optimization algorithms, reassignment recommendations, balancing the load levels of the MTSs in the CMU.
  • the technician skill level may be utilized to calculate a load threshold for each technician to which the load index is compared. For example, an inexperienced CMU technician 36 may be assigned a lower load threshold than an experienced technician.
  • the load index 72 calculated for each MTS 32 may be compared to the load index assigned to the CMU technician 36 working at that MTS 32 . If the load index 72 exceeds the respective load threshold, then that MTS 32 may be identified as an overloaded MTS indicating a need for reassignment of one or more patients in order to adjust the alarm load distribution.
  • the load threshold schedule 60 may further include other load balancing factors and/or equations, such as to account for various considerations when assigning burden value for each active alarm and/or load threshold for each CMU technician 36 .
  • additional load balancing factors could include modifiers to account for factors such as clinician fatigue (e.g., to lighten a load on a clinician after a period of high stress or high load).
  • the load threshold schedule 60 may include equations and/or other information on how to balance an overall alarm load across all MTS 32 a - 32 c of the CMU 30 . Additional factors may be considered in addition to load index 72 , such as the differences between load indexes amongst the various MTS 32 a - 32 c .
  • the load threshold schedule 60 may include a threshold difference between load indexes 72 that may also trigger a load rebalancing.
  • Load rebalancing may further account for forecasted values indicating future load, and thus rebalancing may occur prior to a load index 72 exceeding a load threshold.
  • the assignment management module 42 may calculate a forecasted load index 74 for each MTS 32 .
  • the forecasted load index may account for any of several factors, including an actual response time 78 and/or technician response inputs 54 .
  • a technician may indicate that a response will exceed the expected response duration and/or has an unusually high complexity based on the particular alarm type.
  • the load index 72 or forecasted load index 74 may be modified upwards accordingly, alternatively or additionally, the forecasted load index 74 may account for alarm probabilities 76 , which indicate the probability of an alarm being generated within a predetermined future time period based on the patient monitoring data 50 or related patient information.
  • alarm probabilities 76 may be increased for certain monitoring devices as the monitored values approach an alarm limit.
  • alarm probabilities 76 may be increased for a particular patient or patient monitoring device 16 based on the other active alarms for that patient 3 and/or based on patient information such as diagnosis or medical history.
  • a critical ECG alarm may be closely followed by alarms generated by other patient monitoring devices, such as blood pressure and/or SpO2.
  • high alarm probability values may account for those subsequent alarms, which may be reflected in the forecasted load index 74 for a particular MTS 32 .
  • certain alarms may be more likely in predefined conditions for patients with certain diagnoses or medical histories.
  • the alarm probability 76 may account for such information, and thus may increase when those predefined conditions or patterns are detected.
  • the assignment management module 42 may also receive or calculate an overall alarm load 80 representing the alarm load across all MTS 32 a - 32 c .
  • the overall alarm load 80 is a total of all load indexes 72 for the current operating MTS 32 a - 32 c for the CMU 30 .
  • the overall alarm load 80 may be determined based on the load indexes 72 , and in some embodiments also the forecasted load indexes 74 .
  • the assignment management module 42 may be configured to account for the overall alarm load 80 for the CMU 30 , such as to ensure that the load is not inequitably distributed to otherwise carried more by certain CMU technicians 36 may in others.
  • the load determination is made based on burden value schedules indicating factors to be accounted for when assessing load.
  • FIG. 3B depicts exemplary burden value schedules 58 providing a non-exhausted list of alarm types and other care activity types that a CMU technician 36 might engage in such that most or all of the demands on the CMU technician are accounted for in the load index 72 calculation.
  • Each alarm type and/or activity type is associated with various information that may be considered in determining the burden value for each active alarm.
  • the burden schedules list an expected response duration and an expected documentation duration for each alarm type.
  • the burden value schedules 58 may further contain an expected complexity value and/or allow calculation of an expected complexity based on the values indicated therein.
  • each alarm type and care activity type is classified into one of three expected complexity values, being low, medium, and high. Higher complexity values can be reflected in a higher burden value associated with the alarm type.
  • the burden value schedules 58 may be configured and provided upon installation of a CMU 30 and maintained and updated as part of system maintenance. Alternatively or additionally, the schedules may be configurable, such as by a system administrator for the CMU 30 . Thus, the burden value schedules 58 may be adjusted to account for particular realities in the healthcare environment in which the CMU 30 is operated. In still other embodiments, the assignment management module 42 may be configured to automatically adjust the burden value schedules 58 based on actual occurrences and operation at the CMU 30 .
  • the assignment management module 42 may employ machine learning algorithms to update the burden schedules 58 , such as to update the expected response durations and/or expected documentation duration values in the burden schedule based on actual response times 78 for the various alarm types and actual documentation durations.
  • the complexity values may be updated, such as based on the technician response inputs 54 measured for certain alarm types compared to the expected response inputs reflected in the burden value schedule 58 .
  • machine learning may be employed to maintain a burden value schedule 58 for each CMU technician 36 a - 36 c , such as to accurately predict the response and documentation times for that technician, and thus more accurately predicts the amount of load that the respective technician 36 a - 36 c can effectively handle.
  • FIG. 3A provides an exemplary list of alarm activity detail for a group of patients 5 assigned to a particular MTS 32 .
  • the group of patients 5 consists of four patients, identified as patient 234 , patient 345 , patient 456 , and patient 567 .
  • a number of alarms are generated for each patient.
  • the alarm activity schedule lists various alarm notification information 52 , including alarm type and alarm start time. Certain additional information is also provided summarizing certain activity totals for each alarm event, including the total alarm time and the number of alarm escalations, which represent the number of persons, such as responding clinicians or technicians 8 , who were called in or tasked to respond to the alarm.
  • Such escalation information and total time information may be utilized, for example, by the machine learning algorithm to modify the burden schedule 58 , which may be on a per-alarm-type basis and/or on a per-technician basis.
  • FIG. 2 is a block diagram representing an exemplary central computing system 40 of a CMU 30 having an assignment management module 42 executable to operate as described herein.
  • the central computing system 40 includes a processing system 206 , storage system 204 , software 202 , and a communication interface 208 .
  • the processing system 206 loads and executes software 202 from the storage system 204 , including the assignment management module 42 , which is an application within the software 202 .
  • the module 42 includes computer-readable instructions that, when executed by the computing system 40 (including the processing system 206 ), direct the processing system 206 to operate as described in herein in further detail, including to determine the load index 72 for each MTS 32 and to manage the load distribution among the MTSs 32 accordingly.
  • central computing system 40 as depicted in FIG. 2 includes one software 202 encapsulating one assignment management module 42 , it should be understood that one or more software elements having one or more modules may provide the same operation.
  • the processing system 206 includes the processor 44 , which may be a microprocessor, a general purpose central processing unit, an application-specific processor, a microcontroller, or any other type of logic-based device.
  • the processing system 206 may also include circuitry that retrieves and executes software 202 from storage system 204 .
  • Processing system 206 can be implemented within a single processing device but can also be distributed across multiple processing devices or sub-systems that cooperate in executing program instructions.
  • the storage system 204 which stores the database 43 housing various schedules 58 , 60 and information necessary to facilitate the assignment management and load balancing activities by the assignment management module 42 , can comprise any storage media, or group of storage media, readable by processing system 206 and capable of storing software 202 .
  • the storage system 204 can include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data.
  • Storage system 204 can be implemented as a single storage device but may also be implemented across multiple storage devices or sub-systems.
  • the software 202 may be stored on a separate storage device than the database 43 housing the schedules 58 , 60 .
  • database 43 can be stored, distributed, and/or implemented across one or more storage media or group of storage medias. Similarly, database 43 may encompass multiple different sub-databases at different storage locations and/or containing different information which may be stored in different formats.
  • Storage system 204 can further include additional elements, such a controller capable of communicating with the processing system 206 .
  • Examples of storage media include random access memory, read-only memory, optical discs, flash memory, virtual memory, and non-virtual memory, magnetic sets, magnetic tape, magnetic disc storage or other magnetic storage devices, or any other medium which can be used to store the desired information and that may be accessed by an instruction execution system, as well as any combination or variation thereof, or any other type of storage medium.
  • the storage media may be housed locally with the processing system 206 or may be distributed in one or more servers, which may be at multiple locations and networked, such as in cloud computing applications and systems.
  • the storage media can be a non-transitory storage media. In some implementations, at least a portion of the storage media may be transitory.
  • the communication interface 208 interfaces between the elements within the central computing system 40 and external devices, such as the communications gateway 22 at various medical facilities 18 a , 18 b in order to receive patient monitoring data 50 and/or active alarm notification data 52 .
  • the communication interface 208 may also interface with the computing systems of the MTSs 32 a (which in certain embodiments described above, may each comprise its own computing system or in other embodiments may all be facilitated in a cloud computing environment).
  • the central computing system 40 may be associated with a user interface, such as for receiving input from and communicating information to a system administrator.
  • the central computing system 40 may be associated with one or more displays 46 , which may display various dashboards and/or other display tools indicating various statistics and information about the current load indexes 72 of the MTSs 32 and the overall alarm load 80 or load distribution status for the CMU 30 .
  • Each user interface for the central computing system 40 may include a mouse, a keyboard, a voice input device, a touch input device for receiving a gesture from a user, a motion input device for detecting non-touch gestures and other motions by a user, and other comparable input devices and associated processing elements capable of receiving input from a user, such as a clinician.
  • Output devices such as video displays can display an interface further associated with embodiments of the system and method as disclosed herein. Speakers, printers, haptic devices and other types of output devices may also be included in the user interface.
  • FIGS. 4-9 provide flowcharts exemplifying embodiments of methods 100 , or portions thereof, of centralized patient monitoring management at a CMU 30 .
  • FIG. 4 depicts one exemplary method at a high level, where a load index is calculated and an overall alarm load is redistributed accordingly.
  • instructions are executed to access a list of active MTSs 32 and corresponding CMU technicians 36 assigned thereto.
  • the group of patients assigned to each MTS is accessed at step 102 , and a load index is calculated at step 103 for each MTS 32 .
  • Step 104 is executed to detect an overloaded MTS (e.g., 32 a ), after which at least one patient is removed from the overloaded MTS 32 a at step 105 and reassigned to a different MTS 32 b - 32 c at step 106 —i.e., changing the MTS assignment 70 for that patient.
  • an overloaded MTS e.g., 32 a
  • various methods may be employed for calculating the load index 72 and detecting an overloaded MTS.
  • various algorithms may be employed to determine which patient or patients should be removed from the overloaded MTS, and where those patients should be reassigned.
  • the reassignment may be executed automatically by the central computing system 40 upon detecting an overloaded MTS, in other embodiments the central computing system may seek approval input from on or more CMU technicians 36 or an administrator prior to executing the reassignment.
  • FIGS. 5A and 5B depict exemplary steps for identifying an overloaded MTS and a low-load MTS in order to adjust the distribution of patients among the MTS.
  • a load threshold is determined for each MTS 32 a - 32 c at step 110 .
  • the load threshold for each MTS 32 a - 32 c may be determined and set based on skill level of the CMU technician 36 a - 36 c at the respective MTS 32 a - 32 c and/or other information contained in the load threshold schedule 60 .
  • the load index 72 calculated for each MTS 32 is compared to its corresponding load threshold at step 111 . Overloaded MTS are identified at step 112 based on that comparison.
  • an overloaded MTS may be any MTS 32 for which the load index 72 meets or exceeds the respective load threshold determined for that MTS 32 .
  • One or more low-load MTSs are identified at step 113 , such as the one or more MTSs with the largest difference between the load index and the load threshold for that MTS (where the load index is less than the load threshold).
  • the low-load MTS may be identified based on a percentage basis, rather than an absolute value basis, to account for the variation in load thresholds between the CMU technicians 36 a - 36 c . Instructions are then executed at step 114 to remove at least one patient from the overloaded MTS and assign that patient to the low-load MTS.
  • the exemplary method steps in FIG. 5B employ a different method of assessing load index and identifying overloaded MTS.
  • a burden value is determined at step 118 for each active alarm, such as based on the alarm type of each active alarm and the burden value schedule 58 .
  • Step 119 is then executed to modify the burden value by the skill level of the technician, such as by multiplying the burden value calculated based on the burden value schedule 58 by a multiplier value determined based on the technician skill level from the load threshold schedule 60 .
  • the load index 72 may be assigned as the modified burden value for each alarm for all of the patients in the group of patients assigned to the MTS 32 .
  • the load index may be calculated to only account for the more serious and burdensome alarms being addressed at the MTS 32 .
  • the load index is determined based on a number of alarms above a threshold modified burden value. Either way, the load index determined based on the modified burden value already accounts for the various skill levels of the technicians, and any other burden factors dictated by the load threshold schedule 60 discussed above.
  • the load indexes for the various MTSs 32 can be directly compared to one another in order to determine whether the load distribution needs to be adjusted.
  • the assignment management module 42 may be configured to determine a mean load index and compare the load indexes 72 for each MTS 32 to the mean value in order to identify one or more overloaded MTS and one or more low-load MST, which is represented at step 122 .
  • a threshold deviation from the mean may be set to account for natural and tolerable deviations in load.
  • the overloaded MTS and low-load MTS may be identified as MTS with load indexes that deviate from the mean by more than the threshold amount or threshold percentage.
  • one or more patients are removed from the overloaded MTS and assigned to the low-load MST at step 123 .
  • FIG. 6 is a flowchart representing exemplary steps for calculating load threshold to account for technician skill level. Instructions are executed at step 130 to identify the CMU technician 36 a - 36 c assigned to a respective MTS 32 a - 32 c . A skill level value is accessed for each CMU technician at step 131 , such as may be comprised in the load threshold schedule 60 discussed above. One or more threshold modifier values are determined at step 132 based on the skill level and the load threshold is calculated at step 133 . For example, a default load threshold may be provided and may be multiplied by the threshold modifier value in order to account for the skill level. Other load balancing factors may be accounted for similarly, where a threshold modifier value may be determined at step 132 to account for multiple load balancing factors.
  • FIG. 7 is a flowchart depicting one embodiment of a load index 72 calculation that accounts for the skill level and/or other load threshold values in the load index calculation, rather than in the load threshold calculation depicted in the example at FIG. 6 .
  • a burden value is determined at step 138 and the burden value is multiplied by a skill level factor at step 139 .
  • the actual response time for each alarm is determined at step 140 and compared to the expected response duration in the burden value schedule 58 . If there is a difference between the actual response time for any one alarm and the expected response duration in the burden value schedule, modified by the skill level factor, then an adjustment is made accordingly.
  • the load index is then calculated for each MTS at step 141 based on the adjusted burden value. Similar adjustments may be made to the expected complexity and expected documentation duration values in the burden value schedule 58 in order to arrive at the load index for each MTS.
  • FIG. 8A depicts one embodiment of a method for identifying which patient to remove from an overloaded MTS.
  • a group of patients assigned to an overloaded MTS is identified at step 146 .
  • all unattended alarms for the MTS are identified at step 147 , which are active alarms not yet responded to by the CMU technician 36 . This finds the active alarms for which the clinician has not yet commenced assessment, such as due to being overloaded and busy responding to other alarms.
  • the most critical unattended alarm at the MTS is identified at step 148 .
  • Step 149 is executed to determine whether the identified critical alarm is for the same patient as another active alarm being responded to at the MTS.
  • step 150 is executed to identify the next most critical unattended alarm at the MTS.
  • the next most critical alarm is again assessed at step 149 to determine whether it is generated by the same patient as an alarm being responded to at the MTS. If not, then the patient associated with the identified alarm at step 149 is removed from the overloaded MTS at step 151 and reassigned to a different MTS at step 152 .
  • the method may identify the oldest pending alarm not yet responded to at the MTS instead of the most critical alarm not yet responded to, and may generally follow the same assessment steps to identify an alarm that can be removed from the overloaded MTS without disrupting the CMU technician or negatively impacting patient care.
  • FIG. 8B depicts another embodiment of a method for identifying which patient to remove from an identified overloaded MTS.
  • the group of patients assigned to the overloaded MTS 32 is identified at step 160 .
  • one or more patients that are not currently alarming are identified at step 161 .
  • An alarm probability is then calculated for each monitoring device associated with one of the non-alarming patients at step 162 .
  • the patient with the highest alarm probability is identified at step 163 .
  • the highest alarm probability is then removed from the overloaded MTS at step 164 and is reassigned to a different MTS at step 165 .
  • the reassignment may be executed automatically so as to provide automated load management, in other embodiments the central computing system may seek approval input from on or more CMU technicians 36 or an administrator prior to executing the reassignment.
  • the assignment management module 42 may be configured to generate a prompt at each of the overloaded and reassigned MTSs 32 seeking approval input prior to executing the reassignment.
  • the assignment management module 42 may be configured to generate a prompt to a system manager or administrator overseeing assignments, or otherwise seek input from such an individual, prior to executing the reassignment.
  • FIG. 9 depicts an exemplary embodiment of method steps for determining a forecasted load index for each MTS 32 .
  • Step 170 is executed to determine an expected response duration for each active alarm at a respective MTS.
  • the expected response duration for each active alarm may be the value provided in the burden value schedule 58 based on the response type of each active alarm.
  • the expected response duration for each active alarm may be adjusted at step 171 based on the actual response time for each active alarm, for example if an alarm response is not on track or has already gone over the expected response duration, then the alarm response can be expected to take longer than the expected response duration, and thus the expected end time of the alarm can be adjusted accordingly.
  • the alarm probability is then determined at step 172 for each patient monitoring device associated with each patient in the group of patients assigned to the respective MTS.
  • Various methods for determining alarm probability are described above, such as based on the patient monitoring data being sent by a particular patient monitoring device and/or based on one or more active alarms being generated for a particular patient.
  • a forecasted load index is then calculated for each MTS at step 173 based on the alarm probabilities and the modified expected response durations.
  • the forecasted load index is compared to the load threshold for the respective MTS at step 174 to determine whether load rebalancing is needed. For example, if the forecasted load index exceeds the load threshold then it can be expected that the corresponding MTS is likely to become an overloaded MTS. This situation can be addressed in advance of overloading the MTS by moving one or more patients likely to generate an alarm away from the MTS nearing its load threshold to one or more different MTSs with lower load indexes or forecasted load indexes.
  • a number of MTSs needed may be calculated, and MTSs may be added or removed based on that need.
  • the number of MTSs needed may be determined based on the load indexes 72 and current patient load for the MTSs 32 , such as whether the current patient load is manageable (considering completion of any needed or suggested rebalancing and reassignments as described herein) such that the load indexes 72 can be maintained at or sufficiently below their respective thresholds.
  • the determination of the number of MTSs 32 needed may also account for the forecasted load index.
  • the assignment management module 42 may determine that a new station can be added, or activated, to the CMU 30 (such as by adding an additional CMU technician 36 ). In this case, the assignment management module provides recommended patient reassignments to the newly activated MTS, thereby rebalancing the loads of the MTSs in the CMU. Conversely, if the current number of patients and alarms is such that the MTSs 32 are operating well below their respective thresholds, then then the assignment management module 42 may determine that one of the MTSs 32 can be removed from operation of the CMU 30 (such as by relieving a CMU technician 36 ).

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Medical Informatics (AREA)
  • Public Health (AREA)
  • Business, Economics & Management (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • General Business, Economics & Management (AREA)
  • Pathology (AREA)
  • Emergency Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)
US16/271,299 2019-02-08 2019-02-08 Method and system for centralized patient monitoring management Active US10937545B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/271,299 US10937545B2 (en) 2019-02-08 2019-02-08 Method and system for centralized patient monitoring management
CN202010078424.5A CN111554396B (zh) 2019-02-08 2020-02-03 用于集中患者监测管理的方法和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US16/271,299 US10937545B2 (en) 2019-02-08 2019-02-08 Method and system for centralized patient monitoring management

Publications (2)

Publication Number Publication Date
US20200258624A1 US20200258624A1 (en) 2020-08-13
US10937545B2 true US10937545B2 (en) 2021-03-02

Family

ID=71945304

Family Applications (1)

Application Number Title Priority Date Filing Date
US16/271,299 Active US10937545B2 (en) 2019-02-08 2019-02-08 Method and system for centralized patient monitoring management

Country Status (2)

Country Link
US (1) US10937545B2 (zh)
CN (1) CN111554396B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11622734B2 (en) * 2020-02-27 2023-04-11 GE Precision Healthcare LLC Methods and systems for monitoring compliance
US20210391063A1 (en) * 2020-06-15 2021-12-16 Koninklijke Philips N.V. System and method for dynamic workload balancing based on predictive analytics
US20220087644A1 (en) * 2020-09-24 2022-03-24 GE Precision Healthcare LLC Systems and methods for an adaptive interface for an ultrasound imaging system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130197942A1 (en) * 2012-01-30 2013-08-01 Ross Medical Corporation Dynamic risk management and resource allocation and treatment system and method
US20150244993A1 (en) * 2011-12-19 2015-08-27 Careview Communications, Inc Electronic patient sitter management system and method for implementing
US20170098358A1 (en) * 2015-10-01 2017-04-06 Cerner Innovation, Inc. Generating informative alarm notifications to identify patient need and data quality
US9852265B1 (en) * 2016-09-30 2017-12-26 General Electric Company System and method of medical device alarm management

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150244993A1 (en) * 2011-12-19 2015-08-27 Careview Communications, Inc Electronic patient sitter management system and method for implementing
US20130197942A1 (en) * 2012-01-30 2013-08-01 Ross Medical Corporation Dynamic risk management and resource allocation and treatment system and method
US20170098358A1 (en) * 2015-10-01 2017-04-06 Cerner Innovation, Inc. Generating informative alarm notifications to identify patient need and data quality
US9852265B1 (en) * 2016-09-30 2017-12-26 General Electric Company System and method of medical device alarm management

Also Published As

Publication number Publication date
CN111554396B (zh) 2023-12-05
US20200258624A1 (en) 2020-08-13
CN111554396A (zh) 2020-08-18

Similar Documents

Publication Publication Date Title
US8612254B2 (en) System and method to manage a quality of delivery of healthcare
US20080139898A1 (en) System and Method For Providing Centralized Physiological Monitoring
US20090093686A1 (en) Multi Automated Severity Scoring
US10271799B2 (en) Patient alarm data application
US20060253301A1 (en) System and method for managing alert notifications in an automated patient management system
US10937545B2 (en) Method and system for centralized patient monitoring management
KR101261177B1 (ko) 임상 의사결정 지원 시스템 및 방법
EP2929476B1 (en) A method and system to reduce the nuisance alarm load in the clinical setting
CA2654679A1 (en) Patient monitoring
CA2942983C (en) System and method for managing illness outside of a hospital environment
US20230053474A1 (en) Medical care system for assisting multi-diseases decision-making and real-time information feedback with artificial intelligence technology
US20200373006A1 (en) Medical information processing system
US11837359B2 (en) Method and system for centralized patient monitoring management
US20180314801A1 (en) Healthcare resource tracking system and method for tracking resource usage in response to events
Salman et al. Internet of medical things based telemedicine framework for remote patients triage and emergency medical services
US11298087B2 (en) Method and system for predicting physiological alarm frequency by patient monitors
US11699528B2 (en) Falls risk management
US20220310241A1 (en) Clinical decision support scheduling and alerts
CN118098461A (zh) 基于人工智能的临床患者状态监测方法及系统

Legal Events

Date Code Title Description
FEPP Fee payment procedure

Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

AS Assignment

Owner name: GE PRECISION HEALTHCARE LLC, WISCONSIN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:JANSSEN, BRIAN D.;REEL/FRAME:053846/0695

Effective date: 20190207

STCF Information on status: patent grant

Free format text: PATENTED CASE

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4