Choosing the Right API for Your Medical Device

Cloud-based solutions for data storage is not a recent innovation. A relatively new concept in medical devices is storing data in the cloud. Given the mission-critical task of protecting and managing that data, some medical device developers may consider “build your own” solutions as the best approach.

One challenge with building your own cloud is that you assume additional risk and expense that a cloud-based data storage API can help you avoid, ultimately saving time and money. Click To Tweet

This post gives an overview of what to look for in evaluating an API. We’ll keep the various evaluation criteria at an overview level for the sake of brevity. If you want to discuss your criteria in detail, please contact us; we’ll be happy to dive into your use case one-on-one.

Evaluating an API

Five main criteria should be used in evaluating data storage APIs specific to medical device use. These areas are Cybersecurity, Regulatory Support, System Configurability, Coverage and Scalability. Let’s look at each individually.

Cybersecurity

To say cybersecurity is the most important criterion isn’t 100% true; all five areas are critical for finding a cloud storage provider that meets your needs. However, given the recent FDA emphasis on cybersecurity for medical devices, it’s difficult to overstate cybersecurity’s importance.

The graph below of healthcare breaches reported by HIPAA-covered entities shows why. IT hacks (yellow) is by far the largest (and growing) category, followed by unauthorized access and disclosure (gray).

When evaluating API vendors, the minimum they should provide is as follows:

• Use a secure transport protocol with at least TLS 1.2 encryption.
• Data is encrypted at rest using at least 256-bit encryption.
• A published maintenance window (minimum weekly).
• Results of annual penetration testing.

All of these are non-negotiable items. If your potential vendor cannot or will not provide proof of these items, it’s time to move on to the next candidate.

Ideally, a great vendor will also have HITRUST certification. HITRUST is a cybersecurity and risk framework that includes coverage for things like NIST, HIPAA, and GDPR. HITRUST certification indicates maturity and compliance in those critical areas.

Regulatory Support

Submitting your product to a regulatory agency is a major milestone in any company’s history. While incorporating a data storage cloud API into your product satisfies several recent FDA cybersecurity regulations, how does your vendor help you on the submission side?

Was their product developed using an ISO 13485-compliant Quality Management System (QMS)? Do design controls exist for the product?

A vendor that can provide the necessary documentation and is willing to participate in that process will make your submission process significantly easier.

System Configurability

Configurability vs. customization in medical device software has significant differences that may affect the validation and verification timeline for your device.

Configurability means that the system can be operated within your requirements without changes to the source code. The implication is that you only need end-to-end verification with your medical device’s integration with the API itself.

Customization requires design controls and full verification and validation, adding considerable time and expense to your submission timeline.

Beyond the verification/validation implications, configurability allows you to make changes and test more quickly as you go through the product development lifecycle. Integrating a new cloud feature can take days and weeks instead of months and even years.

Coverage

It may seem obvious, but any API must address all the critical functionality you’re planning for your device and related applications.

Functionality like authentication, sending data, and receiving data are a given, but what about data aggregation? User management? Mechanisms for enabling algorithms to run on data?

Think carefully about your initial needs and document those requirements. While your team will continue to grow and refine the list as you proceed through the product lifecycle, planning for core functionality early allows you to create a path to a minimally viable product (MVP) much faster.

With a minimum set of requirements, refinement becomes easier in evaluating APIs. For example, let’s examine authentication. Authentication sounds straightforward; any API will have built-in support for authenticating users, but what are the requirements beyond that?

If a large healthcare system will be using your device, user authentication likely needs to be integrated with an enterprise-class SSO provider. If patients are going to be authenticating, they might benefit from integration with Google or Facebook, making it much easier for them to log in.

Beyond that, what about your physical devices? They may need to authenticate themselves, thus creating a subset of requirements for provisioning, managing, and securing that authentication mechanism.

Another critical area of recent FDA focus is the ability to update deployed devices’ firmware. Any cloud API should have endpoints that allow your devices to query for new firmware, download it, and verify the image.

Don’t try to reinvent the wheel with simple upload/download endpoints. Having precise control over what image is available and applicable will go a long way in supporting your regulatory submission.

Scalability

One of the most compelling reasons for selecting a cloud API over building your own is the task of running the infrastructure yourself. Building something that runs well when testing 1, 10, or even 100 devices is easy. What about 10,000 or 100,000 devices all trying to communicate to your API (at once!)?

Building out this scalable infrastructure is a daunting task that requires technical expertise and the right people. Staffing an experienced IT department that can run, secure, and scale infrastructure involves significant cost and time. The infrastructure itself also becomes very expensive when you launch your product commercially.

Scaling all of the associated resources, adding redundancy in-depth, and replication to multiple data centers; all of these have associated costs that can quickly add up to tens of thousands of dollars.

A robust API vendor already has redundancy and scalability designed into the product and their infrastructure. Disaster recovery, backups, and regional replication should all be on your requirements list to ensure minimal customer impact if a problem occurs.

When evaluating any potential vendor, ask how they address each of those areas, what (if any) downtime they’ve experienced over the course of months and years, and if they provide any performance guarantees in their contracts.

Moving Ahead

Evaluating a data storage API provider can be daunting, with complicated requirements to consider and the temptation to “hack” your solution. Having a clear understanding of what the infrastructure looks like at scale is key to making an informed decision. We have seen companies build a small cloud for their device without design controls or basic HIPAA/GDPR compliance. Bare bones solutions won’t scale with product usage.

Building out your own cloud solution takes significant time, expertise, and money. A cloud solution vendor should address all of the above items (and more)—so you can focus on building a successful medical device company, not an IT company.

At Galen, we have deep experience helping clients in this critical area. Reach out for a conversation today.