Increasingly complex and connected MedTech solutions need to utilize hospital networks, which poses an integration challenge. Whether they are surgical robots, patient monitoring systems or next-generation medical devices, these solutions must adhere to strict rules that are managed by the hospital’s in-house IT department, which governs the network, security, and infrastructure for the hospital. 

Constraints can vary, but typically include one or more of the following:

• Multicast prohibition
• Restricted port number utilization
• Tight cybersecurity controls

The good news is that there are ways to address the constraints imposed by hospital IT departments. A secure interoperable data framework, such as RTI Connext, can successfully integrate these new systems to enable transformative solutions in the highly competitive MedTech space. This blog explores each of the three major constraints created by typical hospital IT policies, and how Connext offers flexible and performant solutions to create scalable and interoperable distributed systems in seemingly rigid environments. 

Tip #1: How to get applications to discover each other peer-to-peer without Multicast

It’s a simple fact: most networks in hospitals do not allow multicast capability. That’s because multicast traffic can be more challenging to secure compared to unicast traffic. The use of multicast communication is restricted to prevent unnecessary network congestion and ensure a more efficient and reliable network for critical medical systems. But this forces all applications to use unicast, which increases latency and increases network usage.

Although the RTI Connext^® product suite uses multicast for discovery by default, it also provides other options for discovery when multicast is unavailable or prohibited. The easiest and most attractive of these options is RTI Cloud Discovery Service.

RTI Cloud Discovery Service (CDS) is a standalone application that can sit on any host possessing either a DNS name or static IP address. When it receives DDS discovery messages from the system’s nodes, it will relay them to other applications, allowing them to discover each other. The functionality of CDS can also be linked into an existing application, so no additional build or deployment steps are needed. CDS only relays data needed for discovery, and won't relay any user data. In fact, once all the applications in the system have discovered each other, CDS is no longer needed, unless applications come and go at runtime.

Once they discover each other, the communication between the applications will happen point-to-point over unicast. The only configuration applications need is the IP address or DNS name of CDS in their initial peers, which is more straightforward than setting every single IP address of the system. There are multiple ways to set initial peers, including an environment variable, XML QoS or in code.

Tutorials on how to use CDS can be found here.

Tip #2: How to minimize port number usage in applications to work with firewalls

Tight control over port numbers is enforced to manage and secure communication channels. This minimizes the risk of interference and enhances the overall stability of the hospital network. This poses a challenge for dynamic systems where applications come and go.

Hospital IT departments therefore typically require a list of the ports that a company’s applications will need, in order to create firewall rules. In a deterministic system, sharing the list of ports with the IT department would be straightforward. However, for dynamic systems where applications come and go, determining the open ports at any point may not be simple and would depend on the number of applications (DomainParticipants (DPs)). The more DPs in the system, the more ports in use. 

To solve this problem, RTI suggests using a fanout node on every host that will only open a predetermined number of ports. This establishes a layered databus architecture with RTI Routing Service acting as the gateway and reducing the ports needed for DDS. The standalone Routing Service seamlessly integrates with existing applications, providing a swift solution for scaling and integrating real-time systems, especially those dispersed geographically. 

In this context, Routing Service facilitates communication between the shared memory and the UDP domains. Applications within a host will communicate with each other over SHMEM, while Routing Service serves as a gateway between local and remote applications, creating a SHMEM DP (no UDP ports) and a UDP DP (with the 3 default UDP ports) - reduced to 2 ports if multicast is disabled.

This solution ensures a fixed number of UDP ports (2 or 3) regardless of the number of applications on the host. Users can integrate the Routing Service solution with Cloud Discovery Service for enhanced functionality.

Figure 1. RTI Routing Service, with the option to use RTI Cloud Discovery Service if multicast is not allowed.

An example of the Shared Memory / UDP Gateway is available here.

Tip #3: How to secure communications in systems while enabling interoperability

Cybersecurity is a critical concern for IT departments in hospitals. The rationale behind it is easy to understand, given the increasing frequency of cyberattacks to healthcare delivery organizations and potential impacts to patient safety, privacy, and care delivery. Given the larger attack surface of connected medical devices, data communication can be a risk if not secured properly.

Based on the Data Distribution Service (DDS^™), RTI^® Security Plugins can help device manufacturers design zero-trust connectivity architectures that align with regulatory guidance and best practices for secure data communication within hospital IT networks. These plugins leverage DDS-Security^TM to enable data-centric controls applied to data in motion, and a scalable secure communication architecture across the five security pillars: Confidentiality, Integrity, Authenticity, Access Control, and Availability. Security Plugins allow a granular application of security to the system to enable deny-by-default permissions based on the data, use case, and performance requirements of the application. And the configuration of specific controls requires little or no change to existing application code.

For more information on the five pillars of data security and how DDS-Security addresses them, please read this recent RTI blog post, which contrasts DDS-Security with TLS/DTLS options. Helpful tutorials are also available in the RTI Security Plugins Getting Started Guide.

Conclusion

RTI Connext can be a powerful, pivotal ally for medical technology developers contending with the challenges imposed by hospital IT departments. From the constraints of disallowing multicast to the intricacies of restricted TCP/UDP port utilization and the imperative of tight security, Connext offers practical solutions to ensure seamless integration within hospital networks.

As developers navigate the complexities of hospital IT constraints, RTI not only emerges as a resource, but also as a strategic partner for supporting the creation of secure and innovative solutions in the ever-evolving field of medical technology.

We invite you to learn more about Connext in MedTech environments. 

About the Author

Fran Porcel is a Principal Application Engineer at RTI, working for the RTI Professional Services Team in the San Francisco Bay Area. With almost 8 years at RTI, Fran is a Subject Matter Expert in Medical Software & Surgical Robotics. He trains RTI's customers on the usage of Connext daily, while also helping them architect Connext in their systems. He's also helped customers who have successfully been approved by the FDA.