Specification of health data transfer from devices to DiGA (§ 374a SGB V)
Seiteninhalt:
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.
The manufacturer of a certification relevant Device Data Recorder MUST implement the following endpoints, for the purpose of allowing DiGAs to access data from medical aids and implants according to § 374a SGB V:
Search parameters are an integral part of this FHIR API, as they allow the client to request only resources matching certain criteria. For example, by requesting measurement data for a specific date range, or only for a specific LOINC code, as well as including additional FHIR resources in the search result, sorting of search results, etc.
The table below lists what search parameters MUST, SHOULD, or MAY be supported. Each entry links to the search parameters section of the relevant FHIR resource specification. Implementation details for each search parameter (such as syntax and behavior) are defined by their data type on the linked page. For example, code uses the token data type, while device-name uses the string data type.
| Search parameter | Support | Applies to | Note |
|---|---|---|---|
code |
MUST | Observation | Constraining the search to a specific LOINC code, or code from a MIV ValueSet. Link to search parameter list. |
date |
MUST | Observation | Constrain search results based on a date or date range. Link to search parameter list. |
subject |
MUST* | Observation | * Special considerations apply for the subject search parameter. See Retrieving Data for more details. Link to search parameter list. |
valueQuantity |
MUST* | Observation | * Only applies to MIV Lung Function Testing and MIV Blood Glucose Measurement. Search for observations based on their value. Link to search parameter list. |
component-code |
MUST* | Observation | * Only applies to MIV Blood Pressure Monitoring. Search for observations based on component codes. Link to search parameter list. |
component-value-quantity |
MUST* | Observation | * Only applies to MIV Blood Pressure Monitoring. Search for observations based on component values. Link to search parameter list. |
component-code-value-quantity |
SHOULD* | Observation | * Only applies to MIV Blood Pressure Monitoring. Search for observations based on both component code and value. Link to search parameter list. |
device-name |
MUST | Device | Search for devices by their name. Link to search parameter list |
type |
MUST | Device | Search for devices by their coded type. Link to search parameter list |
manufacturer |
MUST | Device | Search for devices by their manufacturer. Link to search parameter list |
patient |
MUST* | Device | * The same special considerations as for the Observation.subject search parameter apply. See Retrieving Data for more details. Link to search parameter list. |
_id |
MUST | all | Search for resources by their logical id. Link |
_include |
MUST | all | Request an additional FHIR resource to be included in the search results, e.g. search for Observation resources and include the referenced Device and DeviceMetric resources in the resulting Bundle. Link |
_sort |
MUST | all | Specifies the order to return search results, with optional descending order using a ‘-‘ prefix. Link |
_count |
MUST | all | Specifies the maximum number of resources to return in a single page of search results. Link |
_lastUpdated |
SHOULD | all | Search for resources based on the last time they were changed. Link |
_has |
MAY | all | Allows selecting resources based on the properties of resources that refer to them (reverse chaining). Link |
_revinclude |
MAY | all | Requests that resources which refer to the matched search results also be included in the resulting Bundle. Link |
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 with 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.
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.