Taking a medical device into the cloud: what manufacturers need to consider beforehand

There are more and more ways we can use software to promote a healthy lifestyle. A whole host of desktop and mobile apps are available on the market to treat everything from knee pain (Recognise Knee) to nicotine withdrawal symptoms (Kwit) and depression (UpLift). If a piece of software is designed by the vendor for therapeutic or diagnostic purposes, it is regarded as a medical device under the law. That means that the manufacturer must comply with all applicable laws and hence all guidelines set out in the different standards there are.

As is the case with many other apps, large amounts of data are often provided, collected and evaluated as content. Because outside providers offer high availability with convenient scaling options, many medical device manufacturers rely on them to store and process this data. In addition to hyperscalers, including the likes of Amazon (AWS), Microsoft (Azure) and Google (Cloud Platform), there are also European providers such as Telekom (Healthcare Cloud) on the market.

This blog post describes how the expectations described in the standards and regulations are presented and grouped to ensure it is possible to examine and document them as part of a larger overall process. It also draws on experience from the pharmaceutical sector, which has been presented by many cloud providers in white papers or guidelines for use under regulated conditions.

What special rules apply to software used in the medical field?

The primary objective when it comes to medical software is the safety and wellbeing of patients, in this case the users of the software. Data is the main consideration in relation to the software and cloud use. which can be broken down into three key aspects:

• Availability: What if data is not available? Take, for example, key findings from an examination that cannot be found shortly before an operation.
• Confidentiality: What if data is available for everyone to see? This could relate to a nasty illness that your colleagues find out about.
• Immutability: What if data is tampered with? Like, for example, your blood glucose levels are doubled.

Lawmakers have provided special procedures to ensure the secure design of software – and for good reason. However, these procedures, which have proved effective in medical software design, cannot be adopted just like that for cloud providers.

Here are the main challenges:

• Internal system updates can be managed by the manufacturer itself. But what about automatic updates to cloud services that are made without prior notice?
• Local suppliers, or even the internal IT department, can be audited to verify compliance with the procedures. But what about international cloud providers?
• How can the handling of highly sensitive personal data be brought in line with the requirements of the EU General Data Protection Regulation and, in the case of digital health apps (‘apps on prescription’), also with the German Social Code (Sozialgesetzbuch, SGB)?

Despite the many challenges and questions, the use of cloud services is not prohibited per se under the applicable laws and standards. Many pharmaceutical companies, medical device manufacturers and medical laboratories already use cloud services and apply many of the principles of computer system validation.

Confusing terminology: what is the difference between qualification, verification and validation?

Depending on how cloud services are used, the requirements in terms of audit documentation may be higher. It is all down to trust or, more specifically, how much trust a manufacturer has to have in order to use cloud services. I will look into this question later on, drawing on the relevant sections of ISO EN 13485 ‘Medical devices – Quality management systems – Requirements for regulatory purposes’.

When it comes to qualification, the sole requirement is that an environment adequately supports the software. This would be the case when the cloud is used as infrastructure within the meaning of Section 6 of ISO EN 13485. Documentation is provided by defining requirements and maintenance activities.

Verification goes one step further: Objective evidence must be provided that a system – in this case the cloud service – has been properly implemented and thus meets the requirements. Section 7.4 of ISO EN 13485 requires the verification of externally procured services. For example, objective evidence could be test cases that are created and run under the two signature rule.

At the top of the pyramid is validation, which involves providing proof that a system fulfils its defined purpose. Here is a simple example: If the cloud service has been tested with respect to the storage of image files but requires a long time to transfer the files, then the defined purpose for use during a short training session in the application has not been met. Validation is always required when the cloud service is used as part of the medical device (ISO EN 13485, Section 7.5).

Specific requirements that the cloud service provider must meet

So what is actually required of the manufacturer of a medical device? As luck would have it, the German Central Office of the Laender for Health Protection with Regard to Medicinal Products and Medical Devices (Zentralstelle der Länder für Gesundheitsschutz bei Arzneimitteln und Medizinprodukten, ZLG) also provides documents that are also used by inspectors to prepare their audits (Aide-Mémoire ZLG 2022). There, right at the top, the following is set out in no uncertain terms: Cloud services may be used if it can be ensured that the cloud service providers are able to act correctly and with sufficient reliability. After the cloud model (private, community, public) as well as the type of services (IaaS, PaaS, SaaS) have been defined in detail, the risks associated with the software and data are analysed and formal agreements with clear-cut responsibilities are drawn up. Also note that the level of risk rises the more customers use the same cloud environment (risk relating to data, less influence on updates). It increases along the axis from the infrastructure to the platform and software, which in turn means that more time and effort will be needed to provide the relevant evidence (qualification – verification – validation).

Unfortunately, there are other sources beyond ISO EN 13485 and the ZLG documentation described above. Requirements that both overlap and complement each other can also be found in the standards for the development of medical software (IEC 62304 and IEC 82304), Technical Guideline TR-03161, the ISPE/GAMP Good Practice Guide IT Infrastructure and white papers or guidelines for use under regulated conditions provided by cloud providers.

Practical examples from adesso

We have collected and categorised the requirements laid out in an array of documents. The following categories:

• Company (certificates);
• Product (documentation);
• Operation (change management); and
• Processes (development)

are used to compile the requirements from each of the sources. While the basic concept is often the same, the details often differ depending on the environment and relevant standards and guidelines. This matrix can be used like an audit checklist. Firstly, the applicable requirements are selected. The existing implementation is then described and evaluated for each requirement in order to define additional activities. Final comments are made on implementation of the activities to complete the description of the requirement.

When collecting the relevant information about the cloud service provider, we recommend a step-by-step approach based the overall level of risk. Many aspects are already covered by existing certificates or reports (ISO EN 9001, ISO/IEC 27001, SOC2) or can be found in the providers’ documents. If necessary, a questionnaire can be filled in by the sales contact at the cloud service provider or an online survey of the departments involved (remote audit) can be arranged. This makes it possible to avoid an on-site visit, which is often mentioned in certain nightmare scenarios.

Phases in the model

Selection phase: In the selection phase, you need to define the expectations in terms of data, supported processes and risks (for example, what happens if a digger cuts the data line?). This also includes choosing an appropriate cloud service provider, the deployment model (private/hybrid/public) and the service model (IaaS/PaaS/SaaS).

Rollout phase: During this phase, the contracts are drafted in order to define the processes at the cloud service provider and also back them up with specific numbers and information (service level, key performance indicators).

Use phase: During this phase, the processes are monitored with the aid of KPIs and an annual audit is carried out to see whether the contracts are being honoured.

By taking this approach, a medical device manufacturer can demonstrate that the specific risks associated with the use of cloud services have been considered and that the requirements set out in the relevant standards and regulations have been reviewed.

You can find out what other challenges the development of medical products entails on our website.

You can find more exciting topics from the adesso world in our blog articles published so far.

Also interesting

• Spelling an end to Schrems II? The new Data Privacy Framework and its implications
• The era of digital health data in Europe – a detailed look at key legislative initiatives
• Personal Health App