MII IG ICU
2027.0.0-ballot.3 -
Germany
MII IG ICU
2027.0.0-ballot.3 -
Germany
This page is part of the MII IG ICU (v2027.0.0-ballot.3: Release) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions
| Official URL: https://www.medizininformatik-initiative.de/fhir/ext/modul-icu/ImplementationGuide/mii-ig-icu | Version: 2027.0.0-ballot.3 | |||
| Draft as of 2026-09-15 | Computable Name: MII_IG_ICU | |||
This specification describes the FHIR representation of the core dataset module 'Intensive Care Medicine' of the Medical Informatics Initiative. The use cases of the module and the associated FHIR profiles and terminology resources are described below.
This guideline has been created as part of the Medical Informatics Initiative and is subject to the governance process of the Interoperability Forum and the Technical Committees of HL7 Germany e.V.
Felix Erdfelder
Margaux Gatrio
Christian Gebauer
Christoph Müller
Tim Steinbach
Questions about this publication can be asked at any time at https://chat.fhir.org in the 'german/mi-initiative' stream.
Comments and criticism are always welcome in the form of 'issues' in the Simplifier project.
Felix Erdfelder
Margaux Gatrio
Christian Gebauer
Christoph Müller
Tim Steinbach
Alexander Zautke
Berke Dincel
Ludwig C. Hinske
Larissa Neumann
Lily Wissing
Copyright © 2019: TMF e. V., Charlottenstraße 42, 10117 Berlin
The content of this specification is public. The rights of subsequent use and publication are not restricted.
For the rights of use of the underlying FHIR technology, see the FHIR Basis Specification.
Some of the code systems used are published and maintained by other organisations. The copyright of the publishers listed there applies.
The content of this document is public. Please note that parts of this document are based on FHIR Version R4, which is copyrighted by HL7 International.
The modelling of the data should meet the requirements in terms of complexity and granularity of intensive care, emergency medicine, peripheral inpatient and outpatient data.
This document describes the KDS core dataset intensive care in accordance with development stage 2 (see figure below, "Stage 2").
At least one generic profile is provided for each data type to accommodate data that has not yet been specifically profiled. These generic profiles serve exclusively as templates for the rapid development of prototypes. Whenever possible, the specific profiles should be used.
The profiling also covers the underlying procedures (applications of extracorporeal procedures, ventilation and measurement procedures), the devices involved and their firmware and configuration versions.
Monitoring or vital data includes data such as: Blood pressure (arterial, central venous, pulmonary arterial, ventricular, arterial…), heart rate, temperature, haemodynamic monitoring (cardiac output per time period, cardiac output, systemic and pulmonary vascular resistance, etc.), pre- and post-ductal pulse oximetric oxygen saturation, etc.
The established monitoring and vital data profiles were transferred to ISiK Profile in version 2025.0.0 and have been maintained there in close cooperation ever since.
Parameters of extracorporeal procedures (extracorporeal membrane oxygenation, haemofiltration, dialysis, apharesis …) include data such as: Blood flow, gas flow, dialysate flow, venous and arterial pressure etc.. Accesses are not yet part of the development stage 2 profiled here and are to be modelled in separate specific profiles in the future.
Using the example of ECMO parameters:
A gas flow is set on the ECMO device without a directly corresponding measured value being collected. The blood flow, on the other hand, can be both set and measured (set target value and actual measured blood flow). In both cases, the values are assigned to the same ECMO device on which the values are set or measured.
We distinguish between two types of measured and set values (see figure above):
The device that collected the measured value/for which a value was set is known. It corresponds to the resources with * (i.e. "set value*" and "device*"). In this case, the physical device is known. There is therefore at least one DeviceMetric (as part of the higher-level procedure) to which all (or the applicable) observations refer. This DeviceMetric then contains (in addition to measured/set) a reference to the device that generates the measured values or where a value was set.
The device is not known or should not be modelled. It corresponds to the resources with ** (i.e. "set value** " and "device**"). In this case, the physical device is not known. Observations each point to a generic resource for set value or measured value. These two can in turn refer to a generic device. The DeviceMetrics indicate that the observation is a set or measured value as part of an extracorporeal procedure (see Procedure.category = Observation.category = DeviceMetric.type), the Device indicates that it is an ECMO device, for example. In this case, these same three FHIR resources can be used to annotate all values measured or set in the context of ECMOs.
Ventilation values include data such as ventilation mode, plateau pressure, end-expiratory pressure, support pressure, compliance, inspiratory oxygen fraction (FiO2), end-expiratory CO2 partial pressure, tidal volume, spontaneous and mechanical respiratory rate, etc.. Airways and accesses are not yet part of the development stage 2 profiled here and are to be modelled in separate specific profiles in the future.
Ventilation values are profiled analogue to parameters of extracorporeal procedures.
The semantic annotation references at least one primary code of the LOINC and/or SNOMED CT terminologies. Furthermore, a semantic annotation in accordance with ISO/IEEE 11073-10101 is added whenever possible to enable interoperability with medical device and medical product communication. Attention is also paid to semantic interoperability with the AKTIN data set.