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) per MIV 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 optional. If present it MUST refer to a DeviceDefinition resource in the BfARM HIIS VZ. This ensures that DiGA can only receive static product information which was registered by the vendor of the device.
• 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 pressure value as FHIR Observation resources.

This profile defines the exchange of blood pressure value data for the Mandatory Interoperable Value (MIV) "Blood Pressure Monitoring" which is technically defined by the ValueSet hddt-miv-blood-pressure-value. This MIV is e.g. implemented by automated sphygmomanometers (oszillometric, auscultatory) that can connect to a Personal Health Gateway (e.g. a mobile app for tracking blood pressure values) through wireless communication.

Blood pressure measurements consist of multiple components: systolic blood pressure, diastolic blood pressure, and optionally mean blood pressure. This profile uses the LOINC panel code #85354-9 “Blood pressure panel with all children optional” defined in the MIV hddt-miv-blood-pressure-value to represent the complete measurement.

Obligations and Conventions:

Each Blood Pressure Measurement MUST hold a reference to a Personal Health Device Device resource. Blood pressure devices typically do not require calibration.

This profile inherits from the FHIR Blood Pressure profile (http://hl7.org/fhir/StructureDefinition/bp) and adds HDDT-specific constraints. The blood pressure components (systolic and diastolic are mandatory; mean is optional) are inherited from the parent profile with the MeanBP component added as an optional slice. Each component MUST include a value in mmHg (millimeters of mercury).

Caution: For privacy and data protection, the subject reference MUST only use pseudonymized or anonymized identifiers. Direct patient identification is not permitted.

Constraints applied:

• status is restricted to final
• code.coding[BPCode] is constrained to ValueSet HddtMivBloodPressureValue containing LOINC panel code 85354-9
• component cardinality is set to 2..3 to require systolic and diastolic components (inherited from parent), with mean blood pressure as optional
• component[MeanBP] is added as an optional slice (0..1) for mean blood pressure with LOINC code 8478-0
• Each component’s valueQuantity MUST use UCUM code mm[Hg] for the unit
• device is mandatory and restricted to reference only HddtPersonalHealthDevice

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 the relative lung function testings (i.e. an individual measurement divided by the corresponding reference value) as FHIR Observation resources.

This profile defines the exchange of a single relative value for the Mandatory Interoperable Value (MIV) "Lung Function Testing" which is technically defined by the ValueSet hddt-miv-lung-function-testing. This MIV is e.g. implemented by peak flow meter that can connect to a Personal Health Gateway (e.g. a mobile app for tracking lung function values) through wireless or wired communication.

Obligations and Conventions:

Each Lung Function Testing MAY either hold a reference to a Sensor Type And Calibration Status DeviceMetric resource or to a Personal Health Device Device resource (eXclusive OR). Typically the reference will be to a Device resource, but the option to reference a DeviceMetric resource is provided for compatibility with the overarching HDDT specification.

Each instance of this Observation MUST reference the Observations holding the corresponding raw measurement and reference value via the derivedFrom element.

Constraints applied:

• status is restricted to final
• code is constrained to a subset of the MIV Lung Function Relative Values ValueSet, defined by the HddtLungFunctionRelativeValues ValueSet.
• 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.
• derivedFrom is constrained to require exactly two references: one to the raw lung function testing Observation and one to the lung function reference value Observation.

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.

Profile for capturing the refence values as a FHIR Observation resource when evaluating lung function testings.

This profile defines the exchange of a single reference value for the Mandatory Interoperable Value (MIV) "Lung Function Testing" which is technically defined by the ValueSet hddt-miv-lung-function-testing. This MIV is e.g. implemented by peak flow meter that can connect to a Personal Health Gateway (e.g. a mobile app for tracking lung function values) through wireless or wired communication.

Obligations and Conventions:

Each Lung Function Testing MAY either hold a reference to a Sensor Type And Calibration Status DeviceMetric resource or to a Personal Health Device Device resource (eXclusive OR). Typically the reference will be to a Device resource, but the option to reference a DeviceMetric resource is provided for compatibility with the overarching HDDT specification.

Constraints applied:

• status is restricted to final
• code is constrained to a subset of the MIV Lung Function Reference Values ValueSet, defined by the HddtLungFunctionReferenceValues ValueSet.
• effective[x] is restricted to effectivePeriod 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.
• method is considered mandatory in order to provide information about the method used to determine the reference value. It can be either a code from the HddtLungFunctionReferenceValueMethod ValueSet or a text description.

Profile for capturing lung function testings as FHIR Observation resources.

This profile defines the exchange of a single measurement data for the Mandatory Interoperable Value (MIV) "Lung Function Testing" which is technically defined by the ValueSet hddt-miv-lung-function-testing. This MIV is e.g. implemented by peak flow meter that can connect to a Personal Health Gateway (e.g. a mobile app for tracking lung function values) through wireless or wired communication.

Obligations and Conventions:

Each Lung Function Testing MUST either hold a reference to a Sensor Type And Calibration Status DeviceMetric resource or to a Personal Health Device Device resource (eXclusive OR). Typically the reference will be to a Device resource, but the option to reference a DeviceMetric resource is provided for compatibility with the overarching HDDT specification.

Constraints applied:

• status is restricted to final
• code is constrained to a subset of the MIV Lung Function Testing ValueSet, defined by the HddtLungFunctionTestingValues ValueSet.
• 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.

This ValueSet is part of the Health Device Data Transfer specification (HDDT) which defines profiles, operations, and value sets for sharing data between medical aids and digital health applications (DiGA). Core of the HDDT specification are Mandatory Interoperable Values (MIVs). MIVs are classes of measurements that contribute to defined use cases and purposes of DiGA.

The ValueSet HddtMivBloodGlucoseMeasurement 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). DiGA use cases served by this MIV require glucose values that 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 is part of the Health Device Data Transfer specification (HDDT) which defines profiles, operations, and value sets for sharing data between medical aids and digital health applications (DiGA). Core of the HDDT specification are Mandatory Interoperable Values (MIVs). MIVs are classes of measurements that contribute to defined use cases and purposes of DiGA.

The ValueSet HddtMivBloodPressureValue defines the Mandatory Interoperable Value (MIV) "Blood Pressure Monitoring". 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 Pressure Monitoring covers values from blood pressure measurements performed using oszillometric or auscultatory, automated sphygmomanometers. Measurements are performed based on a care plan (e.g., daily or once per week). DiGA use cases served by this MIV require blood pressure values that are accurate and therefore suited for therapeutic decision making.

The ValueSet for the MIV Blood Pressure Monitoring contains the LOINC code for complete blood pressure panel, but should still have the option to include additional code in future updates.

This ValueSet is part of the Health Device Data Transfer specification (HDDT) which defines profiles, operations, and value sets for sharing data between medical aids and digital health applications (DiGA). Core of the HDDT specification are Mandatory Interoperable Values (MIVs). MIVs are classes of measurements that contribute to defined use cases and purposes of DiGA.

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 (or even more). By this, the MIV 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.

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

CAVE: This ValueSet is part of the Health Device Data Transfer specification (HDDT) which defines profiles, operations, and value sets for sharing data between medical aids and digital health applications (DiGA). The content of the value set will always at latest cover all types of device types for whoch HDDT defines Mandatory Interoperable Values (MIVs). By this, this value set MAY in the future include codes which are not part of the FHIR ValueSet Device Type.

A ValueSet for codes used to specify the method used to determine lung function reference values. Included are codes from the HddtLungFunctionReferenceValueMethodCodes CodeSystem:

• Personal Best
• Predicted Value according to Global Lung Initiative 2012
• Predicted Value according to Global Lung Initiative 2022
• Other

This ValueSet is part of the Health Device Data Transfer specification (HDDT) which defines profiles, operations, and value sets for sharing data between medical aids and digital health applications (DiGA).

This ValueSet defines the LOINC codes, used for lung function reference values:

• The reference value for Peak Expiratory Flow (PEF) is the personal best value achieved by the patient within a certain time frame.
• The reference value for Forced Expiratory Volume in 1 second (FEV1) is in most cases a predicted value, calculated based on demographic data of the patient.

This ValueSet is part of the Health Device Data Transfer specification (HDDT) which defines profiles, operations, and value sets for sharing data between medical aids and digital health applications (DiGA).

This ValueSet defines the LOINC codes, used for relative lung function values. The relative value is calculated by dividing the individual measurement by the reference value, resulting in a percentage value (%). Included codes are for

• FEV1 measured/predicted
• PEF measured/personal best

This ValueSet is part of the Health Device Data Transfer specification (HDDT) which defines profiles, operations, and value sets for sharing data between medical aids and digital health applications (DiGA).

This ValueSet defines the codes used for individual lung function testings, measured by hand-held peak flow meters or spirometers. Included are codes for Peak Expiratory Flow (PEF) and Forced Expiratory Volume in 1 second (FEV1).

This ValueSet is part of the Health Device Data Transfer specification (HDDT) which defines profiles, operations, and value sets for sharing data between medical aids and digital health applications (DiGA). Core of the HDDT specification are Mandatory Interoperable Values (MIVs). MIVs are classes of measurements that contribute to defined use cases and purposes of DiGA.

This ValueSet defines the Mandatory Interoperable Value (MIV) "Lung Function Testing". 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 Lung Function Testing covers values from lung function testings that are performed by exhaling air into a hand-held peak flow meter or spirometer. Measurements are performed twice a day, or more frequently if required by the care plan or the patient’s condition.

The ValueSet for the MIV Lung Function Testing includes LOINC codes for measuring the Peak Expiratory Flow (PEF) and Forced Expiratory Volume in 1 second (FEV1). Also included are LOINC codes for the corresponding reference values, and relative values (e.g. FEV1 measured/predicted). This ValueSet does not include LOIC codes directly, instead the codes come from three separate ValueSets:

• HddtLungFunctionTestingValues: codes for individual lung function testings
• HddtLungFunctionReferenceValues: codes for lung function reference values
• HddtLungFunctionRelativeValues: codes for relative lung function values, calculated in percentages (%)

This CodeSystem is part of the Health Device Data Transfer specification (HDDT) which defines profiles, operations, and value sets for sharing data between medical aids and digital health applications (DiGA). Core of the HDDT specification are Mandatory Interoperable Values (MIVs). MIVs are classes of measurements that contribute to defined use cases and purposes of DiGA.

The MIV HddtMivLungFunctionTesting requires reference values for evaluating measured lung function values. These reference values can be determined using different methods. This CodeSystem provides codes to express typical methods for determining lung function reference values.

Temporary codes for the MIV Lung Function Testing until LOINC codes are avaiblable.

A mapping from temporary codes defined in the HddtLungFunctionTemporaryCodes CodeSystem to LOINC codes. In case no LOINC code is available yet, the mapping indicates that with an equivalence of ‘unmatched’. Whenever a LOINC code becomes available for a temporary code, this ConceptMap will be updated accordingly.

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.

This example represents a Blood Pressure Cuff device definition from the HIIS-VZ.

Example of a blood pressure cuff as a personal health device: The device BP Cuff Pro from HealthTech GmbH performs blood pressure measurements. The device does not have an expiration date as it is a durable medical device. The vendor-defined model number of this type of device is Digital BT 2 and the serial number of the patient’s individual device is BPC0011223345. Both identifiers are printed on the device and allow the patient to validate the authenticity of this Personal Health Device resource.

Example of a blood pressure measurement with systolic, diastolic, and mean blood pressure components.

Example organization representing the manufacturer of the CGM device.

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 organization representing the manufacturer of the glucometer device.

Example of a forced expiratory volume in 1 second (FEV1) measurement taken with a digital peak flow meter.

Example of a peak expiratory flow measurement (PEF) taken with a peak flow meter. Simple version without a reference value or relative value.

Example of a forced expiratory volume in 1 second (FEV1) reference value (predicted) for a patient.

Example of a forced expiratory volume in 1 second (FEV1) relative value (measured/predicted) for a patient.

This example represents a Peak Flow Meter device definition from the HIIS-VZ.

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.

Example authentication endpoint for a universal backend system for processing HiMi data according to § 374a SGB V.

Example FHIR endpoint for a universal backend system for processing HiMi data according to § 374a SGB V.

Example for a universal backend system for processing HiMi data according to § 374a SGB V. Supports multiple device types. Values in the ‘mivSet’ extensions are just exemplary, and do not reflect the specification.

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.