This publication includes IP covered under the following statements.
Copyrights permitted under terms specified by Creative Commons Attribution 4.0 International (CC BY 4.0)
.Consistent with the terms of CC BY 4.0, HL7 is permitted to share, copy and redistribute the material in any medium or format and adapt, remix, transform, and build upon the material for its purposes as long as the CC BY 4.0 license terms are upheld. HL7 must must give appropriate credit, provide a link to the license, and indicate if changes were made. HL7 may do so in any reasonable manner, but not in any way that suggests the licensor endorses HL7 or it's use. And HL7 may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.
Publications of the World Health Organization enjoy copyright protection in accordance with the provisions of Protocol 2 of the Universal Copyright Convention. All rights reserved.
The HPO vocabularies, annotation files, tools and documentation are freely available.
The HPO is copyrighted to protect the integrity of the vocabularies, which means that changes to the HPO vocabularies need to be done by HPO developers. However, anyone can download the HPO and use the ontologies or other HPO files under three conditions:
That the Human Phenotype Ontology Consortium is acknowledged and cited
properly.
That any HPO Consortium file(s) displayed publicly include the date(s) and/or version number(s) of the relevant HPO file(s).
That neither the content of the HPO file(s) nor the logical relationships embedded within the HPO file(s) be altered in any way. (Content additions and modifications have to be suggested using our issue tracker
.)
Users of the HPO should add the following statement to their online presence. This service/product uses the Human Phenotype Ontology (version information). Find out more at http://www.human-phenotype-ontology.org
. We request that the HPO logo be included as well.
The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed
or info@snomed.org
.
Unless otherwise noted, the contents of the FDA website (www.fda.gov) — both text and graphics — are not copyrighted. They are in the public domain and may be republished, reprinted and otherwise used freely by anyone without the need to obtain permission from FDA. Credit to the U.S. Food and Drug Administration as the source is appreciated but not required.
Eine der vier Basen der FAIR-Prinzipien ist die Reusability (R), die Mehrfachnutzung von einmal erhobenen Daten für verschiedene erlaubte Zwecke. Das Kernparadigma der Medizininformatik-Initiative in Deutschland ist die Mehrfachnutzung der an Klinischen Arbeitsplätzen erhobenen Daten. Und wenn bei mehrfach benötigten Daten Lücken identifiziert werden - wie das bei der ORPHA-Kodierung der SE-Diagnosen in Deutschland lange Zeit der Fall war - , darf geprüft werden, inwieweit es gelingt, die (zusätzlichen) Ressourcen für die Erhebung an einem Ort zu fokussieren. Wenn die Arbeitsprozesse es erlauben, können die Klinischen Arbeitsplätze oder die klinischen Patientenakten die richtigen Stellen sein. Als Vorbild kann die Datenerhebung für das Zentralregister für Seltene Erkrankungen (Banque Nationale de Données Maladies Rares, BNDMR) in Frankreich dienen. ( src
)
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7. ( src
)
One of the four pillars of the FAIR principles is reusability (R), the multiple use of data collected once for various permitted purposes. The core paradigm of the Medical Informatics Initiative in Germany is the multiple use of data collected at clinical workstations. And where gaps are identified in data needed multiple times — as was long the case with ORPHA coding of RD diagnoses in Germany — it may be examined to what extent the (additional) resources for collection can be focused at one place. If the work processes allow it, the clinical workstations or the clinical patient records can be the right places. The data collection for the central registry for rare diseases (Banque Nationale de Données Maladies Rares, BNDMR) in France can serve as a model. ( src
)
There are examples where a medication request may include the option of an oral dose or an Intravenous or Intramuscular dose. For example, "Ondansetron 8mg orally or IV twice a day as needed for nausea" or "Compazine® (prochlorperazine) 5-10mg PO or 25mg PR bid prn nausea or vomiting". In these cases, two medication requests would be created that could be grouped together. The decision on which dose and route of administration to use is based on the patient's condition at the time the dose is needed. ( src
)
Woher die Versionen kommen.
Jedes Paket der Tabelle ist direkt in
sushi-config.yaml
( dependencies:
) gepinnt — auch hl7.terminology.r4
(THO) und
hl7.fhir.uv.extensions.r4
, und diese beiden mit Bedacht: Die
Automatik des IG Publishers
liest ausschließlich die eigene
Abhängigkeitsliste dieses Leitfadens;
ohne direkten Pin würde jeder Build stillschweigend das jeweils aktuellste
THO-/Extensions-Release injizieren — eine allein im MII-Meta-Paket gepinnte
Version kann den Build nicht steuern (verifiziert im Publisher-Quellcode des
gepinnten Release). Eine wöchentliche Prüfung warnt, wenn diese beiden Pins
von den Vorgaben des gepinnten Meta-Pakets abweichen; die von einem
konkreten Build verwendeten Versionen stehen in dessen qa-versions.json
.
Copyrights permitted under terms specified by Creative Commons Attribution 4.0 International (CC BY 4.0)
.Consistent with the terms of CC BY 4.0, HL7 is permitted to share, copy and redistribute the material in any medium or format and adapt, remix, transform, and build upon the material for its purposes as long as the CC BY 4.0 license terms are upheld. HL7 must must give appropriate credit, provide a link to the license, and indicate if changes were made. HL7 may do so in any reasonable manner, but not in any way that suggests the licensor endorses HL7 or it's use. And HL7 may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.
That neither the content of the HPO file(s) nor the logical relationships embedded within the HPO file(s) be altered in any way. (Content additions and modifications have to be suggested using our issue tracker
.)
Users of the HPO should add the following statement to their online presence. This service/product uses the Human Phenotype Ontology (version information). Find out more at http://www.human-phenotype-ontology.org
. We request that the HPO logo be included as well.
The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
Expansionsparameter sind Query-Parameter, die an eine ValueSet
-
$expand
-Operation übergeben werden können, um zu steuern, wie das ValueSet
expandiert wird — also wie die vollständige Liste der Codes aus der
ValueSet-Definition erzeugt wird. Die für diesen IG verwendeten
IG-Parameter
sind in
sushi-config.yaml
( parameters:
) deklariert. Ein Modul, das seine Expansionsparameter über ein
CRMI-Manifest pinnt, verlinkt hier zusätzlich die generierte
Parameters
-Ressource (siehe die auskommentierten Manifest-Blöcke in
sushi-config.yaml
und die Seite Metadata Overview, sofern das Modul sie
behält).
MONDO (Monarch Disease Ontology) harmonisiert verschiedene Klassifikationen und ermöglicht die Integration mit internationalen Standards wie Phenopackets
und GA4GH. Weitere Informationen finden sich unter Terminologien
.
MONDO (Monarch Disease Ontology) harmonisiert verschiedene Klassifikationen (SNOMED CT, Orphanet, OMIM, ICD) und ermöglicht die Integration mit internationalen Standards wie Phenopackets
und GA4GH:
Hinweis zum BfArM Terminologieserver:
Die nachfolgend beschriebenen Kodesysteme ICD-10-GM und ORPHAcodes können über den Terminologieserver des BfArM
abgerufen und in FHIR-basierten Systemen genutzt werden. Der Server stellt diese Terminologien als FHIR-konforme CodeSystem- und ValueSet-Ressourcen zur Verfügung.
Im vorliegenden IG wird daraus abgeleitet, nach europäischem Datensatz ( CDS-ERDRI.eu
) und französischen Datensatz ( SDM-MR.fr
) Vorbild in möglichst vielen Einrichtungen, an möglichst vielen klnischen Arbeitsplätzen für möglichst viele Betroffene von Seltenen Erkrankungen sowie durch Betroffene in eigener Regie die Dokumentation einheitlicher, interoperabler Minimalbasisdatensätze anzustreben.
Im vorliegenden IG wird daraus abgeleitet, nach europäischem Datensatz ( CDS-ERDRI.eu
) und französischen Datensatz ( SDM-MR.fr
) Vorbild in möglichst vielen Einrichtungen, an möglichst vielen klnischen Arbeitsplätzen für möglichst viele Betroffene von Seltenen Erkrankungen sowie durch Betroffene in eigener Regie die Dokumentation einheitlicher, interoperabler Minimalbasisdatensätze anzustreben.
Der Patient wird über die Möglichkeit informiert, die Daten über seine Seltene Erkrankung in ein zentrales deutschlandweites "Nationale Register für Seltene Erkrankungen" (NARSE)
einzutragen. Der Patient willigt ein und unterschreibt die Einwilligungserklärung und seine behandelnde Ärztin nimmmt die Registrierung des Patienten beim NARSE vor und trägt die Krankheitsdaten des Patienten ins Register ein. Neben den Daten zu seiner Anamnese und Diagnose trägt seine Ärztin, die vom Patienten genannten Symptome seiner Erkrankung in Form von HPO (Human Phenotyp Ontology)
Terms ein. Für die Schmerzen im Bereich des Herzens kodiert sie unter anderem den HPO-Term HP:0100749
(chest pain) ein.
Das Modul Seltene Erkrankungen ist ein KDS-Modul für die Basismodule der Medizininformatik-Initiative in Deutschland und steht daher im direkten Zusammenhang zu den Basismodulen Person, Diagnose, Labor, Prozedur oder Medikation sowie zu den anderen KDS-Modulen wie Symptom/Klinischer Phänotyp oder dem Molekulargenetischer Befundbericht, s. Abb. MII-KDS_2025-06-12_de auf MII KDS
.
In Frankreich basiert die vorrangige Strategie der Datenerfassung für die mehrfache lokale und übergreifende Datennutzung, der sogenannte Verbundene Modus (mode connecté), auf der Interoperabilität von Krankenhausinformationssystemen (KIS) mit dem Zentralregister BNDMR und seinen Zugängen, siehe: Le mode connecté avec le dossier patient
.
"Dieser vom französischen Gesundheitsministerium favorisiert geförderte Verbundene Modus setzt voraus, dass die elektronische Patientenakte (DPI/EPA) oder die Facharztakte zuvor vom Softwarehersteller (oder dem Partnerkrankenhaus) an die Erhebung des nationalen Mindestdatensatzes für Seltene Krankheiten (SDM-MR.fr) angepasst wurde, und zwar gemäß den technischen Spezifikationen, die gemeinsam von der Agentur für Digitale Gesundheit und dem operativen Team des BNDMR veröffentlicht wurden (Komponente für Seltene Krankheiten des nationalen Interoperabilitätsrahmens Gesundheitsinformationssysteme). Die Implementierung dieses Modus erfolgt in enger Zusammenarbeit mit den Herstellern von Unternehmenssoftware und den Abteilungen für Informationssysteme der Partnerkrankenhäuser (siehe Publishers' Kit).
Entscheidet sich die Partnerinstitution für die Methode der vernetzten Datenerhebung (mode connecté), sind die Gesundheitsfachpersonen verpflichtet, den Mindestdatensatz SDM-MR.fr direkt in ihre elektronische Patientenakte einzugeben. Sie haben den Vorteil, dass sie nicht viele bereits vorhandene Daten, insbesondere Identitätsdaten, erneut eingeben müssen. Innerhalb des KIS gilt die elektronische Patientenakte (EMR) als zentrales Element des Vertrauens in Bezug auf Patientenidentitäten."
Grundlage des KDS-Moduls Seltene Erkrankungen ist hauptsächlich der europäische Basis-Datensatz für Seltene Erkrankungen der European Rare Disease Registry Infrastructure - ERDRI ( ERDRI CDS
). Ziel dabei ist die Harmonisierung der verwendeten Datenelemente und Datenstrukturen in bestehenden und zukünftigen Registern in Europa. Die Verwendung des "Satzes gemeinsamer Datenelemente für die Registrierung seltener Krankheiten" ("Set of common data elements for rare diseases registration") durch jedes Register ist ein erster Schritt auf dem Weg zu diesem Ziel und zur Interoperabilität der Register für seltene Erkrankungen europaweit.
Eine weitere wichtige Referenz ist der Datensatz des Nationalen Registers für Seltene Erkrankungen (NARSE)
, welches von der Eva Luise und Horst Köhler Stiftung angestoßen wurde und vom Berlin Institute of Health in der Charité (BIH@Charité) umgesetzt wird.
Da im Modellvorhaben Genomsequenzierung
eine Datensatzspezifikation
für den Bereich der Onkologie und
für den Bereich der Seltenen Erkrankungen
vorgenommen wurde, ist es besonders wichtig, beide Datensätze zu harmonisieren.
Das Netzwerk Universitätsmedizin (NUM)
hebt die Forschung und die Verbesserung der Versorgung für Menschen mit SE bei den Kriterien der Projektauswahl besonders hervor. Da zirka 80 Prozent der SE genetischen Ursprungs sind, müssen laut NAMSE die einrichtungsübergreifenden, sowohl auf Versorgungs‐ als auch Forschungsunterstützung ausgerichteten Dokumentationen neben der präzisen Kodierung der Diagnosen (ICD reicht nicht, es müssen ORPHACodes sein), auch Angaben zu Phänotypisierung und Genotypisierung enthalten.
Wegen der Heterogenität der Erkrankungen mit unterschiedlichen Versorgungs‐, Forschungs‐ und Dokumentationsbedarfen sind von der Gemeinsamen Forschungsstelle (Joint Research Council, JRC) der EU Kommission 24 Erkrankungsgruppen definiert worden, bei denen die europaweite Zusammenarbeit von Versorgungseinrichtungen und Forschungsgruppen in 24 Europäischen Referenznetzwerken (ERN)
gefördert werden, die jeweils voneinander unterschiedliche, an die Krankheitsbilder angepasste Datenerhebungen in Registern umsetzen oder anstreben. Bei aller Verschiedenheit konnte für die verschiedenen ERN‐Register dennoch ein gemeinsamer Kerndatensatz (Common Data Set, CDS) festgelegt werden ‐ im Bild einer umfassenden Blume die gemeinsame Blüte, um die sich die Blütenblätter der verschiedenen spezifischen Dokumentationen reihen. Dieses Dataset wird Set of Common Data Elements der European Rare Disease Registry Infrastructure (ERDRI CDS) genannt und spielt auch bei der Ableitung des deutschen Kerndatensatzes für SE eine zentrale Rolle.
Das Nationale Aktionsbündnis für Menschen mit Seltenen Erkrankungen (NAMSE)
, dessen Gründung nach französischem Vorbild in 2010 auf eine Empfehlung der EU‐Kommission zurückgeht, ist ein Zusammenschluss zwischen dem Bundesministerium für Gesundheit (BMG), dem Bundesministerium für Bildung und Forschung (BMBF) und der Betroffenenorganisation ACHSE e.V. (Allianz Chronischer Seltener Erkrankungen) mit 25 Bündnispartnern ‐ allesamt Spitzen‐ und Dachverbände der wesentlichen Akteure im Gesundheitswesen auf dem Gebiet der SE. Das NAMSE hebt in seiner Digitalstrategie die Notwendigkeit der einrichtungsübergreifenden digitalen Zusammenarbeit der Akteure im Gesundheitssystem hervor, und betont die Notwendigkeit von abgestimmten, präzisen, interoperablen, auffindbaren Dokumentationen im Versorgungs‐ und im Forschungskontext. Dabei kommt der Vernetzung der Zentren für Seltene Erkrankungen in der Universitätsmedizin mit Anschluss an komplementäre europäische Strukturen eine besondere Bedeutung zu. Das Bundesministerium für Bildung und Forschung hat bei der Ausschreibung der Medizininformatik‐Initiative die Notwendigkeit der IT‐Unterstützung bei Diagnose und Therapiewahl exponiert angezeigt.
Als KDS-Modul „Seltene Erkrankungen" des MII KDS
über die Datenintegrationszentren
in der MII und im NUM für Verteilte und Zentrale Auswertungen
zur Verfügung stehen,
Seit dem 2026-09-11 beansprucht jedes Artefakt dieses Moduls die passenden
CRMI-Profile und trägt dieselben Governance-Metadaten wie der
ImplementationGuide
selbst. Die Regeln stehen in
input/fsh/rulesets/crmi.fsh
,
aus kerndatensatz-basis
portiert, und werden über je ein Sammel-RuleSet pro
Artefakttyp angewandt:
Veröffentlicht ein Modul CodeSystem-Supplements, ist zu beachten: Das
CRMI-Profil ShareableCodeSystem
verlangt CodeSystem.caseSensitive
, während
die FHIR-Validierung warnt, dass ein Supplement caseSensitive
nicht erneut
angeben sollte, weil das dem ergänzten CodeSystem widersprechen könnte.
kerndatensatz-basis
beansprucht deshalb bei Supplements nur das Publishable
-CRMI-Profil und lässt
das Shareable-Profil weg.
Die FAIR-Prinzipien
beschreiben
Ziele dafür, digitale Objekte auffindbar (Findable), zugänglich (Accessible),
interoperabel (Interoperable) und wiederverwendbar (Reusable) zu machen. Dieser
Abschnitt ist eine informative Selbsteinschätzung, wie die CRMI-Metadaten dieses
Leitfadens eine FAIR-konforme Veröffentlichung von FHIR-Spezifikationsartefakten
unterstützen.
Hinweis:
Detaillierte Informationen zu medizinischen Forschungsvorhaben und Studien werden im Modul Medizinische Forschungsvorhaben
der Medizininformatik-Initiative abgebildet.
Das Profil Studieneinschluss-Anfrage
ist jedoch derzeit nicht im Modul Medizinische Forschungsvorhaben enthalten und wird daher hier im Modul Seltene Erkrankungen definiert. Dieses Profil basiert auf dem entsprechenden Studieneinschluss-Anfrage Profil aus dem MTB-Modul
und wurde für die Anforderungen bei seltenen Erkrankungen angepasst.
Das
übergreifende Datenschutzkonzept der Medizininformatik-Initiative
regelt, wie Patientendaten über das Netz der Datenintegrationszentren hinweg
für die Forschung verarbeitet werden
dürfen: die Rechtsgrundlage (der Broad Consent der MII), die Rollen der
Datenintegrationszentren und der Use-&-Access-Committees sowie die
standortübergreifenden Anwendungsszenarien (Machbarkeitsanfragen, verteilte
Analysen, Daten- und Bioproben-Bereitstellung). Alles, was dieses Modul
spezifiziert, bewegt sich innerhalb dieses Rahmens — dieser Leitfaden fügt
keinen eigenen Verarbeitungszweck hinzu.
Wie Daten, die ein Datenintegrationszentrum verlassen, praktisch
de-identifiziert werden, spezifiziert
DIMP (De-Identification — Minimisation — Pseudonymisation)
in der Dokumentation des Datenportals: direkte Identifikatoren werden
entfernt, vom genehmigten Projekt nicht benötigte Datenelemente entfallen, und
identifizierende Werte werden durch projektspezifische Pseudonyme ersetzt
(FHIR-Pseudonymizer-Konfiguration). Die Profile dieses Moduls beschreiben die
Daten vor
Anwendung von DIMP; welche Elemente eine konkrete
Datenbereitstellung erreicht, entscheidet je Projekt die DIMP-Konfiguration,
nicht dieser Leitfaden.
Übersetzte Seiten liegen unter input/translations/de/pagecontent/
(gleicher
Dateiname wie die englische Seite); Ressourcen-Übersetzungen als .po
-Dateien
unter input/translations/de/
. Details:
docs/recipes/add-translation.md
in diesem Repository.
Offen:
Welche SNOMED-CT-Edition und -Version dieses Modul bindet, ist hier
noch nicht angegeben. MII-weit gilt die
Terminology Version Policy
des Meta-Moduls.
Releases folgen dem
Module Release Workflow
:
Die Version wird im Release-Branch angehoben, der Changelog-Eintrag geschrieben,
die Validierungs-Workflows laufen auf dem Release-Pull-Request, und nach dem
Merge wird das Release getaggt.
Where the versions come from.
Every package in the table is pinned
directly in
sushi-config.yaml
( dependencies:
) — including hl7.terminology.r4
(THO) and
hl7.fhir.uv.extensions.r4
, and those two deliberately so: the IG
Publisher's
automatic-packages rule
consults only this guide's own
dependency list, so without a direct pin
every build would silently inject the latest THO/extensions release — a
version pinned by the MII meta package alone cannot control the build
(verified in the publisher source at the pinned release). A weekly check
warns when these two pins drift from what the pinned meta package ships,
and the exact versions a concrete build used are recorded in its
qa-versions.json
output.
Expansion parameters are query parameters that can be passed to a ValueSet$expand
operation to control how the ValueSet is expanded — that is, how the
full list of codes is generated from the ValueSet definition. The
IG Parameters
used for this IG are declared in
sushi-config.yaml
( parameters:
). A module that pins its expansion parameters through a CRMI
manifest additionally links the generated Parameters
resource from here (see
the commented manifest blocks in sushi-config.yaml
and the Metadata Overview
page, if the module keeps it).
MONDO (Monarch Disease Ontology) harmonizes different classifications and enables integration with international standards such as Phenopackets
and GA4GH. Further information can be found under Terminologies
.
MONDO (Monarch Disease Ontology) harmonizes different classifications (SNOMED CT, Orphanet, OMIM, ICD) and enables integration with international standards such as Phenopackets
and GA4GH:
Note on the BfArM terminology server:
The code systems ICD-10-GM and ORPHAcodes described below can be retrieved via the BfArM terminology server
and used in FHIR-based systems. The server provides these terminologies as FHIR-conformant CodeSystem and ValueSet resources.
Following the model of the European data set ( CDS-ERDRI.eu
) and the French data set ( SDM-MR.fr
), this IG derives the goal of striving for the documentation of uniform, interoperable minimal base data sets in as many institutions as possible, at as many clinical workstations as possible, for as many people affected by rare diseases as possible, as well as by affected persons themselves.
Following the model of the European data set ( CDS-ERDRI.eu
) and the French data set ( SDM-MR.fr
), this IG derives the goal of striving for the documentation of uniform, interoperable minimal base data sets in as many institutions as possible, at as many clinical workstations as possible, for as many people affected by rare diseases as possible, as well as by affected persons themselves.
The patient is informed about the possibility of entering the data about his rare disease into a central Germany-wide "National Registry for Rare Diseases" (NARSE)
. The patient consents and signs the consent form, and his attending physician registers the patient with NARSE and enters the patient's disease data into the registry. In addition to the data on his history and diagnosis, his physician enters the symptoms of his disease reported by the patient in the form of HPO (Human Phenotype Ontology)
terms. For the pain in the area of the heart she codes, among others, the HPO term HP:0100749
(chest pain).
The Rare Diseases module is a KDS module for the base modules of the Medical Informatics Initiative in Germany and is therefore directly related to the base modules Person, Diagnosis, Laboratory, Procedure and Medication as well as to the other KDS modules such as Symptom/Clinical Phenotype or the Molecular Genetics Report — see the figure MII-KDS_2025-06-12_de at MII KDS
.
In France, the primary strategy of data collection for multiple local and cross-institutional data use, the so-called connected mode (mode connecté), is based on the interoperability of hospital information systems (HIS) with the central registry BNDMR and its access points, see: Le mode connecté avec le dossier patient
.
"This connected mode, favored and promoted by the French Ministry of Health, requires that the electronic patient record (DPI/EPA) or the specialist record has previously been adapted by the software manufacturer (or the partner hospital) to the collection of the national minimum data set for rare diseases (SDM-MR.fr), in accordance with the technical specifications published jointly by the Agency for Digital Health and the operational team of the BNDMR (rare diseases component of the national interoperability framework for health information systems). The implementation of this mode takes place in close cooperation with the manufacturers of enterprise software and the information system departments of the partner hospitals (see Publishers' Kit).
If the partner institution opts for the connected data collection method (mode connecté), health professionals are obliged to enter the minimum data set SDM-MR.fr directly into their electronic patient record. They have the advantage of not having to re-enter many already existing data, in particular identity data. Within the HIS, the electronic patient record (EMR) is considered the central element of trust with regard to patient identities."
The basis of the KDS module Rare Diseases is mainly the European base data set for rare diseases of the European Rare Disease Registry Infrastructure — ERDRI ( ERDRI CDS
). The goal is the harmonization of the data elements and data structures used in existing and future registries in Europe. The use of the "Set of common data elements for rare diseases registration" by every registry is a first step towards this goal and towards the interoperability of rare disease registries across Europe.
Another important reference is the data set of the National Registry for Rare Diseases (NARSE)
, which was initiated by the Eva Luise and Horst Köhler Foundation and is implemented by the Berlin Institute of Health at Charité (BIH@Charité).
Since the Model Project Genome Sequencing
has produced a data set specification
for the field of oncology and
for the field of rare diseases
, it is particularly important to harmonize both data sets.
The University Medicine Network (NUM)
particularly emphasizes research and the improvement of care for people with RD in its project selection criteria. Since about 80 percent of RD are of genetic origin, according to NAMSE the cross-institutional documentation, aimed at supporting both care and research, must contain — in addition to the precise coding of diagnoses (ICD is not sufficient, ORPHAcodes are required) — information on phenotyping and genotyping.
Because of the heterogeneity of the diseases with different care, research and documentation needs, the Joint Research Centre (JRC) of the EU Commission has defined 24 disease groups for which Europe-wide cooperation of care institutions and research groups is promoted in 24 European Reference Networks (ERN)
, each implementing or aiming at different data collections in registries adapted to the disease patterns. Despite all differences, a common core data set (Common Data Set, CDS) could nevertheless be defined for the various ERN registries — in the image of a comprehensive flower, the common blossom around which the petals of the various specific documentations are arranged. This data set is called the Set of Common Data Elements of the European Rare Disease Registry Infrastructure (ERDRI CDS) and also plays a central role in the derivation of the German core data set for RD.
The German National Action League for People with Rare Diseases (NAMSE)
, whose foundation in 2010 followed a recommendation of the EU Commission based on the French model, is an alliance between the Federal Ministry of Health (BMG), the Federal Ministry of Education and Research (BMBF) and the patient organization ACHSE e.V. (Alliance of Chronic Rare Diseases) with 25 alliance partners — all of them umbrella organizations of the key actors in the healthcare system in the field of RD. In its digital strategy, NAMSE emphasizes the necessity of cross-institutional digital cooperation of the actors in the health system, and stresses the need for coordinated, precise, interoperable, findable documentation in the care and research context. The networking of the Centers for Rare Diseases in university medicine with connection to complementary European structures is of particular importance. The Federal Ministry of Education and Research prominently indicated the necessity of IT support for diagnosis and therapy selection in the call for proposals of the Medical Informatics Initiative.
Be available as KDS module "Rare Diseases" of the MII KDS
via the data integration centers
in the MII and in the NUM for distributed and central analyses
,
Since 2026-09-11 every artefact of this module claims the matching CRMI profiles
and carries the same governance metadata as the ImplementationGuide
itself. The
rules live in input/fsh/rulesets/crmi.fsh
,
ported from kerndatensatz-basis
, and are applied through one composite rule set
per artefact type:
Where a module publishes CodeSystem supplements, note that the CRMI
ShareableCodeSystem
profile requires CodeSystem.caseSensitive
, while FHIR
validation warns that a supplement should not restate caseSensitive
because
that could contradict the supplemented code system.
kerndatensatz-basis
therefore claims only the publishable
CRMI profile on supplements and omits
the shareable one.
The FAIR principles
describe goals
for making digital objects Findable, Accessible, Interoperable and Reusable.
This section is an informative self-assessment of how the CRMI-based metadata of
this guide supports FAIR-aligned publication of FHIR specification artifacts.
However, the study enrollment request
profile is currently not contained in the Research Study module and is therefore defined here in the Rare Diseases module. This profile is based on the corresponding study enrollment request profile from the MTB module
and was adapted to the requirements of rare diseases.
The
overarching data protection concept of the Medical Informatics Initiative
governs how patient data may be processed for research across the network of
Data Integration Centers: it
covers the legal basis (the MII Broad Consent), the roles of the Data
Integration Centers and Use & Access Committees, and the cross-site application
scenarios (feasibility queries, distributed analyses, data and biosample
provision). Everything this module specifies operates inside that framework —
this guide adds no processing purpose of its own.
How data leaving a Data Integration Center is de-identified in practice is
specified by
DIMP (De-Identification — Minimisation — Pseudonymisation)
in the data portal documentation: direct identifiers are removed,
data elements not needed by the approved project are dropped, and identifying
values are replaced by project-specific pseudonyms (FHIR Pseudonymizer
configuration). The profiles of this module describe data before
DIMP is
applied; which elements survive a concrete data release is decided per project
by the DIMP configuration, not by this guide.
Translated pages live under input/translations/de/pagecontent/
(same file name
as the English page); resource translations are .po
files under
input/translations/de/
. Details:
docs/recipes/add-translation.md
in this repository.
Open:
the SNOMED CT edition/version this module binds against is not yet
stated here. The MII-wide rule is the
Terminology Version Policy
of the meta module.
Releases follow the
Module Release Workflow
:
the version is raised in the release branch, the changelog entry is written, the
validation workflows run on the release pull request, and the release is tagged
after the merge.
(
extensible
)
