Module DIAGNOSIS

Landingpage (Medizininformatik Initiative - Modul Diagnosis - ImplementationGuide)

Core Data Set Module DIAGNOSIS

Note	Under construction!
Image Not Showing Possible Reasons The image file may be corrupted The server hosting the image is unavailable The image path is incorrect The image format is not supported Learn More →	This Implementation Guide represents the current working version of the module 'DIAGNOSIS'. The respective version published for productive use can be found on this page of the Medical Informatics Initiative.
This specification describes the FHIR representation of the module `DIAGNOSIS` in the core data set of the Medical Informatics Initiative (MII).

The use cases of the module, as well as the associated FHIR profiles and terminology resources, are described below in their binding form.

Publication
Date	04/07/2021
Version	1.0.3
Status	Active
Realm	DE

Note Das Datum an dieser Stelle ist US Format. Also 07.04.2021

IG MII KDS module Diagnosis
- Description of the module
- Context in the overall project / references to other modules
- References
- Use cases / information model
  - Descriptions of scenarios for the application of the modules
  - Data sets incl. descriptions
  - UML
- Technical implementation
  - FHIR profiles
  - Terminologies

Impressum

This guideline was created within the framework of the Medical Informatics Initiative (MII) and is subject to the voting process of the Interoperability Forum and the technical committees of HL7 Germany e.V. per governance process.

Note: Hier bin ich nicht ganz Sicher, Technisches Komitee der HL7 Deutschland e.V. übersetzt werden soll

Contact

Josef Schepers, Berlin Institute of Health (BIH)
Andrea Essenwanger, Berlin Institute of Health (BIH)
Karoline Buckow, TMF – Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V.
Sylvia Thun, Berlin Institute of Health (BIH), Charité Universitätsmedizin

Questions about this publication can be asked at any time at chat.fhir.org in the stream 'german/mi-initiative'.

Comments and criticism are always welcome in the form of 'Issues' in the Simplifier project.

Authors (alphabetical order)

Alexander Zautke (HL7 Deutschland)
Andrea Essenwanger (BIH)
Antje Wulff (HiGHmed)
Caroline Böhnisch (HiGHmed)
Christian Kamann (MIRACUM)
Dagmar Büschges (SMITH)
Danny Ammon (SMITH)
Detlef Kraska (MIRACUM)
Eugenia Rinaldi (HiGHmed)
Fabian Prasser (DIFUTURE)
Florian Rißner (SMITH)
Hauke Hund (HiGHmed)
Heinrich Lautenbacher (DIFUTURE)
Holger Stenzhorn (DIFUTURE)
Josef Schepers (CORD-MI)
Julia Schaefer (TU Berlin)
Julian Saß (HiGHmed)
Kai Heitmann (HL7 Deutschland)
Kutaiba Saleh (SMITH)
Laurence Strasser (Medizinische Universität Wien)
Martin Boeker (MIRACUM)
Matthias Löbe (SMITH)
Miriam Hübner (Universität zu Lübeck)
Moritz Lehne (HiGHmed)
Quynh Trang Nguyen Thi (Technische Universität Ilmenau)
Raffael Bild (DIFUTURE)
Sylvia Thun (HL7 Deutschland)
Thomas Ganslandt (MIRACUM)
Toralf Kirsten (SMITH)
Ulrich Sax (HiGHmed)

Copyright notice

The content of this specification is public. There are no restrictions on subsequent use or publication rights.

For usage rights of the underlying FHIR technology, see the FHIR Base Specification.

Some code systems used are published and maintained by other organizations. The copyright of the respective publisher is valid.

Disclaimer

The content of this document is public. It should be noted that parts of this document are based on FHIR Version R4, which is copyrighted by HL7 International.

Although this publication has been prepared with the utmost care, the authors cannot accept any liability for direct or indirect damage that may arise from the contents of this specification.

Description module diagnosis

Introduction

Diagnoses play a vital role in many different Questions, therapy decisions and business processes of the German healthcare system and thus also in the use cases of Medizininformatik-Initiative (MII) (Eng. Medical Informatics Initiative).

The goal of providing support and enabling for the use cases of MII, across consortia and institutions, is the superficial criterion in modelling the module DIAGNOSIS and the respective FHIR-profiles. As far as possible, as well as focused as possible, more use cases are anticipated.

The module DIAGNOSIS is meant to hold the description of disease and more features of a person (as stored in module PERSON). Each person may have one or more diseases at a given point in time or during a time period. These can be described by diagnoses with variable accuracy.

Due to the MII priority of secondary use of real-world data of the health care context for both care and research, the basic module DIAGNOSIS, which is intended to designate and provide diagnoses in a provider-, sector- and context-neutral manner as far as possible, encounters notable challenges. For some use cases, the design of the module can only compensate to a limited extent for the limitations regarding the requirements of multiple usability, temporal assignment and international interoperability of the digitally available data sources.

The authors of the module DIAGNOSIS attempt to provide their part in overcoming these restrictions by setting milestones for documentation in the german healthcare system.

First and foremost, the use of additional catalogs will be anticipated. For international - or special projects (e.g. rare diseases) the parallel availability of complementary diagnostic catalogs is required. The following can be highlighted:

ORPHA codes for rare diseases
SNOMED CT (Systematized Nomenclature of Human and veterinary Medicine - Clinical Terms)
Alpha-ID which is based on the alphabetical index in ICD-10-GM

As of now, the 11th revision of the ICD must also be taken into account, the introduction of which is being prepared by the subordinate BMG authorities DIMDI and BfArM.

For example, the use of the ICD-O which allows a more differentiated description of cancers, is also aimed at. However, this will not be opened in the basic module DIAGNOSIS, but in the extension module ONKOLOGY. Furthermore, the use of symptom and phenotype terminologies, such as the Human Phenotype Ontology is to be standardized. However, this will also not be done via the basic module DIAGNOSIS, but via an extension module with the working title CLINIC/SYMPTOM/PHENOTYPE.

Mapping of the DIAGNOSIS module in ART-DECOR

The module provides for the following characteristics of a diagnosis, which are already or will soon be needed for the automated processing of diagnostic information in the use cases of the MII:

Image here

Features module DIAGNOSIS

The MII core data set is intended to enable all use cases of the MII across institutions and consortia. Its implementation requires a significant use of resources. This effort must be justified by the advantages over more easily available alternatives that satisfy the FAIR principles “Findable, Accessible, Interoperable, Reusable” at a lower level.

In this sense, the MII core data set can be interpreted as a further development and as a competing offer to the data set according to §21 KHEntG. Therefore, the closer presentation of the features will be structured by reflecting on the dimensions that have been mentioned as orientation aspects for the design in the first description of the MII core data set dated March 10, 2017 (PDF):

National and international interoperability
Multiple usability
Time allocation

1. National and international interoperability

One approach to interoperability is to synchronize the MII core data set with the information model of the important FHIR reference, International Patient Summary (IPS) and the Medical Information Objects (MIO) of the KBV.

National interoperability refers to the ability to interoperate within Germany. This is guaranteed, for example, by the data set according to §21 KHEntG (“P21”) in the communication of about 2000 German hospitals with about 150 German health insurance companies – especially for the more or less flat-rate service remuneration. Due to the high focus on billing and the restriction to the ICD-10-GM classification, hospitals and other health care facilities can only interact on a rough basis in these circumstances. A major goal of the MII core data set - as described below - is to enable a more differentiated, requirements-based collaboration in care and research. In this context, a distinction from international interoperability is not useful.
International interoperability accordingly refers to the ability to interact as seamlessly as possible beyond German borders. This is particularly necessary in international research and even more when specific and specialized issues are involved. In the area of rare diseases this is self-evident; however, the increasing differentiation of observations and understanding the cause-effect relationships is ultimately found in every discipline. International interoperability is also required if digitally stored knowledge generated in one or more countries is to be automatically verified and applied in foreign contexts.

As a first step, this requires categorizing, classifying, and coding diagnoses in a meaningful and uniform way at each origin using internationally agreed classifications and/or terminologies. In the second step, the diagnosis information must be made available for “sharing” in conjunction with other individual tasks in a data protection-compliant manner and in accordance with the FAIR principles.

ICD-10-GM

The International Classification of Diseases and Related Health Conditions (ICD) is now available in its 10th revision (ICD-10) and has proven itself for many issues. For example, according to §301 and §295 of the German Social Code, Book V (SGBV), the specification of diagnoses and their coding with the version ICD-10-GM (German Modification) published annually by the BMG authority DIMDI or, since 2020, by the Federal Office for Drugs and Medical Devices (BfArM, german: Bundesamt für Arzneimittel und Medizinprodukte) is required by law for inpatient and outpatient billing. It is based on the ICD-10 of the World Health Organisation (WHO). These and other legal requirements shape the coding of diagnoses in the German healthcare system by ICD-10-GM at almost every point. For many purposes, classification and coding with the ICD-10-GM is useful (for example, death certificates, cause of death statistics, certificates of incapacity for work, billing records for fee-for-service billing). However, it is not meaningful enough for many other issues and thus not sufficient (see, for example, the coding of rare diseases).

For this reason, the categorization and coding of diagnoses in the core data set should also be possible using other terminologies and classifications, if required.

SNOMED CT

This includes the inclusion of the most comprehensive medical terminology, the Systematic Nomenclature of Medicine - Clinical Terms (SNOMED - CT) in the canon of code systems. Thus, the MII core data set also follows the resolutions of the MII National Steering Committee, the support of the BMBF, and the efforts of the Patient Data Protection Act from the BMG to introduce this internationally used nomenclature in Germany.

Orpha-code

The inclusion of Orpha-codes in the canon of code systems follows the recommendations of the National Action Alliance for People with Rare diseases (German: Nationales Aktionsbündnis für Menschen mit seltenen Erkrankungen), in which the BMBF and BMG ar involved, on the coding of rare diseases.

This supports the objectives of the cross-consortia collaborative project CORD-MI and corresponds with the decision of the Joint Federal Committee (GBA, German: Gemeinsamer Bundesausschuss) of self-administration in the German health care system, which links the remuneration of the centers for rare diseases in university hospitals, of which about two thirds are organized in CORD-MI.

Alpha-ID

Similarly, the consideration of the Alpha-ID as MII code system follows the request of the GBA, the BMG and the DIMDI for the field of rare diseases.

2. Multiple usability

Multiple usability refers to the goal of being able to use data technically for different purposes without significant transformations, insofar as this is permitted by data protection rules. The secondary use of patient data collected primarily for health care (in particular also diagnostic data) in the research context is a core objective of the MII.

In the data sources which the MII is initially built on, diagnoses are primarily used for treatment justification, billing justification, and fee-for-service measurement. Even these basic applications span a very wide range and present various challenges for classification and coding of diseases and related health conditions. In addition, diagnoses should differentiate disease and health states in current and future application scenarios, whereby demanding requirements of biomedical research, socio-medical research, epidemiology, quality management, care monitoring and care planning across institution, sector, country and time boundaries must be taken into account.

The synchronization of the MII core data set with the information models of the International Patient Summary (IPS) and the Electronic Patient Record (EPA) project of the National Association of Statutory Health Insurance Physicists (KBV, German: Kassenärztliche Bundesvereinigung), which is referred to as access to interoperability, also serves the purpose of multiple usability. It should be noted that both information models of IPS and EPA do not recognize cases. In both implementations, diagnoses are documented case-free. The MII core data set follows the IPS and EPA in that the DIAGNOSIS and PERSON modules correspond directly with each other.

In parallel, however, the DIAGNOSIS module in the MII core data set also corresponds to the CASE module, which establishes the link to care in healthcare facilities. Since the main source of medical data in the MII is the hospital information systems and clinical workstation systems, it is in principle easy to form logical relationships between cases and diagnoses. These can be found in the case-diagnosis relations of the CASE module. The pitfalls, however, lie in the details, such as the differentiation between the case variants facility contact and care center contact, which have significantly different requirements for the case-diagnosis relations.

The direct correspondence of the DIAGNOSIS and PERSON modules is intended to express that diagnoses are in principle also present without being found in inpatient or outpatient healthcare facilities and are differentiated into major, minor and non-relevant diagnoses for organizational and billing purposes and before being classified and coded using the ICD-10-GM.

The ideal of provider, sector and time neutrality of the module DIAGNOSIS as a bridge to multiple usability cannot be fully achieved. Neither for the definitely different, since sector-dependent billing cases (FHIR category Account), nor for the supply contacts (FHIR category Encounter).

It starts with the fact that the common catalog, the ICD-10-GM, is not primarily maintained according to medical requirements - for example, the identification of common as well as rare diseases - but according to statistical and billing priorities. It should be noted that the ICD-10-GM, as the main catalog of the DIAGNOSIS module, is updated annually changing catalogs (possibly with changes in the meaning of some four- and five-digit codes). Thus, only the 3-tuple diagnosis name, diagnosis code and diagnosis catalog is always unique. Time Series spanning year boundaries are therefore only reliably possible for the three-digit stable categories, but not for the four- and five-digit subcategories.

The dominant role of billing in requirements and the German Coding Guidelines, which are based on their paradigms, in documentation in hospital information systems has already been mentioned above as a further challenge in the multiple use of diagnosis data from the context of care. These (supposed) billing requirements drove the first wave of digitization in German hospitals around the turn of the millennium and, from a medical perspective, led to partial mis-digitization. The contradictions that arose must be compensated for as best as possible in the core data set of the MII through the different relations of diagnoses to care center contacts and facility contacts to diagnoses - which will require a lengthy learning and continuous improvement process. Selected inconsistencies between diagnoses in billing cases and in facility contacts (see module CASE) can be mentioned as examples, even if both case variants describe a constellation that is identical in itself (e.g., inpatient stay between admission and discharge):

Billing cases may only be assigned diagnoses that have caused expenses in the inpatient setting (see German Coding Guidelines).
In contrast, all observed diagnoses should be assigned to the facility contacts, even for untreated diseases. They may be relevant for quality assurance and for the scientific context.
For billing purposes and frequency-oriented evaluations, it regularly seems sensible to use a 'statistical' classification such as the ICD-10-GM with its limited number of approximately 13000 entities, regardless of the fact that even four- or five-digit subcategories often combine very different clinical pictures.
More sophisticated nomenclatures and terminologies are needed for a differentiated research and medical digitalized care support if individual treatment needs are to be adequately addressed. For example, the ICD code for 'Other sphingolipidoses (E75.2)' hides a broad spectrum of diseases such as Fabry disease, Gaucher disease, Krabbe disease, Farber disease and others with different care requirement, and a few topologically differentiated variants of 'Malignant neoplasm of the mammary gland' (C50.1 to C50.9) conceal many dozens of etiologies and morphologies with a wide range of therapeutic approaches

Although the ICD catalog, as most widely used diagnosis catalog, is updated annually, it is still incomplete with regard to requirements in some areas (rare diseases, oncology, psychiatry, international comparisons).

Multiple usability must focus on the care contacts in the basic modules and the extension modules of the MII core data set, without disregarding that they are often based on billing-oriented documentation.

Since the MII core data set in general and the DIAGNOSIS module in particular are not designed on a greenfield side, the pursuit of the goal of multiple usability cannot avoid allowing several code systems (nomenclatures, terminologies, classifications) in parallel. In this sense, the DIAGNOSIS module in the MII core data set continues to build on the use of ICD-10-GM, since on the one hand this is the classification in general use in very many, especially administrative, applications. However the module also opts for the adoption of 'untruncated' free-text designations and it opens up the use of supplementary code systems such as SNOMED CT, Orpha codes and ICD-11.

However, as already mentioned, these dimensions of the data model can only be seen as signposts for better documentation and digital transformation in the German healthcare system. Indeed, the design of the information model does not automatically lead to its filling. For example, only a limited number of ICD codes can be uniquely converted into Orpha codes and SNOMED CT terms. As a rule, an adaptation of the documentation processes is necessary, which can only be roughly anticipated.

3. Time allocation

As a further need for further development, the initial paper on the MII core data set of March 2017 indicated the need for better 'temporalization of diagnoses'. In the data set pursuant to Section 21 KHEntgG('P21'), which is used by the MII core data set to locate the potential for improvement, temporal orientation is limited to the assignment of the list of diagnoses to a case, which only knows an admission and a discharge date as time markers. In P21, however, it remains open whether the diagnosis was already present at the time of admission or was only acquired in the hospital (e.g. fall, infection, pressure ulcer) and whether it can be considered cured at the time of discharge, whether relief was achieved in a chronic process, or whether treatment failed altogether. The information model of the MII core data set adopts this optimizable approach in its minimal version, but also opens up further options for temporal assignment such as documentation date, determination date, clinically relevant period and life phase - i.e. also the identification of 'present-at-admission' and 'present-at-discharge'. However, it is not yet possible to estimate how extensively these options can be used on the basis of existing primary documentation or how quickly digitization in the German healthcare system will take account of the underlying requirements.

Linkage to temporally defined cases

As already mentioned, the link to cases, although not explicitly stated in the ART-DECOR model, is a basic temporal definition for diagnoses. As mentioned under multiple usability, a facility contact as well as the department contacts and care center contacts contained therein and billing case are practically always linked to at least one diagnosis. In both case variants - facility contact and billing case - there is a start date (usually corresponds to the date of admission to a hospital) and the end date (usually the date of discharge), which are often, but not always, congruent across case variants (see module CASE).

However, none of the case start dates should per se be equated with the start date of the disease. Likewise, none of the end dates must be associated with the end of disease. In order to be able to clarify this circumstance, it is planned to optionally set up the possibility of an 'existing on admission' and an 'existing on discharge' indicator in the CASE-DIAGNOSIS relation (not shown in the data model).

Beyond the case reference (which is not explicitly presented), further information on diagnoses should provide information on their temporality:

Date of documentation

The date on which the illness was documented by a physician must be entered here.

Determination date

In contrast to the documentation date, the determination date is the date on which a disease was determined (for example by a physician). The determination date can also be referred to as synonymously as the diagnosis date.

Clinically relevant period

Independent of the case reference, it is possible in the DIAGNOSIS module to take into account the clinically relevant period or validity period of a disease, provided that a corresponding source is available. This characteristic describes the period from when to when a patient suffered from a disease. It should be noted that the start date (here from/on) does not have to match that of the diagnosis date.

The specification of the validity period is particularly useful for acute and curable diseases with a datable beginning of the disease and an obvious end of the disease.

Life phase

In addition to a calendar period, it is possible to specify the phase of life at which a disease was present. This can be used, for example, to indicate that a person has already had an illness as an infant. The corresponding value set is currently still being developed.

The specification of the end date (until) is not obligatory for both entries, because in the case of chronic diseases (including congenital diseases) it is often impossible to determine the end of the disease and the disease persists beyond the care phase.

Clinical status

As a further characteristic, the information model allows the addition of a clinical status (active, not active) in conjunction with a defined time point. This information is more commonly used in the outpatient sector.

Other characteristics in detail

As explained above, the DIAGNOSIS base module provides for separate and parallel coding of diagnoses using the following four coding systems in order to improve interoperability and multiple usability:

ICD-10-GM
Alpha-ID
ORPHA codes
SNOMED CT

These code systems can be used separately or in relation to a common free text, as required. None of the code systems is generally prescribed, but coding using ICD-10 is prescribed in many places - for example, when billing for services and when implementing cause-of-death statistics.

A logical-deterministic linking of the coding systems (for example, by means of the Alpha-ID) has not yet been provided for in the information model and will probably have to be implemented more programmatically. The GBA (dt. Gemeinsamer Bundesausschuss) has suggested something similar in its resolution on Section 136c (5) SGB V of December 5, 2019, on the financing of centers with special tasks (e.g., centers for rare diseases).

A logical-deterministic linking of the coding systems (for example, by means of the Alpha-ID) has not yet been provided for in the information model and will probably have to be implemented more programmatically. The GBA has suggested something similar in its resolution on Section 136c (5) SGB V of December 5, 2019, on the financing of centers with special tasks (e.g., centers for rare diseases).

Each of the code systems has special features - especially for the use of the common systems there are various regulations.

ICD-10-GM diagnosis coded

Complete diagnosis code for ICD coding

The complete diagnosis code is a triple that combines the diagnosis code, the corresponding code system (including the corresponding version number or year designation of the ICD-10-GM) and the catalog text of the diagnosis code:

The diagnosis code indicates the primary code(s). Some diagnostic findings require a special type of double or multiple coding. If this is the case, the diagnosis code includes all codes.
The code system this year is ICD-10-GM 2020. Due to annually changing catalogs, the meaning of some codes may change. Therefore, the corresponding version must also be taken into account here.
The catalog text associated with the diagnosis code is also provided.

Since ICD-10 classifies primarily according to the etiology of a disease, important information (such as the manifestation of a disease) can be lost. For the etiology and manifestation coding, the cross-star system is provided. In this system, one code stands for the etiology, the following one describes the manifestation of a disease. The cross-star system must not be used for diseases that have no etiological connection.

Etiology code

The etiology code of a disease is marked with a cross (†) in the ICD coding. Unlike the secondary diagnosis codes, the etiology code may stand alone. In the cross-star system, the cross code is the primary code.

Secondary diagnosis code:

In addition to the etiology code, a diagnosis can be coded with one or more secondary diagnosis codes. The secondary diagnosis codes must not be used without the preceding cross code.

1. Manifestation code

The manifestation code is marked with an star (*), and coding is done according to the cross-star system. Star codes are explicitly defined as such in the ICD-10-GM.

2. Exclamation mark code

Beside the cross-star system, there is another secondary diagnosis code: the exclamation mark code. These additional codes are used to describe a disease in more detail or to delimit its severity. Exclamation mark codes are designated as "optional" key numbers in the ICD-10-GM and § 301 SGB V. There are also exclamation mark codes that are mandatory German Coding Guidelines.

Additional identifiers

When coded using ICD-10-GM Diagnosis, the two additional indicators of ICD-10-GM, diagnosis certainty and side localization, can be recorded.

Diagnosis certainty

The additional indicator diagnosis certainty indicates how certain a diagnosis is to be evaluated in an individual case: A (excluded diagnosis), G (confirmed diagnosis), V (suspicion diagnosis), Z ((asymptomatic) state after the diagnosis in question)

In outpatient care, the indication of the additional information is obligatory for billing purposes
In contrast, the additional indicators of diagnostic certainty are not permitted for inpatient care for billing purposes (DRG)

For pure medical documentation, additional codes are common and are used in all areas.

Side localization

This additional identifier can be used to specify the side localization of a diagnosis:

R (right), L (left), B (both sides)

In contrast to diagnostic certainty, there is no need to differentiate between inpatient and outpatient care, as the information is voluntary in both cases.

Double classification

It should be noted that in certain cases a form of double classification other than the cross-star classification is applicable. Further information can be found in the German Coding Guidelines - Chapter Double Coding. For example, several codes (which can normally be used as independent primary codes) can be combined with one another for new developments with functional activity.

ALPHA-ID coded

Alternatively, the coding of a diagnosis using the Alpha-ID is possible in the core data set. The Alpha-ID is based on the alphabetical index of the ICD-10-GM - each entry is assigned a unique and stable identification number (Alpha-ID code). There are alphabetical entries with their own Alpha-ID's that designate synonyms and there are alphabetical entries with their own Alpha-ID's that designate independent disease entities within a "collective ICD" (often "others"). Unlike the ICD-10-GM, the Alpha-ID does not have any additional identifiers.

Complete diagnosis code for Alpha-ID coding

The complete diagnosis code is sufficient here, which consists of the triple: Alpha-ID code, the corresponding code system and the catalogue text of the alpha-ID.

Complete diagnosis code with Orpha coding

In addition, the coding of rare diseases is possible by the specific Orpha identification numbers from the Orphanet database. Within the framework of the ICD-10-GM, the recording of rare diseases is only possible to a limited extent - of approximately 8.000 rare diseases that differ from one another, only around 300 can be represented by ICD codes, as they are, e.g., grouped together. Adequate care and scientific coverage of the approximately 7.700 diagnoses that cannot be specifically ICD-coded is therefore only possible to a limited extent without the use of the Orpha code numbers.

Complete diagnosis code for Orpha codig

There are no other additional identifiers for the Orpha codes. The full diagnosis code includes the Orpha code, the corresponding code system and the disease name.

SNOMED diagnosis coded

The Systematic Nomenclature of Medicine (SNOMED CT) is used internationally and is much more differentiated than the ICD-10 and is therefore introduced in Germany, which is anticipated by the information model described here.

Complete diagnosis code for SNOMED coding

The Full Diagnostic Code includes the SNOMED CT code, the corresponding code system and the Preferred Name.

Further code systems

If required, the addition of further classifications and terminologies is possible. The addition of ICD-11 as a further code system is in preparation. Some areas of application for diagnosis documentation, such as ICD-0 in the field of oncology, will be outsourced to the corresponding extension modules.

Body side

The body side can be used to indicate in which area of the body a disease is diagnosed (topographical information). The body side was deliberately separated from SNOMED Diagnosis coded so that, for example, when coding using ICD-10-GM, it is possible to code the body side. This is done using SNOMED CT, but does not require a complete SNOMED CT code. The indication of the body side should not be confused with the ICD additional identifier (side) localisation (right, left, both sides).

Complementary issues

In addition to the catalogue/terminology-based classification and coding, the DIAGNOSIS module offers the possibility of providing more detailed information on a diagnosis, for example, by means of free text fields.

Free-text description

Plain text description of the diagnosis - this does not have to correspond to the catalogue text of the respective code system. For medical documentation, the free-text description is obligatory.

Diagnosis explanation

The diagnosis explanation is intended to give the doctor the possibility of writing more extensive information in addition to a diagnosis.

Context in overall project/ References to other modules

Diagnoses are the central entity in the description of health and disease in all use cases of the MII. In ''Description of scenarios for the application of the modules'' you can find the description of the application of the DIAGNOSE module in the individual consortia.

Module person

As the basis of the MII is formed by the real-world data of the participating university hospitals, there is always a reference to the house-specific personal entity PATIENT in addition to the general personal reference.

Module case

The following aspects are taken into account for the inpatient and day-care context. In the course of the hospital admission process (including digital communication with the health insurance funds), initial diagnoses are recorded as a prerequisite for cost coverage by the health insurance funds. The category admission diagnosis describes the disease information of the referring physician. The category Admission diagnosis reflects the (preliminary) assessment of the admitting hospital.

Diagnosis information is also regularly noted in the course of the care process - for example as main and secondary department diagnoses, or to justify service requirements and therapeutic measures, including medications.

The almost final diagnosis documentation takes place in the course of discharge from the hospital. The diagnoses recorded in this process are reviewed by senior physicians and controllers, and ( influenced by billing rules) a distinction is made between main and secondary hospital diagnoses. In this context, the German Coding Guidelines prohibit the consideration of information on diagnoses in the communication with the payers if these have not generated any expenses during the inpatient stay. These diagnoses therefore do not occur in relation to the billing case.

If the recorded but non-billing-compatible diagnoses are not deleted (which is forbidden), they should be taken into account in the relations to the facility contacts and, if possible, to the department contacts. If possible, the distinction according to the diagnosis relation types with the characteristics main diagnosis, secondary diagnosis and non-billing compatible may be checked.

In future (at the latest with the introduction of ICD-11), a distinction will have to be made between the conditional terms admission and admission diagnosis, for which only individual diagnoses are flagged, and the characteristic "present-on-admission" (POA) for all diagnoses. It will be obligatory to include this yes-no indicator for each diagnosis that is assigned to a facility contact. Correspondingly, a "present-on-discharge" (POD) indicator is to be provided for occasional use for each care case diagnosis.

In the FHIR profiles, this has the following appearance. The relation to the diagnosis profile can be made from the case profile as well as from the diagnosis profile. But these two alternatives are not equally important. An Encounter can refer to none up to several diagnoses, and each of these diagnosis references can be assigned a so-called diagnosis role. This role is primarily intended to express whether the referenced diagnosis for the contact instance is a principal or a secondary diagnosis. The principal diagnosis is coded here as Chief Complaint (CC), while the secondary diagnosis can be coded as Comorbidity (CM) (for more information see DiagnosisRole).

For the reference from the diagnosis to the case, it must be noted that a diagnosis may refer to a case, but it must be the case/contact in the context of which the diagnosis was also determined. In other words, a diagnosis must not refer to a facility contact, but to the relevant department/provider contact.

Further relations

Usually, there are no direct relations between diagnoses and care locations, procedures, medications and laboratory findings in the available real-world data, although these naturally exist, for example, therapeutically, physiologically or aetiologically. The connection must usually be established via the care context (facility contact, department contact) or via the temporal connections.

The consideration of such references is reserved for the further development of the DIAGNOSE module and its relations.

Outsourcing

Type of diagnosis

The type of diagnosis is indicated via the diagnosis type. The diagnosis type is indicated in code.

The following diagnosis types result for data transmission according to §301 SGB V:

Admission diagnosis
Briefing diagnosis
Department diagnosis
Follow-up diagnosis (with subsequent incapacity to work)
Discharge diagnosis
Additional department diagnosis
Referral diagnosis
Treatment diagnosis
Main and secondary diagnoses (essentially defined for billing purposes) as well as primary and secondary diagnoses are mapped via additional attributes.

According to the German Basic Profiles, the Diagnosis Type attribute is modelled as a property of the Encounter and is thus not part of the diagnosis profile.

Present-at-admission and Present-at-discharge

In some cases, a diagnosis only begins during an inpatient stay (e.g. in the case of a nosocomial infection or a fall). This can be distinguished by the yes-no characteristic "present-at-admission", if it was recorded. The validity of a diagnosis beyond case closure can be expressed by the yes-no characteristic "present-at-discharge".

This aspect is also initially outsourced from the DIAGNOSIS module. However, with the 11th version of the ICD, present-at-admission and present-at-discharge will be introduced as additional indicators and should then be included in the module.

References

The modelling of the dataset for the DIAGNOSE module contains references to the following projects:

on the one hand, it is based on the format of the data set according to §21 KHEntgG for the purpose of backward and cross-compatibility
for forward and international compatibility, the IPS (International Patient Summary) is a guiding model. Reconciliation with the OMOP and OHDSI Common Data Model is left to later versions
the HL7 Germany diagnosis guideline was also taken into account.

The HL7 FHIR Core Specification, including the corresponding resource Condition, and the previous work on the German Basic Profiles in STU3 and R4 were also taken into account.

The present specification was designed on the basis of the description of the MII core data set in the version of 10.3.2017 (PDF), as well as the data set description in ART-DECOR.

The classifications and terminologies to be supported are ICD-10-GM, Alpha-ID, Orpha codes and SNOMED CT. The use of ICD-11-GM will have to be taken into account at the officially specified time and must already be considered today in all planning.

Use Cases/ information model

Description of scenarios for the application of the DIAGNOSIS module

The modelling and FHIR profiling of the basic modules of the MII core data set, including the DIAGNOSE module, aim to generate the most generic information models possible for a wide range of application scenarios. Priority consideration was given to the consortial use cases of the four consortia of the Medizininformatik-Initiative (MII) DIFUTURE, HiGHmed, MIRACUM and SMITH and the two transconsortial joint projects CORD-MI and POLAR-MI. The fact that the digitally stored (or to be stored) patient data from the care processes in the 34 university hospitals involved form the essential basis of the Medical Informatics-Initiative has also had a major influence on the design.

Referring to DIAGNOSE module: Diagnoses play a central role in every use case of the MII.

The scenarios of the consortia in detail:

DIFUTURE: The DIFUTURE approach is use case driven, whereby use cases are linked to specific diseases. The focus is on neurological disease entities multiple sclerosis and Parkinson's disease, but also on oncological and cardiological indications. Multiple sclerosis and Parkinson's disease can be identified in a relatively differentiated manner using the diagnostic codes of the ICD-10 (possibly Alpha-ID as well). The other parameters of the DIAGNOSE module are also decisive in the DIFUTURE use cases
HiGHmed: In the absence of fine-grained diagnoses that were documented for care instead of billing, the diagnoses coded for billing are also used in HiGHmed. Diagnoses play an important role in all HiGHmed use cases, but mainly in the use cases cardiology and oncology in order to be able to include comorbidities.
MIRACUM: In all use cases of the MIRACUM consortium, the diseases of the patients and the coded diagnoses based on them are in the foreground. In Use Case 1 "IT support for patient recruitment", they are an important criterion for input or exclusion of patients from studies; in use case 2 "prediction of clinical courses" they are included in the models to be developed as a criterion for the examined population and its comorbidities and in use case 3 "IT support for molecular tumor boards" tumor entities are primarily described by the ICD coding alongside other classification systems.
SMITH: In the SMITH use case ASIC, the focus is on patients with Acute Respiratory Distress Syndrome (ARDS), whose diagnosis must be coded accordingly, including a specific degree of severity. HELP, as a second use case, is in the context of antibiotic stewardship - here complications with a specific diagnosis such as endocarditis, sepsis or septic shock are relevant. Finally, in the Phenotyping Pipeline (PheP), the determination and specification of a wide variety of diagnoses in the context of phenotyping patients plays an important role.
CORD-MI: Within the framework of CORD-MI, the further development of diagnostic documentation for patients with rare diseases is being pursued through the broad reinforcement of Orpha codes in the care context. Specific evaluations of cystic fibrosis, phenylketonuria, Fabry disease, sagittal synostosis, POMC deficiency and neuromyelitis optica, as well as non-specific evaluations of the dissemination of and data quality for several diagnoses, are intended to illustrate developments in the project's progress.
POLAR-MI: In the POLAR-MI use case, diagnoses have a double meaning. On the one hand, they are the justification for the application of drugs. On the other hand, they represent adverse drug reactions. And contributing to their reduction is the central concern of POLAR-MI.

Data sets including descriptions

The official and approved version of the information model for the DIAGNOSE module can be found on ART-DECOR. To standardise the representation, the information model was additionally mapped as FHIR Logical Model:

It should be noted that the Logical Model aims at mapping the data elements and their description. Used data types and cardinalities are not to be considered mandatory. This is finally determined by the FHIR profiles. For each element within the Logical Model, there is a 1:1 mapping to an element of a concrete FHIR resource.

Tabelle

Logical dataset	Description
Diagnosis	The basic module Diagnoses contains diagnoses as reasons for treatments and billing-based classification features, e.g. as principal diagnosis, secondary diagnosis, quarterly diagnosis, etc.
Diagnosis.ICD10GMDiagnosisCoded	In the area of administrative and statistical evaluation, the diagnosis is coded with the help of coding systems. For example, when billing according to §301 and §295 SGB V, the coding of diagnoses using ICD-10 GM is prescribed by law.
Diagnosis.ICD10GMDiagnosisCoded.FullDiagnosisCode	Primary code with secondary codes (if applicable) code system and catalogue text
Diagnosis.ICD10GMDiagnosisCoded.AetiologyCode	Aetiology (trigger), e.g. which pathogen. The code for the aetiology of a disease can be marked with a cross (†) in the ICD coding.
Diagnosis.ICD10GMDiagnosisCoded.ManifestationCode	Additional information on the ICD-10 aetiology code: Manifestations. The code for the organ manifestation of a disease is marked with an asterisk (*) in the ICD coding.
Diagnosis.ICD10GMDiagnosisCoded.ExclamationmarkCode	These additional codes are used to describe a disease in more detail/demarcate the severity.
Diagnosis.ICD10GMDiagnosisCoded.DiagnosisCertainty	The certainty of diagnosis, i.e. how certain the diagnosis is to be assessed in the individual case, can be indicated in different ways. For billing purposes in outpatient care, an additional indicator for the certainty of diagnosis (A, G, V or Z) must be specified, i.e. the specification is obligatory. In inpatient care, these additional indicators for specifying the certainty of diagnosis are not permitted for billing purposes.
Diagnosis.ICD10GMDiagnosisCoded.SideLocation	For the specification of diagnosis information ( ICD-10), the additional indicators for sidedness (R, L or B) may be indicated, i.e. the indication is optional; this applies to inpatient and outpatient care.
Diagnosis.ALPHAIDDiagnosisCoded	It should be possible to code a diagnosis using different code systems. Here by using Alpha-ID.
Diagnosis.ALPHAIDDiagnosisCoded.FullDiagnosisCode	Alpha ID, code system and catalogue text
Diagnosis.ORPHANETDiagnosisCoded	It should be possible to code a diagnosis using different code systems. For example, for the coding of rare diseases, the Orpha code number is required.
Diagnosis.ORPHANETDiagnosisCoded.FullDiagnosisCode	Orpha code number, code system and name of disease
Diagnosis.SNOMEDDiagnosisCoded	It should be possible to code a diagnosis using different code systems. Here by using SNOMED CT.
Diagnosis.SNOMEDDiagnosisCoded.FullDiagnosisCode	SNOMED-CT Code, Code System and preferred name
Diagnosis.FurtherCodingSystems	If required, the inclusion of further classifications and terminologies is possible.
Diagnosis.FurtherCodingSystems.FullDiagnosisCode	Indication of the code, code system and catalogue text
Diagnosis.BodySide	The body part can be used to indicate in which area of the body a disease was diagnosed (topographical information).
Diagnosis.FreeTextDescription	Diagnosis in plain text. In the field of medical documentation, the text description should be obligatory.
Diagnosis.DiagnosisExplanation	This is to give the doctor the possibility to provide more detailed information on a diagnosis in the form of free text.
Diagnosis.DocumentationDate	The date is the time when a disease was documented, e.g. by a doctor. Note: If it is not necessary to distinguish between the establishment of the diagnosis and the documentation date, the date on which the diagnosis was established (diagnosis date) must be indicated.
Diagnosis.ClinicalStatus	Indication of clinical status
Diagnosis.ClinicallyRelevantPeriod	The clinically relevant period or the life phase of a disease can be specified here. Date information on diagnoses can be available in varying degrees of precision.
Diagnosis.ClinicallyRelevantPeriod.Period	The period is described by two dates, i.e. from when to when a patient suffered from the diagnosed disease. The time period can also be used to express since when a patient has been suffering from a disease by specifying only the start date of the time period. The start date of the period may differ from the diagnosis date.
Diagnosis.ClinicallyRelevantPeriod.Period.from-at	Date of beginning
Diagnosis.ClinicallyRelevantPeriod.Period.until	Date of ending
Diagnosis.ClinicallyRelevantPeriod.LifeStage	Indication of the life stage of a disease
Diagnosis.ClinicallyRelevantPeriod.From	Date of beginning
Diagnosis.ClinicallyRelevantPeriod.Until	Date of ending
Diagnosis.DateOfDetermination	The date is the point in time when a disease was diagnosed, e.g. by a doctor.

UML

A UML class diagram was created as a more abstract version of an information model and to better clarify relationships between the technical concepts. Concepts mapped as groups in ART-DECOR are modelled as separate classes, which here have association relationships to each other. Properties of the person and the case are colour-coded from the other properties of the diagnosis.

Technical Implementation

FHIR Profile

The work of the Core Data Set Specifications is based, where possible, on international standards and terminologies. In particular, the International Patient Summary should be emphasized here. Adaptation to the general conditions of the German health care system takes place through the use of the German Basic Profiles of HL7 Germany.

All elements of the core data set, adapted to the details and requirements for the use cases of the Medical Informatics Initiative, are described below in the form of FHIR StructureDefinitions. The need to adapt the FHIR profiles is explained in textual form below the profile.

Note: For mandatory elements or elements marked as must-support, please refer to the corresponding rules of the IPS, which also apply to this ImplementationGuide.

Condition

FHIR element	Description
Condition.id	must-support, but optional
Condition.meta	must-support, but optional
Condition.clinicalStatus	No restrictions, entire diagnostic workflow is supported. The element is optional as it is not routinely recorded. In addition, the status at discharge is usually not recorded.
Condition.code	At least one coded diagnosis must be included. Selectable from Alpha-ID, SNOMED CT, Orpahanet and ICD-10 GM.
Condtion.code.coding:icd10-gm.extension	Within the extensions "ExclamationMarkCode", "ManifestationCode" and "PrimaryCode", the respective code components should be coded without respective special characters (e.g. "!", "+" or "*").
Condition.bodySide	If this optional element is used, the body side must be coded with at least one SNOMED-CT code. It is not necessary to specify the laterality, this should be specified by Condition.code.coding:icd10-gm.extenison:Side localisation. The purpose of this field is to document additional information (beyond the code) about the manifestation.
Condition.subject	The reference to the Person module is always given.
Condition.encounter	It should be noted that in most cases this field should not be used to link the case and the diagnosis. This element is used to link the diagnosis to the case/contact in which the diagnosis is established (always a contact with a specific care unit!). Generally, the link should be made via Encounter.diagnosis.
Condtion.onset[x]	Can be coded as Period or dateTime according to the IPS. Life phases can be additionally indicated if exact times are not known.
Condition.RecordedDate	Can be coded as Period or dateTime according to the IPS. Life phases can be additionally indicated if exact times are not known.
Condition.note	Additional description of the diagnosis

FHIR element	Description
Encounter.period.start / Diagnose.encounter	It should be noted that the mapping of the logical data element "DeterminationDate" is not done to the condition resource but to the encounter resource. Thus, the linking of the diagnosis SHOULD always be done to an Encounter Resource (See Module Case).

FHIR element	Logical dataset
Condition.code:icd-10gm	Diagnosis.ICD10GMDiagnosisCoded
Condition.code:icd-10gm.coding.code	Diagnosis.ICD10GMDiagnosisCoded.CompleteDiagnosisCode
Condition.code:icd-10gm.coding:extension:Primarycode	Diagnosis.ICD10GMDiagnosisCoded.AetiologyCode
Condition.code:icd-10gm.coding:extension:ManifestationCode	Diagnosis.ICD10GMDiagnoisCoded.Manifestationcode
Condition.code:icd-10gm.coding:extension:Exclamation markCode	Diagnosis.ICD10GMDiagnosisCoded.Exclamationmarkcode
Condition.code:icd-10gm.coding:extension:Diagnostic certainty	Diagnosis.ICD10GMDiagnosisCoded.DiagnosisCertainty
Condition.code:icd-10gm.coding:extension: Sidelocalisation	Diagnosis.ICD10GMDiagnosisCoded.Sidelocation
Condition.code:alpha-id	Diagnosis.ALPHAIDDiagnosisCoded
Condition.code:alpha-id (coding.system, coding.value)	Diagnosis.ALPHAIDDiagnosisCoded.CompleteDiagnosisCode
Condition.code:orphanet	Diagnosis.ORPHANETDiagnosisCoded
Condition.code:orphanet (coding.system, coding.value)	Diagnosis.ORPHANETDiagnosisCoded.CompleteDiagnosisCode
Condition.code:sct	Diagnosis.SNOMEDDiagnosisCoded
Condition.code:sct (coding.system, coding.value)	Diagnosis.SNOMEDDiagnosisCoded.CompleteDiagnosisCode
Condition.code	Diagnosis.FurtherCodingsystems
Condition.code (coding.system, coding.value)	Diagnosis.FurtherCodingsystems.CompleteDiagnosisCode
Condition.bodySide	Diagnosis.Bodyside
Condition.code.text	Diagnosis.Freetextdescription
Condition.note	Diagnosis.Diagnosisdescription
Condition.recordedDate	Diagnosis.Dateofdocumentation
Condition.clinicalStatus	Diagnosis.ClinicalStatus
Condition.onset[x]	Diagnosis.ClinicalRelevantStatus
Condition.onsetPeriod	Diagnosis.ClinicalRelevantStatus.Status
Condition.onsetPeriod.start	Diagnosis.ClinicalRelevantStatus.Status.from-at
Condition.onsetPeriod.end	Diagnosis.ClinicalRelevantStatus.Status.until
–-	Diagnosis.ClinicalRelevantStatus.Lifephase
Condition.onsetPeriod.start.extension:lebensphase-start	Diagnosis.ClinicalRelevantStatus.Lifephase.from
Condition.onsetPeriod.end.extension:lifephase-ending	Diagnosis.ClinicalRelevantStatus.Lifephase.until

FHIR element	Logical dataset
Encounter.period.start	Diagnosis.DateOfDetermination

Invariants	Description	Expression
sct-icd-1	Diagnosis has do be coded with ICD or SNOMED-CT	coding.where(system = 'http://snomed.info/sct').exists() or coding.where(system = 'http://fhir.de/CodeSystem/dimdi/ops').exists()
icd-1	If a code is specified in the main cross-extension, it must also be part of the post-coordinated ICD code!	extension('https://www.medizininformatik-initiative.de/fhir/core/StructureDefinition/icd-10-gm-primaercode').empty() or code.contains($this.extension('https://www.medizininformatik-initiative.de/fhir/core/StructureDefinition/icd-10-gm-primaercode').value.code)
icd-2	When specifying a code in the asterisk extension, this must also be part of the post-coordinated ICD code!	extension('https://www.medizininformatik-initiative.de/fhir/core/StructureDefinition/icd-10-gm-manifestation').empty() or code.contains($this.extension('https://www.medizininformatik-initiative.de/fhir/core/StructureDefinition/icd-10-gm-manifestation').value.code)
icd-3	When specifying a code in the asterisk extension, this must also be part of the post-coordinated ICD code!	extension('http://fhir.de/StructureDefinition/icd-10-gm-ausrufezeichen').empty() or code.contains($this.extension('http://fhir.de/StructureDefinition/icd-10-gm-ausrufezeichen').value.code)
icd-8	If a code is specified in the side localisation extension, it must also be part of the ICD code!	extension('http://fhir.de/StructureDefinition/seitenlokalisation').empty() or code.contains($this.extension('http://fhir.de/StructureDefinition/seitenlokalisation').value.code)

Terminologies

Note: In addition to international terminologies, the DIAGNOSE module also defines its own CodeSystems. It should be noted that CodeSystems may contain an implicit ValueSet, which can be found in the respective FHIR CodeSystem resource.

According to § 301 and § 295 of the German Social Code, Book V (SGB V), coding for billing in the German health care system with the International Statistical Classification (ICD-10-GM) is prescribed by law.

However, since ICD-10-GM is not meaningful enough for many questions (see description of module), the core data set should also allow coding with other terminologies and classifications (such as Alpha-ID, SNOMED CT and ORPHA code numbers).

ValueSets

It should be noted that the following ValueSets do not include an expansion. To use them for validation purposes, they must be created by the FHIR terminology server.

Canonical: https://www.medizininformatik-initiative.de/fhir/core/modul-diagnose/ValueSet/diagnoses-sct

The ValueSet 'diagnoses-sct' contains all codes which may be used for Condition.code:sct.

ValueSet 'ValueSetSNOMED-Diagnosis-Code'

Contains SNOMED Clinical findings, event and situation with explicit context codes

This value set includes codes from the following code systems:

Include codes from SNOMED_CT where concept IsA 404684003 include codes from SNOMED_CT where concept IsA 272379006Include codes from SNOMED_CT where concept IsA 243796009

CodesSystems

The CodeSystem with the Canonical http://fhir.de/CodeSystem/dimdi/icd-10-gm is published within the module Diagnosis, according to license conditions.