The $hddt-cgm-summary operation is defined on the Observation resource type.
It allows clients to request CGM summary data filtered by effective period, and optionally include related device context (Device, DeviceMetric).

Use cases supported by this operation include:

• Retrieving CGM summary statistics (mean glucose, time-in-range, GMI, etc.) for a patient over a specified interval

Input Parameters:

• effectivePeriodStart (dateTime, optional): Lower bound of the observation effective period.
• effectivePeriodEnd (dateTime, optional): Upper bound of the observation effective period.
• related (boolean, optional): If true, the response bundle also contains related Device and DeviceMetric resources.

Output Parameter:

• result (Reference, required): A Bundle conforming to profile HddtCgmSummary profile containing all matching CGM Observations and, if requested, their related devices.

Error handling (OperationOutcome):

• MSG_PARAM_UNKNOWN: Returned when an unsupported input parameter is used.
• MSG_PARAM_INVALID: Returned when a parameter value is invalid (e.g., bad date format).
• MSG_NO_MATCH: Returned when no matching observations are found.
• MSG_BAD_SYNTAX: Returned when the request is malformed.

This profile defines the exchange of aggregated measurement data for the Mandatory Interoperable Value (MIV) "Continuous Glucose Measurement". By this it provides a patient’s glucose profile for a defined period. The MIV "Continuous Glucose Measurement" is e.g. implemented by real-time Continuous Glocose Monitoring devices (rtCGM) and Automated Insulin Delivery systems (AID) that control an insulin pump from rtCGM data. Future non-invasive measuring methods will expectedly be linked with this MIV and therefore use this profile for sharing aggregated glucose profile data with DiGA, too.

This profile constrains the FHIR Bundle resource for use as the result container of the $hddt-cgm-summary operation.
The operation requests a patient’s glucose profile. The glucose profile is calculated form continuous glucose measurement data and consists of the machine-readable parts of the HL7 CGM summary profile.

The Bundle is of type collection and MUST contain only resources of the following types:

• Observations conforming to HL7 CGM profiles:
  • CGM Summary Observation
  • Mean Glucose (Mass)
  • Mean Glucose (Moles)
  • Times in Ranges
  • Glycemic Variability Index (GMI)
  • Coefficient of Variation
  • Days of Wear!
  • Sensor Active Percentage
• Device resources conforming to HddtPersonalHealthDevice to provide context about the actual Personal Health Device device used.

The purpose of this Bundle profile is to provide a consistent structure for server responses when clients query for CGM data with aggregation logic.
It ensures interoperability across different implementations by defining a predictable response format.
This supports use cases such as:

• Retrieval of CGM summary metrics over a given time interval in support for the upcoming digital disease management program (dDMP) on Diabetes, e.g. for
  • continuous therapy monitoring and adjustment
  • forwarding key data to treating physicians, e.g. for clinical decision support
  • supporting asynchonous telemonitoring by ad hoc provisioning of condensed status information
• Combining aggregated measurement data and device metadata for downstream applications such as visualization or compliance monitoring

Constraints applied:

• Bundle.type is fixed to collection.
• Bundle.entry.resource is restricted to CGM Observation profiles and HddtPersonalHealthDevice. No other resource types are allowed in the Bundle.
• Bundle.entry is set as mandatory. A requests for a CGM summary that would result in an empty bundle, MUST give an OperationOutcome with an error or warning message as its response. Therefore there is no scenario where an empty bundle would be shared with a DiGA.

This profile defines a Personal Health Device within the context of § 374a SGB V. A Personal Health Device acc. to this profile is any medical aid or implant that

• is distributed to patients at the expense of the statutory health insurance and
• transmits the data about the patient electronically to the device manufacturer or third parties, which make the data available to patients and/or physicians via publicly accessible networks.

Personal Health Devices that fulfill the criteria of this regulation MUST be able to pass on data to authorized Digital Health Applications (DiGA acc. § 374a SGB V) using the protocols and interfaces as defined in the HDDT specification.

This profile helps a device data consuming DiGA to

• increase patient safety by comparing the serial number of a Personal Health Device as presented with this profile with the serial number the patient may have provided to the DiGA
• increase data quality by getting information about the current status of the end-to-end communication flow from the Personal Health Device to the device backend and thus being able to detect if there may be more data available for the requested period
• optimize its interactions with the device data providing resource server by getting access to the DeviceDefinition resource that holds static attributes about the device and its connected backend (e.g. minimum delay between data measurement and data availability)

Obligations and Conventions:

The Personal Health Device’s backend regularely synchronizes with the device hardware through a gateway (Personal Health Gateway). The maximum delay that the concrete end-to-end synchronization from the Personal Health Device to the FHIR resource server imposes is provided by the BfArM HIIS-VZ (Device Registry) through the static attribute Delay-From-Real-Time. If a resource server has not synchronized with the connected Personal Health Device for a time span longer than Delay-From-Real-Time(e.g. due to temporarely lost Bluetooth or internet connectivity), the status of the Device resource that represents the Personal Health Device MUST be set to unknown.

Constraints applied:

• status is set to Must Support in order to allow a DiGA to detect missing data (e.g. due to connection issues)
• deviceName and serialNumber are set to Must Support to allow a validation of the source of device data by comparing this information with information printed on the Personal Health Device
• definition is constrained as a mandatory element in order to enable a DiGA to obtain static device attributes through this reference
• expirationDate is set to Must Support to allow a DiGA to be aware of regular sensor changes (e.g. for patient wearing a rtCGM)

The HddtSensorTypeAndCalibrationStatus profile captures the calibration status of a sensor which is part of a Personal Health Device.

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 resource server at all depends on the concrete product. For a DiGA as a device data consumer to process device data in a safe manner, it must be transparent if the data it received was measured by a calibrated sensor or not.

For devices where the sensor that measured a value requires automated or manual calibration, the Observation capturing this value MUST refer to a HddtSensorTypeAndCalibrationStatus resource through its Observation.device element. The HddtSensorTypeAndCalibrationStatus implements a FHIR DeviceMetric resource which holds calibration information in a calibration.type, a calibration.state and a calibration.date element. In addition the HddtSensorTypeAndCalibrationStatus can provide a definition of the unit that is preferrably to be used for presenting measured values to the patient.

The HddtSensorTypeAndCalibrationStatus of a measurement MUST always refer to a HddTPersonalHealthDevice Device resource that represents 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 as a HDDT Personal Health Device can provide pulse and SPO2 as two different interoperable values with each of this values being linked with a dedicated HddtSensorTypeAndCalibrationStatus resource.

Obligations and Conventions:

DiGA as device data consumers SHOULD NOT rely on the DeviceMetric.operationalStatus of a sensor as this status does only reflect the status of the sensor and does not provide information about the end-to-end status of the flow of device data from the sensor within the Personal Health Device to the resource server in the device backend. Instead DiGA SHOULD process the Device.status information that can be obtained through the DeviceMetric.source reference. This element considers the end-to-end availability of data and therefore is the only source for information about potentially missing data (e.g. due to temporal problems with the bluetooth or internet connection).

Constraints applied:

• unit is restricted to UCUM.
• source is constrained as a mandatory element in order to enable a DiGA to obtain dynamic and static device attributes through this reference
• calibration is set to Must Support. This element and respective status information MUST be provided if the sensor performs automated or requires manual calibration after the device has been put into operation with the patient (Device.statusis active).

Profile for capturing blood glucose measurements as FHIR Observation resources.

This profile defines the exchange of a single measurement data for the Mandatory Interoperable Value (MIV) "Blood Glucose Measurement" which is technically defined by the ValueSet hddt-miv-blood-glucose-measurement. This MIV is e.g. implemented by blood glucose meter (glucometer) that can connect to a Personal Health Gateway (e.g. a mobile app for keeping diabetes diary) through wireless or wired communication.

Obligations and Conventions:

Each Blood Glucose Measurement MUST either hold a reference to a Sensor Type And Calibration Status DeviceMetric resource or to a Personal Health Device Device resource (eXclusive OR). A reference to Sensor Type And Calibration Status MUST be provided from the Observation resource if the sensor for measuring blood glucose needs to be calibrated (either automatically or by the user) or if the sensor may change its calibration status over time.

Constraints applied:

• status is restricted to final
• code is constrained to the ValueSet that represents the MIV Blood Glucose Measurement
• effective[x] is restricted to effectiveDateTime and constrained as mandatory.
• value[x] is restricted to valueQuantity. The elements valueQuantity.value, valueQuantity.system, and valueQuantity.code are constrained in a way that a value MUST be provided and that UCUM MUST be used for encoding the unit of measurement. Observation.valueQuantity MAY only be omitted in case of an error that accured with the measurement. In this case, Observation.dataAbsentReason MUST be provided.
• device is set to be mandatory in order to provide the DiGA with information about the sensor’s calibration status and with information about the static and dynamic attributes of the Personal Health Device.

Profile for capturing continuous glucose measurements from real-time monitoring devices (esp. rtCGM).

This profile defines the exchange of raw measurement data for the Mandatory Interoperable Value (MIV) "Continuous Glucose Measurement" which is technically defined by the ValueSet hddt-miv-continuous-glucose-measurement. This MIV is e.g. implemented by real-time Continuous Glocose Monitoring devices (rtCGM) and Automated Insulin Delivery systems (AID) that control an insulin pump from rtCGM data. Future non-invasive measuring methods will expectedly be linked with this MIV and therefore use this profile for sharing data with DiGA, too.

Obligations and Conventions:

Devices for continuously measuring glucose values may produce data with a sample rate of more than 1000 values per day (e.g. current rtCGM provide measures for glucose in interstitial fluid with up to one value per minute). For sharing such data efficently, this profile makes use of the FHIR sampledData data type. Sampled data is portioned into chunks of a fixed size (for an exception see below), with the chunk size being set by the resource server (e.g. such that 24 h of measurements fit into a single chunk). If a DiGA requests data for a period where the end time is earlier that the expected end time of the current chunk, the resource server only fills up the chunk up to the requested end time and sets the Observation.status to incomplete while Observation.effectivePeriod captures the full period of the chunk (see section "Retrieving Data" in the HDDT specification for details on chunks and missing data).

Each Continuous Glucose Measurement MUST either hold a reference to a Sensor Type And Calibration Status DeviceMetric resource or to a Personal Health Device Device resource (eXclusive OR). A reference to Sensor Type And Calibration Status MUST be provided from the Observation resource if the sensor for continuous measuring needs to be calibrated (either automatically or by the user) or if the sensor may change its calibration status over time. A change in DeviceMetric.calibration.state or a change of Device.status to inactive finalizes the current chunk and therefore is the only reason why a chunk may be smaller than the defined fixed size.

Constraints applied:

• code is constrained to the ValueSet that represents the MIV Continuous Glucose Measurement
• effective[x] is restricted to effectivePeriod and constrained as mandatory. Both a starting time and an end tme MUST be given.
• value[x] is restricted to valueSampledData. The elements valueSampledData.origin.unit, valueSampledData.origin.system, and valueSampledData.origin.code are mandatory. valueSampledData.origin.system is restricted to UCUM. Observation.valueSampledData MAY only be omitted in case of an error that accured with the measurement. In this case, Observation.dataAbsentReason MUST be provided.
• device is set to be mandatory in order to provide the DiGA with information about the sensor’s calibration status and with information about the static and dynamic attributes of the Personal Health Device.

This ValueSet includes codes used to identify Personal Health Devices and Device Data Recorders.

This ValueSet’s definition is a subset of the definition of the FHIR R5 ValueSet Device Type, adapted for use with the FHIR R4 based HDDT profiles.

This ValueSet includes concepts from ISO/IEEE 11073-10101:2020, SNOMED CT and HL7 International. Codes from the ISO/IEEE 11073-10101 Health informatics — Point-of-care medical device communication — Nomenclature standard are included under the terms of HL7 International’s licensing agreement with the IEEE. Users of this specification may reference individual codes as part of HL7 FHIR-based implementations. However, the full ISO/IEEE 11073 code system and its contents remain copyrighted by ISO and IEEE.

This ValueSet defines the Mandatory Interoperable Value (MIV) "Blood Glucose Measurement". The definition is made up from

• this description which provides the semantics and defining characteristics of the MIV
• a set of LOINC codes that define MIV-compliant measurement classifications along the LOINC axes component, system, scale and method

The MIV Blood Glucose Measurement covers values from "bloody measurements" e.g. using capillary blood from the finger tip. Measurements are performed based on a care plan (e.g. measuring blood sugar before each meal) or ad hoc (e.g. a patient feeling dim what may be an indicator for a hypoglycamia). Values are very acurate and therefore suited for therapeutical decision making.

The ValueSet for the MIV Blood Glucose Measurement contains LOINC codes for blood glucose measurements using blood or plasma as reference methods with the values provided as mass/volume and moles/volume. In addition more granular LOINC codes for "Glucose in Capillary blood by Glucometer" provided as mass/volume and moles/volume are included with the value set because these codes are already in use by several manufacturers of glucometers.

This ValueSet defines the Mandatory Interoperable Value (MIV) "Continuous Glucose Measurement". The definition is made up from

• this description which provides the semantics and defining characteristics of the MIV
• a set of LOINC codes that define MIV-compliant measurement classifications along the LOINC axes component, system, scale and method

The MIV Continuous Glucose Measurement covers values from continuous monitoring of the glucose level, e.g. by rtCGM in interstitial fluid (ISF). Measurements are performed through sensors with a sample rate of up to one value per minute. By this Continuous Glucose Measurement can e.g. be used to assess dependencies between a patient’s individual habits and behavious and his glucose level. Due to the high density of values over a long period of time, many key metrics can be calculated from Continuous Glucose Measurement which help the patient and his doctor to easily capture the status of the patient’s health and therapy.

The ValueSet for the MIV Continuous Glucose Measurement includes codes relevant to continuous glucose monitoring (CGM) in interstitial fluid (ISF), considering mass/volume and moles/volume as commonly used units. In the future codes defining non-invasive glucose measuring methods may be added to this value set.

Example of a blood glucose measurement taken with a glucometer.

Example of a blood glucose measurement taken with a glucometer.

Example of a blood glucose measurement taken with a glucometer.

Example of a glucometer as a personal health device: The device GlukkCheck plus mg/dl from Glukko Inc. performs “bloody” measurements from capillary blood. As glucometers do not expire (that is just the case for the test stripes), the expiration date is not set. The vendor-defined model number of this typeof devices is CGPA987654 and the serial number of the patient’s individual device is SN123456. Both identifiers are printed on the back of the device and allow the patient to validate the authenticity of this Personal Health Device resource.

Example for a medical device definition (Glucometer) from the HIIS-VZ.

Example of a DeviceMetric for blood glucose measurements from a glucometer: The device measures the glucose concentration from capillary blood by using test strips. The patient’s preferred unit is mg/dl which is used by the device for displaying measured values. The glucometer needs to be calibrated by the patient using control strips. The last calibration was performed in Septemer 2025 and the glucometer is still calibrated.

Example of a CGM time series with status preliminary and dataAbsentReason

Example of a real-time Continuous Glucose Monitoring device (rtCGM) as a personal health device: The device GlukkoCGM 18 from Glukko Inc. performs continuous glucose measurements from interstitial fluid. The sensor stops transmitting data on September 10, 2025, and must be replaced by the patient at that date. The vendor-defined model number of this typeof devices is GCGMA98765 and the serial number of the patient’s individual device is CGM1234567890. Both identifiers are printed on the package of the device and allow the patient to validate the authenticity of this Personal Health Device resource.

This example represents a Continuous Glucose Monitoring (CGM) device definition from the HIIS-VZ.

Example configuration for measurements from a real-time Continuous Glucose Monitoring (rtCGM): The device measures the glucose concentration from interstitial fluid with a frequency of one measurement every minute. The the unit set by the patient for displaying measured values is mg/dl. The device is calibrated by the manufacturer and does not require user calibration.

Example of a CGM time series with 1-minute intervals over 1 hour (60 samples).

Example of a CGM time series with 5-minute intervals over 1 hour (12 samples).

Example of a CGM time series with 1-minute intervals over 20 minutes (20 samples), but incomplete.

Returned when the request is malformed.

Returned when a parameter value is invalid.

Returned when no CGM observations are found.

Returned when an unsupported input parameter is provided.

This example represents a patient without content.

This example is an instance of the CGM Summary profile. It provides a consolidated summary of a patient’s CGM data over one month, linking to more detailed observations for specific metrics.

This example is an instance of the Coefficient of Variation (CV) profile. It represents a summary observation of the glucose variability for a patient over the period from May 1, 2024, to May 31, 2024, with a final recorded coefficient of variation value of 34%.

This example is an instance of the Days of Wear profile. It represents a summary observation of the number of days a Continuous Glucose Monitoring (CGM) device was worn by the patient over the period from May 1, 2024, to May 31, 2024, with a final recorded value of 28 days.

Bundle containing CGM summary observations for a patient together with associated Device and DeviceMetric resources.

This example is an instance of the Glucose Management Indicator (GMI) profile. It represents a summary observation of the estimated A1C-like value (GMI) for a patient over the period from May 1, 2024, to May 31, 2024, with a final recorded value of 6.8%.

This example is an instance of the Mean Glucose (Mass) profile. It represents a summary observation of the mean glucose level for a patient over the period from May 1, 2024, to May 31, 2024, with a final recorded value of 145 mg/dL (mass per volume).

This example is an instance of the Mean Glucose (Molar) profile. It represents a summary observation of the mean glucose level for a patient over the period from May 1, 2024, to May 31, 2024, with a final recorded value of 8.1 mmol/L (moles per volume).

This example is an instance of the Sensor Active Percentage profile. It represents a summary observation of the percentage of time a Continuous Glucose Monitoring (CGM) sensor was active for the patient over the period from May 1, 2024, to May 31, 2024, with a final recorded value of 95%.

This example is an instance of the CGM Summary Times in Ranges profile. It represents a summary observation of the time a patient spent in different glucose ranges over the period from May 1, 2024, to May 31, 2024. The recorded values are 3% in the very low range, 8% in the low range, 65% in the target range, 20% in the high range, and 4% in the very high range.