Medication IG DE
2.0.0-ballot - ballot

Medication IG DE, published by HL7 Deutschland e.V.. This guide is not an authorized publication; it is the continuous build for version 2.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/hl7germany/medication-ig-de-r4/ and changes regularly. See the Directory of published versions

Release Notes

Release: 2.0.0

Version des Textgenerierungs-Algorithmus: 2.0.0-rc.3. Die erzeugten Texte ändern sich gegenüber 2.0.0-ballot, etwa täglich: 1-0-1-0 Stück statt 1-0-1-0 Stück und bei Kopfschmerzen, alle 8 Stunden: je 1 Stück statt bei Kopfschmerzen: alle 8 Stunden je 1 Stück. Alle Änderungen des Algorithmus stehen im CHANGELOG.md von hl7germany/dgMP-DosageTextgenerierung-Skript.

Neue Seiten

Textgenerierung

  • Dosis: Textgenerierung und Bereitstellung des Dosierungstextes: Vorbedingung der Textgenerierung ist eine gegen das Profil validierte Ressource. Der Algorithmus prüft keine Profilregeln und keine Wertebereiche; er bricht nur ab, wenn der Text nicht bildbar wäre, wenn er eine Angabe unterschlagen würde, wenn sich gelesene Angaben widersprechen oder wenn ein Feld nicht den JSON-Datentyp seines FHIR-Typs hat. Ein erzeugter Text belegt keine Profilkonformität. Ausgenommen ist der Freitext-Fallback der Migration von 1.0.7 auf 2.0.0.

Extensions

  • GeneratedDosageInstructionsMeta
    • Die Beschreibung bezieht die Extension auf den Text in renderedDosageInstruction und nennt die Freitext-Dosierung, bei der die Textgenerierung den Freitext unverändert übernimmt. Bisher sprach sie nur von strukturierten Dosierungsinformationen.
    • algorithmVersion ist die Version der normativen Algorithmusspezifikation. Bisher verwies die Kurzbeschreibung auf die Version der Python-Referenzimplementierung.

Invarianten: neu

  • DosageDoseUnitMatchesCode (DosageDgMP) und DosageDoseUnitMatchesCodeWarning (DosageDE)
    • In doseQuantity, doseRange.low und doseRange.high muss unit exakt dem Anzeigetext des Codes aus KBV_CS_SFHIR_BMP_DOSIEREINHEIT entsprechen, und der Code muss zu diesem CodeSystem gehören. Bisher prüfte das keine Regel; die Textgenerierung übernimmt unit wörtlich, die Reichweitenberechnung verwendet den Code. In DosageDE gilt die Regel als Warnung und nur für Dosen mit diesem CodeSystem.
    • Die Kurzbeschreibung von unit in DosageDgMP nennt die Regel.
    • Sendende Systeme, die eigene Einheitentexte übermitteln (etwa „Tabletten“ zu Code 1), müssen den Anzeigetext des Codes übernehmen. Die Mehrzahl bildet die Textgenerierung nicht; sie folgt, sobald das CodeSystem sie führt (hl7germany/dgMP-DosageTextgenerierung-Skript#52).
    • Bei der Migration aus 1.0.7 wird unit auf den Anzeigetext des Codes gesetzt (M15).
  • TimingNoDuplicateValues (TimingDgMP)
    • Innerhalb eines Dosage-Elements dürfen dayOfWeek, when und timeOfDay keinen Wert mehrfach enthalten. Bisher schlossen das nur die Schemata ohne Wochentag sowie das reine Wochentagsschema aus. Bei Wochentagen mit Tagesabschnitt oder Uhrzeit war zum Beispiel montags MORN, MORN mit frequency = 2 gültig, obwohl FHIR mehrere Angaben in when als Vereinigung wertet und der Dosierungstext eine Gabe nennt.
    • Bei der Migration aus 1.0.7 werden doppelte Werte zusammengeführt und frequency angepasst (M14).
  • AsNeededForRequiresAsNeededWarning (DosageDE) (HDB-924)
    • Warnt, wenn ein Anlass (extension[asNeededFor]) ohne asNeededBoolean = true angegeben ist. dos-1 lässt einen Anlass ohne asNeeded wie in FHIR R5 weiterhin zu; lesende Systeme werten ihn als Bedarfsdosierung. In den dgMP-Profilen bleibt der Fall über AsNeededForRequiresAsNeeded ein Fehler.
  • TimingValuesPositive (TimingDgMP) und TimingValuesPositiveWarning (TimingDE) (HDB-971)
    • period, periodMax und boundsDuration.value müssen größer als 0 sein. FHIR R4 verlangt über tim-5 nur period >= 0; periodMax und boundsDuration waren ungeprüft.
    • In TimingDE zusätzlich boundsRange: low nicht negativ, high größer als 0.
  • DosageLimitsPositive (DosageDgMP) und DosageLimitsPositiveWarning (DosageDE) (HDB-971)
    • Mindestabstand (valueDuration.value) und maxDosePerPeriod (numerator.value, denominator.value) müssen größer als 0 sein.
  • MaxDoseNotBelowDose (DosageDgMP) (HDB-971)
    • maxDosePerPeriod.numerator.value darf nicht kleiner als doseQuantity.value beziehungsweise doseRange.high.value sein. Zuvor wurde nur die Einheit verglichen (MaxDoseSameUnitAsDose).
  • TimingBoundsPeriodFullDate (TimingDgMP)
    • boundsPeriod.start und boundsPeriod.end müssen ein vollständiges Kalenderdatum enthalten. FHIR dateTime erlaubt auch JJJJ und JJJJ-MM; die Textgenerierung kann ein Teildatum nicht darstellen und bricht ab.
  • TimingBoundsPeriodMatchesTime (TimingDgMP)
    • Im Uhrzeitenschema (timeOfDay) muss eine Uhrzeit in boundsPeriod.start oder boundsPeriod.end einer der angegebenen Uhrzeiten entsprechen.
    • Bekannte Einschränkung: Der FHIRPath-Ausdruck prüft nur den Uhrzeitanteil, nicht den Zeitzonenversatz. Die Übereinstimmung mit Europe/Berlin muss die Anwendung zusätzlich prüfen.
  • TimingBoundsPeriodNotForWhen (TimingDgMP)
    • Im Tageszeitenschema (when) und im Wochentagsschema ohne timeOfDay dürfen boundsPeriod.start und boundsPeriod.end keine Uhrzeit enthalten.
    • Das Beispiel Example-MR-Dosage-1000-startdatetime verwendet deshalb jetzt das Uhrzeitenschema, Example-MR-Dosage-1000-startdatetime-daychange ein reines Intervall.

Invarianten: ersetzt

  • DosageRequiresGeneratedText (DosageDgMP) ersetzt DosageStructuredRequiresGeneratedText (HDB-947)
    • GeneratedDosageInstructionsMeta und renderedDosageInstruction sind unabhängig von der Art der Dosierung anzugeben, also auch bei Freitext. Zuvor galt die Pflicht nur für strukturierte Dosierungen.
    • Der Schlüssel erscheint in Validierungsmeldungen; Werkzeuge, die auf DosageStructuredRequiresGeneratedText abstellen, müssen angepasst werden.

Invarianten: geändert

  • Alle Invarianten über mehrere Dosage-Elemente: combine() statt |
    • | entfernt nach FHIRPath gleiche Elemente; zwei identische Elemente zählten deshalb als eines. Betroffen waren AsNeededSingleDosageOnly, FreeTextSingleDosageOnly/…Warning und TimingSingleDosageForWhen/…ForTimeOfDay samt Warnungen: Zwei gleiche reine Bedarfsdosierungen waren gültig, obwohl genau ein Element verlangt ist (die Textgenerierung bricht dort ab).
  • FreeTextMatchesRenderedText (DosageDgMP) (HDB-947)
    • Bei einer Freitext-Dosierung muss renderedDosageInstruction vorhanden sein und Dosage.text exakt entsprechen. Zuvor wurde nur verglichen, wenn die Extension vorhanden war.
  • DosageDoseUnitSameCode (DosageDgMP) und DosageDoseUnitSameCodeWarning (DosageDE)
    • Alle Dosis-Codes der Ressource müssen bzw. sollen gleich sein. Verglichen werden doseQuantity.code, doseRange.low.code und doseRange.high.code aller Dosage-Elemente, nicht system oder unit. Dosierungen ohne Dosis-Code zählen nicht mit. Bisher löste doseAndRate ohne jeden Dosis-Code die Regel aus, etwa eine reine rate-Angabe oder eine Dosis ohne Code in DosageDE.
    • Die Prüfung über alle Dosage-Elemente der Ressource läuft je Auswertung einmal statt einmal je Element. Bisher wuchs die Validierungszeit mit der dritten Potenz der Anzahl der Dosage-Elemente. Validatoren auf Basis von HAPI (org.hl7.fhir.core) übersahen mit der bisherigen Fassung einen Teil der gemischten Einheiten (hapifhir/org.hl7.fhir.core#2843).
    • Die Beschreibungen nennen die verglichenen Felder. Neue Beispiele mit Dosisbereich.
  • DosageDoseQuantityAllowedFractions (DosageDgMP)
    • Zusätzlich zulässig ist der Bruchteil .125 (1/8), auch mit ganzzahligem Anteil wie 1.125, in doseQuantity und in beiden Grenzen von doseRange. Weitere Achtel wie .375 sind nicht zulässig.
    • Die Ganzzahligkeit wird mit $this.truncate() = $this statt mit mod 1 = 0 geprüft, siehe TimingPeriodOnlyWholeNumber.
  • DosageDoseValueDecimalNotation (DosageDgMP)
    • Höchstens drei statt zwei Nachkommastellen.
  • TimingPeriodOnlyWholeNumber und TimingBoundsDurationOnlyWholeNumber (TimingDgMP)
    • Die Regeln prüfen mit $this.truncate() = $this statt mit mod 1 = 0, ob ein Wert ganzzahlig ist. Validatoren auf Basis von HAPI (org.hl7.fhir.core) lehnten bisher ganzzahlige Werte in Dezimalschreibweise wie 1.0 oder 14.0 fälschlich ab, weil dort 1.0 mod 1 den Wert -0.0 ergibt und dieser nicht gleich 0 ist (hapifhir/org.hl7.fhir.core#2859). Nach FHIRPath sind diese Werte gültig; Constraint-Keys, Schweregrade und Kontext bleiben unverändert.
  • MinimumIntervalOnlyPureAsNeeded und MaxDoseOnlyPureAsNeeded (DosageDgMP)
    • Verlangen zusätzlich doseAndRate: Mindestabstand und Maximalmenge sind nur an einer strukturierten reinen Bedarfsdosierung zulässig. An einer Freitext-Dosierung mit asNeededBoolean = true waren sie bisher gültig, konnten aber nie im Dosierungstext erscheinen, weil der Freitext unverändert übernommen wird.
  • TimingOnlyOneBounds (TimingDgMP)
    • Erkennt jetzt auch einen Wechsel zwischen Dauer und Zeitraum über die Elemente und einen Zeitraum, dessen Start oder Ende nur in einem Teil der Elemente steht. Bisher wurden Dauer und Zeitraum getrennt geprüft und fehlende Werte übergangen; die Textgenerierung liest den Zeitrahmen nur aus dem ersten Element, ein abweichender ging verloren.
  • TimingOnlyOneTimeForInterval (TimingDgMP)
    • Alle Elemente einer Intervall-Kombination müssen period und periodUnit tragen; ein Element ohne period wurde übergangen (der Fall war über TimingOnlyOneType bereits ausgeschlossen).
    • periodMax muss in allen Elementen gleich sein oder in allen fehlen; bisher wurde es nicht verglichen. Die Textgenerierung liest den Rhythmus nur aus dem ersten Element.
    • Die Prüfung über alle Dosage-Elemente der Ressource läuft je Auswertung einmal statt einmal je Element. Bisher wuchs die Validierungszeit mit der dritten Potenz der Anzahl der Dosage-Elemente.
  • TimingOnlyWhenOrTimeOfDay (TimingDgMP): Ausdruck umgeformt, ohne fachliche Änderung
    • Die Prüfung über alle Dosage-Elemente der Ressource läuft je Auswertung einmal statt einmal je Element. Bisher wuchs die Validierungszeit mit der dritten Potenz der Anzahl der Dosage-Elemente. Constraint-Key, Schweregrad und Kontext bleiben unverändert.
  • TimingOnlyOneTimeOfDay, TimingOnlyOneWhen und TimingOnlyOneDayOfWeek (TimingDgMP)
    • Verglichen werden nur die Elemente, die das jeweilige Schema nutzen (nur timeOfDay, nur when bzw. nur dayOfWeek). Bisher zählten auch Elemente anderer Schemata mit, etwa dieselbe Uhrzeit in einem Element mit dayOfWeek. Eine Mischung der Schemata verletzt weiterhin TimingOnlyOneType.
    • Bei TimingOnlyOneTimeOfDay wächst die Validierungszeit nicht mehr mit der dritten Potenz der Anzahl der Dosage-Elemente.
  • TimingPeriodUnit (TimingDgMP)
    • Mit dayOfWeek ist nur period = 1 und periodUnit = wk zulässig, wie beschrieben; bisher wurde jede Periode in Wochen akzeptiert (der Fall war über TimingOnlyOneType bereits ausgeschlossen).
  • TimingSingleDosageForWhen, TimingSingleDosageForTimeOfDay (TimingDgMP) und die Warnungen in TimingDE
    • Beschreibung an den Ausdruck angeglichen: Die Regel gilt bei täglicher Gabe und in einer Intervall-Kombination, nicht nur bei täglicher Gabe.
    • Bekannte Einschränkung: Der HL7-Validator (org.hl7.fhir.core, geprüft bis 7.0.5) meldet einen Verstoß, wenn auf einen Dosisbereich mit Unter- und Obergrenze ein Dosisbereich nur mit derselben Obergrenze folgt, etwa morgens 1 bis 2 Stück und abends bis zu 2 Stück. Die Dosen sind verschieden, die Regel ist erfüllt (hapifhir/org.hl7.fhir.core#2843).
  • TimingFreqOrPeriodGtOne (TimingDgMP) / TimingFreqOrPeriodGtOneWarning (TimingDE) (HDB-942)
    • Beschreibung, Begründung und Beispiele um die Kombination aus variabler Frequenz und variabler Periode ergänzt („1 bis 3 x alle 2 bis 3 Tage“). Der Ausdruck ist unverändert; die Kombination war bereits ausgeschlossen.

Profile

  • DosageDgMP, TimingDgMP: Begründungen der ausgeschlossenen Elemente (0..0)
    • additionalInstruction, boundsDuration.comparator und die beiden comparator von maxDosePerPeriod tragen jetzt eine Begründung; bisher fehlte sie dort. Die Begründungen sprechen einheitlich von der „aktuellen Ausbaustufe“.
  • DosageDgMP: maxDosePerPeriod.numerator.comparator und .denominator.comparator sind 0..0
    • Bereiche und Obergrenzen haben eigene Elemente (doseRange, maxDosePerPeriod); ein Vergleichsoperator ist daneben nicht vorgesehen; die Textgenerierung definiert für ihn keine Darstellung. Bei der Dosis schließt SimpleQuantity den comparator bereits aus.
  • DosageDgMP, TimingDgMP: Kurzbeschreibungen nennen den Wertebereich
    • Dosis, Dosisbereich, Mindestabstand, Maximalmenge, Periode und Anwendungsdauer zeigen in der Kurzbeschreibung, dass nur Werte größer als 0 zulässig sind; die Untergrenze eines Dosisbereichs darf auch 0 sein. Die Seite Fachliche Rahmenvorgaben des dgMP und die Seiten der betroffenen Schemata nennen die Regel ebenfalls. Die Invarianten sind unverändert.

Fachliche Informationsmodelle

  • dosierungsdetails.anlass
    • In den Modellen der Zeitschemata (TimeSchemeLogical, WhenSchemeLogical, WeekdaySchemeLogical, IntervalSchemeLogical, IntervalCombinationSchemeLogical, WeekdayCombinationSchemeLogical) heißt dosierungsdetails.einnahmeanlass jetzt dosierungsdetails.anlass, wie bereits in PRNSchemeLogical.
    • In allen Modellen gilt 0..* statt 0..1. Mehrere Anlässe sind fachlich ODER-verknüpft, entsprechend asNeededFor 0..*.
  • PRNSchemeLogical
    • Enthält keinen zeitrahmen mehr: Eine reine Bedarfsdosierung hat kein timing und damit keinen Anwendungszeitraum über bounds[x].
    • zeitangaben.mindestabstand.einheit ist an MindestabstandUnitsOfTimeDgMP gebunden (required), wie in DosageDgMP.
    • Die Seite Schema für Bedarfsmedikation erläutert, dass eine reine Bedarfsdosierung genau ein Dosage-Element erlaubt (AsNeededSingleDosageOnly).

Beispiele

  • MR-Dosage-comb-interval-4-unsorted, MD-Dosage-comb-interval-4-unsorted, MS-Dosage-comb-interval-4-unsorted — neu: Intervall-Kombination mit unsortierten Uhrzeiten innerhalb der Dosage-Elemente.
  • MR-Dosage-BoundsDuration-Decimal — neu (JSON): boundsDuration.value als ganze Zahl mit Dezimalpunkt (14.0).
  • Dosis-Codes in Beispielen: 36 Beispiele der dgMP-Profile (etwa MR-Dosage-4schema-noon-only, MD-Dosage-4schema-ml-units) und die Untergrenzen in den Beispielen zu DoseRangeHighRequiredWhenLowPresent und DoseRangeLowAndHighSameUnit verwenden Codes aus KBV_CS_SFHIR_BMP_DOSIEREINHEIT (1 Stück, s ml, v mg) statt UCUM. Die Beispiele zu DosageDoseUnitSameCode und DosageDoseUnitSameCodeWarning verwenden für Milligramm den Code v statt mg, das es in diesem CodeSystem nicht gibt. Die dgMP-Profile binden die Dosis required an das KBV-ValueSet; aufgefallen ist das bisher nicht, weil der IG nicht vom KBV-Paket abhängt und der IG Publisher das ValueSet nicht kennt. Die erzeugten Texte ändern sich nicht.
  • Beispiele für Dosierungen: Die Spalte bounds[x] der Übersicht zeigt eine Behandlungsdauer als Wert und Einheit, etwa Duration = 5 Tag(e). Bisher stand dort die interne Darstellung des Erzeugungsskripts, etwa {'system': 'http://unitsofmeasure.org', 'value': 5, 'code': 'd', 'unit': 'Tag(e)'}.

Nachtrag zu 2.0.0-ballot

  • ExtRequiresDosage-MR, ExtRequiresDosage-MD und ExtRequiresDosage-MS (MedicationRequestDgMP, MedicationDispenseDgMP, MedicationStatementDgMP)
    • Die drei Invarianten sind seit 2.0.0-ballot Teil der Profile, fehlten aber in den Release Notes zu 2.0.0-ballot. Trägt eine Ressource GeneratedDosageInstructionsMeta oder renderedDosageInstruction, muss sie mindestens eine Dosierung enthalten. Zur Überführung bestehender Daten siehe Migration, M12.

Release: 2.0.0-ballot

Diese Version erweitert das dgMP-Dosiermodell erheblich: Dosierungen, die bisher als „nicht unterstützt" geführt waren, sind jetzt strukturiert abbildbar. Der Eintrag fasst alle Änderungen seit 1.0.5 zusammen; die dazwischenliegenden Versionen 1.0.6 und 1.0.7 waren technisch getrieben und ohne fachliche Änderung.

Version des Textgenerierungs-Algorithmus: 2.0.0-ballot. Der Algorithmus wird in hl7germany/dgMP-DosageTextgenerierung-Skript gepflegt; seine Änderungen stehen im dortigen CHANGELOG.md.

Neu unterstützte Dosierangaben

  • Variable Einzeldosis über doseRange — „1 bis 2 Stück" statt eines festen Werts. Untergrenze 0 ist zulässig, Obergrenze ist Pflicht. Siehe Variable Angaben.
  • Variable Frequenz und Periode über frequencyMax und periodMax — „1 bis 2 x täglich", „alle 2 bis 3 Tage". Bei einer reinen Intervallangabe darf von beiden nur eine größer als 1 sein (TimingFreqOrPeriodGtOne): „2 x alle 8 Stunden" wird als „alle 4 Stunden" ausgedrückt, und beide Achsen zugleich zu variieren ist damit ebenfalls ausgeschlossen. Im generischen DE-Profil löst die Regel eine Warnung aus.
  • Bedarfsmedikation über asNeededBoolean, mit Anlass (asNeededFor), Mindestabstand zwischen zwei Gaben und Maximalmenge (maxDosePerPeriod). Mehrere Anlässe sind zulässig und werden als Aufzählung wiedergegeben; der Mindestabstand ist der reinen Bedarfsdosierung vorbehalten. Siehe Schema für Bedarfsmedikation.
  • Anwendungszeitraum über boundsPeriod — Start- und/oder Enddatum, optional mit Uhrzeit und Zeitzone. Siehe Angabe von Start- und Enddatum.
  • Zusätzliche Instruktionen über patientInstruction für Hinweise, die sich nicht strukturiert abbilden lassen. Siehe Zusätzliche Instruktionen.
  • Kombination aus Zeitintervall und Tageszeiten- beziehungsweise Uhrzeiten-Bezug — nicht tägliche Perioden (d, wk, mo) zusammen mit when oder timeOfDay. Siehe Schema für Kombinationen von Zeitintervallen.
  • Rückwärtskompatibilität für redundante Legacy-Angaben: Bei Wochentagsschemata bleiben frequency sowie das Paar period = 1, periodUnit = wk zulässig. Sie begründen kein Intervallschema und verändern den erzeugten Text nicht.

Damit entfallen 20 Beispiele aus der Liste nicht unterstützter Dosierkonfigurationen: asNeededBoolean, asNeededCodeableConcept, doseRange, maxDosePerPeriod und boundsPeriod.

Neue Artefakte

  • Extensions: MinimumIntervalBetweenAdministrations, Backport von asNeededFor aus R5
  • ValueSet: MindestabstandUnitsOfTimeDgMP
  • Seiten: Bedarfsmedikation, Variable Angaben, Start- und Enddatum, Zusätzliche Instruktionen

Invarianten

Neu sind 31 Invarianten; sie sichern die oben genannten Angaben ab. Was jede einzelne prüft, beschreibt die Übersicht der Timing- & Dosierungs-Invarianten.

  • DosageDgMP: AsNeededForIdentical, AsNeededForRequiresAsNeeded, AsNeededIdentical, AsNeededSingleDosageOnly, DosageDoseQuantityAllowedFractions, DosageDoseValueDecimalNotation, DosageDoseValuePositive, DosageFourSlotPatternInText, DoseRangeHighRequiredWhenLowPresent, DoseRangeLowAndHighSameUnit, DoseRangeNoVarPeriod, MaxDoseOnlyPureAsNeeded, MaxDosePerPeriodOnly24hOr1d, MaxDoseSameUnitAsDose, MinimumIntervalOnlyPureAsNeeded, MinimumIntervalUnitMatchesCode, PatientInstructionIdentical
  • TimingDgMP: TimingBoundsDurationOnlyWholeNumber, TimingFreqOrPeriodGtOne, TimingPeriodOnlyWholeNumber, TimingVarFreqGtMin, TimingVarPeriodGtMin
  • DosageDE (Warnungen): DosageDoseUnitSameCodeWarning, DosageDoseValuePositiveWarning, DosageFourSlotPatternInTextWarning, DosageStructuredRequiresBothWarning, dos-1
  • TimingDE (Warnungen): TimingBoundsUnitMatchesCodeWarning, TimingFreqOrPeriodGtOneWarning, TimingSingleDosageForTimeOfDayWarning, TimingSingleDosageForWhenWarning

Geändert haben sich die folgenden bestehenden Regeln. Ihr Wortlaut steht hier, weil die Übersichtsseite nur den aktuellen Stand zeigt, nicht den Unterschied zu 1.0.5:

  • TimingOnlyOneType (TimingDgMP)
    • Bei dayOfWeek sind frequency sowie das Paar period = 1, periodUnit = wk als redundante Legacy-Angaben zulässig; zuvor führten sie zu einem Fehler. Jede andere Periode ist mit dayOfWeek nicht kombinierbar.
    • Die Kombination aus Zeitintervall und Tageszeiten- beziehungsweise Uhrzeiten-Bezug ist als eigenes Schema erfasst.
    • Eine variable Frequenz (frequencyMax) bleibt der reinen Intervallangabe vorbehalten; konkrete Zeitpunkte und Wochentage legen die Zahl der Gaben bereits fest.
  • TimingPeriodUnit (TimingDgMP)
    • periodUnit darf nur zusammen mit period angegeben werden. Bei dayOfWeek ist ausschließlich die redundante Wochenangabe zulässig; bei when oder timeOfDay ohne dayOfWeek sind Tage, Wochen oder Monate zulässig. Zuvor war dort ausschließlich d erlaubt, wodurch wöchentliche und monatliche Kombinationen nicht abbildbar waren.
  • TimingSingleDosageForTimeOfDay und TimingSingleDosageForWhen (TimingDgMP)
    • Geprüft wird jetzt, ob jedes Dosage-Element eine eindeutige vollständige Dosis einschließlich Datentyp trägt. Zuvor genügte es, dass überhaupt zwei unterschiedliche Werte vorkamen — Ressourcen mit den Dosen 1, 1 und 2 wurden dadurch fälschlich akzeptiert.
  • TimingFrequencyCount (TimingDgMP)
    • Beschreibung präzisiert, Ausdruck unverändert: frequency ist bei when, timeOfDay und dayOfWeek optional, muss bei Angabe aber der Anzahl der konkreten Anwendungen entsprechen.
  • DosageWarnungViererschemaInText (DosageDE) — umbenannt in DosageFourSlotPatternInTextWarning
    • Der Schlüssel trug als einziger einen deutschen Wortstamm und zudem „Warnung" statt des sonst verwendeten Warning-Suffixes. Er erscheint in Validierungsmeldungen; Werkzeuge, die darauf abstellen, müssen angepasst werden. Der Ausdruck ist unverändert.
  • TimingVarFreqGtMin (TimingDgMP)
    • Vergleicht frequency und frequencyMax jetzt numerisch über .value.toInteger(). Zuvor verglich der Ausdruck die Werte als Zeichenketten: „9 bis 10 x täglich" galt dadurch als ungültig, weil "9" < "10" lexikographisch nicht zutrifft. Betroffen war jede variable Frequenz, deren Ober- und Untergrenze unterschiedlich viele Stellen haben.
  • TimingOnlyOneWhen, TimingOnlyOneTimeOfDay, TimingOnlyOneDayOfWeek, TimingOnlyOneTimeForInterval und TimingOnlyWhenOrTimeOfDay (TimingDgMP)
    • Die Schema-Erkennung in der Vorbedingung setzt frequency, period und periodUnit nicht mehr voraus. Zuvor griffen diese Regeln nur, wenn alle drei Felder belegt waren — seit sie optionale Legacy-Angaben sind, wären Ressourcen ohne sie ungeprüft geblieben. Die Regeln erfassen damit alle Ressourcen des jeweiligen Schemas.
  • DosageStructuredRequiresBoth und DosageStructuredRequiresGeneratedText (DosageDgMP)
    • Beide berücksichtigen jetzt die reine Bedarfsmedikation: doseAndRate darf ohne timing angegeben werden, wenn asNeededBoolean = true oder ein Anlass gesetzt ist, und eine solche Dosierung verlangt ebenfalls die Extension GeneratedDosageInstructionsMeta. Zuvor galt eine Dosierung ohne timing als unvollständig.
  • TimingOnlyOneBounds (TimingDgMP)
    • Deckt zusätzlich boundsPeriod ab: Start und Ende müssen über alle Dosage-Elemente gleich belegt sein. Zuvor prüfte die Regel nur boundsDuration, obwohl die Textgenerierung den Zeitrahmen in beiden Fällen ausschließlich aus dem ersten Element liest. Ebenso gilt jetzt: Entweder tragen alle Elemente einen Zeitrahmen oder keines.
  • TimingOnlyOnePeriodForDayOfWeek (TimingDgMP)
    • Von Timing.repeat auf Timing verschoben, um einen Überlauf im IG Publisher bei der Erzeugung der Excel-Tabellen zu umgehen. Der Ausdruck wertet ohnehin die gesamte Ressource aus; inhaltlich ändert sich nichts.
  • MinimumIntervalOnlyPureAsNeeded (DosageDgMP) — neu
    • modifierExtension[MinimumIntervalBetweenAdministrations] ist nur zusammen mit asNeededBoolean = true und ohne timing zulässig.
    • Ein strukturierter Rhythmus legt den Abstand zwischen zwei Gaben bereits fest. Eine zweite, schwächere Untergrenze daneben lässt offen, welche Angabe gilt — „alle 8 Stunden, mit mindestens 6 Stunden Abstand" ist als Anweisung widersprüchlich.

Sonstiges

  • Die Spezifikation der Dosis-Textgenerierung liegt nicht mehr im IG. Die Seite Dosis Textgenerierung verweist auf das externe Repository; der Build bezieht den Algorithmus als über Tag und Prüfsumme gepinnte Version.
  • Die Seiten der Dosierschemata beschreiben jetzt durchgängig, welche frequency-, period- und periodUnit-Angaben optional zulässig sind und dass sie den erzeugten Text nicht verändern.

Release: 1.0.7

What's Changed

  • Fehlerkorrektur in der package.json
    • Behebung eines Fehlers im Feld url, der durch den Tooling-Workaround bei der Nutzung der alten SUSHI-Version entstanden ist.
    • Keine fachlichen Änderungen; das Release stellt lediglich sicher, dass die Abhängigkeiten unverändert zu Version 1.0.4 bleiben.

Release: 1.0.6

What's Changed

  • Technischer Rebuild von 1.0.5
    • Neu gebaut mit SUSHI 3.18.1, um zu verhindern, dass das Paket hl7.fhir.uv.xver-r5.r4#0.1.0 automatisch als Abhängigkeit aufgenommen wird.
    • Keine fachlichen Änderungen; das Release stellt lediglich sicher, dass die Abhängigkeiten unverändert zu Version 1.0.4 bleiben.

Release: 1.0.5

What's Changed

  • Fix für Timing-Schema-Mischungen mit dayOfWeek:
    • TimingDgMP: TimingOnlyWhenOrTimeOfDay
  • Erweiterte Negativbeispiele zur Absicherung gegen Schema-Mischung

Details

  • TimingOnlyWhenOrTimeOfDay (TimingDgMP)
    • Vom Fix betroffene Ressourcentypen: MedicationRequest, MedicationDispense, MedicationStatement
    • Fix: Die Einschränkung dayOfWeek.empty() wurde aus der Schema-Erkennung entfernt. Dadurch wird jetzt auch der Fall korrekt invalidiert, in dem innerhalb einer Ressource dayOfWeek + timeOfDay und dayOfWeek + when gemischt werden.
  • Testabdeckung für Mischformen von Dosierschemata
    • Für TimingOnlyWhenOrTimeOfDay wurden Negativbeispiele für alle drei Ressourcentypen um Fälle mit gesetztem dayOfWeek ergänzt.
    • Für TimingOnlyOneType wurden zusätzliche Negativbeispiele ergänzt, um Mischungen zusammengesetzter Schemata explizit abzudecken:
      • reines dayOfWeek gemischt mit dayOfWeek + when
      • reines dayOfWeek gemischt mit dayOfWeek + timeOfDay
      • reines Interval gemischt mit Interval + when
      • reines Interval gemischt mit Interval + timeOfDay
      • dayOfWeek + when gemischt mit reinem Interval
      • dayOfWeek + timeOfDay gemischt mit reinem Interval
      • dayOfWeek + when gemischt mit Interval + when
      • dayOfWeek + timeOfDay gemischt mit Interval + timeOfDay

Release: 1.0.4

What's Changed

  • Gefixte Invarianten:
    • DosageDE: DosageStructuredOrFreeTextWarning, DosageStructuredRequiresBoth, DosageDoseUnitSameCode
    • DosageDgMP: DosageStructuredOrFreeText
    • TimingDgMP: TimingOnlyOneType, TimingOnlyOneTimeForInterval, TimingOnlyOnePeriodForDayOfWeek

Details je Invariante

  • DosageStructuredOrFreeTextWarning (DosageDE)
    • Vom Fix betroffene Ressourcentypen: MedicationDispense, MedicationStatement
    • Fix: Fehlende %resource.-Präfixe vor ofType(...) ergänzt, damit die Regel in allen drei Ressourcentypzweigen korrekt evaluiert wird.
  • DosageStructuredRequiresBoth (DosageDE)
    • Vom Fix betroffene Ressourcentypen: MedicationDispense, MedicationStatement
    • Fix: Fehlende %resource.-Präfixe vor ofType(...) ergänzt, damit die wechselseitige Pflicht von timing und doseAndRate korrekt geprüft wird.
  • DosageDoseUnitSameCode (DosageDE)
    • Vom Fix betroffene Ressourcentypen: MedicationDispense, MedicationStatement
    • Fix: Ressourcentypspezifische Pfade im Ausdruck korrigiert; dadurch wird die Einheitengleichheit über alle Dosierungen je Ressource korrekt für Quantity und Range geprüft.
  • DosageStructuredOrFreeText (DosageDgMP)
    • Vom Fix betroffene Ressourcentypen: MedicationDispense, MedicationStatement
    • Fix: Analog zu DosageStructuredOrFreeTextWarning wurden fehlende %resource.-Präfixe ergänzt, damit Mischformen aus Freitext und Struktur verlässlich erkannt werden.
  • TimingOnlyOneType (TimingDgMP)
    • Vom Fix betroffene Ressourcentypen: MedicationDispense, MedicationStatement
    • Fix: Fehlende %resource.-Präfixe in den Unterbedingungen ergänzt; dadurch greifen die Typprüfungen (DayOfWeek, Interval, Kombinationsschemata) konsistent pro Ressource.
  • TimingOnlyOneTimeForInterval (TimingDgMP)
    • Vom Fix betroffene Ressourcentypen: MedicationStatement
    • Fix: In der MedicationStatement-Prüfung wurde eine logisch redundante und inhaltlich falsche Typbedingung entfernt; dadurch wird die Konsistenz von period/periodUnit auch für MedicationStatement tatsächlich geprüft (zusätzlich zur Einzigartigkeitsprüfung von timeOfDay/when).
  • TimingOnlyOnePeriodForDayOfWeek (TimingDgMP)
    • Vom Fix betroffene Ressourcentypen: MedicationRequest, MedicationDispense, MedicationStatement
    • Fix: Falsche Collection-vs-Integer-Vergleiche korrigiert (distinct().count() statt distinct()), damit doppelte (dayOfWeek + when/timeOfDay)-Kombinationen korrekt validiert werden.

Release: 1.0.3

What's Changed

  • Fix dosage dose unit same code by @patrick-werner in #106 to also support dosageRanges
  • Added guidance on backport extension usage and for defect tim-9 invariant

Release: 1.0.2

What's Changed

  • Fix: Update constraints and examples for DosageStructuredRequiresGeneratedText, maintain versioning in configuration

Release: 1.0.1

What's Changed

  • Fix dosage structured requires generated text constraint by @patrick-werner in #104
  • Updates from Publication Feedback by @patrick-werner in #105

Release: 1.0.0

What's Changed

  • Add ISiK as an example case in the Implementation Guide by @f-peverali in #39
  • Update schema-freitext.md by @f-peverali in #70
  • fix: correct punctuation in dosage text generation documentation by @patrick-werner in #79
  • refactor: update dosage terminology from 'Tablette' to 'Stück' in examples and descriptions by @patrick-werner in #72
  • fix: update link in dosage text generation documentation by @patrick-werner in #73
  • Fix der Timing Tabelle, Verbesserung des python scripts, HDB-650 by @patrick-werner in #74
  • feat: add invariant for structured dosage instructions requiring generated text by @patrick-werner in #75
  • fix: correct description of dosage timing bounds in TimingDgMP.fsh by @patrick-werner in #76
  • feat: made value in duration in TimingDgMP mandatory (1..1), added MS in TimingDE.fsh by @patrick-werner in #77
  • refactor: rename GematikDosageTextGenerator to DgMPDosageTextGenerator by @patrick-werner in #78
  • Add note to usage of dosage text script by @florianschoffke in #80
  • refactor: fix python indentation by @patrick-werner in #81
  • feat: set comparator on boundsDuration to 0..0 in TimingDgMP by @patrick-werner in #82
  • Add all 0..0 fields to deny lists in text generation script HDB-656 by @patrick-werner in #83
  • feat: add invariant for timing bounds unit string consistency with UCUM codes by @patrick-werner in #84
  • feat: fix TimingBoundsUnitMatchesCode invariant and add examples by @patrick-werner in #85
  • Add Examples for DosageStructuredRequiresGeneratedText by @florianschoffke in #86
  • fix: update dosage unit from 'Tablette' to 'Stück' for consistency across documentation by @patrick-werner in #87
  • fix: clarify mustSupport requirements for implementation and processing of elements by @patrick-werner in #88
  • refactor script by @florianschoffke in #89
  • Only one dosage by @patrick-werner in #90
  • Ig-page-for-script by @florianschoffke in #92
  • Skript für eine zusammenfassende Evaluierung der Dosierung by @florianschoffke in #93
  • added DosageFourSlotPatternInTextWarning & example by @patrick-werner in #91
  • feat: add FreeTextSingleDosageOnly invariant to enforce single dosage element in free text by @patrick-werner in #95
  • Update ext card and script by @patrick-werner in #94
  • Extract-script by @florianschoffke in #96
  • Set extension cardinality and add language support by @florianschoffke in #99
  • fix: update duration unit retrieval in medication dosage text generation by @patrick-werner in #103
  • docs: clarify prerequisites for text generation in dosage script by @patrick-werner in #102
  • 1.0.0 release by @patrick-werner in #98

Release: 1.0.0-ballot

Release for the first ballot: 1.0.0-ballot