MII Implementation Guide Core Dataset Base
2026.0.1 - Release
Germany
MII Implementation Guide Core Dataset Base
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
This page documents the computable metadata used in this implementation guide. The metadata is intended to make the artifacts easier to discover, evaluate, validate, cite, govern, and reuse by humans and software.
The metadata model is based on the Canonical Resource Management Infrastructure Implementation Guide (CRMI).
CRMI focuses on facilitating consistent exchange of knowledge artifacts throughout the artifact management lifecycle, from authoring through publishing and distribution to implementation. This IG applies selected CRMI profiles, extensions, and manifest mechanisms to make the MII artifacts more discoverable, version-aware, governable, packageable, and reusable.
The work described here is preliminary. It records the current CRMI-based metadata approach used in this IG and may be refined as CRMI matures, as the MII publication process evolves, and as FAIR assessment methods for FHIR implementation guides become more concrete.
CRMI metadata is used in this IG to describe the FHIR specification artifacts themselves. Most CRMI metadata described here is descriptive and does not change the clinical or technical conformance requirements defined by the profiles, value sets, code systems, logical models, capability statements, or examples. The manifest parameters are different: they document and support the publication and validation context, such as terminology expansion and canonical version pinning, and can therefore influence generated output and validation results.
The metadata can be inspected in the generated FHIR resources, especially in the JSON and XML representations linked from each artifact page and in the downloadable package.
CRMI organizes artifact management into lifecycle phases and supporting concerns. This IG does not implement every CRMI capability; it applies the parts that are directly useful for publishing the MII core dataset as a versioned FHIR implementation guide.
| CRMI Area | Used in this IG | Purpose |
|---|---|---|
| Artifact lifecycle | Shareable, computable, and publishable profiles; status; version; resource-approvalDate; resource-effectivePeriod; contributor extensions |
Positions artifacts in authoring, release, publication, and maintenance workflows. |
| Version Manifest | CRMIManifestParameters; cqf-expansionParameters; package-source; canonical version pinning |
Supports reproducible terminology expansion and stable canonical version resolution. |
| Artifact Conventions | Canonical URLs; package/resource version alignment; artifact-versionAlgorithm; artifact-versionPolicy |
Aligns the IG with canonical-resource authoring and versioning conventions. |
| Packaging | FHIR package; ImplementationGuide.packageId; package version; package-source |
Connects artifacts to the package context in which they are authored, tested, released, and distributed. |
| Publishing | Publishable profiles; contributor extensions; resource-approvalDate; resource-effectivePeriod; artifact-relatedArtifact; artifact-purpose; artifact-usage |
Adds trust, governance, publication context, and human-readable intent to canonical artifacts. |
| Distribution | Published IG pages; JSON/XML resources; package download; manifest parameters | Supports downstream retrieval and tooling use through the FHIR publishing ecosystem. CRMI repository operations are not implemented. |
| Signing | Not currently implemented | Candidate future enhancement for integrity, authenticity, and non-repudiation of released artifacts. |
This IG does not currently define a CRMIManifestLibrary, CRMI artifact repository operations such as $package and $data-requirements, CRMI publishing through a Knowledge Artifact Repository, syndication feeds, or artifact signing. These may be considered in future publication and release workflow work.
The following CRMI-related metadata is currently used in this IG.
| Metadata Artifact | CRMI Area | FHIR Location in this IG | Applied Resource Types | Artifact Management Role |
|---|---|---|---|---|
| CRMI Shareable ImplementationGuide CRMI Publishable ImplementationGuide CRMI ImplementationGuide |
Artifact lifecycle; publishing; packaging | ImplementationGuide.meta.profile |
ImplementationGuide |
Enforces the minimum ImplementationGuide metadata set, adds post-publication metadata for distribution, repository inclusion, consumption, and implementation, and declares expansion parameters for the IG. |
| CRMI Shareable StructureDefinition CRMI Publishable StructureDefinition |
Artifact lifecycle; publishing | StructureDefinition.meta.profile |
StructureDefinition |
Enforces the minimum StructureDefinition metadata set and adds post-publication metadata for distribution, repository inclusion, consumption, and implementation. |
| CRMI Shareable CapabilityStatement CRMI Publishable CapabilityStatement |
Artifact lifecycle; publishing; distribution | CapabilityStatement.meta.profile |
CapabilityStatement |
Enforces the minimum CapabilityStatement metadata set and adds post-publication metadata for distribution, repository inclusion, consumption, and implementation. |
| CRMI Shareable CodeSystem | Artifact lifecycle; artifact conventions | CodeSystem.meta.profile |
CodeSystem excluding supplements |
Enforces the minimum CodeSystem metadata set required for shared and published code systems. |
| CRMI Publishable CodeSystem | Publishing; distribution | CodeSystem.meta.profile |
CodeSystem including supplements |
Defines and enforces minimum expectations for CodeSystem publication and distribution, including as part of an artifact repository or IG publication, while allowing supplements to avoid restating inherited CodeSystem properties. |
| CRMI Shareable ValueSet CRMI Publishable ValueSet |
Artifact lifecycle; publishing; distribution | ValueSet.meta.profile |
ValueSet |
Enforces the minimum ValueSet metadata set and the minimum expectations for ValueSet publication and distribution, including as part of an artifact repository or IG publication. |
| CRMI Computable ValueSet | Artifact lifecycle; authoring; packaging | ValueSet.meta.profile |
ValueSet resources with computable definitions |
Declares that a ValueSet has a computable expression-based definition, represented through compose, expression, or rules-text content, with an optional expansion. |
| CQF Knowledge Capability | Artifact lifecycle; artifact conventions | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement, CodeSystem, ValueSet |
Declares the knowledge capability afforded by an artifact, using CRMI lifecycle categories such as shareable, publishable, and computable on resources without a native knowledgeCapability element. |
| Artifact Purpose | Publishing; distribution | ImplementationGuide.extension; native purpose element on canonical resources where available |
ImplementationGuide and definitional artifacts with purpose metadata |
Explains why a definitional artifact is needed and why it was designed as it is, especially where the resource does not have a native purpose element. |
| Artifact Usage | Publishing; implementation | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement |
Provides usage guidance for the artifact; in this IG, describes how the artifact should be used within the MII core dataset specification. |
| Artifact Topic | Publishing; distribution | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement, CodeSystem, ValueSet |
Adds high-level descriptive topics related to artifact content for filtering, searching, and grouping. |
| Artifact Version Algorithm | Artifact conventions; versioning | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement, CodeSystem, ValueSet |
Declares the mechanism used to compare versions and determine which version is more current. |
| Artifact Version Policy | Artifact lifecycle; versioning | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement, CodeSystem, ValueSet |
Provides the artifact versioning policy; in this IG, package means artifact versions are managed with the IG package version, so a release can update an artifact version even when the individual artifact content did not change. |
| Package Source | Version manifest; packaging; distribution | Resource.meta.extension |
Definitional resources and example resources | Declares the package in which an artifact is defined or included so evaluation environments can resolve namespaces and dependencies in the intended IG or package scope. |
| Resource Approval Date | Artifact lifecycle; publishing; governance | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement, CodeSystem, ValueSet |
Records the date on which the publisher officially approved the artifact content for use. |
| Resource Effective Period | Artifact lifecycle; publishing; implementation | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement, CodeSystem, ValueSet |
Records the period during which the resource content is planned to be or has been effective. |
| Artifact Author Artifact Editor Artifact Reviewer Artifact Endorser |
Publishing; governance; provenance | DomainResource.extension |
ImplementationGuide, StructureDefinition, CapabilityStatement, CodeSystem, ValueSet |
Records the author involved in creation and maintenance, the editor responsible for internal coherence, reviewers responsible for artifact review, and endorsers responsible for official endorsement for use. |
| Artifact Related Artifact | Publishing; provenance | DomainResource.extension |
ImplementationGuide |
Links related artifacts such as additional documentation, justification, dependencies, bibliographic references, and predecessor or successor artifacts. |
| CQF Expansion Parameters | Version manifest; publishing; distribution | ImplementationGuide.extension |
ImplementationGuide |
Specifies the expansion parameters to use when expanding ValueSets referenced from the ImplementationGuide. |
| CRMI Manifest Parameters | Version manifest; packaging; distribution | Parameters.meta.profile; referenced from ImplementationGuide.extension:cqf-expansionParameters |
Parameters |
Defines the expected Parameters resource for version pinning; in this IG, the same manifest is referenced from cqf-expansionParameters and used by the Publisher. |
CodeSystem supplements are published with CRMI publishable metadata, but they are not currently asserted as CRMI ShareableCodeSystem. The CRMI ShareableCodeSystem profile requires CodeSystem.caseSensitive, while FHIR validation warns that supplements should not restate caseSensitive because this could contradict the supplemented code system. For this reason, supplement CodeSystems in this IG use the publishable CRMI profile and omit the shareable CRMI profile.
The human-readable versioning scheme is documented on the Versioning page. This section describes how the versioning policy is expressed as CRMI metadata.
This IG uses Calendar Versioning in the SemVer-compatible numeric form YYYY.MINOR.PATCH[-label], for example 2026.0.0. The calendar year is used as the CRMI <major> component, while MINOR and PATCH follow the usual additive and corrective versioning semantics. Stable versions can therefore be compared using the declared semver version algorithm. Labels support pre-release content and build metadata; following CRMI/FHIR versioning conventions, no ordering is inferred among labels.
| CRMI Conformance Requirement | How this IG conforms |
|---|---|
| Conformance Requirement 3.3: Artifact Versioning | Artifacts specify a version. The version follows the CRMI convention <major>.<minor>.<patch>[-<label>], with the year used as the major component. artifact-versionAlgorithm declares SemVer-compatible comparison using semver. |
| Conformance Requirement 3.4: Artifact Versioning Policy | artifact-versionPolicy is set to package. Artifact versions are managed as the version of the package in which the artifact appears. This reflects that artifacts are released as part of the IG package and may receive a new version when the package is released, even without a content change to that specific artifact. |
| Conformance Requirement 3.5: Artifact Collection Versioning | Artifacts are authored as part of the IG/package collection and use the same version as the overall package. A package release may therefore assign a new version to artifacts that did not individually change. The IG uses manifest parameters to establish dependency and terminology version context. |
| Conformance Requirement 3.6: Artifact Package Source | Artifacts indicate their package source using package-source, including the package id de.medizininformatikinitiative.kerndatensatz.base, package version, and package source URI. |
Additional release metadata complements this versioning approach. resource-effectivePeriod records the intended period of applicability for the version. Together, version, version algorithm, version policy, package source, and effective period help users and tooling determine whether an artifact belongs to the expected release package and whether its metadata is consistent with the version being implemented.
The IG uses a CRMI Manifest Parameters resource together with IG Publisher parameters for canonical pinning and terminology expansion. The manifest records version-related parameters that help make generated output and validation more reproducible.
The manifest is linked from the ImplementationGuide resource using cqf-expansionParameters. The IG Publisher also uses the same manifest through the publication configuration. This gives both readers and tooling a stable place to inspect the parameters used for expansion and package pinning. This IG does not currently define a CRMIManifestLibrary; the current mechanism is the manifest Parameters resource used by the publisher and exposed through the IG metadata.
The FAIR principles describe goals for making digital objects Findable, Accessible, Interoperable, and Reusable. This section provides an informative self-assessment of how selected CRMI-based metadata in this IG supports FAIR-aligned publication of FHIR specification artifacts.
The following table reuses the indicator structure from the HL7 FHIR-for-FAIR page FAIR Data Maturity Indicators and priority, which is based on the RDA FAIR Data Maturity Model. The mapping is adapted for implementation guide artifacts and published FHIR conformance resources.
FHIR-for-FAIR Metadata and Data emphasizes that the FAIR digital object can have different levels of granularity and that the boundary between metadata and data is contextual. This table therefore distinguishes between metadata for this IG and its conformance artifacts, example/test data included in the IG, and production clinical data exchanged by implementations. The IG can directly address FAIR indicators for its own specification artifacts and examples. Indicators for production data are supported by the IG, but must be fulfilled by implementing systems, repositories, and governance processes.
The example instances and example transaction Bundle demonstrate FAIR-relevant FHIR structures for test data. They do not represent production clinical data and are not asserted as a persistently identified FAIR dataset.
| Principle | Indicator ID | FAIR Data Maturity Indicator | Priority | Addressed in this IG by |
|---|---|---|---|---|
| F1 | RDA-F1-01M | Metadata is identified by a persistent identifier | Essential | For IG metadata and conformance artifacts: canonical url values, package id de.medizininformatikinitiative.kerndatensatz.base, package version, and package-source. Persistence depends on publication governance. |
| F1 | RDA-F1-01D | Data is identified by a persistent identifier | Essential | For example/test data in this IG: Resource.id, Bundle.identifier, resource-specific identifier elements, and Bundle.entry.fullUrl demonstrate identification patterns but are not asserted as persistent data PIDs. For production data in implementations: persistent business identifiers or maintained resolvable URLs must be assigned by implementing systems. |
| F1 | RDA-F1-02M | Metadata is identified by a globally unique identifier | Essential | For IG metadata and conformance artifacts: globally scoped canonical url values and the package id identify artifacts within controlled MII namespaces. |
| F1 | RDA-F1-02D | Data is identified by a globally unique identifier | Essential | For example/test data in this IG: identifier.system plus identifier.value patterns demonstrate globally scoped identification. For production data in implementations: global uniqueness depends on controlled identifier namespaces and implementation governance. |
| F2 | RDA-F2-01M | Rich metadata is provided to allow discovery | Essential | For IG metadata and conformance artifacts: CRMI shareable/publishable profiles, purpose, artifact-usage, artifact-topic, resource-approvalDate, resource-effectivePeriod, contributors, package-source, and related artifacts. |
| F3 | RDA-F3-01M | Metadata includes the identifier for the data | Essential | For IG metadata and conformance artifacts: artifact metadata and artifact identifiers are carried together in the same FHIR resources and package. For example/test data in this IG: the transaction Bundle has a Bundle.identifier and groups resources by Bundle.entry.fullUrl, but is not asserted as a persistent dataset metadata record. |
| F4 | RDA-F4-01M | Metadata is offered in such a way that it can be harvested and indexed | Essential | For IG metadata and conformance artifacts: published artifact pages, canonical url values, JSON/XML representations, downloadable FHIR package, artifact-topic, and package metadata. Harvesting and indexing depend on the publication site, package registry, or consuming repository. |
| A1 | RDA-A1-01M | Metadata contains information to enable the user to get access to the data | Important | For IG metadata and conformance artifacts: artifact pages, canonical url values, package-source, downloads, and CapabilityStatement resources describe access to the specification artifacts. For production data in implementations: endpoint availability and access processes are implementation-specific. |
| A1 | RDA-A1-02M | Metadata can be accessed manually, i.e. with human intervention | Essential | For IG metadata and conformance artifacts: human-readable IG pages and artifact pages. |
| A1 | RDA-A1-02D | Data can be accessed manually, i.e. with human intervention | Essential | For example/test data in this IG: example resource pages and generated JSON/XML are available through the IG. For production data in implementations: manual access depends on implementing systems and local access policies. |
| A1 | RDA-A1-03M | Metadata identifier resolves to a metadata record | Essential | For IG metadata and conformance artifacts: canonical artifact url values resolve to published artifact pages with links to computable JSON and XML resources, subject to publication governance. |
| A1 | RDA-A1-03D | Data identifier resolves to a digital object | Essential | For example/test data in this IG: example pages and downloadable JSON/XML provide access to the published example objects, but example identifiers are not asserted as persistent resolving data PIDs. For production data in implementations: identifier resolution depends on implementing systems or external PID services. |
| A1 | RDA-A1-04M | Metadata is accessed through standardised protocol | Essential | For IG metadata and conformance artifacts: the IG and artifact pages are published over HTTPS, generated resources are available as FHIR JSON/XML, and the IG is distributed as a FHIR package using the NPM package format. |
| A1 | RDA-A1-04D | Data is accessible through standardised protocol | Essential | For example/test data in this IG: example resources and the example transaction Bundle are downloadable from the IG as FHIR JSON/XML over HTTPS and through the FHIR package. For production data in implementations: access depends on conforming FHIR REST servers and local access policies. |
| A1 | RDA-A1-05D | Data can be accessed automatically, i.e. by a computer program | Important | For example/test data in this IG: downloadable JSON/XML resources and the example transaction Bundle support automated tooling. For production data in implementations: automated access depends on FHIR server implementation, supported searches, operations, and authorization. |
| A1.1 | RDA-A1.1-01M | Metadata is accessible through a free access protocol | Essential | For IG metadata and conformance artifacts: public HTTPS access to IG pages, generated artifacts, and downloadable FHIR package. |
| A1.1 | RDA-A1.1-01D | Data is accessible through a free access protocol | Important | For example/test data in this IG: examples are accessible over HTTPS and through the FHIR package. For production data in implementations: FHIR REST uses an openly specified protocol, while actual access may be restricted by local authorization and governance. |
| A1.2 | RDA-A1.2-01D | Data is accessible through an access protocol that supports authentication and authorisation | Useful | Not fulfilled by the IG publication itself. For production data in implementations: systems can use FHIR REST with appropriate authentication and authorization; this is outside the metadata layer. |
| A2 | RDA-A2-01M | Metadata is guaranteed to remain available after data is no longer available | Essential | For IG metadata and conformance artifacts: versioned IG publication, downloadable FHIR package, version history, and canonical artifacts support long-term availability. Long-term guarantees depend on publication governance. The example Bundle is not a durable dataset metadata registry. |
| I1 | RDA-I1-01M | Metadata uses knowledge representation expressed in standardised format | Important | For IG metadata and conformance artifacts: FHIR R4 resources, CRMI profiles, standard FHIR extensions, JSON, XML, and FHIR package metadata. |
| I1 | RDA-I1-01D | Data uses knowledge representation expressed in standardised format | Important | For example/test data in this IG: published examples are FHIR R4 resources. For production data in implementations: conforming data is expected to follow the MII FHIR R4 profiles and terminology bindings. |
| I1 | RDA-I1-02M | Metadata uses machine-understandable knowledge representation | Important | For IG metadata and conformance artifacts: computable FHIR resources, CRMI profiles, coded extensions, canonical url values, and manifest Parameters. |
| I1 | RDA-I1-02D | Data uses machine-understandable knowledge representation | Important | For example/test data in this IG: examples demonstrate coded elements, references, identifiers, and declared profiles. For production data in implementations: machine-understandable representation depends on conforming resources, coded data, and consistent references. |
| I2 | RDA-I2-01M | Metadata uses FAIR-compliant vocabularies | Important | For IG metadata and conformance artifacts: CRMI, FHIR terminology, NCI Thesaurus artifact topics, SPDX license code, and coded package/version metadata. The IG can identify and use these vocabularies, but their own persistence, versioning, licensing, and availability are governed by the vocabulary maintainers. |
| I2 | RDA-I2-01D | Data uses FAIR-compliant vocabularies | Useful | For example/test data in this IG and production data in implementations: terminology bindings and examples use SNOMED CT, ICD-10-GM, OPS, Alpha-ID, Orphanet, and other code systems where applicable. Actual vocabulary use, versioning, and licensing depend on implementation context. |
| I3 | RDA-I3-01M | Metadata includes references to other metadata | Important | For IG metadata and conformance artifacts: IG dependencies, package-source, manifest Parameters, artifact-relatedArtifact, canonical references, and meta.profile declarations. |
| I3 | RDA-I3-01D | Data includes references to other data | Useful | For example/test data in this IG: examples demonstrate FHIR Reference elements between resources. For production data in implementations: profiles define expected reference patterns, but actual data linkage depends on implementation. |
| I3 | RDA-I3-02M | Metadata includes references to other data | Useful | For IG metadata: primarily references specification artifacts rather than production data. For example/test data in this IG: the example transaction Bundle groups resources using Bundle.entry.fullUrl, but is not asserted as a separate persistent dataset metadata object. |
| I3 | RDA-I3-02D | Data includes qualified references to other data | Useful | For example/test data in this IG: typed FHIR elements demonstrate qualified references. For production data in implementations: profiles constrain references and implementations must populate them consistently. |
| I3 | RDA-I3-03M | Metadata includes qualified references to other metadata | Important | For IG metadata and conformance artifacts: artifact-relatedArtifact, IG dependencies, canonical profile references, package-source, and manifest parameters provide qualified metadata links. |
| I3 | RDA-I3-04M | Metadata includes qualified references to other data | Useful | Partially addressed through example Bundle resources, CapabilityStatement resources, and profile-defined references. Production data references and any separate dataset metadata resource are implementation-specific. |
| R1 | RDA-R1-01M | Plurality of accurate and relevant attributes are provided to allow reuse | Essential | For IG metadata and conformance artifacts: CRMI profiles, purpose, artifact-usage, artifact-topic, resource-approvalDate, resource-effectivePeriod, artifact-versionPolicy, package-source, contributors, and related artifacts. For production data: additional dataset-specific context may be required. |
| R1.1 | RDA-R1.1-01M | Metadata includes information about the licence under which the data can be reused | Essential | For IG metadata and conformance artifacts: IG-level license: CC-BY-4.0, copyright notice, package metadata, and resource-specific copyright statements for terminology artifacts. For production clinical data: reuse licence and access conditions must be supplied by data providers. |
| R1.1 | RDA-R1.1-02M | Metadata refers to a standard reuse licence | Important | For IG metadata and conformance artifacts: SPDX license code CC-BY-4.0 in IG metadata. For production data: standard licence or data-use terms are implementation-specific. |
| R1.1 | RDA-R1.1-03M | Metadata refers to a machine-understandable reuse licence | Important | For IG metadata and conformance artifacts: machine-readable IG license element and package metadata. For production data: machine-understandable licence metadata is implementation-specific. |
| R1.2 | RDA-R1.2-01M | Metadata includes provenance information according to community-specific standards | Important | For IG metadata and conformance artifacts: contributor, reviewer, endorser, approval date, artifact-relatedArtifact, package-source, version, and MII governance metadata provide publication provenance. Full dataset or resource provenance would require FHIR Provenance or an equivalent implementation profile. |
| R1.2 | RDA-R1.2-02M | Metadata includes provenance information according to a cross-community language | Useful | For IG metadata and conformance artifacts: FHIR and CRMI metadata structures provide cross-community computable publication metadata. For production data: FHIR Provenance is the stronger cross-community mechanism. |
| R1.3 | RDA-R1.3-01M | Metadata complies with a community standard | Essential | For IG metadata and conformance artifacts: FHIR R4, CRMI profiles, MII publication conventions, and canonical resource metadata. |
| R1.3 | RDA-R1.3-01D | Data complies with a community standard | Essential | For example/test data in this IG: examples declare MII profiles and demonstrate conformance expectations. For production data in implementations: compliance must be validated against the MII FHIR profiles, terminology bindings, and CapabilityStatement expectations. |
| R1.3 | RDA-R1.3-02M | Metadata is expressed in compliance with a machine-understandable community standard | Essential | For IG metadata and conformance artifacts: CRMI-conformant FHIR metadata in JSON/XML and FHIR package form; the FHIR package format follows the NPM package convention used by the IG Publisher ecosystem. |
| R1.3 | RDA-R1.3-02D | Data is expressed in compliance with a machine-understandable community standard | Important | For example/test data in this IG: FHIR R4 examples, declared profiles, terminology resources, and CapabilityStatement resources demonstrate the machine-understandable community standard. For production data in implementations: fulfillment depends on validation against the computable MII profiles and bindings. |
Implementers can use the metadata in several ways:
purpose and artifact-usage.For most users, the human-readable artifact pages are the easiest entry point. For automated processing, the downloadable package and the JSON representations of the generated resources provide the complete computable metadata.