Integrate Medical Devices

Improving Patient Safety via Shared Information

Introduction

RTI Connext DDS is peer-to-peer middleware that helps integrate medical devices to create safer hospitals and to improve patient safety.

The patient-monitoring medical devices used at hospitals today are very sophisticated, but they are not designed to work with each other. Individually each device can detect and alert on specific patient health problems. However they also generate many false alarms resulting in "alarm fatigue" and incorrect remedial actions – a very significant and unfortunately often fatal problem.

The same medical devices, when networked together and combined with smarter algorithms that look at the aggregate information can detect true alarm conditions far more quickly and accurately, avoiding the false positives and preventing undesirable consequences.

This Case+Code application will help you connect multiple medical devices to gather real-time patient readings and correlate and interpret those results. This use case applies to a variety of medical devices types including:

  • Patient monitoring
  • Alarm data
  • Point-of-care devices
  • In-home patient monitoring

The following sections show coding examples of how Connext DDS can be used in applications that send ECG and pulse-oximeter data, an application that correlates the data from the two devices to generate more accurate patient alarms, and an HMI application.

Medical-Device Integration

In the hospital, a patient is hooked up to a variety of medical devices to monitor vital signs such as heart rate, oxygen saturation of the blood, and blood pressure. Each of these monitoring devices have known failure modes that can lead to false alarms or false readings, and some of these failure modes can happen under normal circumstances. When too many false alarms are generated, it can lead to what is called "alarm fatigue" – nurses unintentionally ignoring an alarm that is vitally important. This leads to patient deaths that could be prevented by reducing the number of false alarms. One relatively easy way to reduce the number of false alarms is to generate alarms based on information from more than just a single device. While a single device may give a false alarm in normal circumstances, the data from multiple devices can be correlated to build a more accurate picture of the patient's vital signs, and even to predict problems. This can dramatically reduce the number of false alarms, reducing alarm fatigue and increasing patient safety.

RTI Connext DDS provides a distributed system platform to easily connect medical devices and allow them to share real-time and non-real-time data. The Connext platform provides several features that make this interoperability simple:

  • Automatic discovery of devices and applications allows devices to be hooked up to the network at any time
  • A well-defined data model allows applications to understand the data from many devices
  • Low-latency, high-throughput performance allows patient data to be monitored in real-time
  • Quality of Service (QoS) tuning allows data to be sent according to the requirements of the application or the network

Ultimately, this platform allows devices and applications to share data to improve patient care and to increase patient safety.

Medical Devices and Supervisor Applications communicating on the RTI Connext DDS bus

What This Example Does

This example illustrates data that has been pre-recorded from a simulated ECG and a pulse oximeter. The data flows to an application that correlates the data from the two devices and decides when there is a valid alarm condition. This application sends alarm data when both the ECG and pulse oximeter data indicate a patient alarm. The HMI application displays alarms that are generated.

The applications are:

Device Data Replay detail

Device Data Replay (RTI Replay Service):


Device-Patient Mapping detail

Device-Patient Mapping (PatientDeviceApp):

  • Sends data associating device IDs with patient IDs

Bedside Supervisor detail

Bedside Supervisor (BedsideSupervisor):

  • Receives ECG and pulse oximeter data
  • Sends alarm data when the values provided by both the ECG and the pulse oximeter are out of range.

Human-Machine Interface detail

Human-Machine Interface (HMI):

Running the Example

Download the Example

Download the example files [ Linux  |  Windows ] and extract them into a location of your choice. We'll refer to this location in this document as EXAMPLE_HOME.

To view and download the example source code without pre-built executables, visit the RTI Community DDS Use Cases repository in GitHub.

This download includes:

  • Pre-built example applications you can configure and run without rebuilding
  • Example source and project files for Windows and Linux systems

Download RTI Connext DDS Professional

If you do not already have RTI Connext DDS Professional installed, download and install it now. You can use a 30-day trial license to try out the product. Your download will include the libraries that are required to run the example, and tools you can use to visualize and debug your distributed system.

Run the Example

Before running the examples, you must set an environment variable called REPLAY_HOME. This must be set to the location of RTI Recording Service in the RTI Connext installation directory. For example, if you installed RTI Connext in the default location, you must set REPLAY_HOME to c:\program files\rti\RTI Recording Service 5.1.0.

On Windows systems, navigate to the EXAMPLE_HOME\ExampleCode\scripts directory. In this directory, there are four separate batch files to start the applications. These are called:

  • DeviceData.bat
  • PatientDeviceApp.bat
  • BedsideSupervisor.bat
  • HMI.bat

On Linux systems, navigate to the EXAMPLE_HOME/ExampleCode/scripts directory. In this directory, there are four separate script files to start the applications:

  • DeviceData.sh
  • PatientDeviceApp.sh
  • BedsideSupervisor.sh
  • HMI.sh

You can run these script or batch files on the same machine, or you can copy this example and run them on multiple machines. If you run them on the same machine, they will communicate over the shared memory transport. If you run them on multiple machines, they will communicate over UDP.

When you run all of these applications, you will initially see no data when there are no patient alarms active. After the devices have been monitoring the patient for some time, you will see an alarm appear for a patient, and update as the device values update.

Human-Machine Interface screen shot

If you have access to multiple machines on the same network, start running these applications on separate machines. Note: If you do not have multicast on your network, see the section Run the Example with No Multicast for details on how to change the configuration to run without multicast.

How to Run the Medical Device Connectivity Example on a Windows System [Download video file]

Run the Example with No Multicast

If your network doesn't support multicast, you can run this example using only unicast data. The two steps you must take to run with only unicast are:

  • Edit the qos_profiles.xml file to add the address of the machines that you want to contact. These addresses can be valid UDPv4 or UDPv6 addresses.
  • Run all four applications with the parameter --no-multicast. This causes the applications to load the .xml files that do not depend on multicast in the network.
<discovery>
  <initial_peers>
    <!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
    <!-- Insert addresses here of machines you want     -->
    <!-- to contact                                     -->
    <!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
    <element>127.0.0.1</element>
    <!-- <element>192.168.1.2</element> -->
  </initial_peers>
</discovery>

Building the Example

Directory Overview

EXAMPLE_HOME
|-- Docs
`-- ExampleCode
    |-- make
    |-- win32
    |-- replay
    |-- scripts
    `-- src
        |-- CommonInfrastructure
        |-- Config
        |-- Generated
        |-- Idl
        `-- . . .

The source code is divided into:

  • make - Linux makefiles
  • win32 - Windows project and solution files
  • replay - Prerecorded device data and replay scripts
  • scripts - Scripts to run applications
  • src - Source code
    • CommonInfrastructure - The code that all applications use to start using RTI Connext DDS to send or receive data
    • Config - XML QoS configuration files
    • Generated - Source files generated from Idl
    • Idl - Describes the data types that are sent over the network
    • Other directories - Source code for specific applications. RTI Connext DDS publishing and subscribing code is in FooInterface.h, FooInterface.cxx or FooInterface.java

Building the Example

On all platforms, the first thing you must do is set an environment variable called NDDSHOME. This environment variable must point to the ndds.5.x.x directory inside your RTI Connext DDS installation. For more information on how to set an environment variable, please see the RTI Core Libraries and Utilities Getting Started Guide.

Windows Systems

For C++ applications on a Windows system, start by opening up the win32\MedicalDeviceIntegrationExample-<compilerver>.sln file.

This code is made up of a combination of libraries, source, and IDL files that represent the interface to the application. The Visual Studio solution files are set up to automatically generate the necessary code and link against the required libraries.

For Java developers, an Eclipse project is located in the src\HMI directory. To build in Eclipse, you must follow these steps:

  • Ensure a C++ preprocessor is in your path. One way to do this is by running the Visual Studio application vcvars32.bat from a command prompt, then opening Eclipse from that same command prompt.
  • Ensure the NDDSHOME environment variable is set to the RTI Connext DDS installation directory.
  • Import the HMI project into Eclipse
  • Right-click on the build.xml file and select Run As | Ant Build. This will call the code generator to generate code from the .idl files.
  • Right-click on the src directory. Select Build Path | Configure Build Path… Go to the Libraries tab, and select Add External JARs… Navigate to the %NDDSHOME%\lib\java directory and select nddsjava.jar. For example, if you have installed RTI Connext DDS in c:\program files\rti_connext_dds-5.3.0, you will navigate to c:\program files\rti_connext_dds-5.3.0\lib\java\ and select nddsjava.jar
How to Build the Medical Device Connectivity Example on a Windows System [Download video file]
Linux Systems

To build the applications on a Linux system, change directories to the ExampleCode directory and use the command:

gmake –f make/Makefile.<platform>

The platform you choose will be the combination of your processor, OS, and compiler version. Please review the selection of Makefiles in the make directory to find the closest match to your system.

For Java developers, an Eclipse project is located in the src\HMI directory. To build in Eclipse, you must follow these steps:

  • Ensure a C++ preprocessor is in your path
  • Ensure the NDDSHOME environment variable is set to the RTI Connext DDS installation directory.
  • Import the HMI project into Eclipse
  • Right-click on the build.xml file and select Run As | Ant Build. This will call the code generator to generate code from the .idl files.
  • Right-click on the src directory. Select Build Path | Configure Build Path… Go to the Libraries tab, and select Add External JARs… Navigate to the %NDDSHOME%/lib/java directory and select nddsjava.jar. For example, if you have installed RTI Connext DDS in ~/rti_connext_dds-5.3.0, you will navigate to ~/rti_connext_dds-5.3.0/lib/java/ and select nddsjava.jar
  • Edit the run configuration to ensure that the LD_LIBRARY_PATH environment variable includes this directory: NDDSHOME/lib/<architecture>jdk
How to Build the Medical Device Connectivity Example on a Linux System [Download video file]

Under the Hood

Data-Model Considerations

The data model in this application includes three major pieces:

  • Device data (ice.idl): These applications use the Integrated Clinical Environment (ICE) data model, which has been developed as part of the MDPnP project.
  • Device-Patient Mapping (patient.idl): This data contains a mapping from each device to the patient it is monitoring. It models each device as a unique instance. This data is configured with QoS for state data, meaning that any application interested in knowing which device is monitoring which patient will be reliably notified as soon as it starts up.
  • Alarm (alarm.idl): This is a very simple structure that represents a patient alarm. It contains a patient key, alarm kind, and a sequence of device updates that indicate an alarm. This models each patient as a unique instance.

Configuration Details: XML Configuration for Devices

The qos_profiles.xml file contains the configuration for different types of data in this application. The QoS in this file inherits from built-in QoS profiles. The build-in profiles used by this example are:

  • Reliable Streaming: Configures data for fast reliable transfer between DataWriters and DataReaders
  • Status and Alarm Status: Configures data to be reliably delivered to existing and late-joining applications. Only the most-recent alarm update for each patient is sent.

Bedside Supervisor (C++)

This application receives updates about which devices are monitoring which patients. It also receives streaming patient data from devices. It looks for a pulse oximeter and ECG providing too-high pulse data. If a patient's pulse is too high, it sends an alarm.

The RTI Connext DDS code in this example is concentrated into these files:

  • DDSCommunicator.h and DDSCommunicator.cxx: This class is used to create a DDS DomainParticipant and DDS Topics. The DDS DomainParticipant is the DDS object responsible for discovery of other DDS objects. DDS Topics are associated with DataWriters and DataReaders, and contain a string that describes the meaning of the data.
  • DDSTypeWrapper.h: This class is a template wrapper for DDS data types, and provides a constructor, assignment operator, and destructor.
  • DDSNetworkInterface.h and DDSNetworkInterface.cxx: These files contain all the DDS code that is specific to this application, including creating the Device Numeric DataReader, the Device-Patient Mapping DataReader, and the Alarm DataWriter.

HMI (Java)

This application receives alarm updates and displays them in a GUI. It does not show any data when there are no active alarms.

The RTI Connext DDS code in this example is concentrated in three files:

  • DDSCommunicator: This class contains the code to create the DDS DomainParticipant object. This object starts the discovery process.
  • GenericDataReader: This class contains the code to create a type-specific DDS DataReader that receives data over the network. This class uses DDS WaitSets to be notified of data arriving in the application's main thread.
  • DDSNetworkInterface: This class instantiates the DDSCommunicator and the DataReader that receives alarm data. This specifies the DDS Topic and the QoS that will be used for receiving data.

Next Steps

Extra Credit

The MDPnP project has created a demo application with multiple simulated devices, more detailed data visualization, and more complex scenarios.  This application is interoperable with this example code, and allows you to:

  • Visualize the recorded medical data from this example
  • Run additional simulated devices
  • Change the simulation parameters to force other alarm scenarios

To view the data from this example in the ICE PnP user interface, you can run their example application, select the ICE Supervisor application, and then select Data Visualization.  This allows you to view the data from this example.

Case + Code: Medical Device Example: Integrating with MDPnP [Download video file]

To find out more about the ICE data model and the MDPnP project, please visit the MDPnP website.

Join the Community

Post questions on the RTI Community Forum.

Contribute to our Case + Code examples on RTI Community GitHub using these instructions.