MII Implementierungsleitfaden Kerndatensatz Basis
2026.0.1 - Release
Germany
MII Implementierungsleitfaden Kerndatensatz Basis
2026.0.1 - Release
Germany
This page is part of the MII Implementation Guide Core Dataset Base (v2026.0.1: Release) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. 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 dokumentiert die in diesem Implementation Guide verwendeten computable Metadaten. Die Metadaten sollen die Artefakte für Menschen und Software besser auffindbar, bewertbar, validierbar, zitierbar, steuerbar und wiederverwendbar machen.
Das Metadatenmodell basiert auf dem Canonical Resource Management Infrastructure Implementation Guide (CRMI).
CRMI unterstützt den konsistenten Austausch von Wissensartefakten über den gesamten Artefaktmanagement-Lebenszyklus hinweg, von der Erstellung über Veröffentlichung und Distribution bis zur Implementierung. Dieser IG wendet ausgewählte CRMI-Profile, Extensions und Manifestmechanismen an, um die MII-Artefakte besser auffindbar, versionierbar, steuerbar, paketierbar und wiederverwendbar zu machen.
Die hier beschriebene Arbeit ist vorläufig. Sie dokumentiert den aktuellen CRMI-basierten Metadatenansatz in diesem IG und kann weiterentwickelt werden, wenn CRMI reift, sich der MII-Publikationsprozess weiterentwickelt und FAIR-Bewertungsmethoden für FHIR Implementation Guides konkreter werden.
CRMI-Metadaten werden in diesem IG verwendet, um die FHIR-Spezifikationsartefakte selbst zu beschreiben. Die meisten hier beschriebenen CRMI-Metadaten sind deskriptiv und ändern nicht die klinischen oder technischen Konformitätsanforderungen, die durch Profile, ValueSets, CodeSystems, Logical Models, CapabilityStatements oder Beispiele definiert werden. Die Manifest-Parameter unterscheiden sich davon: Sie dokumentieren und unterstützen den Publikations- und Validierungskontext, z.B. Terminologieexpansion und kanonisches Version-Pinning, und können daher generierte Ausgaben und Validierungsergebnisse beeinflussen.
Die Metadaten können in den generierten FHIR-Ressourcen eingesehen werden, insbesondere in den JSON- und XML-Repräsentationen, die von jeder Artefaktseite verlinkt sind, sowie im herunterladbaren Package.
CRMI organisiert Artefaktmanagement in Lebenszyklusphasen und unterstützende Themenbereiche. Dieser IG implementiert nicht jede CRMI-Funktionalität; er nutzt die Teile, die unmittelbar für die Veröffentlichung des MII-Kerndatensatzes als versionierter FHIR Implementation Guide relevant sind.
| CRMI-Bereich | In diesem IG verwendet | Zweck |
|---|---|---|
| Artifact lifecycle | Shareable-, computable- und publishable-Profile; status; version; resource-approvalDate; resource-effectivePeriod; Contributor-Extensions |
Ordnet Artefakte in Workflows für Erstellung, Release, Veröffentlichung und Pflege ein. |
| Version Manifest | CRMIManifestParameters; cqf-expansionParameters; package-source; kanonisches Version-Pinning |
Unterstützt reproduzierbare Terminologieexpansion und stabile Auflösung kanonischer Versionen. |
| Artifact Conventions | Kanonische URLs; Ausrichtung von Package- und Ressourcenversionen; artifact-versionAlgorithm; artifact-versionPolicy |
Richtet den IG an Konventionen für die Erstellung und Versionierung kanonischer Ressourcen aus. |
| Packaging | FHIR Package; ImplementationGuide.packageId; Package-Version; package-source |
Verknüpft Artefakte mit dem Package-Kontext, in dem sie erstellt, getestet, veröffentlicht und distribuiert werden. |
| Publishing | Publishable-Profile; Contributor-Extensions; resource-approvalDate; resource-effectivePeriod; artifact-relatedArtifact; artifact-purpose; artifact-usage |
Ergänzt Vertrauen, Governance, Publikationskontext und menschenlesbare Intention für kanonische Artefakte. |
| Distribution | Veröffentlichte IG-Seiten; JSON/XML-Ressourcen; Package-Download; Manifest-Parameter | Unterstützt nachgelagerte Nutzung und Tooling im FHIR-Publishing-Ökosystem. CRMI-Repository-Operationen sind nicht implementiert. |
| Signing | Derzeit nicht implementiert | Mögliche zukünftige Erweiterung für Integrität, Authentizität und Nichtabstreitbarkeit veröffentlichter Artefakte. |
Dieser IG definiert derzeit keine CRMIManifestLibrary, keine CRMI-Artefakt-Repository-Operationen wie $package und $data-requirements, keine CRMI-Publikation über ein Knowledge Artifact Repository, keine Syndication Feeds und kein Artifact Signing. Diese Punkte können in zukünftigen Arbeiten am Publikations- und Release-Workflow geprüft werden.
Die folgenden CRMI-bezogenen Metadaten werden derzeit in diesem IG verwendet.
| Metadatenartefakt | CRMI-Bereich | FHIR-Position in diesem IG | Angewendete Ressourcentypen | Rolle im Artefaktmanagement |
|---|---|---|---|---|
| CRMI Shareable ImplementationGuide CRMI Publishable ImplementationGuide CRMI ImplementationGuide |
Artefaktlebenszyklus; Publishing; Packaging | ImplementationGuide.meta.profile |
ImplementationGuide |
Erzwingt das Mindestset an ImplementationGuide-Metadaten, ergänzt Metadaten für Aktivitäten nach der Veröffentlichung wie Distribution, Aufnahme in Repositories, Nutzung und Implementierung und deklariert Expansionsparameter für den IG. |
| CRMI Shareable StructureDefinition CRMI Publishable StructureDefinition |
Artefaktlebenszyklus; Publishing | StructureDefinition.meta.profile |
StructureDefinition |
Erzwingt das Mindestset an StructureDefinition-Metadaten und ergänzt Metadaten für Distribution, Aufnahme in Repositories, Nutzung und Implementierung nach der Veröffentlichung. |
| CRMI Shareable CapabilityStatement CRMI Publishable CapabilityStatement |
Artefaktlebenszyklus; Publishing; Distribution | CapabilityStatement.meta.profile |
CapabilityStatement |
Erzwingt das Mindestset an CapabilityStatement-Metadaten und ergänzt Metadaten für Distribution, Aufnahme in Repositories, Nutzung und Implementierung nach der Veröffentlichung. |
| CRMI Shareable CodeSystem | Artefaktlebenszyklus; Artefaktkonventionen | CodeSystem.meta.profile |
CodeSystem ohne Supplements |
Erzwingt das Mindestset an CodeSystem-Metadaten, das für geteilte und veröffentlichte CodeSystems erforderlich ist. |
| CRMI Publishable CodeSystem | Publishing; Distribution | CodeSystem.meta.profile |
CodeSystem einschließlich Supplements |
Definiert und erzwingt Mindestanforderungen für Veröffentlichung und Distribution eines CodeSystems, einschließlich der Veröffentlichung als Teil eines Artefakt-Repositorys oder IGs, während Supplements geerbte CodeSystem-Eigenschaften nicht erneut angeben müssen. |
| CRMI Shareable ValueSet CRMI Publishable ValueSet |
Artefaktlebenszyklus; Publishing; Distribution | ValueSet.meta.profile |
ValueSet |
Erzwingt das Mindestset an ValueSet-Metadaten und die Mindestanforderungen für Veröffentlichung und Distribution eines ValueSets, einschließlich der Veröffentlichung als Teil eines Artefakt-Repositorys oder IGs. |
| CRMI Computable ValueSet | Artefaktlebenszyklus; Authoring; Packaging | ValueSet.meta.profile |
ValueSet-Ressourcen mit computable Definitionen |
Deklariert, dass ein ValueSet eine computable, ausdrucksbasierte Definition besitzt, die über compose, eine Expression oder Rules-Text-Inhalte repräsentiert wird, optional mit einer Expansion. |
| CQF Knowledge Capability | Artefaktlebenszyklus; Artefaktkonventionen | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement, CodeSystem, ValueSet |
Deklariert die Knowledge Capability eines Artefakts anhand von CRMI-Lebenszykluskategorien wie shareable, publishable und computable auf Ressourcen ohne natives knowledgeCapability-Element. |
| Artifact Purpose | Publishing; Distribution | ImplementationGuide.extension; natives purpose-Element auf kanonischen Ressourcen, sofern verfügbar |
ImplementationGuide und definitional artifacts mit Purpose-Metadaten |
Erklärt, warum ein definitional artifact benötigt wird und warum es so gestaltet wurde, insbesondere wenn die Ressource kein natives purpose-Element besitzt. |
| Artifact Usage | Publishing; Implementierung | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement |
Stellt Nutzungshinweise für das Artefakt bereit; in diesem IG beschreibt dies, wie das Artefakt innerhalb der MII-Kerndatensatzspezifikation verwendet werden soll. |
| Artifact Topic | Publishing; Distribution | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement, CodeSystem, ValueSet |
Ergänzt übergeordnete beschreibende Themen zum Artefaktinhalt für Filterung, Suche und Gruppierung. |
| Artifact Version Algorithm | Artefaktkonventionen; Versionierung | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement, CodeSystem, ValueSet |
Deklariert den Mechanismus, mit dem Versionen verglichen werden, um zu bestimmen, welche Version aktueller ist. |
| Artifact Version Policy | Artefaktlebenszyklus; Versionierung | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement, CodeSystem, ValueSet |
Stellt die Versionierungspolicy des Artefakts bereit; in diesem IG bedeutet package, dass Artefaktversionen über die Version des IG-Packages verwaltet werden. Dadurch kann ein Release eine neue Artefaktversion vergeben, auch wenn sich der Inhalt eines einzelnen Artefakts nicht geändert hat. |
| Package Source | Version Manifest; Packaging; Distribution | Resource.meta.extension |
Definitional resources und Beispielressourcen | Deklariert das Package, in dem ein Artefakt definiert oder enthalten ist, damit Ausführungsumgebungen Namespaces und Abhängigkeiten im vorgesehenen IG- oder Package-Kontext auflösen können. |
| Resource Approval Date | Artefaktlebenszyklus; Publishing; Governance | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement, CodeSystem, ValueSet |
Dokumentiert das Datum, an dem der Publisher den Artefaktinhalt offiziell zur Nutzung freigegeben hat. |
| Resource Effective Period | Artefaktlebenszyklus; Publishing; Implementierung | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement, CodeSystem, ValueSet |
Dokumentiert den Zeitraum, in dem der Ressourceninhalt wirksam sein soll oder wirksam war. |
| Artifact Author Artifact Editor Artifact Reviewer Artifact Endorser |
Publishing; Governance; Provenance | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement, CodeSystem, ValueSet |
Dokumentiert Authoring-Rollen für Erstellung und Pflege, Editor-Rollen für interne Kohärenz, Reviewer-Rollen für Prüfung und Endorser-Rollen für offizielle Unterstützung der Nutzung. |
| Artifact Related Artifact | Publishing; Provenance | DomainResource.extension |
ImplementationGuide |
Verlinkt verwandte Artefakte wie zusätzliche Dokumentation, Begründungen, Abhängigkeiten, bibliografische Referenzen sowie Vorgänger- oder Nachfolgeartefakte. |
| CQF Expansion Parameters | Version Manifest; Publishing; Distribution | ImplementationGuide.extension |
ImplementationGuide |
Spezifiziert die Expansionsparameter, die für die Expansion von ValueSets verwendet werden sollen, die aus dem ImplementationGuide referenziert werden. |
| CRMI Manifest Parameters | Version Manifest; Packaging; Distribution | Parameters.meta.profile; referenziert aus ImplementationGuide.extension:cqf-expansionParameters |
Parameters |
Definiert die erwartete Parameters-Ressource für Version-Pinning; in diesem IG wird dasselbe Manifest aus cqf-expansionParameters referenziert und vom Publisher verwendet. |
CodeSystem-Supplements werden mit CRMI-Publishable-Metadaten veröffentlicht, aber derzeit nicht als CRMI ShareableCodeSystem deklariert. Das CRMI ShareableCodeSystem-Profil verlangt CodeSystem.caseSensitive, während die FHIR-Validierung warnt, dass Supplements caseSensitive nicht erneut angeben sollen, da dies dem supplementierten CodeSystem widersprechen könnte. Aus diesem Grund verwenden Supplement-CodeSystems in diesem IG das publishable CRMI-Profil und lassen das shareable CRMI-Profil aus.
Das menschenlesbare Versionierungsschema ist auf der Seite Versionierung dokumentiert. Dieser Abschnitt beschreibt, wie die Versionierungspolicy als CRMI-Metadaten ausgedrückt wird.
Dieser IG verwendet Calendar Versioning in der SemVer-kompatiblen numerischen Form YYYY.MINOR.PATCH[-label], zum Beispiel 2026.0.0. Das Kalenderjahr wird als CRMI-<major>-Komponente verwendet, während MINOR und PATCH den üblichen Semantiken für additive bzw. korrektive Änderungen folgen. Stabile Versionen können daher mit dem deklarierten semver-Versionsalgorithmus verglichen werden. Labels unterstützen Pre-Release-Inhalte und Build-Metadaten; gemäß CRMI/FHIR-Versionierungskonventionen wird aus Labels keine Reihenfolge abgeleitet.
| CRMI-Konformitätsanforderung | Wie dieser IG die Anforderung erfüllt |
|---|---|
| Conformance Requirement 3.3: Artifact Versioning | Artefakte geben eine version an. Die Version folgt der CRMI-Konvention <major>.<minor>.<patch>[-<label>], wobei das Jahr als Major-Komponente verwendet wird. artifact-versionAlgorithm deklariert SemVer-kompatiblen Vergleich mit semver. |
| Conformance Requirement 3.4: Artifact Versioning Policy | artifact-versionPolicy ist auf package gesetzt. Artefaktversionen werden als Version des Packages verwaltet, in dem das Artefakt erscheint. Dies entspricht der Veröffentlichung der Artefakte als Teil des IG-Packages und macht deutlich, dass sich die Version eines Artefakts mit einem Package-Release ändern kann, auch ohne individuelle Inhaltsänderung. |
| Conformance Requirement 3.5: Artifact Collection Versioning | Artefakte werden als Teil der IG-/Package-Sammlung erstellt und verwenden dieselbe Version wie das gesamte Package. Ein Package-Release kann daher Artefakten eine neue Version zuweisen, auch wenn sie sich einzeln nicht geändert haben. Der IG verwendet Manifest-Parameter, um den Versionskontext für Abhängigkeiten und Terminologie festzulegen. |
| Conformance Requirement 3.6: Artifact Package Source | Artefakte geben ihre Package Source mit package-source an, einschließlich Package-ID de.medizininformatikinitiative.kerndatensatz.base, Package-Version und Package-Source-URI. |
Zusätzliche Release-Metadaten ergänzen diesen Versionierungsansatz. resource-effectivePeriod dokumentiert den vorgesehenen Gültigkeitszeitraum der Version. Zusammen helfen Version, Versionsalgorithmus, Versionierungspolicy, Package Source und Gültigkeitszeitraum Nutzenden und Werkzeugen zu bestimmen, ob ein Artefakt zum erwarteten Release-Package gehört und ob seine Metadaten mit der implementierten Version konsistent sind.
Der IG verwendet eine CRMI Manifest Parameters-Ressource zusammen mit IG-Publisher-Parametern für kanonisches Pinning und Terminologieexpansion. Das Manifest dokumentiert versionsbezogene Parameter, die dazu beitragen, generierte Ausgaben und Validierung reproduzierbarer zu machen.
Das Manifest wird aus der ImplementationGuide-Ressource über cqf-expansionParameters verlinkt. Der IG Publisher verwendet dasselbe Manifest außerdem über die Publikationskonfiguration. Dadurch erhalten Leserinnen und Leser sowie Werkzeuge eine stabile Stelle, an der die Parameter für Expansion und Package-Pinning eingesehen werden können. Dieser IG definiert derzeit keine CRMIManifestLibrary; der aktuelle Mechanismus ist die vom Publisher verwendete und über die IG-Metadaten offengelegte Manifest-Parameters-Ressource.
Die FAIR-Prinzipien beschreiben Ziele, um digitale Objekte auffindbar, zugänglich, interoperabel und wiederverwendbar zu machen. Dieser Abschnitt bietet eine informative Selbsteinschätzung, wie ausgewählte CRMI-basierte Metadaten in diesem IG eine FAIR-ausgerichtete Veröffentlichung von FHIR-Spezifikationsartefakten unterstützen.
Die folgende Tabelle nutzt die Indikatorstruktur der HL7-FHIR-for-FAIR-Seite FAIR Data Maturity Indicators and priority, die auf dem RDA FAIR Data Maturity Model basiert. Die Zuordnung wurde für Implementation-Guide-Artefakte und veröffentlichte FHIR-Konformitätsressourcen angepasst.
FHIR-for-FAIR Metadata and Data betont, dass ein FAIR Digital Object unterschiedliche Granularitäten haben kann und dass die Grenze zwischen Metadaten und Daten kontextabhängig ist. Diese Tabelle unterscheidet daher zwischen Metadaten für diesen IG und seine Konformitätsartefakte, Beispiel-/Testdaten in diesem IG und klinischen Produktionsdaten, die von Implementierungen ausgetauscht werden. Der IG kann FAIR-Indikatoren für seine eigenen Spezifikationsartefakte und Beispiele direkt adressieren. Indikatoren für Produktionsdaten werden vom IG unterstützt, müssen aber durch implementierende Systeme, Repositories und Governance-Prozesse erfüllt werden.
Die Beispielinstanzen und das Beispiel-Transaktions-Bundle demonstrieren FAIR-relevante FHIR-Strukturen für Testdaten. Sie stellen keine klinischen Produktionsdaten dar und werden nicht als persistent identifizierter FAIR-Datensatz deklariert.
| Prinzip | Indikator-ID | FAIR Data Maturity Indicator | Priorität | In diesem IG adressiert durch |
|---|---|---|---|---|
| F1 | RDA-F1-01M | Metadaten werden durch einen persistenten Identifier identifiziert | Essential | Für IG-Metadaten und Konformitätsartefakte: kanonische url-Werte, Package-ID de.medizininformatikinitiative.kerndatensatz.base, Package-Version und package-source. Persistenz hängt von der Publikationsgovernance ab. |
| F1 | RDA-F1-01D | Daten werden durch einen persistenten Identifier identifiziert | Essential | Für Beispiel-/Testdaten in diesem IG: Resource.id, Bundle.identifier, ressourcenspezifische identifier-Elemente und Bundle.entry.fullUrl demonstrieren Identifikationsmuster, werden aber nicht als persistente Daten-PIDs deklariert. Für Produktionsdaten in Implementierungen müssen persistente fachliche Identifier oder dauerhaft auflösbare URLs von den implementierenden Systemen vergeben werden. |
| F1 | RDA-F1-02M | Metadaten werden durch einen global eindeutigen Identifier identifiziert | Essential | Für IG-Metadaten und Konformitätsartefakte: global gültige kanonische url-Werte und die Package-ID identifizieren Artefakte innerhalb kontrollierter MII-Namensräume. |
| F1 | RDA-F1-02D | Daten werden durch einen global eindeutigen Identifier identifiziert | Essential | Für Beispiel-/Testdaten in diesem IG: Muster mit identifier.system plus identifier.value demonstrieren global abgegrenzte Identifikation. Für Produktionsdaten in Implementierungen hängt globale Eindeutigkeit von kontrollierten Identifier-Namensräumen und Implementierungsgovernance ab. |
| F2 | RDA-F2-01M | Reichhaltige Metadaten werden bereitgestellt, um Auffindbarkeit zu ermöglichen | Essential | Für IG-Metadaten und Konformitätsartefakte: CRMI shareable/publishable Profile, purpose, artifact-usage, artifact-topic, resource-approvalDate, resource-effectivePeriod, Contributors, package-source und verwandte Artefakte. |
| F3 | RDA-F3-01M | Metadaten enthalten den Identifier für die Daten | Essential | Für IG-Metadaten und Konformitätsartefakte: Artefaktmetadaten und Artefaktidentifier werden gemeinsam in denselben FHIR-Ressourcen und im Package transportiert. Für Beispiel-/Testdaten in diesem IG: Das Transaktions-Bundle besitzt einen Bundle.identifier und gruppiert Ressourcen über Bundle.entry.fullUrl, wird aber nicht als persistenter Datensatz-Metadatensatz deklariert. |
| F4 | RDA-F4-01M | Metadaten werden so angeboten, dass sie geharvestet und indexiert werden können | Essential | Für IG-Metadaten und Konformitätsartefakte: veröffentlichte Artefaktseiten, kanonische url-Werte, JSON/XML-Repräsentationen, herunterladbares FHIR Package, artifact-topic und Package-Metadaten. Harvesting und Indexierung hängen von Publikationsseite, Package Registry oder konsumierendem Repository ab. |
| A1 | RDA-A1-01M | Metadaten enthalten Informationen, die den Zugang zu den Daten ermöglichen | Important | Für IG-Metadaten und Konformitätsartefakte: Artefaktseiten, kanonische url-Werte, package-source, Downloads und CapabilityStatement-Ressourcen beschreiben den Zugang zu den Spezifikationsartefakten. Für Produktionsdaten in Implementierungen sind Endpunktverfügbarkeit und Zugangsprozesse implementierungsspezifisch. |
| A1 | RDA-A1-02M | Metadaten können manuell, d.h. mit menschlicher Intervention, abgerufen werden | Essential | Für IG-Metadaten und Konformitätsartefakte: menschenlesbare IG-Seiten und Artefaktseiten. |
| A1 | RDA-A1-02D | Daten können manuell, d.h. mit menschlicher Intervention, abgerufen werden | Essential | Für Beispiel-/Testdaten in diesem IG: Beispielressourcenseiten und generierte JSON/XML-Dateien sind über den IG verfügbar. Für Produktionsdaten in Implementierungen hängt manueller Zugriff von implementierenden Systemen und lokalen Zugriffspolicies ab. |
| A1 | RDA-A1-03M | Der Metadaten-Identifier löst zu einem Metadatensatz auf | Essential | Für IG-Metadaten und Konformitätsartefakte: kanonische Artefakt-url-Werte lösen zu veröffentlichten Artefaktseiten mit Links auf computable JSON- und XML-Ressourcen auf, vorbehaltlich Publikationsgovernance. |
| A1 | RDA-A1-03D | Der Daten-Identifier löst zu einem digitalen Objekt auf | Essential | Für Beispiel-/Testdaten in diesem IG: Beispielseiten und herunterladbare JSON/XML-Dateien ermöglichen Zugriff auf die veröffentlichten Beispielobjekte, aber Beispielidentifier werden nicht als persistente, auflösbare Daten-PIDs deklariert. Für Produktionsdaten in Implementierungen hängt Identifier-Auflösung von implementierenden Systemen oder externen PID-Diensten ab. |
| A1 | RDA-A1-04M | Metadaten werden über ein standardisiertes Protokoll abgerufen | Essential | Für IG-Metadaten und Konformitätsartefakte: Der IG und die Artefaktseiten werden über HTTPS veröffentlicht, generierte Ressourcen sind als FHIR JSON/XML verfügbar, und der IG wird als FHIR Package im NPM-Package-Format distribuiert. |
| A1 | RDA-A1-04D | Daten sind über ein standardisiertes Protokoll zugänglich | Essential | Für Beispiel-/Testdaten in diesem IG: Beispielressourcen und das Beispiel-Transaktions-Bundle können aus dem IG als FHIR JSON/XML über HTTPS und über das FHIR Package heruntergeladen werden. Für Produktionsdaten in Implementierungen hängt der Zugriff von konformen FHIR-REST-Servern und lokalen Zugriffspolicies ab. |
| A1 | RDA-A1-05D | Daten können automatisch, d.h. durch ein Computerprogramm, abgerufen werden | Important | Für Beispiel-/Testdaten in diesem IG: herunterladbare JSON/XML-Ressourcen und das Beispiel-Transaktions-Bundle unterstützen automatisiertes Tooling. Für Produktionsdaten in Implementierungen hängt automatisierter Zugriff von FHIR-Server-Implementierung, unterstützten Suchen, Operationen und Autorisierung ab. |
| A1.1 | RDA-A1.1-01M | Metadaten sind über ein freies Zugangsprotokoll zugänglich | Essential | Für IG-Metadaten und Konformitätsartefakte: öffentlicher HTTPS-Zugriff auf IG-Seiten, generierte Artefakte und herunterladbares FHIR Package. |
| A1.1 | RDA-A1.1-01D | Daten sind über ein freies Zugangsprotokoll zugänglich | Important | Für Beispiel-/Testdaten in diesem IG: Beispiele sind über HTTPS und das FHIR Package zugänglich. Für Produktionsdaten in Implementierungen verwendet FHIR REST ein offen spezifiziertes Protokoll, während der tatsächliche Zugriff durch lokale Autorisierung und Governance eingeschränkt sein kann. |
| A1.2 | RDA-A1.2-01D | Daten sind über ein Zugangsprotokoll zugänglich, das Authentifizierung und Autorisierung unterstützt | Useful | Wird durch die IG-Publikation selbst nicht erfüllt. Für Produktionsdaten in Implementierungen können Systeme FHIR REST mit geeigneter Authentifizierung und Autorisierung verwenden; dies liegt außerhalb der Metadatenschicht. |
| A2 | RDA-A2-01M | Metadaten bleiben garantiert verfügbar, nachdem Daten nicht mehr verfügbar sind | Essential | Für IG-Metadaten und Konformitätsartefakte: versionierte IG-Publikation, herunterladbares FHIR Package, Versionshistorie und kanonische Artefakte unterstützen langfristige Verfügbarkeit. Langfristige Garantien hängen von Publikationsgovernance ab. Das Beispiel-Bundle ist kein dauerhaftes Dataset-Metadatenregister. |
| I1 | RDA-I1-01M | Metadaten verwenden eine Wissensrepräsentation in standardisiertem Format | Important | Für IG-Metadaten und Konformitätsartefakte: FHIR-R4-Ressourcen, CRMI-Profile, Standard-FHIR-Extensions, JSON, XML und FHIR-Package-Metadaten. |
| I1 | RDA-I1-01D | Daten verwenden eine Wissensrepräsentation in standardisiertem Format | Important | Für Beispiel-/Testdaten in diesem IG: veröffentlichte Beispiele sind FHIR-R4-Ressourcen. Für Produktionsdaten in Implementierungen wird erwartet, dass konforme Daten den MII-FHIR-R4-Profilen und Terminologiebindungen folgen. |
| I1 | RDA-I1-02M | Metadaten verwenden eine maschinenverständliche Wissensrepräsentation | Important | Für IG-Metadaten und Konformitätsartefakte: computable FHIR-Ressourcen, CRMI-Profile, codierte Extensions, kanonische url-Werte und Manifest-Parameters. |
| I1 | RDA-I1-02D | Daten verwenden eine maschinenverständliche Wissensrepräsentation | Important | Für Beispiel-/Testdaten in diesem IG: Beispiele demonstrieren codierte Elemente, Referenzen, Identifier und deklarierte Profile. Für Produktionsdaten in Implementierungen hängt maschinenverständliche Repräsentation von konformen Ressourcen, codierten Daten und konsistenten Referenzen ab. |
| I2 | RDA-I2-01M | Metadaten verwenden FAIR-konforme Vokabulare | Important | Für IG-Metadaten und Konformitätsartefakte: CRMI, FHIR-Terminologie, NCI-Thesaurus-Artefaktthemen, SPDX-Lizenzcode und codierte Package-/Versionsmetadaten. Der IG kann diese Vokabulare identifizieren und verwenden; ihre eigene Persistenz, Versionierung, Lizenzierung und Verfügbarkeit werden durch die Vokabularverantwortlichen gesteuert. |
| I2 | RDA-I2-01D | Daten verwenden FAIR-konforme Vokabulare | Useful | Für Beispiel-/Testdaten in diesem IG und Produktionsdaten in Implementierungen: Terminologiebindungen und Beispiele verwenden je nach Anwendungsfall SNOMED CT, ICD-10-GM, OPS, Alpha-ID, Orphanet und andere CodeSysteme. Tatsächliche Vokabularnutzung, Versionierung und Lizenzierung hängen vom Implementierungskontext ab. |
| I3 | RDA-I3-01M | Metadaten enthalten Referenzen auf andere Metadaten | Important | Für IG-Metadaten und Konformitätsartefakte: IG-Abhängigkeiten, package-source, Manifest-Parameters, artifact-relatedArtifact, kanonische Referenzen und meta.profile-Deklarationen. |
| I3 | RDA-I3-01D | Daten enthalten Referenzen auf andere Daten | Useful | Für Beispiel-/Testdaten in diesem IG: Beispiele demonstrieren FHIR-Reference-Elemente zwischen Ressourcen. Für Produktionsdaten in Implementierungen definieren Profile erwartete Referenzmuster; tatsächliche Datenverknüpfung hängt jedoch von der Implementierung ab. |
| I3 | RDA-I3-02M | Metadaten enthalten Referenzen auf andere Daten | Useful | Für IG-Metadaten: primär Referenzen auf Spezifikationsartefakte statt auf Produktionsdaten. Für Beispiel-/Testdaten in diesem IG: Das Beispiel-Transaktions-Bundle gruppiert Ressourcen über Bundle.entry.fullUrl, wird aber nicht als separates persistentes Dataset-Metadatenobjekt deklariert. |
| I3 | RDA-I3-02D | Daten enthalten qualifizierte Referenzen auf andere Daten | Useful | Für Beispiel-/Testdaten in diesem IG: typisierte FHIR-Elemente demonstrieren qualifizierte Referenzen. Für Produktionsdaten in Implementierungen schränken Profile Referenzen ein und Implementierungen müssen sie konsistent befüllen. |
| I3 | RDA-I3-03M | Metadaten enthalten qualifizierte Referenzen auf andere Metadaten | Important | Für IG-Metadaten und Konformitätsartefakte: artifact-relatedArtifact, IG-Abhängigkeiten, kanonische Profilreferenzen, package-source und Manifest-Parameter stellen qualifizierte Metadatenlinks bereit. |
| I3 | RDA-I3-04M | Metadaten enthalten qualifizierte Referenzen auf andere Daten | Useful | Teilweise adressiert durch Beispiel-Bundle-Ressourcen, CapabilityStatement-Ressourcen und profildefinierte Referenzen. Produktionsdatenreferenzen und gegebenenfalls separate Dataset-Metadatenressourcen sind implementierungsspezifisch. |
| R1 | RDA-R1-01M | Eine Vielzahl genauer und relevanter Attribute wird bereitgestellt, um Wiederverwendung zu ermöglichen | Essential | Für IG-Metadaten und Konformitätsartefakte: CRMI-Profile, purpose, artifact-usage, artifact-topic, resource-approvalDate, resource-effectivePeriod, artifact-versionPolicy, package-source, Contributors und verwandte Artefakte. Für Produktionsdaten kann zusätzlicher datensatzspezifischer Kontext erforderlich sein. |
| R1.1 | RDA-R1.1-01M | Metadaten enthalten Informationen zur Lizenz, unter der Daten wiederverwendet werden können | Essential | Für IG-Metadaten und Konformitätsartefakte: IG-Level license: CC-BY-4.0, Copyright-Hinweis, Package-Metadaten und ressourcenspezifische Copyright-Angaben für Terminologieartefakte. Für klinische Produktionsdaten müssen Wiederverwendungslizenz und Zugangsbedingungen von Datenbereitstellenden angegeben werden. |
| R1.1 | RDA-R1.1-02M | Metadaten referenzieren eine Standard-Wiederverwendungslizenz | Important | Für IG-Metadaten und Konformitätsartefakte: SPDX-Lizenzcode CC-BY-4.0 in den IG-Metadaten. Für Produktionsdaten sind Standardlizenz oder Datennutzungsbedingungen implementierungsspezifisch. |
| R1.1 | RDA-R1.1-03M | Metadaten referenzieren eine maschinenverständliche Wiederverwendungslizenz | Important | Für IG-Metadaten und Konformitätsartefakte: maschinenlesbares IG-license-Element und Package-Metadaten. Für Produktionsdaten sind maschinenverständliche Lizenzmetadaten implementierungsspezifisch. |
| R1.2 | RDA-R1.2-01M | Metadaten enthalten Provenance-Informationen gemäß community-spezifischen Standards | Important | Für IG-Metadaten und Konformitätsartefakte: Contributor, Reviewer, Endorser, Approval Date, artifact-relatedArtifact, package-source, Version und MII-Governance-Metadaten stellen Publikationsprovenance bereit. Vollständige Datensatz- oder Ressourcenprovenance würde FHIR Provenance oder ein entsprechendes Implementierungsprofil erfordern. |
| R1.2 | RDA-R1.2-02M | Metadaten enthalten Provenance-Informationen in einer community-übergreifenden Sprache | Useful | Für IG-Metadaten und Konformitätsartefakte: FHIR- und CRMI-Metadatenstrukturen stellen community-übergreifende computable Publikationsmetadaten bereit. Für Produktionsdaten ist FHIR Provenance der stärkere community-übergreifende Mechanismus. |
| R1.3 | RDA-R1.3-01M | Metadaten erfüllen einen Community-Standard | Essential | Für IG-Metadaten und Konformitätsartefakte: FHIR R4, CRMI-Profile, MII-Publikationskonventionen und kanonische Ressourcenmetadaten. |
| R1.3 | RDA-R1.3-01D | Daten erfüllen einen Community-Standard | Essential | Für Beispiel-/Testdaten in diesem IG: Beispiele deklarieren MII-Profile und demonstrieren Konformitätserwartungen. Für Produktionsdaten in Implementierungen muss Konformität gegen die MII-FHIR-Profile, Terminologiebindungen und CapabilityStatement-Erwartungen validiert werden. |
| R1.3 | RDA-R1.3-02M | Metadaten werden in Übereinstimmung mit einem maschinenverständlichen Community-Standard ausgedrückt | Essential | Für IG-Metadaten und Konformitätsartefakte: CRMI-konforme FHIR-Metadaten in JSON/XML und FHIR-Package-Form; das FHIR-Package-Format folgt der NPM-Package-Konvention, die im IG-Publisher-Ökosystem verwendet wird. |
| R1.3 | RDA-R1.3-02D | Daten werden in Übereinstimmung mit einem maschinenverständlichen Community-Standard ausgedrückt | Important | Für Beispiel-/Testdaten in diesem IG: FHIR-R4-Beispiele, deklarierte Profile, Terminologieressourcen und CapabilityStatement-Ressourcen demonstrieren den maschinenverständlichen Community-Standard. Für Produktionsdaten in Implementierungen hängt die Erfüllung von der Validierung gegen die computable MII-Profile und Bindings ab. |
Implementierende können die Metadaten auf verschiedene Weise verwenden:
purpose und artifact-usage verstehen.Für die meisten Nutzenden sind die menschenlesbaren Artefaktseiten der einfachste Einstiegspunkt. Für automatisierte Verarbeitung stellen das herunterladbare Package und die JSON-Repräsentationen der generierten Ressourcen die vollständigen computable Metadaten bereit.