DiGA and DiPA manufacturers: setting up the backend system for C5 and TR-03161

This page is for manufacturers of digital health applications (Digitale Gesundheitsanwendungen, DiGA) under Section 139e SGB V (Book V of the German Social Code) and digital nursing applications (Digitale Pflegeanwendungen, DiPA) under Section 78a SGB XI (Book XI of the German Social Code) whose application uses a backend system in the cloud. Whether Section 393 SGB V applies to your service is explained on the Section 393 SGB V page; this needs a legal assessment in each case. This page does not repeat that and is not legal advice.

Three types of evidence side by side

DiGA and DiPA manufacturers come across three types of evidence with different subjects. The table separates them. How the audit subjects of TR-03161 and C5 can be aligned in detail is beyond the scope of this page.

Which guideline applies to the data security certificate is stated by the Federal Institute for Drugs and Medical Devices (Bundesinstitut für Arzneimittel und Medizinprodukte, BfArM): it names the BSI’s TR-03161, Part 1 for mobile applications (version 3.0), Part 2 for web applications and Part 3 for backend systems (version 2.0 each), as “the relevant technical guidelines for the certificates under Section 139e(10) SGB V and Section 78a(7) SGB XI” (our translation).

What TR-03161 Part 3 requires of the platform’s attestation in test aspect O.Org_2 and how the testing body checks it is covered on the TR-03161 and C5 page. For this page it is enough to know: what is required is the cloud service provider’s attestation for the services used and the region used, over the entire period of use.

The example: a DiGA for exercise therapy

Fictitious example, not a client. A manufacturer offers a DiGA that insured persons use to do exercises and record pain scores after knee surgery. The architecture:

• App for smartphones that shows exercise videos and sends inputs to the backend system.
• Backend system on a cloud platform in a region in Germany: app interfaces, data storage, activation with the code from the health insurer.
• Web portal in which treating therapists see progress with the consent of the insured person.
• Crash analytics via a third-party service that collects the app’s error reports.

According to the BSI’s FAQ, all three parts of TR-03161 are therefore relevant: the app (Part 1), the web portal (Part 2) and the backend system (Part 3).

Decision 1: check the platform attestation and define your own attestation

In the example, the backend system runs on several services of the platform. The manufacturer keeps a list of which platform services are in use in which region and compares it with every new platform report: if a service is missing from the report or a report period does not follow on from the previous one, the requirement is open for that service. For how to check what a platform attestation covers for your own service, see C5 scope.

Whether the manufacturer also needs a C5 attestation of its own is covered on the TR-03161 and C5 page. If it comes to that because hospitals, insurers or a regulation require it, the subject matter of the audit in our assessment is the backend system with the web portal and the app interfaces. The app on the smartphone is not part of the cloud service; its development still belongs in the development process the auditor sees. The platform then appears in the system description as a subservice organisation.

Decision 2: one change process for the certificate and type 2

According to the BSI’s FAQ, the TR certificate applies only to the audited version. If a change may affect TR conformity, re-certification is necessary; if an impact is clearly ruled out, the certificate can be extended to the new version through a maintenance procedure. A type 2 C5 report, by contrast, tests whether your change process was effective over the entire period.

DEV-06.01B requires changes to be subject to a risk assessment evaluating their potential impact on the overall cloud service. Our recommendation: add a mandatory field to this risk assessment on whether the change can affect TR conformity, with a justification. The same ticket then evidences the C5 control and documents the decision on re-certification or maintenance. For how to make changes audit-ready overall, see the DEV domain.

Decision 3: purposes and data flows under the DiGAV

The Digital Health Applications Ordinance (Digitale Gesundheitsanwendungen-Verordnung, DiGAV) limits the purposes of data processing. Under Section 4(2) DiGAV, personal data may be processed only on the basis of consent and only for the purposes listed there; consent for ensuring technical functionality, user-friendliness and further development on a permanent basis (no. 4) must be obtained separately from consent for the other purposes. Section 4(3) DiGAV restricts processing, including processing on behalf of the manufacturer, to Germany, the EU, states treated as equivalent and third countries with an adequacy decision.

For the C5 attestation this has two consequences:

• Data flows to service organisations. SSO-07.01B requires the data flow and interfaces to the service organisations used to be documented and customers to be informed what type of data these service organisations process. In the example, error reports flow to crash analytics. In our assessment, the documentation should state that this flow only takes place with separate consent, and the evidence should show how the app enforces this technically.
• Processing locations. PSS-12.01B requires customer data and backups to be processed and stored only in the contractually agreed region. PSS-12.02B requires the same of service organisations: the crash analytics service and every other service organisation that receives data of insured persons must also adhere to the selected region.

Whether the consents are valid under data protection law is a question C5 does not answer. For how to classify service organisations and keep the inventory, see subservice inventory.

Decision 4: customer controls that insured persons can meet

The system description names the complementary customer controls (also called complementary user entity controls, CUEC) that the provider assumes in the design of its controls (section 3.4.5.1 no. 7). For a DiGA, customers are usually insured persons without an IT department. In our view, you should therefore assume only a few simple customer controls, such as a screen lock and installing app updates, and handle everything else in your own service. Guidance for users belongs in the guidelines and recommendations for customers (PSS-01). Therapists in the web portal have their own customer controls, such as how they handle their credentials.

Evidence DiGA and DiPA manufacturers should prepare

Possible gaps at DiGA and DiPA manufacturers