Implementation Guide
Health Device Data Transfer
Version 0.1.0 - ballot

Specification of health data transfer from devices to DiGA (§ 374a SGB V)

FHIR Resource Server

Introduction

Authorized DiGA can access data from medical devices and implants through standard FHIR RESTful APIs and dedicated FHIR operations. These endpoints MUST be implemented by Device Data Recorders as certification relevant systems

This chapter defines the FHIR endpoints which are common to all Mandatory Interoperable Values (MIVs). MIV-specific specifications for HDDT Observation Profiles and HDDT-specific FHIR operations can be found under the menu MIV-Specific APIs.

FHIR Endpoints

The manufacturer of a certification relevant Device Data Recorder MUST implement the following endpoints, for the purpose of allowing DiGA to access data from medical aid and implants according to § 374a SGB V:

Security Considerations

Access to a Device Data Recorder’s FHIR Resource Server MUST be secured according to RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens. Details on concrete procedures and requirements for OAuth 2.0 Mutual-TLS Client Authentication are specified in the Security and Privacy chapter.

With each request the DiGA MUST present a valid access token issued by the OAuth2 Authorization Server of the Device Data Recorder. The Device Data Recorder MUST validate the access token and MUST consider the data associated wth the token (patientID, eligible MIVs) with the access control decision. Details about issuance and renewal of Access Token are specified in the OAuth2 Authorization Server chapter. Details about the application of the SMART scopes encoded with the Access Token are given in the Smart Scopes chapter.

Both DiGA and Device Data Recorder MUST write access and usage logs according to the Security and Privacy chapter.

The sequence diagram below illustrates the access control flow between a DiGA and the Device Data Recorder’s FHIR Resource Server and OAuth2 Authorization Server.

RESTFul FHIR API Access Control LogicDiGABackendDevice Data RecorderAuthorization ServerDevice Data RecorderResource ServerFHIR-Resource Request (access-token)alt[Access Token expired]HTTP 401 UNAUTHORIZED "token_expired"token request including tls_client_auth and refresh-tokenAuthentication of theDevice Data Recorder (FQDN, X.509 Cert)Authentication of the DiGA(client_id, X.509 Cert)Validate status of DiGA(client_id) against DiGA-VZValidate refresh-tokentoken response (access-token, refresh-token)FHIR resource request (access-token)Authentication of theDevice Data Recorder (FQDN, X.509 Cert)Authentication of the DiGA(client_id, X.509 Cert)Validate access-tokenValidate request againstFHIR API access specificationsDerive Pairing-ID and internalpatientID from access tokenValidate request against MIVs/Scopesassociated with the access-tokendiscover requested FHIR ressources(patientID, MIV, request arguments)write log entries (Pairing-ID, ...)FHIR ressourceswrite log entries (Pairing-ID, ...)Process FHIR resources for eligible purposes
Figure: RESTFul FHIR API Access Control Logic


Remark: The FHIR Resource Server MAY cache registry information (e.g. certificate of a DiGA)and certificate status information (e.g. revocation status of a DiGA certificate). See the Security and Privacy chapter for details and maximum caching durations.