ddsf:public:guidebook:03_user:02_health
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
ddsf:public:guidebook:03_user:02_health [2021/07/14 15:40] murphy ↷ Links adapted because of a move operation |
ddsf:public:guidebook:03_user:02_health [2022/05/12 16:08] (current) mitza [Table] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | DDS====== Use Case 1: Connected Healthcare ====== | + | ====== Use Case 1: Connected Healthcare ====== |
| [[ddsf:public:guidebook:03_user:start| Return to User Experiences]] | [[ddsf:public:guidebook:03_user:start| Return to User Experiences]] | ||
| - | |||
| - | * **<color #FF0000><todo @char>Please Review</todo></color>** | ||
| - | * **<color #FF0000><todo @DDSFmember>Please Review</todo></color>** | ||
| - | |||
| Patient Monitoring in a Maturing Digital World | Patient Monitoring in a Maturing Digital World | ||
| Line 10: | Line 6: | ||
| ===== Details ===== | ===== Details ===== | ||
| - | ^ Author | Matt Grubis | | + | ^ Author | Matt Grubis | |
| - | ^ Title | Chief Engineer | | + | ^ Title | Chief Engineer | |
| - | ^ Organization | GE Healthcare | | + | ^ Organization | GE Healthcare | |
| - | ^ Date | 29 Apr 2020 | | + | ^ Date | 29 Apr 2020 | |
| - | ^ Time | 33 Minutes | | + | ^ Time | 33 Minutes | |
| - | ^ Presentation | [[https://www.brighttalk.com/webcast/12231/397992?utm_campaign=channel-feed&utm_source=brighttalk-portal&utm_medium=web | Connected Healthcare - DDSF BrightTalk ]] | | + | ^ Presentation | [[https://www.brighttalk.com/webcast/12231/397992?utm_campaign=channel-feed&utm_source=brighttalk-portal&utm_medium=web| Connected Healthcare - DDSF BrightTalk ]] | |
| - | ^ Docment | [[https://www.dds-foundation.org/wp-content/uploads/2020/03/Application_Example-DDS_in_Patient_Monitoring_JB76285XX1_DDS-Foundation.pdf | DDS in Patient Monitoring ]] | | + | ^ Document | [[https://www.dds-foundation.org/wp-content/uploads/2020/03/Application_Example-DDS_in_Patient_Monitoring_JB76285XX1_DDS-Foundation.pdf| DDS in Patient Monitoring ]] | |
| ===== Patient Monitoring in a Maturing Digital World ===== | ===== Patient Monitoring in a Maturing Digital World ===== | ||
| Line 22: | Line 18: | ||
| ===== Abstract ===== | ===== Abstract ===== | ||
| - | A patient monitoring system typically consists hundreds, sometimes thousands of interconnected physiological acquisition devices (bedside monitors), real-time clinical viewers with [[ddsf:private:guidebook:06_append:glossary:c:c2|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 [[ddsf:private:guidebook:06_append:glossary:d:data_distribution_service_dds]] [[ddsf:private:guidebook:06_append:glossary:m:midware|middleware’s]] [[ddsf:private:guidebook:06_append:glossary:d: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 | + | A patient monitoring system typically consists hundreds, sometimes thousands of interconnected physiological acquisition devices (bedside monitors), real-time clinical viewers with [[ddsf:public:guidebook:06_append:glossary:c:c2|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 [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds]] [[ddsf:public:guidebook:06_append:glossary:m:midware|middleware’s]] [[ddsf:public:guidebook:06_append:glossary:d: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. | clinical information for further care. | ||
| Line 31: | Line 27: | ||
| [[ddsf:public:guidebook:03_user:02_health| Return to the top]] | [[ddsf:public:guidebook:03_user:02_health| Return to the top]] | ||
| - | 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; [[ddsf:private:guidebook:06_append:glossary:i:icu]]; in operating rooms; during anesthesia recovery; and, through out the birthing process for mothers and neonatals. | + | 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; [[ddsf:public:guidebook:06_append:glossary:i: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 | During patient monitor medical devices are attached to patients. The devices measure and collect vital signs and physiological states | ||
| about patients in real-time. | about patients in real-time. | ||
| - | The monitors used in Patient monitoring systems are a perfect examples of [[ddsf:private:guidebook:06_append:glossary:i:iomt]]. The monitors measure and collect vital signs and physiological states | + | The monitors used in Patient monitoring systems are a perfect examples of [[ddsf:public:guidebook:06_append:glossary:i: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 [[ddsf:private:guidebook:06_append:glossary:e:edge]]. | + | 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 [[ddsf:public:guidebook:06_append:glossary:e:edge]]. |
| The following are the basic constraints that apply to patient monitoring systems: | The following are the basic constraints that apply to patient monitoring systems: | ||
| Line 53: | Line 49: | ||
| * Integrate with data analytics such as GE and Partner Analytics | * Integrate with data analytics such as GE and Partner Analytics | ||
| - | The monitors must be well defined [[ddsf:private:guidebook:06_append:glossary:e:endpoint|endpoints]] within an overall seamless integrated patient monitoring ecosystem. | + | The monitors must be well defined [[ddsf:public:guidebook:06_append:glossary:e:endpoint|endpoints]] within an overall seamless integrated patient monitoring ecosystem. |
| The current GE ecosystem has three main components: | The current GE ecosystem has three main components: | ||
| Line 62: | Line 58: | ||
| <figure IoMT> | <figure IoMT> | ||
| {{ ddsf:public:guidebook:03_user:screen_shot_2020-06-05_at_12.13.03_pm.png?700 |}} | {{ ddsf:public:guidebook:03_user:screen_shot_2020-06-05_at_12.13.03_pm.png?700 |}} | ||
| - | <caption> [[ddsf:private:guidebook:06_append:glossary:i:iomt]], (c) General Electric </caption> | + | <caption> [[ddsf:public:guidebook:06_append:glossary:i:iomt]], (c) General Electric </caption> |
| </figure> | </figure> | ||
| - | An architectural decision to use the [[ddsf:private:guidebook:06_append:glossary:d: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 [[ddsf:public:guidebook:06_append:glossary:a:availability|availability]] and allowed for the leveraging of exiting IoMT technology. | + | An architectural decision to use the [[ddsf:public:guidebook:06_append:glossary:d: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 [[ddsf:public:guidebook:06_append:glossary:a:availability|availability]] and allowed for the leveraging of exiting IoMT technology. |
| ==== Use Case ==== | ==== Use Case ==== | ||
| Line 95: | Line 91: | ||
| A connected healthcare system needs to plan for patient monitoring with the idea of: | A connected healthcare system needs to plan for patient monitoring with the idea of: | ||
| - | * [[ddsf:private:guidebook:06_append:glossary:r:realtime|real-time]] acquisition of data | + | * [[ddsf:public:guidebook:06_append:glossary:r:realtime|real-time]] acquisition of data |
| * real-time processing of data | * real-time processing of data | ||
| * analysis of the information, and | * analysis of the information, and | ||
| Line 102: | Line 98: | ||
| 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 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 [[ddsf:private:guidebook:06_append:glossary:g:goal|goal]] for the connected healthcare system is to be proactive of the life critical events. Early detection is the key. | + | In summery, the [[ddsf:public:guidebook:06_append:glossary:g:goal|goal]] for the connected healthcare system is to be proactive of the life critical events. Early detection is the key. |
| * Prompt recognition and treatment of the complication is a critical, actionable point during a patient's postoperative course and can profoundly impact outcomes. (Anesthesiology 2019) | * Prompt recognition and treatment of the complication is a critical, actionable point during a patient's postoperative course and can profoundly impact outcomes. (Anesthesiology 2019) | ||
| * Earlier identification and treatment of threatening conditions lead to lower mortality rates. (Resuscitation 2019) | * Earlier identification and treatment of threatening conditions lead to lower mortality rates. (Resuscitation 2019) | ||
| Line 136: | Line 132: | ||
| * **<color dimgray/lightgrey>[gray dots]</color>** To improve patient care, there are convenient viewing stations in the hallways allowing the nurses to quickly assess a patients status without having to go into the room or without having to return to the central station. | * **<color dimgray/lightgrey>[gray dots]</color>** To improve patient care, there are convenient viewing stations in the hallways allowing the nurses to quickly assess a patients status without having to go into the room or without having to return to the central station. | ||
| - | * In addition to the wards ecosystem, the data is also being sent to a central Electronic Medical Record (ERM) and central [[ddsf:private:guidebook:06_append:glossary:s:server|servers]] allowing mobile consults on a phone or a tablet or the doctor is doing a mobile consult from a remote location. | + | * In addition to the wards ecosystem, the data is also being sent to a central Electronic Medical Record (ERM) and central [[ddsf:public:guidebook:06_append:glossary:s:server|servers]] allowing mobile consults on a phone or a tablet or the doctor is doing a mobile consult from a remote location. |
| * The data is also sent to a cloud server where data analytics are larger analytics or population management. | * The data is also sent to a cloud server where data analytics are larger analytics or population management. | ||
| Line 168: | Line 164: | ||
| 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. | 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 [[ddsf:private:guidebook:06_append:glossary:f:faulttolerance|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. | + | The bottom line, the availability and [[ddsf:public:guidebook:06_append:glossary:f:faulttolerance|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. |
| <table> | <table> | ||
| Line 213: | Line 209: | ||
| 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. | 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 [[ddsf:private:guidebook:06_append:glossary:d: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. | + | Using [[ddsf:public:guidebook:06_append:glossary:d: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. |
| * The Grand Challenge of a Patient Monitoring Ecosystem is that the state of the ecosystem is | * The Grand Challenge of a Patient Monitoring Ecosystem is that the state of the ecosystem is | ||
| Line 256: | Line 252: | ||
| - | [[ddsf:private:guidebook:06_append:glossary:d: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: | + | [[ddsf:public:guidebook:06_append:glossary:d: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: |
| * DDS is not “cloud centric”. If you have a server, you are dependent on the server and consequently any server failures have considered during the design. These kinds of failures are not acceptable during life critical patient monitoring. | * DDS is not “cloud centric”. If you have a server, you are dependent on the server and consequently any server failures have considered during the design. These kinds of failures are not acceptable during life critical patient monitoring. | ||
| - | * Data state are exchanged at “wire-speed” using [[ddsf:private:guidebook:06_append:glossary:q:quality_of_service_qos_policies|Quality of Service (QoS)]] control. We prioritize some traffic over traffic. We are prioritizing real-time event traffic versus historic back logs. For example, if a device had been disconnected for four hours, the backlog data is important and needs to be back filled bit not interfere with the real-time monitoring data. This prioritization of the data delivery is done using a QoS scheme across all the different topics and domains in the system. Naturally, it is optimized for the real-time aspects of patient monitoring. | + | * Data state are exchanged at “wire-speed” using [[ddsf:public:guidebook:06_append:glossary:q:quality_of_service_qos_policies|Quality of Service (QoS)]] control. We prioritize some traffic over traffic. We are prioritizing real-time event traffic versus historic back logs. For example, if a device had been disconnected for four hours, the backlog data is important and needs to be back filled bit not interfere with the real-time monitoring data. This prioritization of the data delivery is done using a QoS scheme across all the different topics and domains in the system. Naturally, it is optimized for the real-time aspects of patient monitoring. |
| * There are no data-mastership concerns, just distributed state reconciliation. In the past, before we used DDS, some data was stored in the device, some in the central station, and some on the servers. This made scaling and extending the system difficult because each data repository had different data and data-mastership issues. | * There are no data-mastership concerns, just distributed state reconciliation. In the past, before we used DDS, some data was stored in the device, some in the central station, and some on the servers. This made scaling and extending the system difficult because each data repository had different data and data-mastership issues. | ||
| * Efficient communication leveraging DDS built-in “type system” ([[ddsf:public:guidebook:06_append:01_family_of_standards:01_core:dds_extensible_types_dds-xtypes|DDS-XTYPES]]). Patient Monitoring data is complex because human physiology is complex. Some example of the data devices collect are: | * Efficient communication leveraging DDS built-in “type system” ([[ddsf:public:guidebook:06_append:01_family_of_standards:01_core:dds_extensible_types_dds-xtypes|DDS-XTYPES]]). Patient Monitoring data is complex because human physiology is complex. Some example of the data devices collect are: | ||
| Line 266: | Line 262: | ||
| * brain waives, | * brain waives, | ||
| * exhaled respiratory gasses such as CO2 | * exhaled respiratory gasses such as CO2 | ||
| - | : There are so many measurements that can be collected from a body, it results in very complex [[ddsf:private:guidebook:06_append:glossary:d:dm]]. Using verbose, un-managed data models like those in HL7 is not efficient and can lead to errors of translation. So, representing the data the data using DDS X-TYPES, the data is ultimately represented as binary data. It is efficient from at the machine level. The data can be sent across the wire in binary format, but is still fully documented and described with XTYPES. So each station shares the same current data model regardless of its computer architecture (i.e., big verus [[ddsf:private:guidebook:06_append:glossary:l:littleendian|little endian]], [[ddsf:public:guidebook:06_append:glossary:0-9:16-bit|16-Bit]], [[ddsf:public:guidebook:06_append:glossary:0-9:32-bit|32-Bit]] or [[ddsf:public:guidebook:06_append:glossary:0-9:64-bit|64-Bit]] processors, etc. | + | : There are so many measurements that can be collected from a body, it results in very complex [[ddsf:public:guidebook:06_append:glossary:d:dm]]. Using verbose, un-managed data models like those in HL7 is not efficient and can lead to errors of translation. So, representing the data the data using DDS X-TYPES, the data is ultimately represented as binary data. It is efficient from at the machine level. The data can be sent across the wire in binary format, but is still fully documented and described with XTYPES. So each station shares the same current data model regardless of its computer architecture (i.e., big verus [[ddsf:public:guidebook:06_append:glossary:l:littleendian|little endian]], [[ddsf:public:guidebook:06_append:glossary:0-9:16-bit|16-Bit]], [[ddsf:public:guidebook:06_append:glossary:0-9:32-bit|32-Bit]] or [[ddsf:public:guidebook:06_append:glossary:0-9:64-bit|64-Bit]] processors, etc. |
| * On the wire compatibility with dynamic data model dynamic changes and evolution. This provides on-wire compatibility which is really important as the data model changes. The data model not only changes through the current care workflow on different machines, but also aa the system is extended and upgraded in the future. For example, providing upward compatibility as parameters are modified or added going forward, or even using new parameters we have not even invented yet. | * On the wire compatibility with dynamic data model dynamic changes and evolution. This provides on-wire compatibility which is really important as the data model changes. The data model not only changes through the current care workflow on different machines, but also aa the system is extended and upgraded in the future. For example, providing upward compatibility as parameters are modified or added going forward, or even using new parameters we have not even invented yet. | ||
| - | * Content aware filtering to drive further efficiency - A lot of our devices are wireless, battery operated and using [[ddsf:private:guidebook:06_append:glossary:w:wan]] connectivity. Sending un-needd or unwanted data to and from these devices can shorten their usefulness or create the the equivalent of a Denial of Service (DoS) attack. Therefore, we have to make sure for efficiency and security that the data transfers are efficient and minimal. In other words, we are not sending data to places in the network that do not need or want the data. So, we rely on the built-in [[ddsf:private:guidebook:06_append:glossary:d:data_distribution_service_dds]] content filtering at both the source and the destination. So we are sending the correct data to the data sinks that require that data and nothing extra. | + | * Content aware filtering to drive further efficiency - A lot of our devices are wireless, battery operated and using [[ddsf:public:guidebook:06_append:glossary:w:wan]] connectivity. Sending un-needd or unwanted data to and from these devices can shorten their usefulness or create the the equivalent of a Denial of Service (DoS) attack. Therefore, we have to make sure for efficiency and security that the data transfers are efficient and minimal. In other words, we are not sending data to places in the network that do not need or want the data. So, we rely on the built-in [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds]] content filtering at both the source and the destination. So we are sending the correct data to the data sinks that require that data and nothing extra. |
| - | * Fully secure endpoint authentication and [[ddsf:private:guidebook:06_append:glossary:e:encryption|encryption]] built-in - In healthcare, security is paramount. Making sure that we have military grade security, there is encryption, authentication, authorization and that different nodes have different rights to different topics and different ways of exerting Command and Control (C2) over a patients state (i.e., admitting, discharging, silencing alarms, changing the way an algorithm behaves.) These types of features must be at the foundation of the system, otherwise the entire system at risk. In our system, we are using DDS-Secure to help with these issues. | + | * Fully secure endpoint authentication and [[ddsf:public:guidebook:06_append:glossary:e:encryption|encryption]] built-in - In healthcare, security is paramount. Making sure that we have military grade security, there is encryption, authentication, authorization and that different nodes have different rights to different topics and different ways of exerting Command and Control (C2) over a patients state (i.e., admitting, discharging, silencing alarms, changing the way an algorithm behaves.) These types of features must be at the foundation of the system, otherwise the entire system at risk. In our system, we are using DDS-Secure to help with these issues. |
| - | * Transport independent, the best transport is used for the communication link - Some of the links are wireless [[ddsf:private:guidebook:06_append:glossary:l:lan|LAN]], some are over wired high-seed networks, and others are over [[ddsf:private:guidebook:06_append:glossary:p:point-to-point|point-to-point]] "body area" [[ddsf:private:guidebook:06_append:glossary:w:wireless|wireless networks]]. Not everything is [[ddsf:private:guidebook:06_append:glossary:e:ethernet|Ethernet]] or [[ddsf:private:guidebook:06_append:glossary:i:ip]], therefore, we use a service which not tied to a specific transport allowing the right transport to be selected for the right purpose. This applies all the way along the communication pathway from the edge to the severs. | + | * Transport independent, the best transport is used for the communication link - Some of the links are wireless [[ddsf:public:guidebook:06_append:glossary:l:lan|LAN]], some are over wired high-seed networks, and others are over [[ddsf:public:guidebook:06_append:glossary:p:point-to-point|point-to-point]] "body area" [[ddsf:public:guidebook:06_append:glossary:w:wireless|wireless networks]]. Not everything is [[ddsf:public:guidebook:06_append:glossary:e:ethernet|Ethernet]] or [[ddsf:public:guidebook:06_append:glossary:i:ip]], therefore, we use a service which not tied to a specific transport allowing the right transport to be selected for the right purpose. This applies all the way along the communication pathway from the edge to the severs. |
| * Software defined domains and topics - Help shape the distribution of data, the virtual communication of which endpoints communicate with each other, also adding to the design architectures and the security and efficiency of the system. | * Software defined domains and topics - Help shape the distribution of data, the virtual communication of which endpoints communicate with each other, also adding to the design architectures and the security and efficiency of the system. | ||
ddsf/public/guidebook/03_user/02_health.1626291647.txt.gz · Last modified: 2021/07/14 15:40 by murphy
