Mastering Cloud Connectivity: Essential Tips for Connected Medical Solutions

The choice of the most suitable wireless technology for data retrieval from your device will be influenced by the specific type of device you're developing and how it will be utilized by patients and/or healthcare providers. To help guide your decision, here are some key factors to consider for each of the most prevalent technologies available:

Is a well-established standard that is cost-effective and widely available, which will be a great option for most battery-operated devices, and many Bluetooth modules are already FCC approved. However, it's important to note that connecting your device to the cloud may require the use of a hub (that can be a cell phone, for example, or a Bluetooth router). Another thing to consider is that there is still significant variability on how Bluetooth is implemented on different phones, and, assuming you are targeting the general population, your patients will have a wide range of models, the differences in Bluetooth implementations may make support harder.

It has the broadest adoption, it's FCC approved, and it is pretty standard everywhere - no significant variability in implementations. A WiFi enabled device is quasi autonomous, as it still requires a working WiFi connection to send data to the cloud. And while a WiFi implementation is standard, it will still require network setup by the device user, which may be somewhat cumbersome. Keep in mind though that standard WiFi is not suitable for most battery operated devices.

The use of more advanced coding and modulation techniques can increase the amount of data that can be transmitted in limited bandwidth. On the security and privacy side, using a regulatory compliant connectivity solution for your device should fully address security and privacy concerns at multiple levels, through:

Compliance with regulations is a complex process, and on the connectivity side, a compliant platform can provide this expertise and ensure that the device meets all necessary regulatory requirements.

As a low-power, low-cost wireless mesh networking standard, it is well suited for small, low data requirements devices. It has a low power consumption which makes it suitable for battery-powered devices and it also offers a low-cost solution compared to other wireless technologies. Zigbee HEALTHCARE is a wireless standard for medical devices, based on Zigbee technology. However, its range is still limited compared to other wireless technologies like WiFi or cellular, it may not be suitable for devices that require high-frequency or high-volume data transfers, and it’s also not as widely adopted as other technologies like Bluetooth or WiFi.

Using Cellular is also a very attractive choice, as it would result in a fully autonomous connected solution, which works anywhere there is cellular coverage, without any setup requirements. However, it is still a rather expensive route to take. You will also likely face a significantly harder path to certification, as any medical solution must also go through a certification process with the carriers, increasing both cost and time-to-market. And while it is a better option for battery operated devices than WiFi is, it’s still not as good of an option as Bluetooth is.

They are both cost-effective solutions, as they provide some of the benefits of Cellular and WiFi (autonomous connectivity & ease of use), without the high cost associated with Cellular, and are low-power technologies, which results in device battery consumption levels similar to those we see with Bluetooth. However, at the moment, these options will work great only for localized US deployments, built around small data loads, so you will have to consider the limitations on data volumes due to the fact that such technologies rely on low-bandwidth connections. Thus, if your device has high-frequency or high-volume data transfer requirements you will need to employ a different technology, but they could be a great solution for deployments that will operate in major cities only, and for which periodic data collection is enough. As coverage expands, they may also become great alternatives for sparsely populated areas, where cellular networks may still fall short of achieving coverage for reliable wireless data services.

Regardless of the technology you choose, you will also have to consider concerns related to either bandwidth or coverage, possible interference, security & privacy concerns, as well as regulatory compliance. But all these can be mitigated. Interference can be reduced by using frequency-hopping techniques, reducing transmission power, and using directional antennas. The use of more advanced coding and modulation techniques can increase the amount of data that can be transmitted in limited bandwidth. On the security and privacy side, using a regulatory compliant connectivity solution for your device should fully address security and privacy concerns at multiple levels, through:

Compliance with regulations is a complex process, and on the connectivity side, a compliant platform can provide this expertise and ensure that the device meets all necessary regulatory requirements.

If you choose to go the route of a single System-on-a-Chip (“SoC”), then the main processor will handle communication as well. This will mean smaller space requirements, a lighter weight, and an overall cost-efficient option due to the simplified design. However, by handling both the main processing and communication tasks, the main processor may be overloaded, which could lead to decreased performance. Also, having the main processor handle communication can result in increased power consumption, which can negatively impact battery life and reduce the portability of the device. If the main processor has sufficient processing power and power consumption is not an issue, having it handle communication as well can result in improved performance, as the device can process and transmit data more efficiently. For a Class A of risk device, this is the preferred option. However, should your communication software malfunction, there’s a chance that it may bring down the entire device, since it's located on the main processor. And this is why, if your medical device happens to be a Class B or C, all communication software will need to be validated as Class B or C, which will significantly increase your cost and time-to-market.

The other option is to have a dedicated processor handle communication. If your device is either a Class B or Class C device (especially Class C), you’ll most likely be better off if your communication module is completely separate. And that’s mainly because your communication module could be treated in many instances as a Class A subsystem, even if your device is Class B or C. As a downside, you will have a more complex system than if you used an SoC, and it will also be marginally more expensive. But it is an overall safer route to take, especially if you are building a Class C device. A separate communication processor can also be optimized for low power consumption, which can result in improved battery life and portability for the device.

If you chose to go with Bluetooth as your wireless connectivity technology, you need to decide if you will use a mobile app or a dedicated hardware hub.

An obvious advantage of a mobile app is that you don’t need another piece of hardware, as your users/patients already have their own wireless devices. Even if you provide it (like in cases where you would be providing your users with a tablet during a trial for example), you don’t need to build it, as it’s available off the shelf. You just need to develop the mobile app. Another advantage is that it provides better communication with the user. So, if you’re going to build an app anyway (because your patients expect to communicate, or if you need to show them something like how to use the device, for example), that app will also be your communication hub – there’s no need for additional hardware.

A dedicated physical BLE hub may work better for some solutions, though. For starters, you won’t need dedicated mobile software development capabilities. And if hardware is your thing already, it may be a simpler that route to take, as your firmware and hardware engineers can also handle the hub. If the hub is cellular enabled, it also becomes easier to use for the user (just plug in and start using). But it may still bring your cost up, as well as your solution’s complexity as you’d be building two devices, and you’ll also have to support two devices.

While many options exist, in most cases you’ll have to choose between REST, MQTT, and low-level UDP. They each come with their pros and cons, so let’s look into it.

REST services are a popular choice for their ease of integration and scalability. Widely used and well understood, they make it easy for developers to implement and integrate into existing systems. They can also be easily scaled, allowing for growth as the number of devices and users increases, and they can be easily integrated with other web-based systems and services. But REST services do not include default security features, so you’ll want to make sure you also implement robust security measures, such as SSL/TLS encryption, authentication, and authorization. And they can be more resource-intensive than other protocols, which may impact the performance and power consumption of the device.

You may be looking at using REST services if you’re building a digital health solution that needs to integrate with web-based systems or other services, such as EHRs, that needs to handle large amounts of data or high volumes of traffic, such as wearable devices with many sensors or diagnostic imaging systems, or that needs to be easily scaled to handle growth or changing demands, such as telemedicine systems or RPM systems.

MQTT has its clear benefits for low power consumption, reliability, and security. A lightweight protocol that is optimized for low power consumption and bandwidth usage, it’s an ideal choice for medical devices with limited resources. It uses a publish/subscribe model, which ensures that messages are reliably delivered and that the device and cloud are always in sync, and it also includes security features such as encryption and authentication, making it a secure choice for transmitting sensitive medical data. However, it can be more complex to implement than other protocols, so the experience of the developers doing the implementation can make the difference. It may also require additional effort to integrate with existing systems and services, as it is not as widely used as REST services.

MQTT may be the right answer if you’re building a digital health solution with limited resources, such as portable or battery-powered devices, that require reliable communication at all times and syncing between the device and cloud, such as implantable devices or continuous glucose monitors (CGMs), or that transmits critical medical data, such as implantable devices or pacemakers.

Low-level UDP is a fast protocol that can transmit data quickly and efficiently, making it ideal for applications where speed and data volumes are critical factors. It is a low overhead protocol, as it requires fewer resources than other protocols, making it a good choice for medical devices with limited resources. It is also highly customizable, which makes it ideal for specialized applications.

But since UDP is a connectionless protocol, it does not guarantee the reliable delivery of data, which makes it less suitable for applications where reliability is a critical factor. Like REST services, it doesn’t include security features by default, so you’ll have to account for implementing those as well.

Low-level UDP may be the way to go if your digital health solution requires high-speed communication, such as real-time diagnostic imaging systems or ECG machines, has limited resources, as in the case of wearable devices or handheld devices, or has strict data volume requirements.

Communication security protocols and certificates play a critical role in ensuring the security and privacy of medical data, as well as the proper functioning and integrity of medtech solutions. These protocols and certificates are a crucial component of a comprehensive cybersecurity strategy for digital health. So, start looking into TLS, MTLS, and X.509, as they are critical to developing and maintaining a secure solution.

Transport Layer Security (TLS) is a security protocol commonly used to encrypt data and prevent unauthorized access or tampering. This is particularly important for medical devices that transmit personal health information (PHI).

Mutual TLS (MTLS) adds an additional layer of security by requiring mutual authentication between the client (device) and the server (cloud or remote system). This helps to prevent man-in-the-middle attacks, where a third party intercepts and alters the communication between the client and server. MTLS is particularly important for medical devices that transmit critical medical information, such as implantable devices or CGMs.

X.509 certificates are used to establish trust between the device and the server. By requiring both parties to present digital certificates signed by trusted certificate authorities, as is the case with MTLS, X.509 certificates help to ensure that client-server communication is secure.

The FDA's Medical Device Cybersecurity Guidance recommends the use of industry-standard security protocols, such as TLS (TLS 1.2 or above is highly recommended), to protect sensitive medical data transmitted over the internet. X.509 digital certificates, either single or multi-tiered, can be used in conjunction with TLS/MTLS to provide a secure and trusted connection between medical devices and healthcare IT systems.

Similarly, while the EU’s Medical Device Regulation (MDR) does not specify which type of digital certificate should be used, the use of X.509 certificates in conjunction with industry-standard security protocols, such as TLS/MTLS, can demonstrate compliance with the MDR's cybersecurity requirements.

There’s no doubt and it goes without saying that if your digital health solution includes a mobile app, that app should be available across platforms. But you will still have the make the choice of whether you’ll go for native development, cross-platform development, or use a hybrid approach.

Cross-platform development will be the most cost-effective route to take, as it enables developers to write and validate code once and deploy it on multiple platforms, resulting in significant savings and wide reach. It will also be faster and more efficient than native development, allowing for quicker time-to-market, while ensuring a consistent user experience across different platforms, which can be a plus for a medical device app.

However, cross-platform apps can run slower and have a less responsive user interface compared to native apps, have limited access to mobile device features, have lower overall performance and provide less flexibility in terms of design, user experience, and custom features, compared to native development.

Native development will give you full control over the communication process between device and phone, and will provide optimal performance, full access to all the features of the device, including sensors, cameras, and other hardware components, which can provide a better user experience. Native development also offers greater flexibility in terms of design, user experience, and custom features, and native apps typically have a more polished, seamless user experience, as they can be designed specifically for the platform they are running on.

One important aspect that may sway you toward native development is if your device requires background running and/or deep operating system integrations. Native development would give you full access to the low-level platform components required for an application running efficiently in the background, which may be a must for some medical devices like CPAP machines, for example, where the phone is collecting data in the background, while the patient sleeps.

But it will likely be more expensive than cross-platform development, and it can also take longer than cross-platform development, as it requires separate development and validation for each platform.

The hybrid route allows you to combine the simplicity and speed of cross-platform development with the low-level control of critical features, such as background connectivity, of native development, but it may not be the most cost-effective approach.

In the end, the decision comes down to a combination of requirements, available resources and time-to-market constraints.

Answer this question early on, as it would probably be one of the most impactful ones in the life of your solution: will your solution only connect to your device, or does it have to connect to other devices as well?

Your solution architecture will vary significantly depending on how you answer this question, so you must have a strategy from the beginning on how to handle it. A solution that needs to pull data from other devices as well will be more complex.

Besides addressing the UI, business logic and BT or WiFi connectivity, you’ll also have to figure out the server components, which would host and process data from multiple devices, including yours, the APIs that would provide a way for the solution to communicate with other devices/device clouds and exchange data between them, and services to securely store data in the cloud, allowing for easy access from multiple clients and enabling remote data processing. The solutio will need a robust network infrastructure to ensure reliable communication between multiple data sources and security will become even more important, as sensitive medical data would potentially be transmitted between multiple endpoints. The architecture will also need to be designed to integrate with existing systems and workflows, to ensure seamless communication between multiple components.

This choice can have significant business and operational implications.

One of the main advantages of a public cloud is that it provides high scalability, allowing you to quickly and easily add or remove resources as needed, it will generally be more cost-effective compared to on-premise solutions, as you only pay for the resources you use, and, while there’s no guarantee that there are no security risks, even with a leading public cloud, you can count on enhanced security as cloud providers invest heavily in their security infrastructure.

But, there will also be tradeoffs, that may or may not make sense for your digital health solution.

Your solution will be dependent on the service providers, who may experience outages or other issues that can impact your operations, and you may have limited control over the configuration and management of your resources in the public cloud. – less and less of an argument

With an on-premise/private cloud you’ll have full control over the configuration and management of your resources. It may also provide a higher level of security, as you have full control over your infrastructure and data, but that will depend a lot on the skills of the resources who deploy, update and maintain your cloud.

However, private cloud solutions can be very expensive and time-consuming to set up and maintain, and can be less scalable compared to public clouds, given the likely investment in additional hardware required to accommodate growth.

The main advantage of hybrid clouds is that they provide you with the flexibility to choose the right mix of public and private cloud resources to meet your specific needs. You can choose to use public clouds for non-sensitive data and a private cloud for highly sensitive data, reducing cost in the process. You can also have the privacy benefits of a private cloud, while still leveraging the scalability and cost-effectiveness of a public cloud.

This is not to say that getting to the right hybrid cloud solution doesn’t come with its challenges.

It can be complex to set up and manage, and it needs to be driven by an integration strategy that balances cost, security, and scalability.

When choosing the database technology you’ll use for data persistence, it will pretty much come down to choosing between SQL (Structured Query Language) and NoSQL (Not Only SQL). Alternative database technologies, such as graph databases and time-series databases, designed for specific use cases, may also be used in conjunction with SQL or NoSQL databases.

The choice of database technology will depend on the specific needs and requirements of the application, and the type of data collected by your digital health solution can play an important role in determining the best database technology to use.

Medical devices often generate large amounts of structured and homogeneous data, such as numerical measurements and timestamps, in which case storing this data in SQL databases would be the best option. However, many medical devices could also generate unstructured or heterogeneous data, which would be better suited for persistence in NoSQL databases.

The data model of a medical solution can be quite complex, with many inter-related entities and data types. A structured schema in a SQL database can help manage these relationships, ensuring data consistency and reliability. On the other hand, if your solution operates on variable models, with changing data types and fields, a NoSQL database would be the preferred approach.

And if you’ll be dealing primarily with homogeneous data generated by your medical solution, SQL databases will likely be the answer, due to their robust query capabilities, making retrieving and manipulating data easy. However, NoSQL databases can also be optimized for fast retrieval of specific data, which can be important for real-time analysis of large volumes of data. Also, when data insert times are critical for a specific solution, no database technology beats a NoSQL system.

Scalability is another important aspect, also triggered by the large amount of data that can be generated. Both types of databases are scalable, but in different ways. SQL databases can be easily scaled vertically, by adding more processing power to the server to handle increased load, which works great for small to medium data volumes. NoSQL databases are often horizontally scalable, by adding more servers to a cluster to handle increased load, making them particularly useful for large data volumes.

When it comes to data consistency, SQL databases are natively ACID compliant (Atomicity, Consistency, Isolation, Durability), providing a high level of data reliability and consistency. While NoSQL databases may have weaker consistency guarantees, as long as specific techniques are used to guarantee that data is still secure and retrievable, for many medical solutions, NoSQL databases are also a perfectly viable option.

Any medical solution handling patient data must be compliant with regulations such as HIPAA/HITECH and GDPR, which can have a significant impact on the architecture of the solution’s data layer. Compliance with these regulations requires strong data privacy and security measures to protect sensitive information, so your data layer must be designed with privacy and security in mind from the start. This may involve implementing encryption and secure data transfer protocols, using compliant servers and storage solutions, and following strict cybersecurity control procedures (e.g. JSP 1.2). Additionally, the architecture will likely need to be scalable and flexible to accommodate any future changes in regulatory requirements, so make sure that the architecture of the data layer is central to your initial design process, ideally in the conceptual and planning phases. The choice of architecture will influence many aspects of the solution, including data storage, data transfer, and how you address security and privacy. By making this decision early, the technical team can ensure that the data layer is properly integrated into the solution and avoid costly and time-consuming redesigns later in the development process.

Adding cloud connectivity to a medtech solution can greatly enhance its functionality and impact. But to do it right, it is crucial to carefully consider all aspects of the solution and its intended use before making decisions that will impact cloud connectivity. Different solutions may trigger different decisions and various business requirements can also impact the design of the medical solution itself. Partnering with a reliable connectivity platform can simplify the process and provide expert guidance in making the right decisions for your solution, leading to a successful integration of cloud connectivity.