Für Medikationen, die komplexe Dosierungsschemata aufweisen, sollte zusätzlich oder alternativ zu den strukturierten Informationen im Attribut .dosage, weitere Begleitinformation mittels Anhang zur Verfügung gestellt werden können (z.B: .dosageAttachment). Als mögliche Dateiformate bieten sich ggf. PDF/A oder ein einfaches standardisiertes Textformat wie z.B. MarkDown an.

Das in FHIR R4 spezifizierte Element "category" ist derzeit nicht Teil der MIO-Spezifikation enthalten. Es enthält ein preferred Binding auf die "Medication usage category codes" von HL7, im folgenden: "inpatient", "outpatient", "community" (für Pflegeeinrichtungen und Hospize) und "patientspecified" für z.B. OTC.

<span class="nobr"><a href="https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/79011" class="external-link" rel="nofollow">https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/79011^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Eine korrekte Annotation, welches Medikament aus welchem Setting heraus genommen wurde, ist in der Spezifikation sonst nicht möglich. Die derzeitigen Entwicklungen wie Ambulantisierung etc. müssen bereits zeitnah in sektorübergreifenden Forschungsfragen untersucht werden, daher ist eine explizite Kodierung des Settings von Nutzen.

In vielen FHIR-Profilierungen des MIOs Medikationsplan besteht die Möglichkeit für die Coding-Elemente Kodes aus unterschiedlichen Kodiersystemen zu hinterlegen. Aus der Profilierung und den vorliegenden Beschreibungen geht jedoch nicht hervor für welche Gesundheits- bzw. Medikationsinformation sich welches Kodiersystem am besten eignet. Damit eine eindeutige Kodierung der Informationen gewährleistet werden kann, empfehlen wir das Hinzufügen von Kurzbeschreibungen zu den jeweiligen Kodiersystemen. Beispielsweise könnten Informationen, wie die Kurzbeschreibung und Definition direkt im Profil auf Simplifier hinterlegt werden.

Es wird nicht ersichtlich, ob sich .note an andere Heilberufler oder an den Patienten richten soll.
Für eine zielgruppenkonforme Kommunikation erscheint es notwendig, dass zwei getrennte Informationen für getrennte Zielgruppen hinterlegt werden können:
1. An den Patienten (siehe EMP1X0X0-124)
2. An die mitbehandelnden Ärzte, Apotheker, Pfleger

#2 ist relevant, um Informationen wie "Bewusste Gabe trotz Wechselwirkungswarnung, wegen ..." hinterlegen zu können, damit andere Ärzte z.B. wissen, dass eine Medikation trotz eines AMTS-Hinweises bewusst erfolgte - und entsprechend NICHT korrigiert werden soll. Auch weitere Hinweise zu für diesen Patienten schlechteren Alternativen (Einschränkung bei Schluckleistung, daher Warnung vor Substitution z.B. durch Rabattverträgen oder Klinikmedikation) sollten hier aufgenommen werden können. Im Sinne der asynchronen, gemeinschaftlichen Behandlung eines Patienten.

All dies lässt sich über .note abbilden. Es sollte nur deutlicher herausgestellt werden, dass .note genau dafür gedacht ist. Diese deutlichen Festlegungen sind wichtig, damit das Feld in seiner Semantik für die Versorgung verstanden und in Folge von allen Herstellern (PVS, AVS, KIS, ePA-App) gleich verwendet wird.

Die Informationen im dgMP sind über die ePA-App auch für den Patienten bzw. für den ihn familiär Betreuenden relevant.
Zur Medikation dieses Medikaments, ist es daher sinnvoll, dem Patienten direkt an ihn gerichtete Informationen mit zu geben.

A)
Aktuell ist vorgesehen, dass zu jeder der n möglichen Dosierungsangaben innerhalb eines Medikationsstatements sowohl eine .dosage.patientInstruction (Einnahme, Lagerung, Anwendung) als auch eine .dosage.additionalInstruction (z.B. "mit den Mahlzeiten") gespeichert werden kann.
Es erscheint unwahrscheinlich, dass sich diese Informationen an den Patienten in den unterschiedlichen Dosierangaben unterscheiden werden.
Daher wäre es sowohl für die Umsetzung als auch für die Verständlichkeit zielführender, wenn .patientInstruction und .additionalInstruction nicht als Unterelemten unter .dosage, sondern als Elemente direkt unter MedicationStatement. verortet werden sollten.

B)
Die an den Patienten (oder seinen Betreuer) zu gebenden Begleitinformationen sind gelegentlich umfangreicher als nur eine Textzeile. Daher wäre es hilfreich, wenn
1. neben der Option auf reinen Text auch Markdown zulässig wäre
2. neben der Option auf Text auch ein Attachment mitgegeben werden könnte (PDF/A)

Insbesondere die Möglichkeit für ein Attachment wäre ausgesprochen hilfreich (und notwendig), um zielgerichtet, niederschwellig und einfach in der technischen Umsetzung, dem Patienten (seinem Begleiter) aufbereitete begleitende Informationen zukommen lassen zu können. Heute werden dem Patienten, z.B. in der Rheumatologie, Begleit-A4 mitgegeben, worauf er bei der Einnahmetherapie des Medikaments zu achten hat. Dies muss strukturiert erfolgen, in Tabellenform, teilweise mit Grafiken oder Illustrationen. Solche Informationen werden arztseitig bislang maximal als PDF erzeugt und bereitgestellt. Diese Informationen sollten im dgMP im Interesse der Patienten mit hinterlegt werden können.

Die aktuellen Festlegungen zu .dosage.maxDosePerPeriod sind für interoperable Implementierungen (von >200 Herstellern) noch nicht ausreichend detailliert.
Auch deshalb sollte für die erste Ausbaustufe daher auf eine textuelle Beschreibung zurückgegriffen werden.

Im Detail:
.dosage.maxDosePerPeriod.numerator
Definiert nicht, welches Codesystem verwendet werden soll. Dies ist zwingend festzulegen. Unter .code wird KBV_VS_SFHIR_BMP_DOSIEREINHEIT lediglich empfohlen. Aus dieser Empfehlung sollte eine Festlegung mit fixen Werte für .system und als zwingendes Valueset für .code werden.

.dosage.maxDosePerPeriod.denominator
Besitzt weder normative Festlegung noch eine Empfehlung, wie die Zeiteinheit codiert werden soll. Hier muss .system und das Valueset für .code festgelegt werden.

Wie an anderer Stelle auch: Abgesehen von den fehlenden Festlegungen für eine interoperable Umsetzung bei allen Herstellern, reicht die Zeit bis zum 15.07.25 nicht für komplexe Geschäftslogiken und Benutzeroberflächen aus.
Daher sollte unter .dosage.maxDosePerPeriod ein zusätzliches Element .text 0..1 string aufgenommen werden, in dem - wie bei .asNeeded - die maximale Dosis per Zeitraum als Fließtext eingetragen werden kann, wie als Beispiel ausgeführt:
"2 Tabletten alle 4 Stunden bis zu einem Maximum von 8/Tag".

Um die Umsetzungskomplexität für die erste Ausbaustufe bis 15.07.25 zu begrenzen (und damit den Terminplan erreichbar zu halten), sollten die Elemente des Knotens
.dosage.asNeeded<span class="error">[x]</span>:asNeededCodeableConcept.coding
nicht auf "must support" gesetzt werden. Insbesondere, da die dort für .code zu verwendenden Werte noch kein ValueSet besitzen und diese für dort sinnvolle Werte von allen Herstellern erst einmal ermittelt werden müssten - was aus Gründen der Interoperabilität bei ziemlich sicher unterschiedlichen Wertemengen wenig hilfreich wäre.
Stattdessen sollte lediglich das Textfeld
.dosage.asNeeded<span class="error">[x]</span>:asNeededCodeableConcept.text
weiterhin mit "must support" versehen bleiben.

Die Umsetzung der Auscodierung erfordert sehr viel Aufwand für die Oberflächensteuerung im PVS und der ePA-App, sowie in der "Umrechung" für die Anzeige der kodierten Werte.
Dies sollte erst für eine zweite Umsetzungsstufe vorgesehen werden.

MedicationStatement sieht mit .identifier:zeilenId die Referenz auf eine Ressource dar, die (sehr aufwändig) lediglich die Zeilennummer festlegen soll, mit der das MedikationsStatement innerhalb des eMP dargestellt werden soll - wobei dort eine UUID statt einer Zeilennummer definiert wird und nicht klar wird, wie eine solche UUID als Zeilennummer interpretiert werden soll.

Das Konzept der Zeilennummern ist im Grobkonzept der gematik zum dgMP nicht abgebildet.

Das Konzept der Zeilennummern sollte grundsätzlich überdacht werden. Grundsätzlich wäre es deutlich sinnvoller, wenn keinerlei Semantik in der Anordnung der Medikationen innerhalb einer Visualisierung eines Plans enthalten wäre. Vielmehr muss jede Zeile informationstechnisch in sich geschlossen sein, bzw. auf gegebenenfalls relevante Informationen per Referenz verweisen.
So können Pläne in ihrer Darstellungsreihenfolge je nach Bedarf erzeugt werden (Einnahmezeitpunkte, Wirkgruppen, etc.)
Eine semantische Aussage durch eine ZeilenID sollte daher strickt unterlassen werden.

Unter
MedicationStatement.extension:behandlungsziel
soll eingetragen werden:
"Die Referenz soll eine Instanz der Ressource KBV_Base_Treatment_Goal sein."

Eine solche Profildefinition KBV_Base_Treatment_Goal ist jedoch (noch) nicht zu finden.
Ferner muss sichergestellt werden, dass die seitens gematik definierten Operationen für dgMP die Übertragung dieses Ressourcentyps zulassen.

alle überschriebenen Felder (must support, fixed values, etc) sollten auch eine Description/short description enthalten
-meta

• meta.versionId
• meta.lastUpdated
• meta.profile
• meta.profile.mioProfile
• text.status
• medication.medicationReference.reference
• subject
• informationSource
• informationSource.reference
• informationSource.identifier
• dosage.timing