MII IG Kerndatensatz-Modul Seltene Erkrankungen
2027.0.0-ballot -
Germany
MII IG Kerndatensatz-Modul Seltene Erkrankungen
2027.0.0-ballot -
Germany
This page is part of the MII Implementation Guide Seltene Erkrankungen (v2027.0.0-ballot: 2027 Ballot 1) 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
Diese Seite enthält Übersetzungen aus der Originalsprache, in der der Leitfaden verfasst wurde. Informationen zu diesen Übersetzungen und Anweisungen zum Abgeben von Feedback zu den Übersetzungen finden Sie hier.
Diese Seite beschreibt die maschinenlesbaren Metadaten des Moduls Seltene Erkrankungen. Sie existieren, damit die Artefakte dieses Leitfadens auffindbar, bewertbar, validierbar, zitierbar, steuerbar und wiederverwendbar sind — für Menschen wie für Software.
Das Metadatenmodell folgt dem Canonical Resource Management Infrastructure Implementation Guide (CRMI); was CRMI ist und leistet, steht dort und wird hier nicht wiederholt.
Ebenso wenig wiederholt diese Seite, was MII-weit gilt und im Modul kerndatensatz-meta gepflegt wird — dort und nicht hier stehen Namenskonventionen für FHIR-Ressourcen, die Terminology Version Policy, der Module Release Workflow und die Übersicht über die Versionen der KDS-Module.
Was unten folgt, ist ausschließlich das, was dieses Modul deklariert.
Das Vorgehen ist vorläufig: Es hält den derzeit genutzten CRMI-Ansatz fest und kann angepasst werden, wenn CRMI reift, sich der KDS-Veröffentlichungsprozess weiterentwickelt und die FAIR-Bewertung von FHIR-Leitfäden konkreter wird.
CRMI-Metadaten beschreiben die FHIR-Spezifikationsartefakte selbst. Sie sind überwiegend beschreibend und ändern die klinischen oder technischen Konformitätsanforderungen der Profile, ValueSets, CodeSysteme, logischen Modelle, CapabilityStatements und Beispiele nicht. Eine Ausnahme sind die Manifest-Parameter: Sie dokumentieren und stützen den Veröffentlichungs- und Validierungskontext — Terminologie-Expansion und kanonische Versions-Pinnung — und können damit die erzeugte Ausgabe und die Validierungsergebnisse beeinflussen.
Die Metadaten sind in den erzeugten FHIR-Ressourcen einsehbar, insbesondere in den JSON- und XML-Darstellungen, die von jeder Artefaktseite verlinkt sind, sowie im herunterladbaren Paket.
CRMI gliedert das Artefaktmanagement in Lebenszyklus-Phasen und begleitende Aspekte. Dieser Leitfaden setzt nicht jede CRMI-Fähigkeit um, sondern die Teile, die für die Veröffentlichung eines KDS-Moduls unmittelbar nützlich sind.
| CRMI-Bereich | In diesem Leitfaden genutzt | Zweck |
|---|---|---|
| Artefakt-Lebenszyklus | Shareable- und Publishable-ImplementationGuide-Profile; status; version; resource-approvalDate; resource-effectivePeriod; Beitragenden-Extensions |
Verortet die Artefakte in Autorenschaft, Release, Veröffentlichung und Pflege. |
| Versions-Manifest | package-source; kanonische Versions-Pinnung (pin-canonicals: pin-all); optional CRMIManifestParameters + cqf-expansionParameters |
Ermöglicht reproduzierbare Terminologie-Expansion und stabile Auflösung kanonischer Versionen. |
| Artefakt-Konventionen | Kanonische URLs; Gleichlauf von Paket- und Ressourcen-Version; artifact-versionAlgorithm; artifact-versionPolicy |
Richtet den Leitfaden an den Konventionen für kanonische Ressourcen aus. |
| Paketierung | FHIR-Paket; ImplementationGuide.packageId; Paketversion; package-source |
Verbindet die Artefakte mit dem Paket, in dem sie erstellt, getestet, veröffentlicht und verteilt werden. |
| Veröffentlichung | Publishable-Profil; Beitragenden-Extensions; resource-approvalDate; resource-effectivePeriod; artifact-purpose; artifact-usage; optional artifact-relatedArtifact |
Ergänzt Vertrauen, Governance, Veröffentlichungskontext und lesbare Zweckangaben. |
| Verteilung | Veröffentlichte Seiten; JSON-/XML-Ressourcen; Paket-Download | Unterstützt Abruf und Werkzeugnutzung im FHIR-Publikations-Ökosystem. CRMI-Repository-Operationen sind nicht umgesetzt. |
| Signierung | Nicht umgesetzt | Mögliche künftige Erweiterung für Integrität, Authentizität und Nachweisbarkeit veröffentlichter Artefakte. |
Dieser Leitfaden definiert keine CRMIManifestLibrary, keine
CRMI-Repository-Operationen wie $package oder $data-requirements, keine
Veröffentlichung über ein Knowledge Artifact Repository, keine
Syndication-Feeds und keine Artefakt-Signierung. Das kann künftige Arbeit am
Release-Workflow aufgreifen.
Die folgenden CRMI-Metadaten werden in
sushi-config.yaml
gesetzt und landen in der erzeugten ImplementationGuide-Ressource.
| Metadaten-Artefakt | CRMI-Bereich | Ort in diesem Leitfaden | Rolle im Artefaktmanagement |
|---|---|---|---|
| CRMI Shareable ImplementationGuide CRMI Publishable ImplementationGuide CRMI ImplementationGuide |
Lebenszyklus; Veröffentlichung; Paketierung | ImplementationGuide.meta.profile |
Erzwingt den Mindestsatz an ImplementationGuide-Metadaten und ergänzt die Metadaten, die nach der Veröffentlichung für Verteilung, Repository-Aufnahme, Nutzung und Implementierung nötig sind. |
| CQF Knowledge Capability | Lebenszyklus; Artefakt-Konventionen | ImplementationGuide.extension (shareable, publishable) |
Deklariert die Wissens-Fähigkeit des Artefakts bei Ressourcen ohne eigenes knowledgeCapability-Element. |
| Artifact Purpose | Veröffentlichung; Verteilung | ImplementationGuide.extension |
Benennt, warum das Artefakt gebraucht wird und warum es so gestaltet ist. |
| Artifact Usage | Veröffentlichung; Implementierung | ImplementationGuide.extension |
Benennt, wie das Artefakt innerhalb der MII-Kerndatensatz-Spezifikation zu nutzen ist. |
| Artifact Topic | Veröffentlichung; Verteilung | ImplementationGuide.extension, codiert mit dem NCI-Thesaurus |
Ergänzt inhaltliche Themen für Filterung, Suche und Gruppierung. |
| Artifact Version Algorithm | Artefakt-Konventionen; Versionierung | ImplementationGuide.extension (semver) |
Deklariert, wie Versionen verglichen werden, um die aktuellere zu bestimmen. |
| Artifact Version Policy | Lebenszyklus; Versionierung | ImplementationGuide.extension (package) |
Deklariert, dass Artefakt-Versionen mit der Paketversion geführt werden — ein Release kann ein Artefakt hochzählen, dessen Inhalt sich nicht geändert hat. |
| Package Source | Versions-Manifest; Paketierung; Verteilung | ImplementationGuide.extension (packageId, version, uri) |
Deklariert das Paket, in dem ein Artefakt definiert ist, damit Auswertungsumgebungen Namensräume und Abhängigkeiten im vorgesehenen Kontext auflösen. |
| Resource Approval Date | Lebenszyklus; Veröffentlichung; Governance | ImplementationGuide.extension (2026-08-28) |
Hält fest, wann der Herausgeber den Inhalt offiziell zur Nutzung freigegeben hat. |
| Resource Effective Period | Lebenszyklus; Veröffentlichung; Implementierung | ImplementationGuide.extension (Beginn 2027) |
Hält fest, für welchen Zeitraum der Inhalt gelten soll oder gegolten hat. |
| Artifact Author Artifact Editor Artifact Reviewer Artifact Endorser |
Veröffentlichung; Governance; Provenienz | ImplementationGuide.extension |
Hält Autorenschaft, die für die innere Stimmigkeit verantwortliche Redaktion, die Reviewer und die offiziell befürwortenden Gremien fest. Bei einem KDS-Modul sind Redaktion, Reviewer und befürwortende Gremien die Governance-Gremien des Kerndatensatz-Prozesses. |
In diesem Gerüst nicht aktiviert, aber als auskommentierte Blöcke in
sushi-config.yaml vorbereitet:
path-expansion-params / pin-manifest.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:
| Artefakttyp | Beanspruchte CRMI-Profile | Anzahl |
|---|---|---|
| Profile, Extensions, Datensatzmodell | crmi-shareablestructuredefinition, crmi-publishablestructuredefinition |
29 |
| ValueSets | crmi-shareablevalueset, crmi-publishablevalueset |
29 |
| CodeSystems | crmi-shareablecodesystem, crmi-publishablecodesystem |
6 |
| CapabilityStatement | crmi-shareablecapabilitystatement, crmi-publishablecapabilitystatement |
1 |
Neben dem Profilanspruch trägt jedes Artefakt cqf-knowledgeCapability,
artifact-usage, artifact-versionPolicy, resource-approvalDate,
artifact-topic und die Beitragenden-Extensions. Wer ein Artefakt für sich allein
liest — außerhalb des Leitfadens —, erfährt damit weiterhin, wer dafür einsteht
und wozu es dient.
crmi-computablevalueset wird bewusst nicht beansprucht: Es verlangt eine
compose-Definition, die nicht jedes ValueSet dieses Moduls hat, und
kerndatensatz-basis beansprucht es ebenfalls nur bei einem von vierzehn.
Offener Punkt für den Ballot: Drei Profile leiten von einem Profil eines Nachbarmoduls ab — die beiden Diagnoseprofile vom
Diagnose-Profil auskerndatensatz-base, die Therapieempfehlung vomMedicationRequest-Profil auskerndatensatz-medikation. Eine abgeleiteteStructureDefinitionerbt die Metadaten-Extensions ihres Elternprofils, und die nennen den Autor des Elternmoduls. Diese drei beanspruchen deshalb nur die CRMI-Profile und wiederholen die Metadaten nicht: Ein andersartiger Wert lässt sich am selben Extension-Index nicht ersetzen, ohne dass beide stehen bleiben. Ob ein abgeleitetes Profil die Governance-Metadaten seines Elternmoduls überhaupt erben sollte, ist eine Frage der MII-weiten Konventionen und nicht dieses Moduls.
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.
Das menschenlesbare Versionsschema beschreibt die Seite Versionierung. Dieser Abschnitt beschreibt, wie diese Politik als CRMI-Metadaten ausgedrückt wird.
Das Modul verwendet die Kalender-Versionierung in der SemVer-kompatiblen
numerischen Form JJJJ.MINOR.PATCH[-label], derzeit 2027.0.0-ballot. Das
Kalenderjahr dient als CRMI-<major>-Komponente; MINOR und PATCH behalten
ihre übliche additive bzw. korrigierende Bedeutung. Stabile Versionen lassen
sich damit über den deklarierten Versionsalgorithmus semver vergleichen. Labels
tragen Vorab- oder Build-Informationen; gemäß CRMI-/FHIR-Konvention wird zwischen
Labels keine Reihenfolge abgeleitet.
| CRMI-Konformitätsanforderung | Umsetzung in diesem Leitfaden |
|---|---|
| Anforderung 3.3: Artefakt-Versionierung | Artefakte tragen eine version in der Form <major>.<minor>.<patch>[-<label>] mit dem Jahr als Major-Komponente. artifact-versionAlgorithm deklariert den Vergleich per semver. |
| Anforderung 3.4: Versionierungs-Politik | artifact-versionPolicy ist package: Artefakt-Versionen werden als Version des Pakets geführt, in dem sie erscheinen — ein Release kann daher ein inhaltlich unverändertes Artefakt hochzählen. |
| Anforderung 3.5: Versionierung von Artefakt-Sammlungen | Artefakte entstehen als Teil der Leitfaden-/Paket-Sammlung und teilen deren Version. |
| Anforderung 3.6: Paket-Quelle des Artefakts | package-source hält Paket-Id, Paketversion und Paket-Quell-URI fest. |
resource-effectivePeriod ergänzt dies um den vorgesehenen
Geltungszeitraum. Version, Versionsalgorithmus, Versionspolitik, Paketquelle und
Geltungszeitraum zusammen erlauben Lesenden und Werkzeugen die Entscheidung, ob
ein Artefakt zum erwarteten Release gehört und ob seine Metadaten zur
implementierten Version passen.
Kanonische Referenzen werden im gebauten Paket gepinnt (pin-canonicals:
pin-all in sushi-config.yaml); das ist eine CRMI-Erwartung und macht die
Ausgabe stabil.
Ein Modul, das zusätzlich eine reproduzierbare Terminologie-Expansion will,
ergänzt eine CRMI-Manifest-Parameters-Ressource — das Idiom aus
kerndatensatz-basis ist Parameters/mii-param-<slug>-manifest —, verlinkt sie
über cqf-expansionParameters aus dem ImplementationGuide und weist den
Publisher mit path-expansion-params und pin-manifest darauf hin. Lesende wie
Werkzeuge haben dann eine stabile Stelle, an der die Parameter für Expansion und
Paket-Pinnung einsehbar sind.
Dieses Modul pinnt seine Expansionsparameter. Das Saatgut liegt in
input/resources/Parameters-expansion-manifest.json, der Publisher füllt es während
des Builds, und das Ergebnis erscheint als
mii-param-seltene-manifest — 253
Parameter in dieser Auflage. Verlinkt ist es aus dem ImplementationGuide über
cqf-expansionParameters und dem Publisher über path-expansion-params und
pin-manifest benannt.
Das Saatgut pinnt die beiden Dinge, die der Build nicht selbst herleiten kann:
20260701 — dieselbe
Ausgabe, die kerndatensatz-base und kerndatensatz-molgen auf der 2027er
Linie pinnen, damit ein Code über die Module einer Auflage hinweg dasselbe
bedeutet.3.0.0.Alles Weitere im publizierten Manifest ist die Mitschrift des Builds über das, was er aufgelöst hat — und damit die Stelle, an der nachzusehen ist, wenn eine Expansion exakt reproduziert werden soll.
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.
Die Tabelle übernimmt die Indikator-Struktur der HL7-Seite FAIR Data Maturity Indicators and priority (FHIR-for-FAIR), die auf dem RDA FAIR Data Maturity Model beruht, und führt die Indikatoren der Priorität Essential auf. FHIR-for-FAIR Metadata and Data betont, dass ein FAIR-Objekt auf verschiedenen Granularitätsebenen existiert und die Grenze zwischen Metadaten und Daten kontextabhängig ist. Die Tabelle unterscheidet daher zwischen den Metadaten dieses Leitfadens und seiner Konformitätsartefakte, den mitgelieferten Beispieldaten und den von Implementierungen ausgetauschten produktiven klinischen Daten. Für die eigenen Artefakte und Beispiele kann der Leitfaden die Indikatoren adressieren; für produktive Daten unterstützt er sie, erfüllt werden müssen sie von den implementierenden Systemen, Repositorien und Governance-Prozessen.
Die mitgelieferten Beispielinstanzen zeigen FAIR-relevante FHIR-Strukturen für Testdaten. Sie sind keine produktiven klinischen Daten und werden nicht als dauerhaft identifizierter FAIR-Datensatz behauptet.
| Prinzip | Indikator | FAIR-Data-Maturity-Indikator | Adressiert durch |
|---|---|---|---|
| F1 | RDA-F1-01M | Metadaten sind über einen persistenten Identifikator identifiziert | Kanonische url-Werte, die Paket-Id de.medizininformatikinitiative.kerndatensatz.seltene, die Paketversion und package-source. Die Persistenz hängt von der Veröffentlichungs-Governance ab. |
| F1 | RDA-F1-01D | Daten sind über einen persistenten Identifikator identifiziert | Bei den Beispielen: Resource.id, Bundle.identifier, identifier-Elemente und Bundle.entry.fullUrl zeigen das Muster, sind aber keine persistenten Daten-PIDs. Produktive Daten benötigen persistente fachliche Identifikatoren aus den implementierenden Systemen. |
| F1 | RDA-F1-02M | Metadaten sind über einen global eindeutigen Identifikator identifiziert | Global gültige kanonische url-Werte und die Paket-Id innerhalb der kontrollierten KDS-Namensräume. |
| F1 | RDA-F1-02D | Daten sind über einen global eindeutigen Identifikator identifiziert | Bei den Beispielen: identifier.system + identifier.value zeigen die global eindeutige Identifikation. Produktiv hängt sie von kontrollierten Namensräumen und lokaler Governance ab. |
| F2 | RDA-F2-01M | Reichhaltige Metadaten ermöglichen das Auffinden | CRMI-Shareable-/Publishable-Profile, purpose, artifact-usage, artifact-topic, resource-approvalDate, resource-effectivePeriod, Beitragende und package-source. |
| F3 | RDA-F3-01M | Metadaten enthalten den Identifikator der Daten | Artefakt-Metadaten und Artefakt-Identifikatoren stehen gemeinsam in denselben FHIR-Ressourcen und im Paket. |
| F4 | RDA-F4-01M | Metadaten können geerntet und indexiert werden | Veröffentlichte Artefaktseiten, kanonische url-Werte, JSON-/XML-Darstellungen, das herunterladbare FHIR-Paket und artifact-topic. Das Ernten hängt von Publikationsseite und Paket-Registry ab. |
| A1 | RDA-A1-02M | Metadaten sind manuell zugänglich | Menschenlesbare Leitfaden- und Artefaktseiten. |
| A1 | RDA-A1-02D | Daten sind manuell zugänglich | Beispielseiten sowie erzeugtes JSON/XML. Produktiv hängt der Zugang von den implementierenden Systemen und lokalen Richtlinien ab. |
| A1 | RDA-A1-03M | Der Metadaten-Identifikator löst auf einen Metadatensatz auf | Kanonische url-Werte lösen auf veröffentlichte Artefaktseiten mit Verweisen auf JSON und XML auf, abhängig von der Veröffentlichungs-Governance. |
| A1 | RDA-A1-03D | Der Daten-Identifikator löst auf ein digitales Objekt auf | Beispielseiten und herunterladbares JSON/XML. Beispiel-Identifikatoren sind keine dauerhaft auflösenden Daten-PIDs. |
| A1 | RDA-A1-04M | Metadaten sind über ein standardisiertes Protokoll zugänglich | Leitfaden- und Artefaktseiten über HTTPS, erzeugte Ressourcen als FHIR-JSON/XML, Verteilung als FHIR-Paket im NPM-Format. |
| A1 | RDA-A1-04D | Daten sind über ein standardisiertes Protokoll zugänglich | Beispiele als FHIR-JSON/XML über HTTPS und über das Paket. Produktiv über konforme FHIR-REST-Server nach lokalen Richtlinien. |
| A1.1 | RDA-A1.1-01M | Metadaten sind über ein frei zugängliches Protokoll erreichbar | Öffentlicher HTTPS-Zugang zu Seiten, erzeugten Artefakten und Paket. |
| A2 | RDA-A2-01M | Metadaten bleiben verfügbar, auch wenn die Daten es nicht mehr sind | Versionierte Veröffentlichung, herunterladbares Paket, Versionshistorie und kanonische Artefakte. Langfristige Zusagen hängen von der Veröffentlichungs-Governance ab. |
| R1 | RDA-R1-01M | Eine Vielzahl zutreffender, relevanter Attribute ermöglicht die Nachnutzung | CRMI-Profile, purpose, artifact-usage, artifact-topic, resource-approvalDate, resource-effectivePeriod, artifact-versionPolicy, package-source und Beitragende. |
| R1.1 | RDA-R1.1-01M | Metadaten enthalten Lizenzinformationen | Die Lizenz CC-BY-4.0 auf Leitfaden-Ebene, der Copyright-Hinweis und die Paket-Metadaten. Nutzungsbedingungen produktiver klinischer Daten kommen von den Datenhaltenden. |
| R1.3 | RDA-R1.3-01M | Metadaten entsprechen einem Community-Standard | FHIR R4, die CRMI-Profile, die KDS-Veröffentlichungskonventionen und die Metadaten kanonischer Ressourcen. |
| R1.3 | RDA-R1.3-01D | Daten entsprechen einem Community-Standard | Die Beispiele deklarieren die Profile dieses Moduls. Produktiv muss die Konformität gegen Profile, Bindings und CapabilityStatement-Erwartungen validiert werden. |
| R1.3 | RDA-R1.3-02M | Metadaten sind gemäß einem Community-Standard maschinenverständlich | CRMI-konforme FHIR-Metadaten als JSON/XML und als FHIR-Paket im NPM-Format des IG-Publisher-Ökosystems. |
Die Tabelle führt bewusst nur die Indikatoren der Priorität Essential auf.
Die Indikatoren Important und Useful werden hier nicht bewertet: Dieser Abschnitt
ist eine informative Selbsteinschätzung, und eine längere Tabelle würde ein Maß an
förmlicher Prüfung nahelegen, das nicht stattgefunden hat. Die vollständige Tabelle
führt kerndatensatz-basis für Module, die das ganze Bild wollen.
Implementierende können diese Metadaten nutzen, um
purpose und artifact-usage zu verstehen,Für die meisten Lesenden sind die menschenlesbaren Artefaktseiten der einfachste Einstieg. Für die automatisierte Verarbeitung tragen das herunterladbare Paket und die JSON-Darstellungen der erzeugten Ressourcen die vollständigen maschinenlesbaren Metadaten.