Data transmission considerations for secure, real-time, lightweight, extensible physiological data transmission for cloud-based predictive analytics system data ingestion.
Randall Bardwell Life Science R&D Dassault Systemes
The world of clinical predictive analytics is confounding enough before you consider their care and feeding, but even more so afterward. In the world of multi-parameter vital signs processing, it had not previously been a big source of concern to have <240 sample-per-send (SPS) ECG sampling when one was only concerned with heart rate variability, with an easy-to-identify deflection for every R wave occurrence.
But what if you were looking at say, expired C02 capnography, similar to Dr. Andrew Seely’s work with his WAVE Study – identifying patients who are better likely to be successfully extubated by exhibiting successful spontaneous breathing trials. This requires CO2 capnography waveforms. Depending on the physiological attribute that you would like to focus on, say P waves in a QRS complex. You will be training a model based upon the successful identification of a very low-amplitude signal often masked by noise as a patient/subject/user ambulates. The point being is how you get data from your subject to the software, so to speak is critical, and thus deserves more attention.
In his book, “Exercise and the Heart“, Second Edition by Victor Froelicher, in chapter two, Special Methods: Computerized Exercise ECG Analysis, Dr. Froelicher covers the biomedical, and clinical informatics realities of dealing with live physiological waveforms including filtering, sampling, and composite beat determination for ST-segment measurement. When you are to the point where you have clean and salient data with which to work, you must then be able to get it to the cloud in a vehicle that can adapt to changing numbers of waveforms, parameters, and diagnostic statements.
The current methodology in commercial systems is to output a “high-speed digital interface” or HSDI. This is basically a two-second streaming XML file, that when laid contiguously, would depict the continuous record, similar to a so-called, Hillrom ‘Bedmaster” record which includes two seconds of signed-integer waveform data and can be connected indefinitely. XML, of course from both a security and network weight perspective, leaves a great deal to be desired, in terms of the perfect vehicle for clinical data, given that it is man-readable, there is no concept of security other than the fact that it is sent extremely fast typically by a server that is streaming up to 200 patients at a time. To visualize it, would require capturing it.
In 2002, the healthcare group, “Integrating the Healthcare Enterprise”, or IHE put forth the beginnings of a document entitled: ” IHE Patient Care Device (PCD) Technical Framework Supplement 10 Waveform Content Module (WCM) (link). This protocol framework gravitated around the concept that you could encapsulate some ECG waveforms, and ignored a host of other commercial and more research-related waveform parameters such as 12/15 lead ECG. That protocol would have ostensibly been the IHE standard, but unfortunately does not check all of the boxes as the technology has evolved to the point where the science is requiring near-real-term data with an ever-changing number of required physiological objects, be they waveform, parameter, or image-based. Thus the IHE WCM which would seemingly seek to establish exactly the kind of “Swiss-Army Knife”, or multi-functional, or even extensible capabilities that the HSDI XML protocol provides, does not provide such tools in the current recommendations.
One current method that is used by Philips, GE, and Hillrom is the so-called “Bedmaster” interface, after Dr. Richard Crane’s (Marquette Electronics ), Excel Medical’s legacy “Bedmaster”, interface which was a metaphorical “black box that would sit on a GE patient monitoring network, open the UDP data packets and drop into SQL for data mining and reconstruction. GE and Philips both offer this capability natively from their respective networks.
To begin with, the HSDI (Bedmaster) is an imperfect data transmission protocol encapsulated in XML, with security so lax that it is a man-readable file, and like HL7 doesn’t require rocket science to decode as it is not encoded to begin with. HSDI is typically sent in two-second snippets which can then be concatenated into a continuous record.
Marketplace implementations of a high-speed, data interface protocol include:
GE Healthcare: In the existing GE implementation, at the time of this writing, the GE Carescape Unity Network protocol provided 8 leads of streaming waveforms and parameter interface information. This included typically three viewing planes of ECG sampled at 240 samples per second, SPO2, or ‘pleth’ waveform, two invasive pressure waveforms, and respiration but as I recall at least as of a few years ago there was an issue with the respiration waveform being available in the stream. Extraneous parameter data from devices connected to the network are available for streaming as well as alarm data.
Philips’s version of that HSDI being more robust with 500 SPS sampled data available for 12 leads of ECG, in addition to four invasive pressure waveforms sampled at 150 SPS, and one SPO2 channel. All of this data is available via their PiiC iX interface in addition to alarm data and peripheral device information. Philips recently acquired Capsule Technology so their implementation of data transports should be interesting as they would have ostensibly more data to convey than almost any other vendor, with their extensive library of connected devices.
Spacelabs originally partnered with Cerner to develop XprezzNet, a bi-directional, binary data transport protocol, which was likely doomed from the start, as the interface, while secure, had very little if any flexibility, being created around a patient monitoring network that was deprecated before the XpressNet. Spacelabs courted a relationship with NantHeath to attempt to replace their aging Flexport interfaces with the NantHealth H-Box, which, even had the marketing relationship worked, the architecture to come together would have needed a reboot whenever they release a new monitoring platform.
Nihon-Kohden re-launched their version of the omnipotent patient monitoring platform to provide a similar high-speed, and alarm network data export, presumable coherent with other HSDI platforms although Nihon Kohden was one of the first to experiment with alternative non-HL7 technologies. Their new patient monitoring export interface likely builds on their long legacy of export expertise with integrated EEG with patient monitoring streaming viewing.
Hillrom “Bedmaster” Interface: At the time of this writing, Baxter had just acquired Hillrom, and is now the owner of the original Dr. Richard Crane “Bedmaster” interface. A product name developed by an engineer if there ever was one, the Bedmaster was the original “black-box” that sat on the original Marquette GE patient monitoring network, that Dr. Crane created, and decoded the streaming UDP data packets off of the Unity Network, the example of the typically excellent marketing by Marquette Medical systems, the kind that got them acquired by GE for $378M. Originally Bedmaster created the HSDI stream, and thus invented it, but became somewhat redundant when GE, Philips, and Nihon Kohden could all create their own.
IoT data transport protocols by contrast start with the concept of security. MQTT is a good example of a so-called “pub-sub” protocol. When a device (or client) wants to send data to a server (or broker) it is called a publish. When the operation is reversed, it is called a subscribe. Under the pub/sub model, multiple clients can connect to a broker and subscribe to topics in which they are interested. The inverse of this is the conventional client-server model, where in order to keep the communications alive, will broadcast a stream of data from point A to point B. Indeed, this is what the current state-of-the-art in high-speed data-interfaces today in 2022 is two-second stream of XML data, however, is implemented slightly differently by each manufacturer,
Lab Streaming Layer: The lab streaming layer (LSL) is a system for the unified collection of measurement time series in research experiments that handles both the networking, time-synchronization, (near-) real-time access as well as optionally the centralized collection, viewing and disk recording of the data. LSL is optimized for EEG waveforms but has the capacity to store anything and so at a base-level would seem to be able to provide a framework. But what about
Data processing and formatting. In so much as the device is using MATLAB to provide the various filter states in the PICSI device, it would seem obvious to utilize MATLAB to initiate a set of streaming conditions. Since the data stream has minimum clinical requirements, the data stream is dependent upon hardware selection. Whether you choose an ADI or TI AFE might unnecessarily challenge the funneling of unlike physiological data without having an arbiter/modulator in the form of the command utility which runs under the PICSI RTOS.
Real-time waveform forwarding for mobile devices. The genesis for the project came from the Clinical Technology BioInsight project⁶, which included the PICSI wearable that could, upon command switch from a headless monitoring mode to a 15-lead adult posterior ECG capture mode, and stream both the static, and dynamic data encapsulated in a secure wrapper. The PICIS RPM operates in a pub/sub environment⁴, so while there is a minimum data stream, it can be augmented or diminished by reformatted data on the fly. This same protocol could even provide b-directional provisioning data back to a device, eliminating the need for a separate console port communications resource.
Other use cases include device to app, and device to cloud, as well as app-to-cloud, and cloud to app, and cloud-to-device, something like a Decisio Health display with a plethora of information available from a single feed. Or an Epic Haiku interface to provide the combined expertise of an algorithm that is cognizant of NLP, structured, and unstructured physiological information as well as laboratory, genetic, and historical information to create a visualization object that is also streamed back to the device (patent-pending)
In each case, the ability to transfer a physiological data stream securely is paramount. Consider the application of the same HSDI XML protocol in a Bluetooth setting to provide a link between the acquisition device and the display device. With the advanced BT hacking tools available, even if the risk of such hacking would be low, it would be enough to trip up the heightened security-conscious inspector at the FDA. Interestingly HSDI protocol has no reference body whatsoever. In other words, no one these days would set out to build a secure data conveyance protocol, and intentionally base it on XML with all of the modern conveyance technologies available.
For more reading:
Secure, lightweight, extensible. real-time physiological data transference protocol (patent pending) (link)
- Andrew Seeley WAVE (link)
- Victor Froelicher, Exercise and the Heart, Second Edition (link)
- Publish-subscribe pattern – Wikipedia (link)
- Hacking BT with Bettercap (link)
- Spacelabs Xprezznet (link)
- Clinical Technology BioInsight Project (link)
- Decisio Health (link)