ASK identifiziert den Wirkstoff und ist daher als Code-Kodierung einer Medikation ungeignet.

Als Vergleich: Die ISIK-Spezifikation sieht im Medikationsmodul 4 eine Kodierung von ASK unter ingredient.itemCodeableConcept vor, nicht jedoch unter Code.

<span class="nobr"><a href="https://simplifier.net/guide/isik-medikation-v4/ImplementationGuide-markdown-Datenobjekte-Profile_Medikament?version=current" class="external-link" rel="nofollow">https://simplifier.net/guide/isik-medikation-v4/ImplementationGuide-markdown-Datenobjekte-Profile_Medikament?version=current^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Hier bitte mit ISIK harmonisieren.

Die ATC-WiDO-Versionen unterscheiden sich von der amtlichen ATC-DE-Version
Daher die Bitte um eine Bereitstellung des ATC-WiDO-Codes samt Jahresversionierung,
wie vom Wissenschaftlichen Institut der AOK bereitgestellt (siehe Link). <span class="nobr"><a href="https://www.wido.de/publikationen-produkte/analytik/arzneimittel-klassifikation/?L=0" class="external-link" rel="nofollow">https://www.wido.de/publikationen-produkte/analytik/arzneimittel-klassifikation/?L=0^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Die Informationen im dgMP sind insbesondere beim Übergang von medizinischer zu pflegender Unterstützung von Menschen relevant und damit auch für die ambulant oder stationär Pflegenden.

Zur Medikation sollten die Pflegenden direkt an sie gerichtete Informationen erhalten.

Dies könnte beispielsweise mittels der zusätzlichen Attribute .nursingInstruction (das Medikament betreffend) und .additionalInstruction (den Kontext der Medikamentengabe betreffend) erfolgen. (Beide analog zu .note).

Gemäß §355 Abs. 3 SGB V „Bei der Fortschreibung der Vorgaben zum elektronischen Medikationsplan hat die Kassenärztliche Bundesvereinigung die Festlegungen nach § 31a Absatz 4 und § 31b Absatz 2 zu berücksichtigen und sicherzustellen, dass Daten nach § 31a Absatz 2 Satz 1 sowie Daten des elektronischen Medikationsplans nach § 334 Absatz 1 Satz 2 Nummer 4 in den von den Vertragsärzten und den Ärzten in zugelassenen Krankenhäusern zur Verordnung genutzten elektronischen Programmen und in den Programmen der Apotheken einheitlich abgebildet und zur Prüfung der Arzneimitteltherapiesicherheit genutzt werden können.“
Die Referenzierung auf die Referenzdatenbank ist sicherzustellen. Dies dient auch einer einheitlichen Darstellung von Daten zu Fertigarzneimitteln und dem Austausch in Europa gemäß § 219d SGB V.

In Bezug auf Arzneimitteldaten muss auch das europäische Datenmodell (SPOR) als Standard zu verwenden sein, welches in DE über die AmAnDa-Datenbank umgesetzt ist. Die Referenzdatenbank nach §31b SGB V wird seit dem 01.04. Vom BfArM, aus der AmAnDa-DB zur Verfügung gestellt. Diese Arbeiten werden auch in Arbeiten zum Terminologieserver einfließen. Insb. vor dem Hintergrund des europäischen Datenaustausches sollten rein nationale Lösungen vermieden werden.

Das FHIR ValueSet "KBV_VS_MIO_EMP_Dose_Form_SNOMED_CT" beinhaltet lediglich eine Expansion, es existiert jedoch keine Valueset-Definition (ValueSet.compose). Alternative Expansions lassen sich somit nicht mehr automatisiert generieren. Wir empfehlen für sämtliche ValueSets, die Bestandteil einer Spezifikation sind auch die Definition mit anzugeben.

Für eine vollständige und sicher Darstellung einer Verordnung ist neben dem Name des Arzneimittels/Wirkstoff, der Formulierung, der Stärke des Formulierten Arzneimittels, auch der Applikationsweg notwendig.
Im aktuellen Medikationsplan und vielen Resourcen wird nur auf Formulierung des Arzneimittels hingewiesen und der Applikationsweg extrapoliert.
Bestimmte Formulierungen könne über verschieden Applikationswege geben werden z.B. oral, buccal oder Magensonde, oral oder IV und SC

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.timing
nicht auf "must support" gesetzt werden. Stattdessen sollte ein zusätzliches Textfeld aufgenommen werden, welche "must support" ist (vergleiche .additionalInstruction)

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.

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.additionalInstruction.coding
nicht auf "must support" gesetzt werden. Lediglich
.dosage.additionalInstruction.text
sollte "must support" 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.

Hier bei Medication.text sowie bei allen anderen eMP-Profilen sollte auf das Hinzufügen von .text-Elementen (oder ähnlichen Felder) verzichtet werden, die die inhaltliche Aussage der Felder einer FHIR-Ressource noch einmal menschenlesbar zusammenfassen.
Die FHIR-Ressourcen werden IMMER durch Apps interpretiert und zur Anzeige gebracht. Keine FHIR-Ressource wird in Rohformat heruntergeladen und von Endnutzern betrachtet werden.
Daher sind inhaltliche Redundanzen (text-Zusammenfassungen zu Summe aller Codierungen in einer Ressource) nur Aufwandstreiber für eine Umsetzung sowie Fehlerquelle für auseinanderlaufende Informationen.
Daher sollte auf solch zusammenfassende, ergänzende Felder grundsätzlich verzichtet werden (Redundanzfreiheit ist ein Grundprinzip in der Datenbanktechnik).

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