Hey You, Get On the Cloud: Safe and Compliant Use of Cloud Computing with Medical Devices

The term “cloud computing” has been around since at least 1993, and many of the technical and business model concepts underlying cloud computing have been around for decades. However, cloud computing as we think of it today was first popularized in 2006 when Amazon created the subsidiary Amazon Web Services and introduced its Elastic Compute Cloud (EC2), which allowed users to rent virtual computers (“server-instances”) on which to run their own computer applications. This allowed users to create, launch, and terminate server-instances on demand. Over time, Amazon added control over the geographic location of instances, which allowed for latency optimization and high levels of redundancy, and added many more types of on-demand services.

EC2 became popular because organizations could more easily, cheaply, and quickly scale computing resources based on real-time demand rather than needing to build and expand data centers. It also allowed purchasers to quickly launch new services on demand. This turned capital expenditures into operational expenditures, reduced barriers to entry, increased availability, and reduced overall maintenance costs.

Over the years, a wide range of major technology vendors (e.g., Microsoft, Rackspace, Oracle, IBM, Google, Alibaba) have launched competitive offerings.

As of early 2020, worldwide cloud infrastructure service revenue was more than $96 billion, with the combined market share of the three largest vendors (Amazon, Microsoft, and Google) at approximately 60%. Cloud revenues of these three vendors have grown by more than 50% per year since 2013.⁵ 

Part of the growth in cloud computing can be attributed to how it complements other technology trends by serving as the backbone of a more connected world that, as of 2019, consisted of more than 26 billion Internet-of-Things (IoT) devices,⁶  4.4 billion Internet users,⁷  and 3.2 billion smartphone users.⁸ 

One result of this rapid growth and the fierce competition among cloud vendors is that vendors continue to invest tens of billions of dollars per year in building out cloud infrastructure and offerings to make them faster, more resilient, more secure, and more powerful. The public cloud vendors now offer hundreds of different services, with additions happening so rapidly that keeping count is an involved exercise for an analyst.⁹ 

The growth has enabled tremendous economies of scale, not just in infrastructure but in information availability. In the cybersecurity area, large cloud vendors see many more potential threats and have put into place robust mitigation and monitoring of their infrastructure—more than many medical device companies could hope to implement.

In healthcare, transition to the cloud for healthcare data is ongoing and increasing in pace. Gartner estimated that by 2021, public cloud service providers will process more than 35% of healthcare providers' information technology (IT) workloads.¹⁰ 

These economies of scale and growth in investment have had a profound effect on the value proposition of the cloud. Although initially the cloud provided just a cheaper, faster way to do computing, it has now also become more secure, robust, resilient, and powerful.¹¹  Transitions to commercial cloud providers by government agencies dealing with highly sensitive data are a testament to the increasing reliability of cloud services.¹² 

The same trends that have been enabled by cloud computing also are present with medical devices: increasingly connected devices, miniaturization, mobile devices, and care settings outside of the hospital. Cloud infrastructure has become a greater part of the medical device ecosystem.

One of the core issues with medical device software is that the majority of regulations, standards, and guidance documents were written well before technologies such as distributed computing, mobile applications, cloud computing, and machine learning emerged. Although regulators and standards bodies have worked hard to provide guidance to cover these new technologies and paradigms, innovation in hardware, software, and connectivity has been happening at an accelerating rate and it is difficult for regulators (not to mention device developers) to keep up.

Cloud computing introduces new and interesting wrinkles to established software development practices, including ones addressed by existing standards, guidelines, and best practices.

In recent years, the FDA has provided guidance on topics closely related to cloud computing or pointed stakeholders to the guidance of peer organizations such as IMDRF. Examples of this include guidance on mobile medical applications,¹³  SaMD, the use of multifunction devices,¹⁴  and a position paper on the use of artificial intelligence in medical devices.¹⁵  However, as of yet, the FDA has not provided guidance on the use of cloud computing.

Medical device makers already are using cloud computing in the operation of medical devices, and this trend is only going to accelerate in the coming years. This article attempts to compile, synthesize, and share a number of emerging and proven best practices on how to most appropriately use cloud computing in a safe, compliant, and effective manner in support of the operation of connected medical devices.

NIST provides a definition of cloud computing, as well as its essential characteristics, service models, and deployment models¹⁶ : “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.”

NIST identifies a suite of essential characteristics for cloud computing offerings:

• On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically, without requiring human interaction with each service provider.

• Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, workstations).

• Resource pooling. The provider's computing resources are pooled to serve multiple consumers using a multitenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, data center). Examples of resources include storage, processing, memory, and network bandwidth.

• Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.

• Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

NIST identifies three types of service models used to deliver cloud computing to customers, each of which supports a different set of customer computing needs:

1. Software as a service (SaaS). The capability provided to the consumer is to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure, including network, servers, operating systems (OSs), storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

2. Platform as a service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or -acquired applications developed using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including network, servers, OSs, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.

3. Infrastructure as a service. The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources, where the consumer is able to deploy and run arbitrary software (e.g., OSs, applications). The consumer does not manage or control the underlying cloud infrastructure but has control over OSs, storage, and deployed applications and potentially has limited control of select networking components (e.g., host firewalls).

NIST provides several types of deployment models for cloud computing, including:

• Public cloud is the type of deployment model that generally comes to mind initially when people generically refer to cloud computing. Public cloud infrastructure is provisioned for open use by the (paying) general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider.

• Private cloud is when cloud infrastructure is provisioned for exclusive use by a single organization. A private cloud may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises. One high-profile example of a private cloud is the Department of Defense's (DoD's) $10-billion contract for Joint Enterprise Defense Infrastructure,¹²  which at of the time of this writing was either going to be awarded to Microsoft or Amazon.

• Hybrid cloud. The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability. For example, many major organizations are now deploying software across multiple public cloud providers (e.g., Amazon, Microsoft, Google) and/or in-house private cloud computing infrastructures.

The following are examples of different categories of the use of cloud computing with medical devices, as well as specific examples of existing medical devices that fall under those use cases:

• Regulated medical devices:

  • ○

    Arterys Software Platform,¹⁷  which is one of six clearances on the company's platform

  • ○

    PhysIQ Heart Rhythm Module,¹⁸  which is one of three clearances on the company's platform

  • ○

    Nanowear SimpleECG¹⁹ 

  • ○

    Genetesis CardioFlux with Faraday Analytic Cloud²⁰ 

• Cloud back-end services to support medical devices. This is currently the most common application of cloud services in the medical device space. This often is the first area for cloud development; it is designed so that functionality requiring regulatory submission is specifically excluded from the cloud. As the overall connected system evolves, some of these may migrate to being part of medical devices requiring regulatory filing or may themselves become Class II or higher SaMD systems. Examples include:

  • ○

    Allergan TrueTear.²¹ 

  • ○

    Dexcom Clarity (for use with Dexcom G6 CGM).²² 

  • ○

    Tandem Diabetes Care t:connect,²³  which originally was Class II but has since been downclassified to Class I.²⁴ 

  • ○

    Apple iWatch,²⁵  which is an example of a connected device that started as a fitness device that was not regulated by the FDA. Then, it became a Class II device when Apple added algorithms and functionality to monitor ECG and detect heart arrhythmias.

Other examples of uses of cloud computing within the medical device industry include:

• Services to support operations and monitoring of the connected device system. These often are third-party SaaS tools (e.g., crash analytics, user-based analytics, cybersecurity monitoring services, e-commerce and customer relationship management systems, single sign-on/identity management).

• Clinical trial data collection and management.

• Automated quality systems.

• Application life cycle/product life cycle management tools.

• Automated configuration management and testing.

• Design tools.

• Automated production systems.

The current work makes several baseline assumptions regarding cloud computing that will not be elaborated on further, including the following:

• The use of commercially available cloud technology has less risk in certain areas (e.g., security, scalability) but more potential risk in other areas (e.g., transparency in system changes, maintaining a validated state) than an on-premises or dedicated-host solution.

• An appropriate “risk management” approach for a cloud-based medical device application can be created. (For those who question if cloud computing generally is mature enough as a technical and business model to handle something as crucial as the operation of a medical device, we note that both the DoD¹²  and Office of the Director of National Intelligence²⁶  made the shift to third-party cloud computing platforms a cornerstone of their strategic plans to meet the future national security needs of the United States.)

• You can create an appropriate validation approach for your cloud-based application.

• You can create an appropriate purchasing control that is compliant with 21 CFR 820.50.

• Your security risk management extends to consideration of risks from cloud computing.

Many of the risks and issues that need to be addressed for cloud services are similar to those for connected device solutions with internal IT services. For example, concerns exist regarding service availability, security, data integrity, and change control, including validation. However, cloud services for medical devices have additional risks to consider in each of these categories.

A central issue is that device manufacturers have limited control over and visibility into changes to the public cloud services they are using. They face challenges regarding how to validate the software and how to maintain it in a validated state. As with many other aspects of cloud computing, companies using the cloud weigh the tradeoff of having less control over their computing environment with the incredible economies of scale of public cloud vendors. Among other benefits, the economies of scale allow public cloud vendors to quickly respond to a constantly shifting security threat landscape.²⁷ 

In particular, guidance titled Off-The-Shelf Software Use in Medical Devices from the FDA describes an approach to software validation that can be challenging in a cloud environment²⁸ : “As in the establishment of a product baseline, verification and validation (V&V) activities should occur when maintenance changes are made to a product baseline. Analysis of these changes directs necessary V&V activities. New [off-the-shelf] OTS Software components in a product baseline introduce unknown logic paths and complexities into the product. ‘Black-box’ testing of OTS Software components may allow some validation claims to be made. However, the unknown logic paths and complexities of OTS Software components make it important to know that design structure or logic elsewhere in the system is not impacted. This means a full system regression test should be performed. Results of these validation activities should be documented.”

This is relatively straightforward to accomplish when companies have full control over all elements of the software and computing environment. When updates to OTS software occur, a medical device manufacturer generally can evaluate the changes and revalidate the impact of those changes on its medical device. This is much more challenging in a cloud environment because the manufacturer is not fully in control of that environment and the cloud services provider can regularly make updates to a customer's technology stack without prior notice, let alone prior approval. However, a number of techniques can be applied to address these requirements:

• Gaining improved visibility into changes to underlying services (hardware, OS, software, and other dependencies) and potentially getting more control over when changes are implemented

• Implementing a set of automated testing that can be run at high frequency to ensure the services remain in a validated state

• Performing appropriate risk analysis to address potential issues specific to each individual device arising from changes to or malfunctioning of cloud services

• Maintaining a complete software bill of materials that facilitates security risk management activities by ensuring that the manufacturer has an inventory of every software component and therefore can assess the risks for each component

The types of validation that a medical device manufacturer needs to perform and the frequency with which it needs to conduct them depend on the level of risk associated with its use of the cloud service for a particular device. Understanding the dependencies and associated risks related to the computing platform for each device is the starting point for determining required mitigations both in design and in ongoing monitoring and testing. To the extent that the potential effects of external cloud dependencies can be reduced through software design, the need for more complex, ongoing risk mitigations is greatly diminished. Further, the greater control and visibility a manufacturer has into the change process at the cloud provider, the easier it is to assess the effects of change and mitigate any potential adverse device effects.

Using cloud services as an integral part of a medical device without design-based risk mitigations and some control/visibility of cloud environment changes is likely to result in the need for more complex, real-time mitigations (e.g., ongoing real-time platform monitoring and testing). The notion of medical devices being dependent on software and computing components that are outside of the manufacturer's control has been considered for OTS software. However, the cloud takes the OTS concept to another level in terms of, for example, rate of change, complexity, and lack of visibility/transparency into changes and makes it much easier (e.g., through web services) to integrate with outside components. As a result, medical device manufacturers need to consider how the principles of OTS risk management can be applied to the more complex problems of cloud.

As a basis for the discussion and recommendations presented below, consider that medical devices initially designed for deployment on a cloud platform can directly incorporate architecture and safety systems that reduce the effects and risk associated with external dependencies (mitigation through design and detection). When combined with reasonable supplier qualification, contractual change control/notification, ongoing monitoring/testing of the cloud environment, and revalidation based on regression analysis, implementing a framework of controls to ensure that a device operates continually in a validated state is possible.

The extent of necessary controls should be determined and scaled based on sound risk management, including specific consideration of cloud-computing platform dependencies. If a device manufacturer does not have a clear understanding of the potential effects of the environment on a device and is not able to select a supplier that will allow reasonable transparency into change processes, mitigating safety and performance risk for cloud-based medical devices becomes difficult, costly, and complex.

To illustrate the concepts that have been outlined in this article, the following example provides a fictional case study about a medical device maker that uses a third-party service vendor to deliver remote software upgrades. For purposes of brevity, this example is fairly elementary; the goal is to illustrate the principles involved in using cloud computing as a component of regulated medical devices. Real-world implementations will have specific requirements based on factors such as device intended use, level of risk, and data requirements.

The fictional company, ACME Medical Devices, manufactures a medical device used for an elective procedure performed in a physician's office. Its customers like the product, and the company is planning for growth from several hundred to several thousand units in the field.

Most of the devices already in the field are connected to the Internet, and ACME has built in the capability to collect diagnostic log information from the devices. It uses the data to help identify performance or usability problems and to assist customers when they contact the company for help.

For software updates, the existing practice at ACME is for a field service technician to visit each specialist's office whenever a new version of software is released. The tech carries a USB flash drive issued by the company that contains an installer for the new release, work instructions for the upgrade, a list of the devices to upgrade, and a log for recording the necessary records. The tech emails the log to the company each day, and the data are used to update the device history records.

As the installed base grows, ACME is looking for ways to reduce field support costs while maintaining or improving customer satisfaction. The current software update process is both manual and time consuming. The process is further slowed because the engineering team is introducing new features and correcting bugs through software releases every few weeks. To address these issues, ACME would now like to add the ability to remotely update the software over the Internet.

To validate its use of the cloud, ACME used the process steps identified in AAMI/ISO TIR80002-2 regarding the validation of quality systems software as a structured approach.²⁹  The process steps include the following.

When it began this effort, the product team identified the upstream boundary as the existing software release process and the downstream boundary as the existing process for updating the device history record. The risk analysis for the manual software upgrade process identified several issues and associated hazards:

• An old or unreleased version of the software could be installed, causing the device to malfunction and causing patient injury that might require surgical intervention.

• The software on the flash drive could be corrupted or be infected with malware, causing the device to fail to operate and delaying treatment until repaired.

• The software update could fail, leaving the previous version in place along with any defects not corrected by the new version.

• The device history record may not be updated to reflect the new software version, or the device history record of the wrong device could be updated. In either case, customer complaints could be attributed to an incorrect version of the software and not addressed appropriately.

Prior to mitigation, the software update process was associated with a moderate level of risk due to the possibility of nonpermanent patient injury. The following risk control measures were already in place:

• The field service technician records the version of the software and the device identification from the info menu before the update and again after the update completes, then confirms that the new version is correct.

• The software calculates a hash of the executable during self-test to ensure that the software has not been corrupted. The self-test will fail and display an error message if the hash value is unexpected.

• Prior to returning the device to service, the technician performs a functional test to ensure the device is working properly.

With these mitigations already in place, the company determined that there is a low residual risk of failure from the current software update process.

With this specific example in mind, the following paragraphs outline a series of steps that demonstrate a roadmap for a compliant cloud-based device. These steps are based on established hardware and software device development and support principles but are intended to include adaptations that meet the specific needs and leverage the strengths of cloud-based devices from the design and development stage throughout the product life cycle.

ACME expects that performing the software update process remotely through the use of a cloud-based IoT service will result in more timely updates of software, a consistent upgrade process, an accurate record of which devices were updated and when, and a reduction in the time needed for field service to perform the updates. After reviewing the existing process and the process risks, the product team determines that the IoT service should allow the team to:

• Upload released software to the service.

• Select which devices to update.

• Download the new software to the selected devices.

• Receive the update status from each device.

• Generate reports of the current software version and update status for all connected devices.

The company also plans to retain the existing capability of the IoT service to remotely collect diagnostic logs. Finally, as not all devices in the field are network connected, the company needs to retain the ability for field service technicians to update the software on site.

The product team considers that the existing service used with the medical device has been validated for log upload but that operation had been determined to be low risk because the devices only transmit data when idle and do not receive data from the network. Further, there was little concern for service availability because no risks were associated with a delay or failure to upload the logs. Remote software update would require additional validation to mitigate the risk arising from that process.

The product team is aware of the questions to ask when considering cloud services and selects the following validation activities from the toolbox:

• A supplier audit to assess the capabilities of the IoT supplier to provide remote software updates and to review the supplier's service-level agreement (SLA) and security certifications

• Write detailed requirements for the remote software update service

• Analyze the service for software risks and write tests to evaluate risk areas

• Develop installation and operational qualifications by evaluating the necessary changes to the service configuration and testing them in a sandbox environment.

• Conduct normal and stress tests of the service as part of a limited internal trial

• Perform beta tests with an initial group of clients while a field service technician is on site

• Require product team review and approval of validation tests

• Modify internal and customer training programs to include training on the remote software update process

The product team writes requirements for the new remote software update service that will be used to validate the service prior to deployment. The requirements identify how software updates will be packaged and uploaded to the service, how devices will be selected for updating, under what conditions the package will be downloaded to the device, how the package will be verified and how the service will be notified of the verification, how the operator will be prompted to update and how the service will be notified of the update status, and how the service will report all of this activity.

The product team uses the supplier audit and software requirements to understand and mitigate new risks associated with the service. The team identifies the following new risks:

• The service may be unavailable for an extended period of time leaving critical bugs uncorrected.

• The service interface may change in a way that requires changes to internal procedures before an update can be distributed.

• The software update package may be corrupted in transit to the service, while stored with the service, or when downloaded to the device.

• A new (or old) software update package could be uploaded to the service without following the approved procedure.

• Acknowledgment messages from the device may not be delivered or may be corrupted.

After review, the product team establishes additional risk control measures to mitigate the risks identified in the new software update service. The field service organization will continue to maintain its ability to perform manual updates for both unconnected devices and for all devices in the event of an extended outage, albeit at a slower pace. To address unidentified changes in the service interface, each new update will first be tested internally and then beta tested with several local customers while a field service technician is on site. In addition, the device also runs basic functional tests as a built-in part of the software upgrade process to ensure that the upgraded software works properly on each upgraded device in the field.

Field service also will perform several additional checks of the device logs whenever new logs are received, including checks for the expected software version. Field service technicians will continue to report the device software version whenever they perform maintenance on a system, and any discrepancies with the version reported by the automated system will be investigated. A new category for complaints related to remote software updates will be added to the existing customer complaint handling system.

The product and field service teams plan for the next release of software to be manually installed and to include the vendor's application for file download. Instructions are provided to walk customers through the updating process, a short training video is made available, and a web page is created where customers can ask questions about the update process.

The software update is first tested internally and then beta tested with service on site. After all validation tests have passed and the new procedure has been approved, the new software is released to the installed base.

Each new update will first be tested internally and then beta tested to ensure that the service is still meeting requirements. Metrics for the remote software update service and summaries of any bugs or complaints will be reported at each management review. The product team will review the performance of the service at least yearly to ensure that the vendor is meeting its SLA. The product team also will maintain a list of alternative vendors and draft plans to migrate to an alternative if the current vendor discontinues the service or changes the service so that it no longer meets ACME's requirements.

The following is an initial list of questions that a medical device manufacturer can ask a cloud services provider to help ensure that it is addressing the range of challenges described above. Although the questions have been organized by risk area, some topics cut across multiple areas (e.g., security also is related to availability and data integrity).

Of note, this topic is far too complex to create a single comprehensive checklist that covers every single question that needs to be asked. Therefore, even if you get answers to all of these questions, please do not think that you are done with your due diligence! Rather, consider yourself to be off to a very strong start.

• Questions for the cloud service provider:

  • ○

    Does the vendor provide notification of the substance and timing for upgrades (e.g., hardware, OS, libraries, services), and does the customer have the option to select when these are implemented or to reject them?

  • ○

    Are the requirements for change management and notification included in the contract or SLA?

  • ○

    Does the vendor have a verification program to fully evaluate changes prior to introduction, including compiling a list of internal and customer requirements that form the scope and depth of testing required?

  • ○

    Does the vendor provide test plans and test reports for the new version that meet customer requirements for quality records?

  • ○

    Is the above policy different for features and improvements versus bug fixes?

  • ○

    What is the vendor's policy to roll back to a previous version if the upgrade fails or has critical bugs?

  • ○

    Does the vendor provide technical documentation (e.g., release notes) on all changes prior to implementation to allow customers to assess potential impact?

  • ○

    Does the vendor have recognized certifications (quality management system, security, privacy)? Are they current, and when do they need to be renewed?

  • ○

    Does the vendor allow periodic audits of technical documentation and on-site visits?

  • ○

    Do the vendor's technical systems support user-defined tests that represent user application requirements that can be executed in an automated fashion prior to the release of any changes?

  • ○

    Does the vendor provide for automated application monitoring as a service that monitors, for example, application performance, security, and integrity?

• Questions for your organization:

  • ○

    Does your risk management program include systems similar to this within its scope of analysis?

  • ○

    Does your design control program include consideration of external dependencies and necessary risk mitigations as a part of device architecture and verification/validation?

  • ○

    Do your engineers and software professionals have an in-depth understanding of the available cloud services and limitations?

  • ○

    In a distributed system, how will you support different versions of the software that support the unique regulatory requirements of different regulatory jurisdictions?

  • ○

    Since cloud service providers do not always make changes to their base platforms simultaneously across all global data centers and technology environments, how will you support having devices in use that are operating on different software versions in the period before all systems are upgraded or local approvals are received?

  • ○

    How will you qualify that updated versions continue to meet the organization's needs and assess whether such changes trigger the need for regulatory filings?

  • ○

    How will you update procedures and train users when the service is upgraded?

• Related notes:

  • ○

    For SaaS, an additional consideration is the validated state of the software. If the vendor has a validation toolkit and maintains the software in a validated state based on that toolkit, this is valuable.

  • ○

    There are vendors in the PaaS space (e.g., BrightInsight) that provide and maintain validated services.

  • ○

    One technique often used by medical device companies is to build automated validation scripts, as you would for commercial off the shelf (COTS) or COTS on a multifunction device (e.g., smartphone). The FDA guidance on multifunction devices is useful in this regard.¹⁴ 

• Questions for the cloud service provider:

  • ○

    What physical and virtual security risk assessment and penetration testing has the vendor provided?

  • ○

    What kind of cybersecurity monitoring and active measures do the vendor have available, and what third-party security tools are available?

  • ○

    To what extent does the vendor provide security best practices for its platform?

  • ○

    How will vulnerability disclosures be handled by the cloud provider in support of the manufacturer?

  • ○

    What physical and virtual security systems does the vendor have in place?

  • ○

    How are security vulnerabilities reported, patched, and disclosed?

  • ○

    Does the cloud provider prevent data hosting offshore?

  • ○

    Does the cloud provider have employees or subcontractors offshore? (Many medical device customers will not accept either of these.)

  • ○

    What physical security controls are in place at the cloud provider's data center(s), including items such as power redundancy, fire detection/control, access control, and maintenance procedures?

  • ○

    How are user access credentials stored and protected?

  • ○

    How quickly can access rights be revoked, particularly between the supplier and subtiers?

  • ○

    How is the provider aligned with the Health Insurance Portability and Accountability Act (HIPAA) Security Rule and General Data Protection Regulation (GDPR)?

• Questions for your organization:

  • ○

    What additional security risk assessment and/or penetration testing do you need to do, and will the cloud provider allow such testing?

  • ○

    How are data encrypted in transit and at rest (to include backups)? Who has access to and how are encryption keys maintained?

  • ○

    What confidentiality agreements do you have in place with the vendor and subtiers?

• Related notes:

  • ○

    This is actually much easier in the cloud than in your own environment, because the cloud vendors have much better tools and see far more than any medical device company would on its own.

  • ○

    Situations may exist where the interests of the provider diverge from those of the manufacturer vis-à-vis public announcements and market stance. Contracts may be able to mitigate this somewhat.

• Questions for the cloud service provider:

  • ○

    Can Trusted Platform Modules (TPMs) be incorporated into the solution?

• Questions for your organization:

  • ○

    How do we define the trust boundaries when everything is software defined?

  • ○

    Can a case be made to “partition” the cloud solution into a hybrid state in which the sensitive aspects are separated into private and public clouds, where TPM is used in the private cloud and “less sensitive” aspects are linked by software-based cryptographic techniques in the public cloud?

• Questions for the cloud service provider:

  • ○

    What guarantees of uptime does the vendor have?

  • ○

    What are their responsibilities during an outage whether caused by them or their subtier suppliers?

  • ○

    What guarantees of uptime do you have?

  • ○

    What fail-over options are available?

• Questions for your organization:

  • ○

    Is it acceptable to operate with limited functionality while the service is unavailable?

  • ○

    What risks are associated with individual users being disconnected?

  • ○

    What will you do if the service goes out of business or stops providing the service that you are using?

  • ○

    What is the criticality of the data being housed? How difficult is it to migrate the data? Is the data in a format that is easily moved?

  • ○

    How is the client protected from business failures or a business failure of a subtier supplier (e.g., the functions that the supplier's supplier provides), and what is the impact of loss of that functionality?

  • ○

    What fail-over or migration options do you have available?

  • ○

    What risks arise for your customers or users while the service is unavailable?

• Related notes:

  • ○

    Major cloud vendors have multiple options for fail-over between different regions.

  • ○

    There also are availability and network connectivity considerations that are independent of specific cloud vendors (e.g., DNS flooding).

• Questions for the cloud service provider:

  • ○

    Where is your data stored? This is important in cases where data sovereignty is required. Additionally, what mitigations are in place to prevent malicious alteration of your data from external actors?

  • ○

    How often are your data backed up, and how often have restores been tested?

  • ○

    What kind of monitoring is in place?

  • ○

    What are the vendor's disaster recovery plans, and can they demonstrate periodic testing of those plans?

  • ○

    How often have restores been tested?

  • ○

    When can you request a restore, and how long will it take?

  • ○

    What is the supplier's development or life cycle methodology? Do they actually follow it? Is there proof? Is it documented, is there training, etc.?

  • ○

    Are good vendor management practices in place? (Has the vendor been certified by a third party? If so, look at the documentation.)

• Questions for your organization:

  • ○

    Are you able to export all of your data whenever needed, and have you tested that no data are lost or corrupted when exported?

  • ○

    How are you going to monitor and ensure that data integrity is maintained at rest and in transit?

  • ○

    Are you able to export all of your data whenever needed? Have you tested that no data is lost or corrupted when exported?

  • ○

    What mitigations are in place to prevent malicious alteration of your data from external actors?

• Related notes:

  • ○

    Best practices include architecting your system to maintain data integrity and to perform continuous, automated monitoring for data integrity.

• Questions for the cloud service provider:

  • ○

    What training will the vendor provide for new users and for upgrades?

  • ○

    Does the vendor provide a list of bugs reported by other users, and will you be notified when new bugs are reported?

• Questions for your organization:

  • ○

    What is your incident response procedure related to these vendors?

• Related notes:

  • ○

    Consider both internally driven changes affecting support and changes driven by your vendor.

• Questions for the cloud service provider:

  • ○

    What is the supplier's development or life cycle methodology, and do they provide evidence in suitable quality records that they actually follow it?

• Questions for your organization:

  • ○

    What procedures and processes do you need for your internal product teams, and how is your internal change control process accommodating the cloud?

  • ○

    Overlapping with cybersecurity: What operational cybersecurity controls and processes will you need, and have you architected your system to accommodate these?

  • ○

    What is your incident response procedure related to these vendors?

• Related notes:

  • ○

    One area to think about here is to determine in what ways you are treating the cloud vendor as a subcontractor and in what ways you are treating it as a vendor of COTS or of a multifunction device (e.g., smartphone). The FDA's guidance on multifunction devices¹⁴  and OTS software²⁸  are both useful in this regard.

• Questions for the cloud service provider:

  • ○

    What is the supplier's approach to HIPAA and GDPR compliance, and how does that match up with your requirements?

• Questions for your organization:

  • ○

    Will your solution need to be HIPAA and/or GDPR compliant?

  • ○

    Do cloud vendor business associate agreements meet your requirements?

  • ○

    What services are available in the geographic regions to which you are deploying?

  • ○

    Do you have hard requirements where your data must reside, and can the provider satisfy them?

• Related notes:

  • ○

    Not all cloud solutions are the same everywhere; local legislation affecting one site may get you in trouble in another jurisdiction.

• Questions for the cloud service provider:

  • ○

    Does the vendor have guidance on which services are suitable for GxP (i.e., “good practice” quality guidelines and regulations)?

  • ○

    What information can they provide on the maturity of specific services?

• Questions for your organization:

  • ○

    How will you evaluate individual services provided by a cloud vendor for suitability for your application?

  • ○

    What are the terms of your license agreement? Does the vendor provide any indemnifications? Does the vendor have the necessary license and patent rights to offer indemnification for all components of their offerings?

• Related notes:

  • ○

    Cloud vendors are constantly adding new services and updating and improving existing services. Not all services are suitable for GxP systems, and in some cases, it may take some time for new services to become GxP compatible.

In addition to rapidly overtaking the larger world of computing, cloud computing can provide medical device manufacturers with a means for enhancing the functionality, scalability, and security of their offerings. When deployed by knowledgeable experts, cloud computing can be an excellent alternative to traditional in-house data centers with servers.

However, to ensure safety and performance of their devices, medical device manufacturers using cloud solutions must take into account the corresponding risks. A cornerstone of a successful medical device cloud deployment is understanding the potential effects of a device's external dependencies when using the cloud and implementing appropriate risk control measures in design, change control, and supplier management.

To benefit from the new opportunities created by cloud computing, manufacturers need to approach this area with a clear understanding of the associated risks. The approach described in this article can serve as the basis for future industry collaborations on the topic of cloud computing.

The authors thank John Murray, a former employee of the Food and Drug Administration, for his vision for this article; Nathan Leong and Steve Mutkoski from Microsoft for contributing ideas to the writing of the manuscript; Wil Vargas, formerly a senior director of standards at AAMI, for his contributions to the manuscript; and Richard de la Cruz of Silver Lake Group Inc. for reviewing the manuscript.