bedingtes Pflichtfeld/bedingtes MS: Alle von einem Server bereitgestellten Ressourcen MÜSSEN über eine id verfügen. Von Clients erzeugte Ressourcen, die im Kontext einer CREATE-Interaktion übermittelt werden, MÜSSEN NICHT über eine idverfügen.

Begründung des Must-Support: Folgeinformation der AMTS-Bewertung, sollte auch an nachfolgende Behandelnde übermittelbar sein

Hinweis: Hier kann ein im Rahmen der Medikation festgestelltes, aber in Kauf genommenes Risiko dokumentiert werden, speziell auch die Begründung und ggf. erforderliche Begleitmaßnahmen.

Begründung des Must-Support: von der Fachseite gewünschte Angabe

Hinweis: Angabe Akut- oder Dauermedikation.

Begründung des Must-Support: von der Fachseite gewünschte Angabe

Hinweis: Freitext-Beschreibung des Behandlungsziels.

Begründung des Must-Support: historische Nachvollziehbarkeit ersetzter Verordnungen.

Hinweis: Diese Extension dient der Abbildung einer Verordnung, die eine vorherige Medikation ersetzt - z.B. bei Unverträglichkeit, mangelnder Wirksamkeit oder Wechsel des Wirkstoffs.
Abgrenzung: Im Gegensatz zum Feld 'priorPrescription', das eine Folgeverordnung bei fortgesetzter Therapie beschreibt, kennzeichnet diese Extension eine bewusste Ablösung der ursprünglichen Verordnung.

Begründung des Must-Support: Erforderliche Angabe im FHIR-Standard.

Hinweis für Implementierende: Im Falle einer create-Operation kann der Server den .code in .status zunächst auf 'on-hold' setzen, z. B. im Falle einer asynchronen Prüfung, die im Rahmen einer textuellen Übergabe möglich ist. Ggf. kann hier zusätzlich ein Mechanismus etabliert werden, der eine anschließende Änderung des Status an den Client kommuniziert. Der Server kann zusätzlich den .code in .statusReason auf 'clarif' setzen ('Clarification is required before the order can be acted upon.'), um anzuzeigen, dass eine Klärung erforderlich ist, bevor die Verordnung ausgeführt werden kann.

Begründung des Must-Support: Erforderliche Angabe im FHIR-Standard

Hinweis: i.d.R. 'order'

Begründung des Must-Support: Basisinformation

Hinweis: kann verwendet werden, wenn keine detaillierten Informationen zum Medikament (z.B. Rezepturen) existieren.

Mehrfachcodierung ist zulässig, da für ein abstraktes Medikament auch mehrere PZN-Codes existieren können, z. B. existieren für Aspirin 3 verschiedene Packungsgrößen.

Mehrfachcodierung ist zulässig, da für ein abstraktes Medikament auch mehrere ATC-Codes existieren können, z. B. existieren für Aspirin 4 verschiedene Codes, je nachdem wofür das Medikament angewendet wird.

Begründung des Must-Support: Basisinformation

Hinweis: wird verwendet, wenn detaillierte Informationen zum Medikament vorliegen

Begründung des Must-Support: Basisinformation

Begründung MS: Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung der Dokumentation zu einem Patienten und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc. Im ISik Kontext MUSS die referenzierte Ressource konform zu ISiKPatient sein. Jenseits von ISiK KÖNNEN weitere Instanzen mit anderen Profilen referenziert werden.

Begründung des Must-Support: Basisinformation im Krankenhaus-Kontext

Begründung MS: Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc. Im ISik Kontext MUSS die referenzierte Ressource konform zu ISiKKontaktGesundheitseinrichtung sein. Jenseits von ISiK KÖNNEN weitere Instanzen mit anderen Profilen referenziert werden.

Begründung des Must-Support: Basisinformation

Begründung des Must-Support: Nachvollziehbarkeit

Festlegung zum MS: Die Elemente .reasonCode und .reasonReference MÜSSEN nach OR-Logik in der Ausgabe verwendet werden, d.h. nur eines MUSS geliefert werden können. Weiterhin MÜSSEN beide Elemente interpretiert werden können. Begründung zu Must-Support: Konsolidierung mit MII Profil: https://www.medizininformatik-initiative.de/fhir/core/modul-medikation/StructureDefinition/MedicationRequest

Begründung des Must-Support: Falls der Grund kodierbar ist, sollte er auch kodiert werden.

Begründung des Must-Support und Kardinalität: Ein Coding Element benötigt immer ein System um die Bedeutung des Codes zu definieren.

Begründung des Must-Support und Kardinalität: Ein Coding Element benötigt immer einen Code um die Bedeutung des Codes zu definieren.

Begründung des Must-Support: Ein Display Element ist für die Lesbarkeit der Information notwendig.

Festlegung zum MS: Die Elemente .reasonCode und .reasonReference MÜSSEN nach OR-Logik in der Ausgabe verwendet werden, d.h. nur eines MUSS geliefert werden können. Weiterhin MÜSSEN beide Elemente interpretiert werden können. Begründung zu Must-Support: Konsolidierung mit MII.

Begründung des Must-Support: Referenz auf die Diagnose oder Untersuchung, die die Medikation begründet.

Begründung des Must-Support: Angabe zusätzlicher Informationen kann fachlich relevant sein

Begründung des Must-Support: Basisinformation. Zur vollständig strukturierten Abbildung der zahlreichen Möglichkeiten sind die hier mit Must-Support gekennzeichneten Unterelemente erforderlich gemäß Konsens der ISiK AG Medikation.

Hinweis: Zahlreiche Beispiele zur Dosierungsanweisung sind im Implementierungsleitfaden Medikament von HL7 Deutschland dokumentiert.

Das Must-Support-Flag auf rateRatio bzw. rateQuantity bedeutet, dass produzierende Systeme zur Kodierung der Ratenangaben nach eigenem Ermessen entweder den Datentyp Ratio oder Quantity verwenden KÖNNEN. Beim Empfang und Verarbeitung der eingehenden Daten MÜSSEN dagegen beide Datentypen interpretiert werden können.

Das Must-Support-Flag auf rateRatio bzw. rateQuantity bedeutet, dass produzierende Systeme zur Kodierung der Ratenangaben nach eigenem Ermessen entweder den Datentyp Ratio oder Quantity verwenden KÖNNEN. Beim Empfang und Verarbeitung der eingehenden Daten MÜSSEN dagegen beide Datentypen interpretiert werden können.

Begründung des Must-Support: Basisinformation

Begründung des Must-Support: Alignment mit dem (E-)Rezept