Medical devices with a patient cloud: scoping the cloud part for the C5 attestation

This page is for manufacturers of medical devices whose devices transfer patient-related data to a cloud that the manufacturer operates itself or has operated on its behalf. Whether Section 393 SGB V (Book V of the German Social Code) applies to your customers, and therefore to you, is explained on the Section 393 SGB V page. Manufacturers based outside Germany should also see international providers; that page has an example on remote monitoring of patients at home.

C5 and medical device law: two separate questions

A C5 attestation answers questions about the information security of a cloud service. It does not answer whether the cloud software itself is a medical device or part of one, which risk class it belongs to and which obligations follow from the European Medical Device Regulation (MDR). Conversely, a conformity assessment under the MDR does not replace a C5 attestation. This page covers C5 only; the classification under medical device law needs a separate assessment. According to the BSI FAQ, C5 does not cover data protection either.

The example: an image cloud for ultrasound devices

Fictitious example, not a customer. A manufacturer of ultrasound devices offers practices and hospitals a cloud service to which the devices upload examinations. The architecture:

• Device in the practice or hospital, connected to its network. It authenticates to the cloud service with a device certificate from the manufacturer’s certificate authority.
• Receiving service in the cloud, which accepts examinations and assigns them to the right customer.
• Diagnostic reading in the browser for physicians, also when they are on the move.
• Image archive per customer, with retention periods set by the customer.
• Firmware distribution: signed updates for the devices via the same service.
• Operation on a cloud platform in a region in Germany.

Who is responsible for what: manufacturer, platform, customer

Decision 1: the device stays outside, its identity comes inside

In our assessment, the device is not part of the cloud service: it sits with the customer, the customer operates it and connects it to its network. Criteria that would relate to its operation can, however, only be excluded with a justification the catalogue allows, and never because the manufacturer has not set up controls there (section 3.4.3). Its operation therefore belongs in the system description as a complementary customer control.

The device’s identity is a different matter. The cloud service trusts a device because it presents a certificate from the manufacturer. CRY-08.01B requires procedures for securely issuing public-key certificates that the provider issues for its own system components or personnel, including verification of identity before issuance. Whether devices at the customer are system components of the service in this sense is not answered expressly by the catalogue. Our recommendation: treat the issuing of device certificates like that for your own system components and present it that way in the system description. Revocation is part of this: if a device is sold, taken back or reported lost, its certificate has to be revoked, otherwise a third-party device uploads into the former customer’s archive. CRY-13 applies to compromised keys. How keys and certificates as a whole become auditable is covered on CRY domain.

Decision 2: approvals under medical device law and under C5 in one workflow

If the cloud software is part of a medical device, a change goes through its own assessment under medical device law. In addition, C5 requires changes to be subject to a risk assessment evaluating their impact on the overall service, with mitigation measures taken before deployment if the risk is high (DEV-06.01B, .02B), as well as approvals before provision in the production environment (DEV-10). In our view a single workflow pays off: one change ticket with both assessments and both approvals. That gives you a record for every change in the period covered by the type 2 report, and the assessment under medical device law is visible in the ticket without the C5 auditor evaluating it.

Urgent security fixes are the hard part. DEV-15.01B requires procedures for exceptions to change management, including emergency changes, so that the risks are appropriately mitigated. Decide in advance how an emergency fix in the cloud service fits with the assessment under medical device law, and document every exception with date and justification. Firmware for the devices goes through the same process, even though the device itself is not in scope. How changes as a whole become auditable is covered on DEV domain.

Decision 3: large image archives at contract end

An image archive grows over years. If a customer terminates, it has to be able to take its data with it. Three criteria interlock here:

• PI-01.02B requires technical means with which customers can extract their data. Where data volume, format or architecture make extraction by the customer infeasible, the provider offers appropriate extraction services. For large image archives this is, in our assessment, the realistic route.
• PI-02 requires contractual rules for providing the data after the end of the contract, including format, time frames and the point in time of deletion.
• PI-03 requires deletion to comply with the contract and to be documented so that the customer obtains proof. Exceptions are only permitted if a court order requires them or if they are needed to fulfil known future financial and legal obligations (PI-03.01B).

Which retention periods apply to the images is determined by the customer according to its own obligations. The contract should be designed so that the customer can meet them itself after the export; this needs a separate legal assessment.

Evidence medical device manufacturers should prepare

Possible gaps at medical device manufacturers