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 device 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 device 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 specialties 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 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 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.

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 (rtCGM). For these devices HL7 International defines a summary report, that holds a PDF report together with coded key metrics such as times in ranges, glucose management index and data quality indicators. HDDT requests Device Data Recorders to implement the machine-readable part of this HL7 report as aggregated data for the MIV Continuous Glucose Measurement.

While the aggregated data in the glucose example is a profile on top of FHIR Observation, 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. If 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 device 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 pulseoximeter 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.
• further property elements may be defined by the HDDT specification to cover specific dynamic attributes and configuration settings of specific device types, e.g. thresholds for alarms.

Each Interoperable Value MUST either hold a reference to a Sensor Type and Calibration Status or to a Personal Health Device (eXclusive OR). 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

Remark: The following definitions about the BfArM Registries only define the external viewpoint. The information model focusses on what kind of information manufactures of DiGA and Device Data Recorders can expect to be available at the BfArM registries. The information model does not make any assumptions on how this information will be exposed (except for the Personal Health Device Definition). APIs for accessing information about registered devices and DIGA will be defined by BfArM in a separate specification (see HIIS-API and DiGA Verzeichnis for details).

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 as well 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:
  • 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 attributes of the device data recorder platform (e.g. the frequency the Device Data Recorder’s Health Record synchronizes with the Personal Health Gateway)
  • trust anchors for secure pairing and secure communications (see Security and Privacy for details)
• Device Data Recorder 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:
  • 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 servers’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. Users of the registry can discover the Device Data Recorder’s FHIR Resource Server and OAuth2 Authorization Server through the HIIS-VZ API (BfArM Device Registry API).

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. Each Personal Health Device can be linked with a Personal Health Device Definition in the HIIS-VZ through the `Device.definition’ element.

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 resource include

• a human readable deviceName and the name of the manufacturer
• the type of the device given as a SNOMED CT or ISO/IEEE 11073-10101:2020 code
• additional static properties (property) of the product. An example is the size of the device’s internal buffer that can temporarily store measured data in case the device is not connected to the Device Data Recorder.

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.

While DiGA use the HIIS-VZ 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 builds upon a DiGA Device Definition which holds data that a DiGA provided to BfArM during registration with the DiGA-Verzeichnis.

The class diagram below shows the classes of the HDDT information model which are managed with the BfArM Registries together with connected classes. Correlations and dependencies between objects which are managed by the BfArM Registries internally are shown as functions on dotted lines. If such resolutions will be available as APIs or only via the registries’ GUIs has no impact on the technical specification of the HDDT API and therefore is not part of this specification.

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’s 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.