MII Implementierungsleitfaden Kerndatensatz-Modul Molekulargenetischer Befundbericht
2027.0.0-ballot.1 -
Germany
MII Implementierungsleitfaden Kerndatensatz-Modul Molekulargenetischer Befundbericht
2027.0.0-ballot.1 -
Germany
This page is part of the MII IG Kerndatensatz-Modul Molekulargenetischer Befundbericht (v2027.0.0-ballot.1: Release) 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 hält die Änderungen zwischen den veröffentlichten Versionen des Moduls Molekulargenetischer Befundbericht fest, die neueste Version zuerst. Sie folgt Keep a Changelog und dem KDS-CalVer-Schema, das die Seite Versionierung beschreibt.
Jede Version erhält einen eigenen Abschnitt mit dem Release-Datum und ihren Änderungen. Dafür stehen diese Kategorien zur Verfügung:
Kategorien ohne Inhalt werden weggelassen. Geht eine Änderung auf ein Issue oder einen Pull-Request zurück, wird darauf verlinkt.
Die Versionsabschnitte gruppieren ihre Einträge thematisch — nach betroffenem Profil oder Bereich — statt nach diesen Kategorien. Beides lässt die Vorlage zu, und für ein FHIR-Modul trägt die thematische Achse weiter: Eine umbenannte Komponente ist Hinzugefügt und Entfernt zugleich, und wer wissen will, was sich an Variante geändert hat, findet es so an einer Stelle.
Sicherheit ist davon ausgenommen. Änderungen mit Auswirkung auf Sicherheit oder Datenschutz bekommen immer einen eigenen, so benannten Block — sie müssen auffindbar sein, ohne dass man thematische Abschnitte danach durchsucht. Bisher gab es keine.
Ein Versionsabschnitt mit einer Breaking Change ist erst vollständig, wenn er ausdrücklich und in diesem Changelog beantwortet:
Was als Breaking Change zählt — behandeln Sie eine Änderung als
Breaking Change, wenn sie eines der Folgenden tut, auch wenn sie klein wirkt:
eine Kardinalität verschärft (0..* → 1..1), eine
Binding-Stärke erhöht (example → required), Codes aus einem required-ValueSet
entfernt, ein Element oder einen Slice entfernt oder umbenennt, einen Typ
einengt, eine Invariante oder eine Must-Support-Pflicht hinzufügt oder eine
kanonische URL ändert. Im Zweifel: als Breaking Change berichten.
Breaking für wen: benennen Sie beide Perspektiven — gespeicherte Daten (Instanzen, die gegen die alte Version valide sind) und Implementierungen (Clients und Server, die dagegen gebaut wurden; ein entfernter Suchparameter bricht Implementierungen, während jede gespeicherte Instanz valide bleibt).
Die Versionsnummer warnt niemanden. Das KDS-Kalender-Versionsschema
(JJJJ.n.n) trägt kein Major-Signal wie SemVer — dieser
Changelog-Abschnitt ist die einzige Warnung, die Lesende bekommen.
Verlinken Sie das technische Delta. Ab der zweiten formalen
Publikation aktivieren Sie den Versionsvergleich des IG Publishers
(version-comparison in sushi-config.yaml — siehe die
Seite Versionierung zur Einrichtung und
ihren Voraussetzungen); er veröffentlicht einen maschinell erzeugten
Vergleich unter comparison-v<Vorversion>/index.html.
Verlinken Sie ihn aus dem Versionsabschnitt, damit die Erläuterung und der
technische Diff nebeneinanderstehen.
Kennzeichnen Sie solche Einträge deutlich (zum Beispiel mit dem Präfix BREAKING:), damit sie beim Überfliegen des Abschnitts nicht übersehen werden können.
Datum: 2026-09-16 · Ballot
Korrektur an den Abhängigkeitsangaben. Kein Profil, keine Extension, kein ValueSet und kein Beispiel ändert sich.
2027.0.0-ballot verwies auf Release-Kandidaten der drei MII-Module, obwohl von allen
dreien die Ballot-Version vorlag:
| Modul | vorher | jetzt |
|---|---|---|
kerndatensatz.meta |
2027.0.0-ballot.rc3 |
2027.0.0-ballot |
kerndatensatz.base |
2027.0.0-ballot.rc1 |
2027.0.0-ballot |
kerndatensatz.biobank |
2027.0.0-ballot.rc2 |
2027.0.0-ballot |
Ein Ballot, der gegen Kandidaten anderer Module validiert, ist inkonsistent — Prüfende hätten gegen Stände geprüft, die selbst als vorläufig gekennzeichnet sind.
Inhaltlich folgenlos, und das ist nachgemessen. Ein Build gegen die alten und ein
Build gegen die neuen Abhängigkeiten unterscheiden sich in 139 von 140 Ressourcen
überhaupt nicht; die einzige Abweichung ist die ImplementationGuide-Ressource mit den
drei geänderten Versionsangaben. Die Upstream-Pakete sind zwar gewachsen — meta von 173
auf 177, base von 36 auf 38, biobank von 44 auf 49 Ressourcen —, aber nichts davon
berührt, was dieses Modul verwendet: acht SearchParameter aus meta, einen IG-Verweis aus
base und SpecimenCore aus biobank.
Datum: 2026-09-15 · Ballot
Die Ballot-Version der 2027er-Linie. Inhaltlich identisch mit 2027.0.0-ballot.rc3 — diese Publikation trägt die Ballot-Kennzeichnung, sie ändert nichts an Profilen, Extensions, ValueSets oder Beispielen.
Gegenüber rc3 hat sich kein Artefakt geändert. Wer gegen rc3 implementiert hat, implementiert gegen diese Version.
Der Eintrag im FHIR-IG-Registry trägt diese Version als Edition 2027. Die
publication-request.json führt status: release, wie es die MII-Referenzmodule
handhaben.
Datum: 2026-09-14 · Release-Kandidat
Der dritte Kandidat schließt, was rc2 offengelassen hat: die Artefakt-Metadaten, die Sicherheitsanalyse und die offenen Redaktionsvermerke.
Geprüft: keine kanonische URL, kein Profilname, kein Slice und keine Kardinalität hat sich geändert. Was hinzukommt, sind Metadaten an den Artefakten und Text im Leitfaden. Instanzen, die gegen rc2 valide waren, bleiben es.
CRMI ist an allen 33 Artefakten angeschlossen — 22 StructureDefinitions, 4 ValueSets, 6 SearchParameter und das CapabilityStatement. Bis rc2 beanspruchte nur der ImplementationGuide selbst CRMI, während 32 fertige RuleSets ungenutzt im Repository lagen; das publizierte rc2-Paket trägt 0 von 22 StructureDefinitions mit CRMI-Anspruch.
Dazu gehören artifact-author, die MII-weiten Gremienangaben aus
Editor, Reviewer und Endorser, artifact-topic, resource-approvalDate,
artifact-versionPolicy, cqf-knowledgeCapability und die Paketherkunft. Die
SearchParameter tragen zusätzlich artifact-title, weil
crmi-publishablesearchparameter einen Titel verlangt und SearchParameter kein
natives title kennt.
Der modulspezifische Abschnitt ist geschrieben. Er stand seit der Migration als Platzhalter und hatte rc1 und rc2 überlebt, obwohl er selbst sagte, er müsse vor dem ersten Release erfolgen.
Er ist an den tatsächlich geführten Elementen belegt: HGVS auf DNA- und Genomebene mit exakten Positionen, Referenz- und Alternativallel, die Unterscheidung Keimbahn gegen somatisch und die Angaben zu Verwandten in der Familienanamnese. Daraus folgt, was den Abschnitt trägt — die Sequenzangaben sind selbst der Identifikator, weshalb eine Pseudonymisierung auf Profilebene das Re-Identifikationsrisiko nicht beseitigt. Fünf Anforderungen als SHALL, SHOULD und MAY benennen jeweils das adressierte Risiko.
Die Clinical Genomics Working Group wird auf der Startseite gewürdigt. Zwölf der
einundzwanzig Profile leiten sich unmittelbar von Clinical Genomics Reporting STU3 ab;
das fachliche Modell, die Komponentenstruktur, die Terminologiebindungen und die
Benennung stammen von dort. Die artifact-author-Angabe bezieht sich auf die
MII-spezifische Einschränkung und beansprucht keine Urheberschaft am Modell.
Breaking Changes tragen jetzt das Präfix BREAKING: in der Überschrift — die
kanonische URL der Familienanamnese und die URL-Namensraum-Migration, beide aus der
2026er-Linie.
Alle redaktionellen Vermerke der Template-Migration sind aufgelöst: sechs waren
reine Protokolle, fünf brauchten eine Entscheidung und haben sie bekommen. Die Klammer
„(CalVer YYYY.n.n)" hinter der Versionsangabe war ein Autorenhinweis der Vorlage und
ist entfernt.
Datum: 2026-09-07 · Release-Kandidat
Der erste Kandidat wurde formal publiziert; dieser räumt auf, was dabei sichtbar wurde.
Geprüft statt angenommen — die CalVer-Nummer warnt von sich aus nicht.
Der SNOMED-CT-Pin springt ein volles Jahr, von 20250701 auf 20260701; das ist die
einzige Änderung hier, die Codes hätte entfernen oder inaktivieren können. Alle 49
verschiedenen SNOMED-Codes dieses Moduls wurden gegen beide Versionen am
MII-Terminologieserver abgefragt: keiner unterscheidet sich — gleiche Existenz,
gleiches Display. Instanzen, die gegen rc1 valide waren, bleiben es gegen rc2.
Die fünf neu gepinnten Systeme schränken künftige Expansionen ein, ändern heute aber nichts: jedes wurde auf die Version gepinnt, die der Server ohnehin als Vorgabe lieferte. Die übrigen Änderungen betreffen Dokumentation und Release-Automatisierung.
Alle extern versionierten Codesysteme sind jetzt gepinnt, nicht nur SNOMED CT. Das Expansions-Manifest band eines von sechzehn in Frage kommenden Systemen, während seine eigene Dokumentation zusagt, eine Expansion liefere „dieselben Codes heute, zum Release-Zeitpunkt und in drei Jahren". Allein LOINC trägt hier 286 Codings und war ungepinnt.
| Codesystem | Version | Codings |
|---|---|---|
| SNOMED CT | …/version/20260701 (vorher 20250701) |
134 |
| LOINC | 2.83 |
286 |
| HGNC | 20250704 |
61 |
| Human Phenotype Ontology | 20250303 |
27 |
| Sequence Ontology | 20241118 |
14 |
| ICD-10-GM | 2026 |
16 |
Jede Version wurde am MII-Terminologieserver abgefragt, nicht geraten. HGVS, ATC und Orphanet sind nicht gepinnt, weil der Server für sie keine Version liefert; UCUM ist konstruktionsbedingt versionslos.
Migration von STU2 auf STU3 ist jetzt eine Seite im Guide. Sie führt zwei
Dokumente zusammen, die unveröffentlicht im Repository-Wurzelverzeichnis lagen, und
korrigiert drei Fehler, die beim Abgleich gegen die gebauten Artefakte auffielen — vor
allem die zweite category, die Mikrosatelliteninstabilität und Mutationslast
brauchen: sie war mit falschem Code und falschem System angegeben und ist der
häufigste Validierungsfehler beim Überführen von Daten der 2025er-Linie.
Diese Anleitung enthält bewusst keine StructureMaps: Die Datenintegration eines Datenintegrationszentrums läuft über eigene ETL-Strecken und enthält selten eine FHIR-Mapping-Engine, deshalb stehen die Abbildungen deklarativ da.
package-registry.json noch die beiden RSS-Feeds an, die ihre eigene
publish-setup.json deklariert; der -go-publish-Aufruf bekam die
Terminologie-Allowlist nicht, die der Build-Aufruf erhält; und der Registry-Prüfer
wies den Editionsnamen „<Sequence> <Status>" zurück, den jede
Nicht-Release-Publikation bekommt.Der QA-Bericht dieser Version meldet 53 Fehler. Sie sind einzeln geprüft; die
Grundlast und ihre Einordnung stehen in known_errors.txt im Repository. Zwei Gruppen
verdienen hier eine Erklärung, weil sie sonst wie Datenfehler aussehen.
Neun SNOMED-CT-Codes im Verwandtschafts-ValueSet. Der Bericht sagt, sie seien „not
valid in the system". Sie sind es. Jeder der neun wurde am MII-Terminologieserver gegen
die hier gepinnte Version …/900000000000207008/version/20260701 einzeln nachgeschlagen
— alle vorhanden, alle aktiv, alle mit dem erwarteten Display:
| Code | Display |
|---|---|
66839005 |
Father |
699110007 |
Second degree blood relative |
13646006 |
Natural parent |
60614009 |
Natural brother |
73678001 |
Natural sister |
45929001 |
Half-brother |
2272004 |
Half-sister |
62296006 |
Natural grandfather |
17945006 |
Natural grandmother |
Was scheitert, ist die Form der Anfrage, nicht der Code. Die vollständige Meldung
nennt den Grund: „Type-level request to $validate-code must specify either valueSet or
url parameter." Der Validator fragt einen Code ohne den Kontext ab, in dem der Server ihn
prüfen kann; der Server lehnt die Anfrage ab, und der Validator meldet das als
ungültigen Code. Nichts an den Daten dieses Moduls ist davon betroffen.
Ein Genfusions-Code, der keiner ist. Das Beispiel mii-exa-molgen-variante-fgfr
trägt in der Komponente gene-fusion:
http://www.genenames.org/geneId#HGNC:3689::HGNC:2697 "FGFR2::DBP"
Das ist die HGVS-Schreibweise einer Fusion — zwei HGNC-Identifikatoren, verkettet mit
::. HGNC selbst kennt HGNC:3689 und HGNC:2697 einzeln, die Verkettung ist dort kein
Code. Der Fehler bleibt in dieser Version bewusst stehen: eine tragfähige Modellierung
von Genfusionen gehört nicht hierher, sondern ins
Erweiterungsmodul Molekulares Tumorboard,
das dafür eine detaillierte Abbildung auf Basis des dnpm-Datensatzes vorsieht. Bis
dahin zeigt das Beispiel, was gemeint ist, ohne vorzugeben, dass die Kodierung
terminologisch trägt.
Das Domänenmodell ist jetzt im Leitfaden zu sehen. Es lag als Bild im Repository, ohne dass eine Seite es einband; es steht nun auf Logische Modelle, weil es genau das illustriert, was die Seite beschreibt. Die PlantUML-Quelle wurde dabei zweisprachig: eine sprachneutrale Struktur und je eine Beschriftungsdatei mit denselben 113 Variablen. Zwei vollständige Kopien hätten sich über die Jahre auseinanderentwickelt.
Vier offene Punkte beantwortet statt vertagt. Die Komponente prognosis entfällt
ersatzlos — geprüft gegen alle STU3-Profile (implication,
diagnostic-implication, therapeutic-implication, molecular-consequence): keines
trägt einen Prognose-Slice, ein Profil genomic-implication existiert nicht. Der
ValueSet-Verweis auf TherapeutischeImplikation nannte den toten STU2-Namen
therapeutic-implication-vs und heißt jetzt genetic-therapeutic-implications-vs, wie
das Elternprofil bindet. Die acht Paketabhängigkeiten stehen als Tabelle auf der
Startseite.
Die Gruppierung dieses Changelogs ist entschieden. Die Versionsabschnitte bleiben thematisch statt nach Keep-a-Changelog-Kategorien, weil eine umbenannte Komponente Hinzugefügt und Entfernt zugleich ist. Sicherheit ist die Ausnahme und bekommt immer einen eigenen Block.
Ein Release wird nicht mehr von Hand veröffentlicht. Bisher legte der Workflow einen Draft an, dessen Text sagte „Add your own release notes here" — der Handgriff war also nicht die Prüfung, sondern das Abtippen von etwas, das auf dieser Seite längst steht. Der Workflow liest den Abschnitt der Version jetzt von hier und veröffentlicht damit direkt. Fehlt der Abschnitt, wird gedraftet statt veröffentlicht.
fhirpkg.lock.json nannte für kerndatensatz.biobank noch rc1, während
sushi-config.yaml auf rc2 zeigt. Der Build war nie betroffen — SUSHI löst gegen
sushi-config.yaml auf —, aber die Sperrdatei log.
Datum: 2026-09-02 · Release Candidate
Erster Release Candidate auf Basis des MII-KDS-Modul-Templates. Der Leitfaden wird jetzt vom HL7 IG Publisher gebaut und gerendert statt von Simplifier, englisch mit deutscher Übersetzung.
kerndatensatz.meta und kerndatensatz.base auf die
2027er-Ballot-Kandidaten, de.basisprofil.r4 auf 1.6.0, hl7.terminology.r4
von 6.1.0 auf 7.3.0 und kerndatensatz.biobank von 2026.0.1 auf
2027.0.0-ballot.rc2. Das 2027.0.0-ballot.rc1 des Biobank-Moduls war nicht
nutzbar: sein Profil SpecimenCore und das davon abgeleitete Specimen wurden
ohne Snapshot ausgeliefert, was der Build dieses Moduls zurückweist. rc2 bringt
für alle 24 StructureDefinitions Snapshots mit, und die Canonicals sind
unverändert — die sechs SpecimenCore-Beispiele hier mussten also nicht angepasst
werden.reason-code wurde behoben.mii-exa-molgen-molekulargenetischer-befundbericht-* →
mii-exa-molgen-befundbericht-*.MAY statt SHALL: genotyp sowie die beiden
Clinical-Genomics-STU3-Profile haplotype und sequence-phase-relationship. Alle
drei sagen etwas über Allele als Ganzes aus statt über einen Einzelbefund, und
viele Labore leiten sie nie ab. sequence-phase-relationship war zuvor gar nicht
deklariert, obwohl die Implementiererseite es als verwendet darstellte; haplotype
stand auf SHALL und verpflichtete damit zu etwas, wozu der Guide kein Beispiel
zeigt.MII_PR_MolGen_MolekularerBiomarker ist jetzt deklariert (SHALL). Es ist das
Elternprofil von Mikrosatelliteninstabilität und Mutationslast, die beide gefordert
waren, während ihr Basisprofil unerwähnt blieb.DiagnosticReport.result:biomarker ist darauf verengt. Zuvor erbte der Slice
von STU3 und akzeptierte jedes molecular-biomarker.molekulare-konsequenz, genomic-study und genomic-study-analysis waren ohne
den Präfix mii-pr-molgen- geschrieben, den diese drei Profile tatsächlich tragen.
Ein Server hätte sie nicht auflösen können. Die Canonicals selbst bleiben
unverändert: sie stehen so im veröffentlichten Paket 2026.0.4.SHALL/MAY-Erwartung — ohne diese Tabelle wären die Erwartungen im gerenderten
Guide unsichtbar.CytogenicLocation →
cytogenetic-location, RefSequenceAssembly → reference-sequence-assembly,
associated-phenotype → predicted-phenotype. Ein Mapping auf
amino-acid-change-type entfiel: STU3 kennt diese Komponente auf variant nicht,
und das Datensatzelement ist nach molecular-consequence gewandert.Task.basedOn verwies in zwei Beispielen auf servicerequest/example — ein
Platzhalter mit kleingeschriebenem Ressourcentyp, der ins Leere zeigte. Jetzt die
BRAF-Anforderung.msi und tmb, die STU3 in
molecular-biomarker zusammengeführt hat.HGNC:3942 (das ist MTOR) mit dem
Label FGFR2 und HGNC:3943 (existiert nicht) mit dem Label FGFR3. Richtig sind
HGNC:3689 und HGNC:3690.known_errors.txt wurde angelegt. Von den Validierungsfehlern geht die große
Mehrheit auf Grenzen des Terminologieservers zurück und nicht auf Defekte dieses
Moduls; die Datei sagt, was was ist, und hält den einen bewusst hingenommenen
Fehler fest (die FGFR2::DBP-Fusionscodierung, bei der LOINC 95123-6 narrativ
skaliert ist, das Profil den Slice aber an CodeableConcept bindet).Datum: 2026-01-02
Problem: v2026.0.3 Package auf Simplifier enthielt unerwünschte Text-Dateien (FSH-Quelldateien, Markdown, etc.)
Behebung:
Version-Ruleset2026.0.0-alpha durch * insert Version ersetzt* insert Version zu allen 6 aktiven SearchParameter-Instanzen hinzugefügt|2026.0.4 aktualisiertTechnische Details:
Dependency Updates
2026.0.x (flexible versioning)Aktuelle Abhängigkeiten
| Package | Version |
|---|---|
hl7.fhir.uv.genomics-reporting |
3.0.x |
de.medizininformatikinitiative.kerndatensatz.meta |
2026.0.x |
de.medizininformatikinitiative.kerndatensatz.base |
2026.0.x |
de.medizininformatikinitiative.kerndatensatz.biobank |
2026.0.x |
de.basisprofil.r4 |
1.5.x |
hl7.terminology.r4 |
6.1.x |
Package Build
Technische Korrektur
npm pack anstatt fhir bake für Package-Erstellungfhir bake package.bake.yamlfhir bake Workflow
Hinweis: v2026.0.1 bleibt auf Simplifier verfügbar, sollte aber nicht verwendet werden. Alle abhängigen Module sollten auf v2026.0.2 aktualisieren.
Breaking Change Fix
https://www.medizininformatik-initiative.de/fhir/ext/modul-molgen/StructureDefinition/familienanamneseHinweis: Die URL familienanamnese entspricht zwar nicht formal den aktuellen Namenskonventionen (erwartbar wäre mii-pr-molgen-familienanamnese), wird aber beibehalten um breaking changes zu vermeiden.
effective[x] und issued MS zu allen Observation-Profilen hinzugefügt| Referenztypen eingeschränkt auf: Practitioner | PractitionerRole | Organization |
Konsolidierung von 18 Terminologie-Seiten in 4 übersichtliche Seiten, organisiert nach Herkunft:
Entfernte Einzelseiten: ClinVar-Evidence-Level, Condition-Inheritance-Pattern, DNAChangeType, Evidence-Level-Examples, Functional-Effect, HGNC, HGVS, HighLowcodes, MolecularConsequence, PharmGKB-Evidence-Level, TBD-Codes, Variant-Confidence-Status, VariantInheritance
example.org URLs durch MII FHIR Namensraum ersetzt (https://www.medizininformatik-initiative.de/fhir/ext/modul-molgen/)MII_PR_MolGen_MolekularerBiomarker als gemeinsames Elternprofil für:
language: de in sushi-config.yaml hinzugefügt (Issue #34)required → extensible für SNOMED CT und v3-RoleCodeDas folgende CodeSystem muss auf dem Terminologie-Server importiert werden:
http://terminology.hl7.org/CodeSystem/variant-confidence-status-cshttp://hl7.org/fhir/uv/genomics-reporting/CodeSystem/variant-confidence-status-cs) zu STU3 geändertMII IG Modul Molekulargenetischer Befundbericht/
├── IG MII KDS Modul Molekulargenetischer Befundbericht
├── Beschreibung Modul Molekulargenetischer Befundbericht
├── Anwendungsfälle Informationsmodell
├── Beschreibung von Szenarien für die Anwendung der Module
├── Datensätze inkl. Beschreibungen
├── Kontext im Gesamtprojekt Bezüge zu anderen Modulen
├── Technische Implementierung/
│ ├── Technische Implementierung (leer)
│ ├── FHIR Profile
│ ├── Anforderung-ServiceRequest
│ ├── Befundbericht-DiagnosticReport
│ ├── DiagnostischeImplikation-Observation
│ ├── TherapeutischeImplikation-Observation
│ ├── Variante-Observation
│ ├── ErgebnisZusammenfassung-Observation
│ ├── UntersuchteRegion-Observation
│ ├── Mikrosatelliteninstabilität-Observation
│ ├── Mutationslast-Observation
│ ├── Familienanamnese---FamilyMemberHistory
│ ├── Empfohlene Folgemaßnahme-Task
│ ├── Medikationsempfehlung-Task
│ ├── Polygener-Risiko-Score---RiskAssessment
│ ├── Genotyp---Observation
│ ├── Haplotype-Observation
│ ├── Sequence-Phase-Relationship---Observation
│ ├── CapabilityStatement
│ ├── Terminologien
│ ├── CodeSystems
│ ├── ValueSets
│ └── [Weitere einzelne Terminologie-Seiten]
├── UML
└── Referenzen
MII IG Modul Molekulargenetischer Befundbericht/
├── Hauptseite
├── Beschreibung Modul Molekulargenetischer Befundbericht
├── Anwendungsfälle / Informationsmodell/
│ ├── Index
│ ├── Basis des Informationsmodells
│ ├── Profile-Relationships
│ └── Szenarien
├── Kontext im Gesamtprojekt Bezug zu anderen Modulen
├── Technische Implementierung/
│ ├── Index
│ ├── Workflow/
│ │ ├── Index
│ │ ├── Befundbericht-DiagnosticReport
│ │ ├── Anforderung-ServiceRequest
│ ├── Genetische Befunde/
│ │ ├── Index
│ │ ├── Variante-Observation
│ │ ├── Genotyp-Observation
│ │ ├── Haplotyp-Observation
│ │ └── Sequence-Phase-Relationship-Observation
│ ├── Genetische Implikationen/
│ │ ├── Index
│ │ ├── Molekulare Konsequenz-Observation 🆕
│ │ ├── Diagnostische Implikation-Observation
│ │ └── Therapeutische Implikation-Observation
│ ├── Molekulare Biomarker/
│ │ ├── Index
│ │ ├── Mikrosatelliteninstabilität-Observation
│ │ ├── Mutationslast-Observation
│ │ └── Polygener Risiko Score-Observation
│ ├── Therapieempfehlungen/
│ │ ├── Index
│ │ ├── EmpfohleneFolgemassnahme-Task
│ │ └── Medikationsempfehlung-Task
│ ├── Methodik/
│ │ ├── Index
│ │ ├── GenomicStudy-Procedure 🆕
│ │ └── GenomicStudyAnalysis-Procedure 🆕
│ ├── Familienanamnese/
│ │ ├── Index
│ │ ├── Familienanamnese---FamilyMemberHistory
│ │ └── Familienanamnese-Extensions 🆕
│ ├── CapabilityStatement
│ └── Terminologie/
│ ├── Index
│ ├── CodeSystems
│ └── ValueSets
│
│
├── Referenzen
├── Release Notes
└── Kommentierung v2026 🆕
extension[genomic-artifact] durch extension[workflow-relatedArtifact] ersetztcomponent[conclusion-string] entfälltcomponent[conclusion-string]component[prognosis] fällt ersatzlos weg. Geprüft gegen alle STU3-Profile: weder therapeutic-implication noch diagnostic-implication, molecular-consequence oder das gemeinsame Elternprofil implication führen einen Prognose-Slice. Wer den Wert bisher gesetzt hat, findet in STU3 keinen Platz dafür.component[predicted-therapeutic-implication] zu component[therapeutic-implication] geändertreasonCode.coding[icd10-gm]: http://fhir.de/ValueSet/bfarm/icd-10-gm → https://www.medizininformatik-initiative.de/fhir/core/modul-diagnose/ValueSet/mii-vs-diagnose-icd10gmreasonCode.coding[alpha-id]: http://fhir.de/ValueSet/bfarm/alpha-id → https://www.medizininformatik-initiative.de/fhir/core/modul-diagnose/ValueSet/mii-vs-diagnose-alphaidreasonCode.coding[sct]: bereits https://www.medizininformatik-initiative.de/fhir/core/modul-diagnose/ValueSet/diagnoses-sctreasonCode.coding[orphanet]: Neues Binding zu https://www.medizininformatik-initiative.de/fhir/core/modul-diagnose/ValueSet/mii-vs-diagnose-orphanetcondition.code.coding Slicesrequired → extensible für SNOMED CT und v3-RoleCode