This is an old revision of the document!
DDS
Patient Monitoring in a Maturing Digital World
Author | Matt Grubis |
---|---|
Title | Chief Engineer |
Organization | GE Healthcare |
Date | 29 Apr 2020 |
Time | 33 Minutes |
Presentation | Connected Healthcare - DDSF BrightTalk |
Docment | DDS in Patient Monitoring |
A patient monitoring system typically consists hundreds, sometimes thousands of interconnected physiological acquisition devices (bedside monitors), real-time clinical viewers with command and control of the ecosystem (central stations), and event annunciation (sounding clinical and system alarms) to a plurality of locations, based on caregiver workflows. The Data Distribution Service (DDS) middleware’s Data-Centric, network-based state management is fundamental to the reliability, robustness and distributed operation of a system designed to make life-critical decisions and provide clinical information for further care.
It is important to understand the motivation behind patient monitoring. It is not as an academic exercise or a nice-to-have but necessity for helping clinicians make the most informed decisions during life critical treatments: in emergency departments; Intensive Care Unit (ICU); in operating rooms; during anesthesia recovery; and, through out the birthing process for mothers and neonatals.
During patient monitor medical devices are attached to patients. The devices measure and collect vital signs and physiological states about patients in real-time.
The monitors used in Patient monitoring systems are a perfect examples of Internet of Medical Things (IoMT). The monitors measure and collect vital signs and physiological states about patients in real-time using wave forms and other digital formats of data. These devices by nature reside on the edge referred to in Edge Computing.
The following are the basic constraints that apply to patient monitoring systems:
The monitors must be well defined endpoints within an overall seamless integrated patient monitoring ecosystem.
The current GE ecosystem has three main components:
An architectural decision to use the Data Distribution Service (DDS) is based on the basic constraints of the patient monitoring system and the understanding that the infrastructure is life critical. DDS is a foundational component that provided the support for well defined endpoints, real-time processing, redundancy, reliability and availability and allowed for the leveraging of exiting IoMT technology.
A man was playing racquet ball and hurts his leg, He goes to Emergency Room (ER) where he is given something to manage the pain. He is provided a self administering plunger that allows him to push a button to get a dose of morphine or other opioid. However, each individual's body reacts differently to the drugs based on their metabolism and absorption. Sometimes, an individual's respiration becomes depressed causing their heart rate to drop and the oxygenation in the lungs to decrease leading to a dangerous situation. The busy caregivers do not notice a problem until a critical event such as a heart attack occurs. Usually, the critical event just does not just “happen”, but there are a series of indicators foretelling of the critical event. In other words, it is not that the patients conditions suddenly deteriorate, it is more a situation that caregivers are unaware of the deteriorating conditions until a critical event.
A connected healthcare system needs to plan for patient monitoring with the idea of:
In fact, in patient monitoring there are critical events that occur to the patient , such as heart fibrillation basically where the heart shakes in the chest, atrial or ventricular fibrillation where a heart could stop. These are life critical events. Therefore, the system needs to assure that communication system is detecting the life critical event and to deliver information about the event to the clinician within 5 to 10 seconds. Most of the critical time is consumed just detecting the event is occurring.
In summery, the goal for the connected healthcare system is to be proactive of the life critical events. Early detection is the key.
Patient monitoring is more than a device connected to a patient that acquires physiological information and processes that information generating alarms. A Patient Monitoring system includes many, often hundreds and sometimes thousands of devices connected to patients geographically dispersed across a hospital campus. Data and processed information from each of these devices are communicated across the hospital ecosystem and are delivered to a variety of data sinks.
The monitoring includes:
On the right of the circular floor plan which for this discussion is called a hospital ward. For this example, it will be referred to as Five East. Around the outside, there are patient rooms with a dozen to 30 rooms. In the middle is a desk where some clinicians can sit watching the patients and the local monitors. Inside pf each of the patient rooms there are patient monitors. In this case the ward (i.e., Five East) can be thought of as an ecosystem. bit in large hospitals there may be a Five West. And there might be floors below and above these wards. Look at some hospitals like Ohio State University Wexner Medical Center, Michigan Medicine, Brigham and Women's, Partners Healthcare, University of California Dan Francisco (UCSF) Health with extremely large care areas with hundreds if not thousands of patient monitors working at the same time.
To summarize, this ecosystem is big, thousands of devices producing data, many devices consuming data, and highly distributed across the ecosystem and they are all connected.
The patient monitoring is not only conveying and monitoring all this information, but it also has to manage the patients' state:
As the patients are moving through the ecosystem the continuity managing these workflows there is a longitudinal aspect of the data as the patient moves through the care areas of the hospital.
The bottom line, the availability and fault tolerance of the system. This system has to run 24/7. It can not fail. The system has to built that once it is turned on, and thousands of patients are connected, we never turn it off. It has to keep running, even if there are failures. It has to keep running if if parts of it are disconnected.
Viewing of Physiological Data | Real-time , fault-tolerant display of waveforms, measurements and trended data. |
---|---|
Includes viewing of historical patient data, analytics and reports. | |
Alarming | Must sound an alarm within 10 seconds from the onset of the physiological condition. |
Failure to alarm is considered a critical failure. | |
Patient Management | Admit, move, discharge patients. Associate and dissociate acquisition devices. |
Configuration of patient (implanted devices, state in treatment, age-based monitoring or therapy) | |
Alarm Management | Clinical alarms must be delivered to all intended destinations which confirmation. |
Alarms states can be modified based on clinical conditions and algorithms. | |
Device and System Management | Configuration and management of all devices in ecosystem. |
Configuration and management of system. (beds, units, time, ADT, HL7, authentication, etc.) | |
Analytical Processing | Execution of life-critical and non-life-critical physiological algorithms. |
Results affect alarming and alarm processing throughout ecosystem. | |
Availability, Fault Tolerance, State Consistency | Must continue to monitor patients including in-unit central viewing, alarming and patient configuration changes if there is an infrastructure or edge-compute failure/disconnection. |
Recovery from failure should be automatic and the must perform safely in failure and during recovery. | |
Must be designed with “BASE” principles (Basic Availability, Soft-state, Eventual consistency |
The following helps describe what is referred to as the “Grand Challenge” of Patient Monitoring.
There is a dynamic nature to the systems
We have to build resilience into the system to adapt to the dynamic ever changing system and environment. So, while all the changes and interruptions are occurring the system is constantly trying to reconcile itself to reflect the real world. So, when the system does come back together, then the data and the system components must reconcile system to a clinically safe state.
Using Data Distribution Service (DDS) to maintain the state in the network and devices, allows the system to do safe and predictable reconsideration when parts of the system fail. As an example, of all the possible failures that could and do occur, you can not rely on always being in communication with the edge compute or the cloud. The system needs to back off components and expectations and continue to operate. The system needs to recover and reconcile.
Graphically, the Grand Challenge s represented in the following diagram of a small system. All the components on the diagram are representaive of the components with the system,. Any one of these could fail or the connections could fail. You can not be
Return to the top GE is using DDS win some of the systems that were built but you don't see it , its under the hood so to speak. But as we move forward, we are continuing to expand our footprint using DDS to convey the information back and forth across the whole system.
Data Distribution Service (DDS) standard in Patient Monitoring specifically designed for real-time, mission-critical applications to manage data-centric states across decentralized systems, in a scalable and secure manner. The reason we are using DDS is: