The following is an excerpt from our recently published eBook: 6 Questions to Ask When Starting A Medical Device Software Project. Download the eBook in its entirety to continue reading.
The medical device industry is booming. In the U.S. alone, medical devices are expected to account for $208 billion of the greater healthcare industry by 2023. That means there are a lot of opportunities in the coming months and years, particularly given the current state of the world as it relates to the COVID-19 pandemic. With cloud healthcare, there’s even more opportunity.
So what are we talking about when we say “medical device”? In this blog post, we’re referring to external, handheld, patient-focused devices intended to make care easier and more efficient for users.
We’re focusing on these types of devices because they typically fall under FDA Class I and II classifications, which is where the bulk of our medical device experience lies.
Within that distinction, there are a few different types of device subsets: connected, disconnected, and hybrid. Determining which of these three patterns your device follows really depends on one thing.
What does your data throughput look like?
Connected devices are those that send a constant stream of data to public clouds or dashboards in real-time. An example of this would be this internet-connected thermometer used to track the spread of a viral disease in real-time. As people take their temperatures, the data automatically feeds into a dashboard and populates an interactive map that healthcare organizations use to identify outbreaks.
Disconnected devices are those that don’t rely on an internet connection or piece of software to operate. They use onboard data storage and upload the data when the device is eventually connected.
A good example of a disconnected device would be a blood glucose meter that doesn’t require a connection of any sort to give a reading. Users can take readings over the course of a week and eventually connect the device to an accompanying mobile app to track results.
Hybrid devices rely on software to function but only send data when they have a connection. The best example of a hybrid device is one from our own portfolio.
The Pops Diabetes Care Rebel is a glucose meter that attaches to the back of a mobile phone. Using an intuitive mobile app and a Bluetooth connection, it allows users to measure and track their blood levels quickly and efficiently. The Bluetooth connection then securely uploads the user’s electronic health records to a cloud-based, HIPAA-compliant network that their doctor can access, limiting the need for in-person visits.
Adoption of Cloud Healthcare for Your Medical Device
Medical devices often deal with large swaths of highly-sensitive healthcare data and protected health information (PHI). As such, an extremely secure solution is needed to transfer and store all of that data. Inevitably, as you discuss your options around data management and storage, you’ll likely land in the cloud.
Generally speaking, the process for managing medical device data in the cloud looks similar to other cloud projects with the addition of HIPAA and PHI considerations. Look at the volume of data you’re dealing with, consider how much of it is HIPAA and PHI that requires high-trust compliance, design architecture around that, and decide on a cloud provider.
Which cloud healthcare provider should you choose?
Ultimately, any cloud healthcare platform you choose for your medical device software is going to be sufficient. However, there’s one provider that makes all of this very easy.
Microsoft Azure is designed as a Platform as a Service (PaaS). They’ve already done a lot of the heavy lifting for you in designing and vetting the necessary steps to host highly-sensitive patient data in the cloud. Azure has pre-built blueprints for common security requirements, including a HIPAA high-trust compliant blueprint to ensure things like medical records are secure.
By selecting the HIPAA blueprint when you’re spinning up your Azure subscription, it puts all the necessary controls and safeguards in place that makes it extremely difficult to break it. If something does go wrong and manages to break, Azure notifies you within 12 hours and provides steps to get it back up and running. Security blueprints also include penetration testing to ensure your platform remains secure at all times.
Azure wasn’t always built this way. For many years, they operated with a similar model as Google and AWS (see below).
But Microsoft eventually took note of customer frustrations and noticed a trend in some of the questions they were being asked. Customers couldn’t see why they ultimately had to manage everything themselves when they paid Microsoft to do it for them.
Eventually, Microsoft said “We’re a software company. We aren’t a hosting company. We’re going to develop a platform to make this easier.” And the medical device world quietly rejoiced.
Google and AWS
Both Google Cloud and Amazon AWS are designed as Infrastructure as a Service (IaaS). They don’t have pre-built platforms and blueprints like Azure. Instead, they both provide a checklist of all the steps necessary to build a secure, HIPAA high-trust compliant cloud healthcare API and infrastructure.
But they leave the building and maintaining it up to their customers.
Will Google and AWS follow Azure’s lead and offer pre-built PaaS? Amazon is trying to apply similar platform patterns as Azure. But they’re running into the problem of being so fully open-source that they can’t automate something like a FedRamp or HIPAA compliant blueprint. Currently, they can only produce architecture patterns that you have to follow, hence the checklists.
So, where does that leave your decision on which cloud services provider to choose? If your device only deals with a small amount of data, any cloud provider will suffice. However, if you’re dealing with large amounts of highly-sensitive and secure data, Microsoft Azure is the clear choice.
To continue reading about building medical device software, download our eBook: 6 Questions to Ask When Starting A Medical Device Software Project.