Specification of health data transfer from devices to DiGA (§ 374a SGB V)
Seiteninhalt:
Every DiGA maintains a patient account for each patient. Patients authenticate with this account using credentials that have been initialized during the patient’s registration with the DiGA. By regulation, DiGA MUST NOT identify the patient as a natural person unless this is required for fulfilling regulatory requirements (e.g. exporting data to the electronic patient record). Therefore, the patient identifier used internally by a DiGA is considered as a pseudonym that allows for authenticating the owner of a patient account without identifying this person.
With respect to Device Data Recorders, HDDT makes no assumptions about if and how a patient is identified. Again, the only assumption is that the Device Data Recorder is able to authenticate a user as the owner of a patient account that links to that user’s device data.
A Device Data Recorder MUST NOT transmit any data to a DiGA that allows the DiGA to identify the patient as a natural person – neither during the authorization & pairing process nor during the actual subsequent health data transfer. In particular, the Device Data Recorder
/patient endpoint that is accessible to DiGAsubject reference with any resources that are transmitted to a DiGAsubject reference (if such a reference is included with a resource).To enable user-based data transmission, DiGA and Device Data Recorder MUST agree on a common identifier for the insured person. This identifier is specific to the combination of DiGA and Device Data Recorder. It MUST be a pseudonym, meaning that third parties MUST NOT be able to infer the identity of the data subject solely from the identifier itself.
Neither Device Data Recorders nor DiGA SHALL obtain knowledge of the patient’s health insurance number (KVNR). In addition, medical data transmitted via FHIR MUST NOT contain information that reveals or enables inference of the patient’s identity.
Further normative requirements and technical details regarding the identifier are specified in the dedicated Pairing ID section.
A DiGA authenticates with a Device Data Recorder during connection establishment (mutual TLS, see below) as a client. DiGA’s X.509 client certificate MUST be registered with the DiGA-VZ. Self-signed certificates MAY be used by the DiGA. Certificates and keys MUST comply with BSI TR-02102-2. DiGA authorization is based on OAuth2 and requires a client_id and a redirect_url to be registered as trust anchors with the DiGA-VZ of the BfArM.
The following table summarizes the trust attributes for identification and authentication of a DiGA that MUST be registered with the DiGA-VZ of the BfArM for each DiGA:
| Data Object | Description | Specifications |
|---|---|---|
| client_id | The client_id is determined by BfArM and provided in the DiGA directory. The client_id represents a DiGA-specific, but aid/implant-wide OAuth client identifier. | urn:diga:bfarm:{DiGA-ID} DiGA-ID: a 5-digit number assigned by BfArM that uniquely identifies a specific DiGA. |
| TLS_Client_Cert_DiGA | A TLS client certificate generated by the DiGA provider itself. The public key can be confirmed either by a CA of the DiGA provider or directly by the associated private key (self-signed). No verifiable certificate chain is required, as the Device Data Recorder backend directly validates against the specific certificate registered in the directory (allow list). Apart from the required key usages digitalSignature and clientAuth, the certificate’s contents are not subject to further restrictions and MUST be acceptable as a TLS client certificate by standard TLS libraries. |
The TLS client certificate MUST be an X.509 certificate issued and signed independently by the DiGA provider. The validity period MUST be at least 365 days and MUST NOT exceed 398 days. Certificate revocation MUST be enforced by registering a new certificate and removing the old certificate from the directory. In the case of a planned certificate renewal, the new client certificate MUST be registered before the current certificate expires. For a limited transitional period, both certificates MAY be active simultaneously until the change has been completed on the DiGA side. |
| redirect_uri | URI to which an aid redirects the DiGA frontend after the authentication code has been issued. | DiGA manufacturer/operator transmits this URI to BfArM, which adds the information to the respective directory entry. redirect_uri as an absolute URI according to [RFC 3986] section 4.3 |
Procedures for registering certificates and for exchanging expiring certificates will be published by BfArM as part of the HIIS-VZ specification or corresponding guidelines.
A Device Data Recorder identifies and authenticates itself to a DiGA during every connection establishment using * *mutual TLS (mTLS)**. This applies to all endpoints of the Device Data Recorder, including the Authorization Server and the FHIR Resource Server. The endpoint addresses and the Fully Qualified Domain Names (FQDNs) used for the X.509 certificates of these endpoints MUST be registered with the HIIS-VZ. During the TLS handshake, the DiGA MUST verify that the FQDN in the certificate matches the one registered in the HIIS-VZ.
The Device Data Recorder MUST NOT use self-signed certificates. Certificates and keys MUST comply with BSI TR-02102-2.
The following table lists the trust attributes that MUST be registered in the HIIS-VZ for the identification and authentication of a Device Data Recorder:
| Device Data Recorder Data Object | Description | Specifications |
|---|---|---|
| FQDN (Authorization Server) | The Fully Qualified Domain Name (FQDN) of the Authorization Server uniquely identifies the Device Data Recorder’s authorization endpoint and enables a DiGA to verify its authenticity through the TLS certificate. The FQDN MUST be registered and published in the HIIS-VZ so that DiGAs can validate the Authorization Server’s certificate and establish a trusted connection. | FQDN as specified in the Internet TLS certificate in the Common Name (CN) or in the Subject Alternative Name (SAN) |
| FQDN (FHIR Resource Server) | The Fully Qualified Domain Name (FQDN) of the FHIR Resource Server serves the same purpose as for the Authorization Server. It enables a DiGA to verify the server’s authenticity via the TLS certificate and MUST likewise be registered and published in the HIIS-VZ. | FQDN as specified in the Internet TLS certificate in the Common Name (CN) or in the Subject Alternative Name (SAN) |
| Base URL FHIR-API of the FHIR Resource Server | Device Data Recorder manufacturers/operators transmit the base URL of the Resource Server so that a DiGA can initiate endpoint discovery for the RESTful FHIR API of an aid/implant using {Base URL FHIR-API}/metadata. | url: {FQDN (Resource-Server)} / {manufacturer-specific path} Example: http://example.com/api/v1/fhir/r4 http://fhir.example.com/r4 |
| Base URL OAuth-API of the Authorization Server | Device Data Recorder manufacturers/operators transmit the base URL of the Authorization Server so that a DiGA can initiate endpoint discovery for the OAuth ACG API of an aid/implant using {Base URL OAuth-API}//.well-known/oauth-authorization-server. | url: {FQDN (Authorization-Server)} / {manufacturer-specific path} Examples: http://example.com/api/v1/oauth http://oauth.example.com/v1 |
Procedures for registering endpoint URLs and FQDNs with the HIIS-VZ at BfARM will be published by BfArM as part of the HIIS-VZ specification or corresponding guidelines.
The Device Data Recorder takes the role of the Data Controller acc. Art. 4 Sentence 1 No. 7 GDPR. The Device Data Recorder MUST implement suitable technical and organizational measures to ensure and be able to prove that the processing is carried out in accordance with the GDPR (Art. 42 GDPR). This especially includes the Device Data Recorder’s responsibility to ensure that device data is only disclosed to authorized DiGA.
Based on the consent of a specific user and the MIV-specific authorizations listed for a DiGA in the DiGA-VZ, the Device Data Recorder MUST grant access to a DiGA only for
The MIV-specific authorizations are technically represented using SMART scopes, which define access rights for specific FHIR resources and search parameters. SMART scopes MUST be used consistently across the OAuth 2.0 interface between the DiGA and the Authorization Server including the Authorization-Request and the Token Response.
The Authorization Server issues OAuth 2.0 Access Tokens to a DiGA that reflect these authorization conditions. The DiGA MUST provide this Access Token as a Bearer Token with every request to the Resource Server. The Resource Server MUST verify the authenticity and integrity of the Access Token against its signature and enforce the access restrictions defined above (see Enforcement of SMART Scopes on Observations, DeviceMetric, and Device).
While SMART scopes define the intended access externally, the internal representation of these scopes within the Access Token is implementation-specific. The Authorization Server MAY embed the SMART scopes directly into the token (e.g., as scope-claim in a JWT) or issue an opaque token that references the corresponding authorization data managed internally. In either case, the Resource Server MUST apply the permissions derived from the SMART scopes associated with the issued token.
The requirements defined in “Identification and Authentication of the Patient” MUST be met, meaning that data enabling patient identification MUST NOT appear in the token.
The figure below summarizes the HDDT authorization model and shows how preconditions and context information map onto the access token issued to a DiGA.
Upon registration with the DiGA-VZ, a DiGA registers the values it processes for its “intended use”. For any of these values that match a defined MIV, BfArM links the DiGA with the respective MIV (see Information Model). For each request for measured or aggregated data the Device Data Recorder MUST verify that the requesting DiGA requires the requested data for its intended use. As MIVs are defined through FHIR ValueSets this means:
In addition to measured and aggregated data, a DiGA can as well request information about the patient’s Personal Health Device from the Device Data Recorder. See SMART Scopes for the enforcement of authorization upon such requests.
Data transfer from a Device Data Recorder to a DiGA MUST only be carried out on the basis of the affected patient’s informed consent (§ 374a (1) SGB V). Both the DiGA and the Device Data Recorder MUST provide means to the patient to revoke the consent from within the DiGA and from all patient GUIs of the Device Data Recorder. Once a consent is revoked, the Access Token MUST be invalidated and the DiGA MUST NOT be able to obtain device data from the Device Data Recorder any more (see unpairing of a DiGA).
The period of validity of the consent MUST NOT be longer than the prescription period of the DiGA. If a DiGA has an unlimited prescription period or a prescription period of more than one year, the consent SHOULD NOT exceed one year. The manufacturer of the Device Data Recorder is generally responsible for properly obtaining and renewing consent and monitoring any revocations as well as the follow-up obligations.
Connections between the DiGA and the backend of a Device Data Recorder are secured via a mutually authenticated TLS channel (mTLS). Since the connection takes place over the Internet, the trust space of the Internet PKI is used for server certificates. Specifically, the CAs that are members of the CA/Browser Forum form the trust space and CA Authorization (CAA, https://datatracker.ietf.org/doc/html/rfc8659) and Certificate Transparency (CT, https://datatracker.ietf.org/doc/html/rfc6962) are implemented.
TLS client certificates are not issued by those CAs. Hence the client certificates can be from any PKI or be self-signed and will be directly registered in the DiGA-VZ (BfArM DiGA directory).
For all connections, the DiGA acts as a client and the Device Data Recorder as a server. In the course of establishing a TLS connection, the following steps MUST be completed as part of the certificate check:
client_id (see (c) below)DiGA and Device Data Recorder operators MUST implement CA Authorization (CAA) and publish a corresponding DNS record for their domain. DiGA and Device Data Recorder operators MUST continuously check the CT logs of the known CT log operators (https://certificate.transparency.dev/google/) for unauthorized certificates for their own domain. The measure ensures that unauthorized certificates are detected and that the operator can report this to the issuing CA. The incident does not go undetected and the affected CA can react to it. In addition, the CA then revokes the certificate issued without authorization. The measure is fully effective if, in addition to the above-mentioned verification steps, the verifying entity also checks the revocation status of the presented certificate against the revocation lists (CRL) provided by the issuing CA. Due to the not inconsiderable size of the CRLs, this can lead to performance problems.
Additional Notes:
client_id) MUST be checked. This data has to match the identity of the DiGA meaning both certificate and client_id have to be in the same DiGA-VZ entry. It can be useful for the Device Data Recorder to extract all DiGA certificates from the DiGA-VZ (or at least those from registered DiGAs) to establish an DiGA trust space. This can be passed to the TLS library which verifies the certificate against that trust space during TLS handshake. Most of unauthorized connection attempts will be repelled by that measure. In any case this verification is not enough as additionally the DiGA has to be identified at application layer as described above.Device Data Recorders and DiGA MAY cache trust related information in order to optimize performance. The following table lists the maximum time spans for which trust-related information MAY be cached:
| Information Source | Information to be Cached | Maximum Caching Duration |
|---|---|---|
| DiGA-VZ (BfArM DiGA Registry) | DiGA client certificate | 4 hours |
| HIIS-VZ (BfArM Device Registry) | Device Data Recorder FQDN and endpoint URLs | 4 hours |
| ZTS (German Central Terminology Server) | MIV ValueSets | 24 hours |
| Certificate Authorities | Certificate status information and Certificate Revocation Lists (CRLs) | 2 hours |
If a source for updating cached information is not reachable, the affected system MUST deny/reject incoming request that rely on this information.
Both the DiGA and the Device Data Recorder MUST write an audit trail for privacy purposes. This audit trail MUST at least log the following events for at least 30 days:
Both the DiGA and the Device Data Recorder MUST provide the patient with the ability to inspect the audit trail. Both the DiGA and the Device Data Recorder MUST upon request give responsible data privacy commissioners access to the audit trails.
In order to implement and operate § 374a SGB V in accordance with the law, manufacturers of DiGA and Device Data Recorders MUST regularly inform themselves about changes in the systems relevant to them:
| Manufacturer | System | Change to be tracked | Possible Impact |
|---|---|---|---|
| DiGA | ZTS | MIV Definitions (ValueSets) | • Adjustments to the interpretation of values to be provided interoperably • Requesting renewed consent due to changes in permissions |
| HIIS-VZ | Device Data Recorder Status Supported MIVs FQDN (FHIR, Authorization) Base URL (FHIR, OAuth) |
• Termination of coupling to an aid/implant • Invalidating consent • Configuration adjustments of the DiGA |
|
| Device Data Recorder | FHIR Capability Statement OAuth Server Data Document |
• Adjustments to RESTful FHIR API calls • Adjustments to the used scopes and endpoints |
|
| Aid/Implant | ZTS | MIV Definitions (ValueSets) | • Migration to ValueSet versions • Adjustments to the values to be provided interoperably |
| DiGA-VZ | DiGA-Status Permissions of a DiGA TLS_Client_Cert_DiGA redirect_uri |
• Configuration changes of the Authorization Server • Termination of pairing with a DiGA • Invalidating consent |
The transfer of data between Device Data Recorder and DiGA and the necessary pairing between the two is considered here. The processing of the data before or after it is transmitted is not considered. This includes internal processes at the backend operators, protection of data during storage, protection of the existing and new interfaces against hacking attacks, the authentication of the patient in order to access DiGA, Personal Health Devices and Device Data Recorder, as well as the secure implementation of the respective front-end to back-end communication.
The threats and vulnerabilities affecting these parties, components, and services MUST be considered by those responsible. This is outside the scope for which gematik has a mandate.