3 Steps To Design Medical Devices That Thrive In The Digital Health Ecosystem

By Shahid Shah, president & CEO, Netspective Communications
Follow me on Twitter @ShahidNShah

In one of this series’ previous installments, I presented the case for why next-generation medical devices need to connect to electronic health records (EHRs) and other digital health ecosystem partners. While discussions about why interoperability is important are pretty common, it’s still difficult for device designers to choose the best architecture and engineering approaches to implement that interoperability.

In this article, I’ll present some specific recommendations for product managers and technical leads, helping you to create point-of-care (POC) devices that are good “digital health ecosystem citizens” and play nicely in modern IT environments. Connecting POC devices — including in vitro diagnostics (IVD) —to EHRs is deceptively difficult: They appear easy to connect in a typical fee-for-services (FFS) business model, but when you consider workflows and new value-driven reimbursements, they can get complicated quickly. 

Focus On The Data, Not The Protocols

Marketers hoping to sell their devices in any modern, IT-enabled health system or physician practice will immediately discover that meeting HL7 standards is a requirement. But, achieving HL7 connectivity is not easy. First, device designers need to:

• Ensure that your POC devices collect sensor data at the highest granularity level possible — Try to avoid storing just summary-only or post-processed (low-granularity) data. Instead, store raw data along with aggregated or summarized data on the device.

For example, if you’re collecting a range of temperatures, glucose measurements, or any other sensor data over time, don’t store just the average. Store each temperature value, each glucose reading, etc., in the local data store, so that it can be extracted and post-processed by an external system. Some non-data scientists may feel this is overkill, but that’s shortsighted thinking — the more data you store, and the more granular it is, the more likely it is to be of value to someone in the future (including your customers).

• Plan to store data for as long as it may be useful — If data fills up too quickly, spend the extra dollars to expand storage and/or to add off-device data archiving. When more data is available, additional telemetry becomes possible and new uses (including monetization) for data become possible. Many shortsighted managers end up telling designers to throw away data too quickly, and this makes interoperability with alarm systems or other post-processing almost impossible.
• Implement a custom RESTful or IoT-style web services layer on the device itself — Accomplish this using free, open-source tools and model-driven code generation. This custom REST, or IoT –style (e.g., MQTT or DDS), layer should include endpoints or data management capabilities that are very specific to the point-of-care device itself.

Given that most POC devices don’t have deep data complexity, MQTT and DDS-style data integration might be overkill. If you’re unsure, just start with a custom RESTful architecture. As early as possible, start designing your REST endpoints via an OpenAPI specification (e.g., Swagger), so that your testing team can start working on their integration tests (even while development is ongoing).

• Create an IoT and modern web services cyber strategy using TLS or SSL certificates for cybersecurity — If your data is secure, you’ll feel more confident in keeping it longer. And, building security in at the design phase is much easier than trying to tack it on layer. Don’t invent cybersecurity for your device: Use the dozens of modern techniques available open-source, essentially for free.

Resist The Healthcare-Specific Standards Temptations

Once you’ve designed high-granularity data structures, ensured that all data is kept for as long as possible, is secure, and is easily accessible via a custom set of web services, you’ll be ready for the next phase: Creating layers of integration for modern IT systems. In my opinion, the biggest mistake that device designers make, in terms of digital health ecosystem interoperability, is focusing first on HL7 or other healthcare-specific standards, rather than focusing first on their own data and testing needs.

Modern device engineers should not initiate their designs with HL7, FHIR, X.12, POCT1, LPOCT, AUTO16, or other “standards.” Instead, focus on common IoT standards like REST, MQTT, DDS, and other non-healthcare-specific protocols, because they have the best tooling and development support. If you have a good, custom, low-level set of web services and well-structured data repositories with open APIs, you’ll be able to solve almost any interoperability problem a customer throws at you.

Many of us are seeing HL7 FHIR as a reasonable next-generation API layer, but you should resist writing your custom API endpoints to FHIR at this time: It’s simply too young and too generic to provide value inside your device. Still, you should absolutely provide a FHIR “layer” as part of a healthcare-specific standardization layer.

Decouple The Healthcare-Specific Standardization

Assuming you’ve resisted the healthcare-specific temptations early, you’ll be ready for the next phase: Choosing the right standards to implement, and the best place to implement them.

If possible, your device should implement a simplified set of web services on the device itself, and leave other protocols to be implemented outside the device (this is what I call “decoupling the healthcare-specific standardization”). If absolutely necessary because of your business model requirements (not the technology), a minimal POCT1 or other non-workflow-aware style connectivity is OK on the device, but should not be preferred. The POCT1 family of standards remains difficult to implement in a plug-and-play manner.  

HL7 and related healthcare interoperability protocols, like FHIR, are probably the right place to start, but should be implemented off-device, if possible (especially if the device has limited processing power). Even if implemented on the device, HL7 / FHIR should be a separate service that can be turned off if the customer wants to integrate using their own HL7 infrastructure. Decoupling is important: Your device should handle its data structures with high granularity and then apply a custom set of web services endpoints that are specific to the device, but leave IT network integration to an off-device gateway, or to a separate service on the device, which can translate between multiple standards (e.g., AUTO16, POCT1, HL7, X.12, and emerging IoT approaches).

Build On The Present, But Plan For The Future

In summary, when designing point-of-care devices with integrated EHRs and digital health connectivity, open yourself to the big picture when it comes to data, and consider that your connectivity solution must adapt to ever-evolving IT systems.

Design your device with the ability to store – on or off-device – both raw and summary/post-processed data, and ensure there is sufficient storage to retain that data for as long as it may be useful. Take advantage of open-source solutions to keep that data secure, as well.

Build your device’s connectivity on common IoT standards, rather than healthcare-specific ones, to ensure ease of interoperability from the start. HL7 and related healthcare interoperability protocols are a solid stepping stone to more specific interoperability implementation, but be mindful of your device’s capabilities, customer needs, and possible emerging standards when adding such protocols.

Adding secure, reliable, and future-proof EHR integration and medical device connectivity capabilities to existing devices is difficult. That’s why designing proper data structures, open APIs, and secure interoperability protocols at the beginning of projects is crucial. Share your design and engineering challenges in the comments below and let’s get a conversation going about how to do EHR integration right, from the start.

Shahid Shah is an award-winning cybersecurity mentor and medical device hardware / software design coach with 25 years of technology strategy and engineering experience. You can reach him via Twitter or email.