Information Model

Caution: In HL7 FHIR R4 the definitions of the Device and DeviceDefinition resources are not very clear about the separation between an operational instance of a device and the general description of the product. This has been corrected with R5. In order to be compliant with FHIR R4, R5, and R6 the HDDT information model does not make use of elements, which are not compliant across these releases._

---

As depicted in the definition of the HDDT logical building blocks, each medical aid or implant in the sense of § 374a SGB V can be divided into

• Personal Health Device: the hardware part including the sensors that measure vital data of the patient
• Device Data Recorder: components responsible for accepting, storing and further processing the measured data. The Device Data Recorder consists of
  • Personal Health Gateway: an intermediate hardware and/or software that retrieves the sensor data at the patient’s or doctor’s side and takes care of securely forwarding it to a Health Record
  • Health Record: a backend platform that stores the measured data

This logical model builds the foundation of the HDDT FHIR based information model. Every artefact of the logical model is mapped onto a class in the HDDT information model. Each class again can be implemented by a standard FHIR R4 resource definition.

Logical model	HDDT information model	HL7 FHIR R4 Resource Definition
Personal Health Device	Personal Health Device Personal Health Device Definition	Device DeviceDefinition
sensor / dynamic configuration	Sensor Type and Calibration Status	DeviceMetric
vital data as measured by the sensor	Interoperable Value	Observation
Device Data Recorder	Device Data Recorder Definition	BfArM internal resource

Measured Data

Data which is measured by a Personal Health Device is shared with a DiGA as an Interoperable Value. Each Interoperable Value is a FHIR Observation resource that implements a defined Observation Profile. These profiles are managed by gematik and made available as FHIR StructureDefinition resources on Simplifier. Each such profile constrains the FHIR Observation resource definition to match the requirements and specific characteristics of a defined Mandatory Interoperable Value (MIV). Each MIV is expressed as a FHIR ValueSet which is managed with the ZTS (German Central Terminology Server). By this, each Interoperable Value is linked with a MIV with respect to its syntax (Observation Profile) and semantics (definition of the MIV).

Remark: In order to keep the UML class diagrams in this section simple and easy to read, not all attributes of the FHIR resources and their HDDT profiles are shown. Only those attributes that are relevant for understanding the HDDT information model are depicted. For the full definitions of the resources please refer to the HDDT profiles in the artifact summary.

Each measured data is described by:

• a LOINC code that defines the kind of data, e.g. a blood sugar value measured as mass per volume. This code MUST be included with the value set of the MIV that is linked with the Observation
• a timestamp (effective[x]) that marks the time or period at which the measurement was performed
• a value[x] that gives the measured value as defined by the code including the unit of the value and the sample rate (for data streams). The value can either be a single point of data, a composite data item, or a sampled stream of data. An example of a single data point is an ad hoc measurement of capillary blood sugar using a blood glucose meter. An example of a composite data item is a blood pressure value made up from systolic and diastolic blood pressure. An example of a stream of data is a sequence of continuous measurements done by a real time Continuous Glucose Monitoring device (rtCGM) during a defined period of time.
• a status that signals the status of the value; e.g. signaling if a data stream is finalized or not

These four elements are the common defined elements of each HDDT Observation Profile on top of the standard FHIR Observation resource definition. Further Observation elements may be constrained by MIV-specific HDDT Observation Profiles. This includes even references between interoperable values, e.g. as in the case of lung function testing, where a measured value may refer to another interoperable value as its baseline (“personal best”).

Beside single observation data, a Device Data Recorder MUST be able to provide aggregated data in the form of a report. Which reports have to be provided and how these reports are implemented on top of standard FHIR resource definitions is defined per MIV in the HDDT specifications.

Example: The MIV Continuous Glucose Measurement defines a HDDT Observation Profile for sampled glucose measurements as performed by real-time Continuous Glucose Monitoring devices (rtCGM). For these devices HL7 International defines a summary report, that holds a PDF report together with coded clinical metrics such as times in ranges, glucose management index and data quality indicators. HDDT requests Device Data Recorders to provide a machine-readable subset of this HL7 report as a HDDT CGM summary report resource.

While the aggregated data in the glucose example is a Collection Bundle, other MIV’s reports may be implemented as FHIR DiagnosticReports or other FHIR resources.

Details on the definition of the MIV ValueSets are given at the end of this section.

Personal Health Device and Device Data Recorder

The part of the HDDT information model that is related to the Personal Health Device is implemented using profiles on standard HL7 FHIR resource definitions as shown in the UML class diagram below. Instances of the classes shown in the blue box are used by the DiGA for retrieving interoperable values and information about the patient’s specific Personal Health Device from the Device Data Recorder.

Personal Health Devices need to be calibrated in order to provide safe measurements. Some devices are already calibrated by the manufacturer while others calibrate themselves after activation and others need to be calibrated by the patient. Whether a Personal Health Device transmits data from a non-calibrated sensor to the Health Record at all depends on the concrete product. For a DiGA to process measured data in a safe manner, the DiGA must know if the data it received was gathered by a calibrated sensor or not.

For Personal Health Devices where the sensor that measures the values requires automated or manual calibration, the Interoperable Value MUST refer to the Sensor Type and Calibration Status. The Sensor Type and Calibration Status is mapped onto a FHIR DeviceMetric resource which holds calibration information in a calibration.type, a calibration.state and a calibration.date element. In addition, the Sensor Type and Calibration Status can provide a definition of the unit that is preferably to be used for presenting measured values to the patient. This unit MAY differ from the unit that is used with the value of the Interoperable Value (which is provided through a backend system).

Example: A rtCGM sensor measures glucose values as mg/dl. All data is stored in the Health Record in this unit. The FHIR Resource Server on top of the Health Record provides the data only using mg/dl as the unit. At the mobile app that came with the rtCGM (the rtCGM’s Personal Health Gateway) the patient configured the preferred unit as mmol/l. Therefore, all data is calculated (by the device or the app) to mmol/l before displaying it to the patient. In this example value.unit of the Interoperable Value is mg/dl while unit within Sensor Type and Calibration Status is mmol/l. The motivation for this behavior is to allow the DiGA to obtain information about the patient’s preference and thus to be in sync with the medical aid by displaying measured values in the same unit.

The Sensor Type and Calibration Status of a measurement refers to the Personal Health Device that contains the sensor. This is a many-to-one relationship which allows for a Personal Health Device to contain multiple sensors for different measured values. E.g. by this a pulse oximeter Personal Health Device can provide pulse and SPO2 as two different Interoperable Values with each of these values being linked with a dedicated Sensor Type and Calibration Status.

In cases where no Sensor Type and Calibration Status reference is provided with the measured value, the Interoperable Value directly refers to the Personal Health Device (element device).

Each instance of a Personal Health Device is represented by a FHIR Device resource and described by

• a human readable devicename and the name of the manufacturer
• its serialNumber. This element is flagged as Must Support (see Use of HL7 FHIR) and as such MUST be provided by the Device Data Recorder’s FHIR Resource Server. This allows the patient to verify that the data processed by the DiGA really originated from the device he is using.
• an expirationDate for devices which have a defined end-of-life. An example for this is an rtCGM sensor which only transmits data for 14 or 15 days (depending on the product) and after this is to be replaced by another device.

Each Interoperable Value MUST contain a device element (as defined by the FHIR Observation resource). This element is mandatory in HDDT profiles. It MUST reference either a Sensor Type and Calibration Status or directly a Personal Health Device (exclusive OR). The exclusive choice between these two types of references depends on the device’s characteristics: A reference to a Sensor Type and Calibration Status MUST be provided from the observation if the personal health device needs to be calibrated (either automatically or by the user) or changes its calibration status over time. If no direct reference to a Personal Health Device is given from the observation, the Personal Health Device MUST be linked with the Sensor Type and Calibration Status. By this, there is always a - direct or indirect - link from any Interoperable Value to the Personal Health Device that originally measured this value. The reasons for this mandatory linking are:

• provenance: the DiGA can always be sure about the full chain of provenance (Personal Health Device -> Device Data Recorder -> DiGA). This information is e.g. needed when a DiGA exports data into the patient’s ePA (personal health record).
• patient safety: There may be situations where a value shown in the device app differs from the same data item when shown in a DiGA, e.g. due to different rounding algorithms or data smoothing. In this cases the serial number provided with the Personal Health Device resource allows the DiGA and the patient to verify that the processed data really originated from the patient’s physical device.

BfArM Registries: Device Definitions

Remark: The following definitions about the BfArM Registries only define the logical viewpoint by describing what kind of information manufactures of DiGA and Device Data Recorders can expect to be available at the BfArM registries. The specification of the BfArM Registries and their FHIR RESTful APIs is the responsibility of BfArM and therefore out of scope of the HDDT specification (see HIIS-API and DiGA Verzeichnis for references to the BfArM specifications which are needed by manufacturers of DiGA, medical aids and implants for managing and discovering DiGA properties and FHIR DeviceDefinitions for Personal Health Devices and Device Data Recorders).

Device Data Recorder Definition

As described in the section on certification relevant systems, the responsibility for implementing the HDDT API is with a Device Data Recorder who operates the Health Record where measured data is stored and made accessible to authorized DiGA through a FHIR Resource Server. These Device Data Recorders must also register themselves with the HIIS-VZ (BfArM Device Registry) such that a DiGA can e.g. discover the API endpoints of the Device Data Recorder’s FHIR Resource Server and OAuth2 Authorization Server. For each Device Data Recorder the HDDT information model incorporates respective resources which are maintained within the HIIS-VZ:

• Device Data Recorder Definition (based on FHIR DeviceDefinition):
  • human readable device name and name of the manufacturer of the Device Data Recorder
  • contact data of the owner of the Device Data Recorder
  • additional static properties of the Device Data Recorder that describe how data for a specific MIV is provided to requesting DiGA (see subsection MIV-Specific Properties of Device Data Recorders below)
  • trust anchors for secure pairing and secure communications (see Security and Privacy for details)
• Device Data Recorder FHIR Endpoint (based on FHIR Endpoint):
  • URL of the FHIR endpoint that a DiGA must call for getting access to the FHIR resources managed by the Device Data Recorder (see previous section).
  • Fully Qualified Domain Name (FQDN) as stated in the FHIR endpoint’s X.509 certificate. This allows a DiGA to securely authenticate the FHIR endpoint.
• Device Data Recorder AuthZ Endpoint (based on FHIR Endpoint):
  • URL of the Device Data Recorder’s Authorization Server that must be called for obtaining the access token for getting access to the FHIR API
  • Fully Qualified Domain Name (FQDN) as stated in the AuthZ server’s X.509 certificate. This allows a DiGA to securely authenticate the authorization endpoint of the Device Data Recorder.

The links between these resources are maintained within the HIIS-VZ as extensions to the FHIR DeviceDefinition that represents the Device Data Recorder Definition (see HIIS-VZ API and https://fhir.bfarm.de/guide/hiis-information-model-en.html for details).

MIV-Specific Properties of Device Data Recorders

For each supported MIV, a Device Data Recorder MUST register the following static properties with the HIIS-VZ:

property	value	comments
Historic-Data-Period	The Historic Data Period defines the maximum number of days into the past for which a Device Data Recorder is able to provide data. E.g. if a Device Data Recorder announces a Historic-Data-Period of 30 days, it MUST be able to serve any request for data that was measured within the last 30 days. If a DiGA queries for data that is older than the declared Historic-Data-Period, the Device Data Recorder will return a 404 Not Found error along with an appropriate OperationOutcome describing that the requested data lies outside the supported historic data period. (See Searching Observations using FHIR-search interactions).	Historic-Data-Period MUST NOT be shorter than the minimum historic data period defined for the affected MIV (see MIV profiles for details).
Delay-From-Real-Time	Average number of seconds until data measured by the Personal Health Device is available under normal operational conditions at the Device Data Recorder’s FHIR end point.	If a DiGA polls for continuously measured device data in fixed intervals, the Delay-From-Real-Time denotes the overlap of two consecutive intervals in order to catch all measured data.
Grace-Period	The Grace-Period defines the number of minutes that a DiGA MUST wait after a previous request for data from the same patient before a new request for data from that patient can be sent to the Device Data Recorder. If a DiGA sends a request for data from a patient before the Grace-Period has elapsed since the last request for that patient, the Device Data Recorder MAY reject the new request.	Grace-Period MUST NOT exceed the maximum grace period defined for the affected MIV (see MIV profiles for details).

A DiGA can retrieve a Device Data Recorder’s specific values for these properties per MIV through the BfArM HIIS-VZ API.

Personal Health Device Definition

Owners of medical aids and implants that fall under the regulation of § 374a SGB V must register at the HIIS-VZ (BfArM Device Registry). This leads to a Personal Health Device Definition which is exposed as a DeviceDefinition resource. A Personal Health Device resource MAY be linked with a Personal Health Device Definition in the HIIS-VZ through the Device.definition element.

Note: The reference from a Personal Health Device to its Personal Health Device Definition is optional for the initial version of the HDDT specification because the Personal Health Device Definition resource does not hold use case relevant information which could not as well be placed in the Device resource (e.g. name and manufacturer of the medcal aid or implant). If a Device resource refers to a Device Definition, this reference MUST point to the respective Personal Health Device Definition entry in the BfArM HIIS VZ.

The Personal Health Device Definition resource for a medical aid or implant is created upon registration of this medical aid or implant with the HIIS-VZ. The information bound to this DeviceDefinition resource include

• a human readable deviceName
• the name of the manufacturer of the device
• the type of the device given as a SNOMED CT code

A Personal Health Device may connect to different Device Data Recorders. E.g. a manufacturer of a blood glucose meter may support different diabetes management platforms of different partners that can all import data from the glucose meter. Each of these solutions may have its own Personal Health Gateway and Health Record (e.g. a SmartPen that can be linked to diabetes diary apps from many different vendors). All of these Device Data Recorders must be able to provide imported blood glucose values to DiGA via the HDDT API (see certification relevant systems). By this there is a many-to-many relationship between Personal Health Devices and Device Data Recorders.

DiGA Definition

While DiGA use the HIIS-VZ RESTful API for retrieving information about registered Personal Health Devices and Device Data Recorders, the manufacturers of Device Data Recorders may use the API of the BfArM DiGA Verzeichnis (BfArM DiGA Registry) for retrieving information about a DiGA that wants to connect to a devive through the HDDT API. This API gives access to DiGA Device Definition data which was provided by DiGA manufacturers to BfArM during registration with the DiGA-Verzeichnis.

HDDT Information Model - Devices and Device Definitions

The orange box in the class diagram below shows the classes of the HDDT information model which are managed with the BfArM Registries. Correlations and dependencies between objects which are managed by the BfArM Registries are shown as dotted lines as it is the responsibility of BfArM to define the respective extensions to the standard FHIR resource types (see https://fhir.bfarm.de/guide/hiis-information-model-en.html for the current version of the HIIS-VZ information model)

MIVs

As written in the beginning of this section, a MIV is technically expressed as a FHIR ValueSet of LOINC observation codes. Each code in a MIV matches the conceptual definition of the MIV and therefore is usable for the intended purposes of a DiGA when processing that MIV. Each MIV’s ValueSet is defined by:

• a description that normatively describes the properties and purposes of the MIV
• a canonical url as a unique identifier that can be used for referencing the ValueSet in the HDDT specification and in BfArM registry entries.
• a business version number that allows MIV value sets to evolve over time (e.g. adding new LOINC codes or splitting MIVs).
• a human-understandable title and a machine-friendly name.
• an extensional list of the LOINC codes that make up the MIV.

url and version together are an unambiguous and widely usable identifier for a MIV ValueSet.

Most of the previously introduced classes of the HDDT information model hold references to a MIV as a whole or to a code from a MIV’s ValueSet:

HDDT class	MIV/code reference	FHIR resource and element
Interoperable Value	The code element signals the MIV of the value. The code MUST be included with the MIV’s value set.	Observation.code
Personal Health Device Definition	For each registered Personal Health Device the BfArM keeps a list of the supported MIVs.	BfArM internal reference
Device Data Recorder Definition	For each Device Data Recorder the BfArM keeps a list of the supported MIVs.	BfArM internal reference
DiGA Definition	For each DiGA the BfArM keeps a list of the MIVs that this DiGA may process for its intended purposes.	BfArM internal reference

All FHIR ValueSet resources that represent the defined MIVs are managed within the ZTS (German Central Terminology Service). DiGA vendors and providers of Device Data Recorders can download all MIV value sets as FHIR packages through a standard API (see section ZTS for details).

The UML class diagram below shows the full HDDT information model. The resources in the blue box are managed by the Device Data Recorder and can be accessed by DiGA via the Device Data Recorder’s FHIR Resource Server. The resources in the orange box reflect the contents of the BfArM registries (Device Registry and DiGA Registry). They can be accessed by DiGA through the BfArM HIIS-VZ API and BfARM DiGA Verzeichnis API. The green box marks the ZTS (German Central Terminology Service) that maintains the definitions and encodings of all MIVs. The ValueSet resources that span the single MIVs can be obtained from this service through a standard RESTful API. The yellow box holds the FHIR Observation Profiles defined for the MIVs and the FHIR profiles for aggregated reports on top of defined MIVs. Upon final approval, these profiles will be made available by gematik on Simplifier.