Cloud hospital software: what vendors decide before the C5 attestation

This page is for vendors of hospital software who offer their software as a cloud service, for example for theatre planning, nursing documentation or patient portals. Whether and how Section 393 SGB V (Book V of the German Social Code) applies to hospitals and their service providers is explained on the Section 393 SGB V page; this page does not repeat that and is not legal advice. For AI software in hospitals with a model provider and inference, see AI in healthcare; for vendors of practice software, see practice software vendors.

The example: theatre and resource planning for hospital groups

Fictitious example, not a customer. A vendor offers software for planning operating theatres, staff and materials as SaaS. The architecture:

• Application in the browser, multi-tenant, run on a cloud platform in a region in Germany; one tenant per hospital.
• Two dedicated instances for large hospital groups that required this in their contracts: their own database and network segments, but the same software, the same deployment and the same operations team.
• Connection to the hospital information system (HIS): patient master data and surgery requests arrive as HL7 messages from the hospital’s communication server, planned and actual surgery times go back. The connection runs through an encrypted site-to-site tunnel between the hospital network and an interface service in the cloud.
• Login of hospital staff via the hospital’s identity provider (single sign-on).
• Operations with on-call cover around the clock, because the hospitals also operate at night and at weekends.

Who is responsible for what: vendor, platform, hospital

The right-hand column belongs in the system description as complementary customer controls (CUEC) (section 3.4.5.1 no. 7). How to word such obligations so that the hospital can implement and evidence them is shown on the complementary customer criteria page.

Decision 1: Where does the subject matter of the audit end at the HIS interface?

In our assessment, at the tunnel endpoint in the cloud. Everything the vendor operates there belongs in the subject matter of the audit: the tunnel endpoint, the interface service and the rules on which messages it accepts. Two criteria describe what has to be evidenced there:

• PI-01 requires, for interfaces through which customers’ IT systems access the service, among other things standardised communication protocols with adequate authentication, encryption over untrusted networks and mechanisms that validate the integrity of the transmitted data (PI-01.01B nos. 1, 2 and 4).
• COS-04 requires every network perimeter to be controlled by security gateways and cross-network access to be based on a security assessment that takes the customers’ requirements into account (COS-04.01B and .02B).

The communication server, tunnel endpoint and firewall in the hospital network are operated by the hospital. They appear as complementary customer controls in the system description. For COS-04 the catalogue also lists complementary customer criteria, but they only cover security gateways at the perimeters of the virtual networks within the cloud service for which the customer is responsible. The auditor does not test these controls at the hospital, only whether they are fairly presented, and points out in the report that the criteria are only met if the customer controls are effective.

Our recommendation: keep an interface sheet per hospital recording which message types flow in which direction, who operates which endpoint and who renews the tunnel’s credentials and certificates. This sheet is evidence for PI-01 and at the same time the basis for the customer controls.

Decision 2: Login via the hospital’s identity provider as an additional criterion?

For hospital software, two additional criteria are worth a look. PI-01.02AC requires interfaces for the customer’s identity providers with a standardised protocol, PI-01.03AC clear documentation of these interfaces for the customer’s subject matter experts. In the example both exist because the hospitals require single sign-on. In our assessment the vendor can add these two subcriteria to the audit scope with little extra effort. Which additional criteria you include is your decision; if you include only some of them, the system description has to state the rationale for the selection (section 3.4.3). The accounts of hospital staff remain a customer control either way.

Decision 3: Do dedicated instances belong in the same report?

In our assessment, yes, if they are part of the service offered. The system description states the name, type and scope of the cloud services provided (section 3.4.5.1 no. 1). If it lists only the shared instance, the two hospital groups receive a report that does not cover their instance. Clarify three consequences before the audit:

1. Population. Patches, changes and access reviews run on all instances. If the auditor draws samples in a type 2 audit, they need the complete list of all cases; your evidence register should therefore show for each control which instances it covers (see evidence register).
2. Patch management. OPS-27 requires, among other things, that patches are scheduled within maintenance windows and tested in a non-production environment before they go into production, with the ability to revert to earlier versions (OPS-27.01B nos. 2 and 3). If you agree separate maintenance windows for dedicated instances, you need evidence for each instance that the patch arrived within the agreed time frame (OPS-28).
3. Separation. Even a dedicated instance shares the platform, deployment tools and operational access with the others. Its separation therefore belongs in the same documented layer model under OPS-30, with a risk assessment that is reviewed at least annually (OPS-31).

Decision 4: Recovery in 24/7 operations

A hospital plans its operating theatres even when the software fails. For that it needs information from the vendor. GC-03 requires the provider to share information on the recovery parameters with the customers’ subject matter experts on request: maximum tolerable period of downtime and RTO, maximum allowable data loss (RPO), recovery time to start emergency operation, minimum business continuity objective and restore time until normal operation. This information is meant to enable the hospital’s own business impact analysis. What GC-03 and the other general conditions require in detail is shown on the general conditions page. Two points matter particularly for hospital software:

• The hospital’s downtime procedure, for example a printout of the day’s schedule and a procedure for emergency surgery, is its own control and belongs in the system description as a complementary customer control.
• BCM-04.01B requires affected cloud service customers and relevant third parties to be involved in the tests of the business continuity plans, which take place at least annually. Invite a hospital to a recovery test and record its feedback. For how continuity tests as a whole become auditable, see BCM domain.

The same applies to incidents: OPS-24 requires the provider to inform customers about the status of incidents that affect them. As a complementary customer criterion, the catalogue adds that the notifications are received and forwarded to the responsible department. For a hospital this means a contact who can be reached at night too.

Evidence vendors of hospital software should prepare

Possible gaps for vendors of hospital software