Implementing Medical Device Cloud Security

Buy vs. Build decisions cover myriad security issues and needs.

Medical devices are increasingly becoming part of our daily lives. As they proliferate, the “bonus feature” of connectivity is quickly becoming a “must have” attribute for commercial success. Cloud connectivity helps meet the following market necessities:

• Collecting patient “vital sign” data
• Collecting device usage data
• Gathering device diagnostic information (e.g., battery level)
• Sending therapeutic control data to the device
• Updating device firmware
• Updating accompanying mobile application software
• Authenticating individual devices for patient-specific use

Clearly, there is a need to secure and protect patient information, commonly referred to as PII (Personally Identifiable Information) and PHI (Protected Health Information). Protecting patient information is not merely prudent from a business and ethical viewpoint–rules such as HIPAA,[1] GDPR,[2] CCPA[3] require doing so.

The protection of diagnostic information about the medical device itself has an intellectual property (IP) component. We typically think of hackers attempting to steal PII and PHI belonging to individual persons. However, much can be learned about how a medical device works – hardware design, software architecture, communication protocols, etc. – through nefarious methods. A medical device company’s most valuable asset, it’s IP, can be stolen easily if proper security measures are not implemented.

Perhaps the most alarming threat is attempting to defeat security protections and take control of a medical device so that it can be remotely operated with the intent of harming the patient.

Security and protection require an active and comprehensive strategy for device design, deployment, and maintenance. These requirements must be considered and met by the medical device manufacturer– there is no choice in the matter and the earlier the better.

There is an important decision regarding building a customer solution (either with in-house resources or using a custom software partner) or buying (licensing) an existing, turnkey cloud platform.

Where to begin?

If you are building your own custom solution, this question has an easy answer: always assume your medical device’s cloud connectivity will be subject to some form of a cybersecurity threat. By “always” we mean you should think about device security and the threat of being hacked so often that it becomes part of your company’s culture; part of your “design DNA.”

Incorporate well-defined medical device design practices that consider security as a critical requirement – not an afterthought. The strategy of beginning development of cloud connectivity after a device is mature and “bolting on” a security layer at that point is neither cost-effective nor truly secure. If a cloud connectivity solution is not designed from the outset with security in mind, there are typically gaps that obviate the entire “bolt-on” security and render your device and patient data vulnerable.

Here are guidelines for creating a security mindset among your team members:

• Include a high-priority focus on security as a critical part of user requirements; begin by defining connectivity use cases for your device and the harms and hazards resulting from each.
• Follow a well-established and documented software development lifecycle and code to industry best practices, and then verify and validate your software.
• Define, implement, and enforce security best practices in requirements, coding, review, and execution.

Velentium is a design and development company, offering word-class innovation in medical devices. Velentium offers a comprehensive training and certification program in embedded cybersecurity. While it focuses on device-specific cybersecurity, many of the concepts it covers also apply to device connectivity.

Security best practices

Hopefully, everything discussed so far makes sense. Now let’s take these high-level strategies and bring them down to a tactical level by outlining relevant standards and guidelines. The following regulatory standards are a great start to meeting general security needs and also the specific requirements of HIPAA, GDPR, and CCPA. Your cloud connectivity solution should be developed by an organization with a deep understanding of, and practical experience with, these standards.

• ISO 13485:2016, Medical Devices – Quality Management Systems (QMS). Consider this ISO standard to be a minimum Whether you choose to build your own solution, hire a custom software company to create it, or purchase a license to a turnkey cloud connectivity solution, cloud platform development must be performed using a QMS certified under this ISO standard.
• IEC 62304, Medical Device Software – Software Lifecycle Processes. Defines how to perform all aspects of device software development. Provides a timeline-based foundation for tackling security requirements throughout the lifecycle of your device software, including the cloud-based connectivity portion.
• ISO 14971, Application of Risk Management to Medical Devices. Describes how to manage risk to ensure patient safety. Several potential risks result from your device being connected; this standard provides guidance to define and mitigate them.
• 21 CFR Part 11, FDA Electronic Records; Electronic Signatures. FDA guidance for paperless (i.e., electronic) record-keeping systems, to ensure document security and authenticity are adequately maintained.
• 21 CFR Part 820, FDA Quality System Regulation. S. federal law; governs device design and development.

If you’re considering partnering with an organization to either build a custom solution or provide a turnkey platform, as them if they comply with these regulatory standards. They should be able to provide a certification of validation documenting their compliance and describing the general software engineering process they follow.

Leveraging cloud infrastructure controls

There is a growing number of cloud infrastructure services, each with its own advantages. Most provide a robust set of controls that, if implemented correctly, can add to the security of a cloud-based platform. Generally, these controls isolate each of the resources in the cloud stack to ensure the containment of public-facing services.

The cloud platform should leverage the security and networking controls of the cloud infrastructure to isolate the various servers that comprise the cloud platform stack from each other, giving only the minimum access necessary for each server to do its job.

For example, the public-facing resources that publish the cloud platform API should only allow access via a single port that uses SSL/TLS to secure the data in transit.

Granting system access to a minimum number of individuals creates additional security. Multi-factor authentication provides additional security. In addition to user authentication, also implement a machine-to-machine authentication scheme such as OAuth 2.0 Client Credential Grant.

Encrypt medical device data both at rest (e.g., AES-256) and in transit (e.g., AES-128 GCM). Finally, implement active security monitoring of the underlying infrastructure with industry-standard tools and perform regular system security patching.

Final thoughts on Buy vs. Build

Obviously, building a cloud connectivity solution for medical devices meeting security and protection objectives requires a broad spectrum of expertise: technical, operational, and regulatory. Identifying and bringing in-house this expertise to “build” a customer solution is often beyond the ability resources of many medical device companies.

When pursuing the “buy” option, identify a cloud connective partner with broad expertise and a clear understanding of security issues in both general cloud connectivity and medical devices. Protecting cloud storage and computing assets by itself is a daunting task, requiring deep expertise across several dimensions. The additional nuances of medical device data security narrow the field of qualified partners.

The Galen Cloud™ platform is a turnkey medical device connectivity solution that meets or exceeds the requirements and standards suggested in this article.

About the authors

Keith C. Drake, Ph.D. is Vice President of Business Development for Galen Data. His dissertation research developed advanced image analysis techniques for military target acquisition. His 35-year career includes developing AI-based decision aiding technology in the US Air Force research labs at Wright-Patterson AFB, NIH-funded research in heart rate variability to diagnose the early onset of sepsis in neonates, and applying data analysis and management technologies to medical diagnostic data and information for companies such as Medical Automation Systems (now Abbott Labs) and Quest Diagnostics. He currently helps medical device companies transition to cloud-based connectivity.

Tim Sandberg is VP of IT Operations for Galen Data. He has over 20 years of experience working in information technology for medical device companies. Tim’s area of focus has been validating COTS software for intended use within organizations, as well as managing enterprise applications both on-premises and migrating them to cloud-based data centers. Before Galen Data, Tim worked as the Director of IT and Product Software Manager for OrthoAccel Technologies and as the Senior Manager of e-Business Applications at Cyberonics (now LivaNova).

[1] Health Insurance Portability and Accountability Act, enacted in 1996

[2] General Data Protection Regulation, a European Union regulation addressing data protection and privacy

[3] California Consumer Privacy Act, a California state law providing privacy rights and consumer protection