Applying the Data Distribution Service in an IoT Healthcare System

In my last post, I described how the Data Distribution Service (DDS) standard is used to provide ubiquitous access to clinical measurements. In this post, I will be introducing the foundations of this enabling technology that can allow healthcare systems to reap the full potential of the Internet of Things.

The abstraction at the foundation of DDS is a global data space. Think of it as the virtual area where data on a patient is going to be gathered, shared, analyzed and acted upon. DDS applications—sensors, devices, applications, etc.—autonomously, anonymously, securely and efficiently cooperate by reading and writing Topics on this global data space – where a unique name, a type and a set of qualities of service (QoS) identify a Topic. Applications that join the global data space automatically discover their mutual existence as well as their interest (i.e. Topics produced and consumed). This information is then used to optimize the protocol and communication path used for efficient and high performance data sharing.

Conceptually the global data space is active, in the sense that it can retain data for late joiners and make it available even if the producer is no longer available. For example, a doctor can take advantage of this feature to see the history of clinical measurements produced by a given device. This feature is commonly called temporal decoupling as the producer and the consumer don’t need to be running at the same time in order to share data.

DDS’ global data space implementations are required to be fully distributed – no single point of failure or single point of bottleneck. This makes it possible for DDS-based system to scale out well and to experience very low latencies and high throughput. As an example, on contemporary hardware connected by a 1 Gbps Ethernet network, DDS has an inter-node latency of ~30 usec and can easily distributed several millions samples per second.

Anatomy of a DDS Application
Structurally a DDS application is composed by different entities (see picture below). The DomainParticipant provide access to a DDS domain. A domain represents a global data space instance and is identified by a natural number, 0, 1, 2, …, n. A domain can be further organized into partitions – partitions are used to organize data within the domain. Publishers and Subscribers control access to the partitions. Finally, the DataWriter and DataReader are used by applications to write and read data into the partitions associated with their respective Publisher and Subscriber.

As DDS is independent of the programming language and hardware and software platform, it allows applications written in different languages and deployed on different OS to exchange data – in other terms DDS takes care of representing data in a programming language and hardware independent manner, dealing with endianness and data layout. This means that a device developed using C++ and running Linux on an ARM processor is going to be able to send and receive data from a device developed using C# and running Windows Embedded on an x86 processor—and it won’t matter if the devices are in the same room, same facility, same state or same country.

Understanding DDS Topics
As I mentioned before, DDS uses Topics to represent the information shared between applications. So far, I’ve told you that a Topic has (1) a unique name, (2) a type used to represent the information associated with the Topic in a programming language, and (3) a set of qualities of service – but there is more. Topic can be keyed or keyless. When available, they key is used to identify a specific topic instances. Let’s try to understand this with an example. Imagine that we want to make available on DDS the data produced by an oxymeter. In this case the first thing we need to decide is how to model the data with a Topic type. Below you see the Topic type that may represent the information provided by a hypothetical oxymeter. The topic type is defined using IDL, but XML or Java could also be used.

struct Oxymetry {
string deviceId;
long spO2;
long bpm;
long pleth;
#pragma keylist Oximetry deviceId

Notice that with the #pragma directive I’ve defined the attribute deviceId as the key for the type. This attribute allows to uniquely identifying the device that produces the data. In DDS terms, each unique value of the deviceId attribute identifies a Topic instance. DDS provides specific life cycle information associated to instances, such as informing you when a new instance is available as well as when is no more in the system. When Topic instances are tied to device, the life-cycle management is particularly useful in learning about the operational status of the device itself.

The values assumed by a specific instance are called samples. Thus, DDS applications write samples belonging to an instance of a specific topic.

Reading and Writing Data
As mentioned above, in DDS data is read and written using DataWriter and DataReader. Specifically, a Datareader will receive in its local cache (a local projection of the global data space) the data written by the DataWriter if the two match. A Datareader and a DataWriter match if they have been defined for the same Topic and with compatible QoS. The set of data received by a Datareader can be controlled through content filters. Content filters are expressions defined with SQL WHERE syntax that predicate Topic attributes. For instance, the filter expression “spO2 < 85” could be used to receive the oxymeter data only when the saturation is below 85percent.

Quality of Service
DDS provides 22 Quality of Service policies that give very fine control over local resource, network utilization, traffic prioritization, and data management. For the complete list refer to the DDS Tutorial.

Your First DDS-Based Pulse Oxymeter
At this point we are ready to write our first oxymeter application. We will write the application that would run on the device and also another application that would display the readings on the console. Below I’ll provide you with the C++ code, but you can also check the Java and Scala version online.

int main(int argc, char* argv[]) {
if (argc < 2) {
std::cout << “USAGE:\n\t oxymeter <device-id>” << std::endl;
return 1;

std::string deviceId(argv[1]);
DomainParticipant dp(0);
Topic<Oxymetry> topic(dp, “TOxymetry”);
Publisher pub(dp);

DataWriter<Oxymetry> dw(dp, topic);

// isActive() becomes false when the device is turning off.
while (isActive()) {
auto o = get_oximetry(deviceId);
// write data
return 0;

int main(int argc, char* argv[]) {
DomainParticipant dp(0);
Topic<Oxymetry> topic(dp, “TOxymetry”);
Subscriber sub(dp);

DataReader<Oxymetry> dr(dp, topic);

// Create the waitset
WaitSet ws;
// Create a ReadCondition for our data reader
// and configure it for new data
ReadCondition rc(dr, DataState::new_data());
// attache the condition
ws += rc;

while (true) {
auto samples =;

[](const dds::sub::Sample<Oxymetry>& s) {
std::cout << << std::endl;
return 0;

This example reveals how simple is to use DDS to share data. Beside the simplicity, as explained in my last blog post, once in DDS, the data can be made available across any device and shared at any scale. DDS-based platforms such as PrismTech’s Vortex provide a good example of how this can be done.

If you want to learn more about DDS, feel free to read the DDS Tutorial or check out the various educational slides.

Unleashing Clinical Measurements

Medical devices are an essential element of modern medicine as they provide accurate clinical measurements such as oxygen saturation, blood pressure and temperature, x-ray and ultrasound imaging, as well as automatically administer intravenous medications, and provide support of critical life functions. In spite of the advances toward improving medical devices’ accuracy, robustness and reducing their form factor, very little has been done to pursue interoperability – most medical devices communicate their measurements through proprietary data formats and protocols thus hindering the integration with other medical systems.

This lack of seamless integration has several negative clinical implications. As an example, the use of a single clinical measurement – oxygen saturation – makes it harder than it should to detect morphine narcolepsy false positives. As the oxygen saturation measurement is very sensible to the proper positioning of the probe, several false positive can be raised in patients that are restless, perhaps due to post-operatory pain.

If multiple clinical measurements, such as breath per seconds, oxygen saturation and perhaps heartbeats, were fused together to detect morphine narcolepsy, then the number of false positives could be dramatically reduced. In addition, the actual insurgence of a narcolepsy could be detected earlier.

Ideally, medical devices should make available their measurements using a standard data model and through an open and standard protocol. The good news is that we have been working for the past year with the MDPnP (Medical Device Plug-and-Play) – a consortium of hospitals, research centers and medical device manufacturers – to explore the use of the OMG Data Distribution Service as the standard for sharing clinical data. In addition, we along with a number of the MDPnP participants have been involved with the SmartAmerica Challenge, a White House Presidential Innovation Fellows project designed to showcase Internet of Things frameworks and benefits for a variety of environments including healthcare.

DDS enables seamless, efficient and secure information sharing across any device and at any scale. As a result, once the clinical data is made available over DDS, it can be consumed virtually anywhere, on anything, and by anybody who has the proper access rights. The simple fact of making data available through DDS enables a series of use cases that are very valuable in supporting both doctors as well as patients.

Read: Applying the Data Distribution Service in an IoT Healthcare System

As an example, if we consider the image below, we see how a DDS-based platform, namely PrismTech’s Vortex, is currently being used to allow doctors to access patient data from anywhere as well as non-hospitalized patient to be continuously monitored.

Specifically, in this use case DDS makes it possible for doctors to enter a hospital room and discover the devices that are available. Doctors can then select one or more devices from which they would like to see live measurements. In case the doctors need to discuss the live data with colleagues from another hospital, the clinical data will be shipped in real-time to the remote doctors on whichever devices they have at hand–a mobile, a tablet or a notebook. In addition, data is continuously streamed to a private cloud where on-line as well as off-line analytics are executed on the various medical measurements.

Likewise, mobile personal medical devices can also make their data available seamlessly to doctors as well as to analytics applications. For instance, consider an elderly patient suffering from dyspnea. This patient can be continuously monitored while staying comfortably at home thanks to the use of a mobile oxymeter. This oxymeter would be sending data to the hospital’s private cloud via 3G/4G or WiFi where analytics applications interpret the data and respond as necessary. For example, if it’s detected that the patient needs some oxygen, a notification can go out to the patient while an alert is sent the doctor.

The beauty of DDS is that each of these use cases is seamlessly supported by its core abstraction: ubiquitous data sharing. Additionally, DDS supports for data modeling and QoS facilitates the definition of common data models for medical devices. The combination of standard data models and interoperable protocol are key elements to enable medical devices interoperability.

If you want to learn more about the DDS standard you can refer to the OMG website where you can find the specification or take a look at the educational material available on SlideShare.

PrismTech’s Intelligent Data Sharing Platform is Key Enabler for Seamlessly Connected, Cohesive Healthcare Systems

Company is member of healthcare team for SmartAmerica Challenge and upcoming expo, a White House-led Internet of Things Initiative

Boston, MA, USA – May 30, 2014 – PrismTech™, a global leader in software platforms for distributed systems, is supporting the realization of a seamlessly connected and cohesive healthcare system.  A member of the SmartAmerica Challenge and its Closed Loop Healthcare team, PrismTech has developed an intelligent data sharing platform, Vortex™, a crucial enabler of real-time data sharing between hospitals, clinicians and patients in the home.

The SmartAmerica Challenge is a White House Presidential Innovation Fellows project that brings together research in cyber-physical systems and combines test-beds, projects and activities from different sectors to show measurable benefits to the economy and in daily life.  An expo to showcase these activities is set for June 11 at the Walter E. Washington Convention Center in Washington, D.C.

The Closed Loop Healthcare team is tasked to showcase a framework and highlight the benefits of a healthcare system built upon the ubiquitous sharing of information between medical devices, healthcare applications, clinicians and patients.  Vortex provides an interoperable solution that allows a patient’s data to be shared securely and in real-time with healthcare professionals and other clinical information systems via the Cloud and using mobile technologies.

By streamlining the healthcare environment into a cohesive system, experts believe the industry can reduce costs, provide better care, and achieve improved health outcomes.

PrismTech and several other Closed Loop Healthcare team members are also part of the Medical Device “Plug-and-Play” (MD PnP) Interoperability Program (  MD PnP is promoting innovation in patient safety and clinical care by leading the adoption of patient-centric integration of medical devices and IT systems in clinical environments.

Vortex™ is designed for business-critical Internet of Things systems and provides efficient, secure and interoperable real-time device-to-device and device-to-cloud information sharing.  It is a crucial enabler for systems that have to reliably and securely deliver high volumes of real-time data with stringent end-to-end qualities-of-service, such as in environments such as healthcare, transportation, smart cities, industrial automation and smart energy.

Further information about PrismTech is available from the website at:

DDS, MQTT and the Internet of Things

The commoditization of network connectivity is providing the foundation for the Internet of Things – a system in which data flows seamlessly, at Internet Scale, between network-connected devices, mobile devices, industrial and information systems.  Yet, network connectivity alone is not sufficient; another key building block needed for the Internet of Things are standards for interoperable data sharing – as without standardized open data sharing there is no Internet of Things.

The Object Management Group (OMG) Data Distribution Service for Real-Time Systems (DDS) and the upcoming OASIS Message Queuing Telemetry Transport (MQTT) provide two excellent examples of standards that address the Internet of Things.

Introduced in 2006, DDS has established itself as the standard for peer-to-peer real-time data sharing in Operational Systems , such as Air Traffic Management Systems, Medical Systems, and Combat Systems.  DDS has recently experienced rapid adoption as the foundation for an increasing number of Intelligent Systems in applications such as Smart Cities, Smart Grids, and m-Health.

MQTT was introduced in 1999 by IBM as a publish / subscribe, extremely simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency or unreliable networks.

DDS and MQTT share some common principles, such as parsimony and efficiency, temporal decoupling and anonymity, yet each technology has some unique features that make it most applicable for certain use cases.

For instance, MQTT is most suitable for sporadic messages and highly resource constrained devices whilst DDS is most suitable for those applications that require real-time data exchange – meaning applications in which data has an inherent temporal validity and in which stale data should never delay fresh data– and tight control over the Quality of Service (QoS).  In addition DDS supports peer-to-peer (infrastructure-less) communication, a feature that comes in handy for device-to-device communications.

In summary, DDS and MQTT are two very good standards for data sharing in the Internet of Things. DDS provides support for both Device-to-Cloud (Device-to-Data Center) communication as well as Device-to-Device.  MQTT provides very good support for Device-to-Data Center communication.

Finally, I have produced an ondemand webcast on Building the Internet of Things which you can access at: