cdamedp:Appendix - Versionsgeschichte

Wikiadmin am 3. August 2017 um 17:38 Uhr

2017-08-03T17:38:30Z

Wikiadmin am 3. August 2017 um 17:38 Uhr

2017-08-03T17:38:06Z

Wikiadmin: /* Projektträger und -kontributoren */

2017-08-03T17:33:26Z

‎Projektträger und -kontributoren

Wikiadmin: /* Kritische Anmerkungen zur Spezifikation des Medikationsplans der AkdÄ in der alten Fassung (vor 2016) */

2017-08-03T15:56:03Z

‎Kritische Anmerkungen zur Spezifikation des Medikationsplans der AkdÄ in der alten Fassung (vor 2016)

Wikiadmin: /* Lizenzen */

2017-08-03T15:26:44Z

‎Lizenzen

Wikiadmin: /* Lizenzen */

2017-08-03T15:25:55Z

‎Lizenzen

Wikiadmin: /* Anmerkungen zur Spezifikation des Medikationsplans laut §291a bzw. nach § 31a in der Fassung ab April 2016 */

2017-08-03T15:21:04Z

‎Anmerkungen zur Spezifikation des Medikationsplans laut §291a bzw. nach § 31a in der Fassung ab April 2016

Wikiadmin: /* Anmerkungen zur Spezifikation des Medikationsplans laut §291a in der Fassung ab April 2016 */

2017-08-03T15:17:05Z

‎Anmerkungen zur Spezifikation des Medikationsplans laut §291a in der Fassung ab April 2016

Wikiadmin: /* Kritische Anmerkungen zur Spezifikation des Medikationsplans der AkdÄ in der alten Fassung (vor 2016) */

2017-08-03T15:15:47Z

‎Kritische Anmerkungen zur Spezifikation des Medikationsplans der AkdÄ in der alten Fassung (vor 2016)

Wikiadmin: /* Appendix (nicht normativ) */

2017-08-03T15:13:03Z

‎Appendix (nicht normativ)

@@ Zeile 72: / Zeile 72: @@
 |-
 | valign=top |ART-DECOR Expert Group
-| style="background:#fff;" |[[Datei:Art-Decor-Logo.png|150px]]
+| style="background:#fff;" |[[Datei:Art-Decor-Logo.jpg|150px]]
 |}

@@ Zeile 1: / Zeile 1: @@
 {{DocumentPart}}
 =Appendix (nicht normativ)=
 ==Kritische Anmerkungen zur Spezifikation des Medikationsplans der AkdÄ in der alten Fassung (vor 2016) ==
 Die „Bundeseinheitlicher Medikationsplan“<ref name="mpakdae20"/> genannte '''Spezifikation in der Fassung vor 2016''' besteht im Grunde aus zwei Teilen: den Dokumentation der medizinisch-inhaltlichen Vorgaben und der technischen Beschreibung eines Formates zur Unterbringung der Informationen auf einem Barcode.

@@ Zeile 51: / Zeile 51: @@
 ==Projektträger und -kontributoren==
-{| class="hl7table" border="0"
+{| class="hl7table" border="0" cellpadding="2"
 |-
 | width=300px valign=top | Ärztekammer Nordrhein

@@ Zeile 16: / Zeile 16: @@
 Hinzu kommen noch grundsätzlich orientierte Probleme, die bei der Umsetzung von proprietären Formaten zu erwarten sind:
-#Um die Daten aus einer Anwendung in die beschriebene Form zu bringen ('''Serialisierung''') ist ein spezialistischer Generator nötig. Diesen muss jedes Softwareunternehmen entweder selber schreiben oder er wird von Ihrer Seite zur Verfügung gestellt. Es ist unbekannt, ob ein solcher Generator für die Serialisierung frei verfügbar ist.
+#Um die Daten aus einer Anwendung in die beschriebene Form zu bringen ('''Serialisierung''') ist ein spezieller Generator nötig. Diesen muss jedes Softwareunternehmen entweder selber schreiben oder er wird von Ihrer Seite zur Verfügung gestellt. Es ist unbekannt, ob ein solcher Generator für die Serialisierung frei verfügbar ist.
-#Um die Daten, die in dieser Syntax eingebettet sind, wieder auslesen zu können, z. B. um sie weiterzuverwenden, muss von jedem Anbieter von Software ein spezialistischer und '''robuster Parser''' programmiert bzw. eingesetzt werden. Der Parser verwandelt die serialisierte Form wieder in Datenobjekte der lesenden Anwendung um, damit diese weiterverwendet oder geändert und in eine neue Version des Plans für den Patienten umgesetzt werden können. Es ist unbekannt, ob ein solcher Parser frei verfügbar ist. Parser müssen robust sein, weil man davon ausgehen muss, dass nicht alle Serialisierungen korrekt sind und man eine Chance haben muss, dies auch zu entdecken.
+#Um die Daten, die in dieser Syntax eingebettet sind, wieder auslesen zu können, z. B. um sie weiterzuverwenden, muss von jedem Anbieter von Software ein spezieller und '''robuster Parser''' programmiert bzw. eingesetzt werden. Der Parser verwandelt die serialisierte Form wieder in Datenobjekte der lesenden Anwendung um, damit diese weiterverwendet oder geändert und in eine neue Version des Plans für den Patienten umgesetzt werden können. Es ist unbekannt, ob ein solcher Parser frei verfügbar ist. Parser müssen robust sein, weil man davon ausgehen muss, dass nicht alle Serialisierungen korrekt sind und man eine Chance haben muss, dies auch zu entdecken.
 #Für die Sicherstellung, ob ein Datensatz in dieser Syntax formal korrekt serialisiert ist braucht man einen '''Validator''' der die Regeln der Syntax überprüft. Dazu ist es auch nötig, die zugrundeliegende Grammatik formal zu beschreiben, zum Beispiel in der üblichen Backus-Naur-Form. Ohne Validator, der auch Bestandteil des Parsers sein kann, ist eine Garantie darauf, dass die Daten korrekt wiedergegeben und wiederverwendet werden können nicht gegeben. Eine Zertifizierung ist ohne Validator äußerst schwierig.
 #Die Syntax mischt zuweilen Anweisungen zum Druck für die Papierfassung mit den eigentlichen Daten. Ein Parser muss diese Druckinstruktionen aus der Serialisierung holen, denn diese können sich bei veränderten Daten natürlich auch ändern. Üblich ist Struktur und Präsentation zu trennen.

@@ Zeile 44: / Zeile 44: @@
 ===Amtlicher ATC-Index mit DDD-Angaben===
 Das Wissenschaftliche Institut der AOK (WIdO) erteilte am 1. Dezember 2014 die Genehmigung zur unentgeltlichen Nutzung des amtlichen ATC-Index mit DDD-Angaben, der jeweils zum Stichtag 1. Januar eines Jahres in Kraft tritt und auf der Homepage http://www.wido.de/amtl_atc-code.html veröffentlicht wird, zur Verwendung in Projekten zum Medikationsplan.
 ===Pharmazentralnummern===
 Informationsstelle für Arzneispezialitäten (IFA)
 ==Projektträger und -kontributoren==

@@ Zeile 26: / Zeile 26: @@
 ==Anmerkungen zur Spezifikation des Medikationsplans laut §291a bzw. nach § 31a in der Fassung ab April 2016==
-Inzwischen wurde die technische Repräsentierung der Information im Barcode derart geändert, so dass sie dem (leicht angepassten) Ultrakurzformat <ref name="ukf" /> entspricht.
+Inzwischen wurde die technische Repräsentierung der Information im Barcode derart geändert, so dass sie dem (leicht angepassten) Ultrakurzformat<ref name="ukfpmp">Addendum zum Implementierungsleitfaden Patientenbezogener Medikationsplan: Ultrakurzformat für kapazitätslimitierte Datenträger (UKFPMP) http://wiki.hl7.de/index.php?title=IG:Ultrakurzformat_Patientenbezogener_Medikationsplan</ref> entspricht.
 ==Aspekte zur Mehrsprachigkeit==

@@ Zeile 25: / Zeile 25: @@
 Des Weiteren muss als Kritikpunkt angeführt werden, dass das Wiedergabeformat des Medikationsplans der AkdÄ eine Insellösung darstellt, die in keiner Weise interoperabel zu anderen Anforderungen ist. So stellt die Wiederverwendung von Medikationsdaten – selbst in domänenzugehörigen Anwendungen zur Arzneimitteltherapiesicherheit AMTS, erst recht in domänenabgelegenen Anwendungen wie zum Beispiel im Rahmen eines Ärztlichen Entlassbriefs oder von der Dokumentation von Notfalldaten – eine unbillige Hürde dar.
-==Anmerkungen zur Spezifikation des Medikationsplans laut §291a in der Fassung ab April 2016==
+==Anmerkungen zur Spezifikation des Medikationsplans laut §291a bzw. nach § 31a in der Fassung ab April 2016==
 Inzwischen wurde die technische Repräsentierung der Information im Barcode derart geändert, so dass sie dem (leicht angepassten) Ultrakurzformat <ref name="ukf" /> entspricht.

← Nächstältere Version		Version vom 3. August 2017, 15:15 Uhr
Zeile 24:		Zeile 24:

	Des Weiteren muss als Kritikpunkt angeführt werden, dass das Wiedergabeformat des Medikationsplans der AkdÄ eine Insellösung darstellt, die in keiner Weise interoperabel zu anderen Anforderungen ist. So stellt die Wiederverwendung von Medikationsdaten – selbst in domänenzugehörigen Anwendungen zur Arzneimitteltherapiesicherheit AMTS, erst recht in domänenabgelegenen Anwendungen wie zum Beispiel im Rahmen eines Ärztlichen Entlassbriefs oder von der Dokumentation von Notfalldaten – eine unbillige Hürde dar.		Des Weiteren muss als Kritikpunkt angeführt werden, dass das Wiedergabeformat des Medikationsplans der AkdÄ eine Insellösung darstellt, die in keiner Weise interoperabel zu anderen Anforderungen ist. So stellt die Wiederverwendung von Medikationsdaten – selbst in domänenzugehörigen Anwendungen zur Arzneimitteltherapiesicherheit AMTS, erst recht in domänenabgelegenen Anwendungen wie zum Beispiel im Rahmen eines Ärztlichen Entlassbriefs oder von der Dokumentation von Notfalldaten – eine unbillige Hürde dar.
		+
		+	==Anmerkungen zur Spezifikation des Medikationsplans laut §291a in der Fassung ab April 2016==
		+	Inzwischen wurde die technische Repräsentierung der Information im Barcode derart geändert, so dass sie dem (leicht angepassten) Ultrakurzformat <ref name="ukf" /> entspricht.

	==Aspekte zur Mehrsprachigkeit==		==Aspekte zur Mehrsprachigkeit==

@@ Zeile 1: / Zeile 1: @@
 {{DocumentPart}}
 =Appendix (nicht normativ)=
-==Kritische Anmerkungen zur Spezifikation des Medikationsplans der AkdÄ ==
+==Kritische Anmerkungen zur Spezifikation des Medikationsplans der AkdÄ in der alten Fassung (vor 2016) ==
-Die inzwischen „Bundesmedikationsplan“<ref name="mpakdae20"/> genannte Spezifikation besteht im Grunde aus zwei Teilen: den Dokumentation der medizinisch-inhaltlichen Vorgaben und der technischen Beschreibung eines Formates zur Unterbringung der Informationen auf einem Barcode.
+Die „Bundeseinheitlicher Medikationsplan“<ref name="mpakdae20"/> genannte '''Spezifikation in der Fassung vor 2016''' besteht im Grunde aus zwei Teilen: den Dokumentation der medizinisch-inhaltlichen Vorgaben und der technischen Beschreibung eines Formates zur Unterbringung der Informationen auf einem Barcode.
 Der erste Teil stellt die gut erfasste, konsentierte und dokumentierte nationale Vorgabe dar. Diese Angaben sollen als inhaltlicher Ausgangspunkt für einen einheitlichen Medikationsplan angesehen werden und sind – wie bereits erwähnt – die Grundlage für die hier vorliegende Spezifikation des Patientenbezogenen Medikationsplans.
-Die technische Beschreibung ist die Definition eines proprietären Formats, das nur hierfür zusammengestellt wurde. Nach Analysen (unter anderem in <ref name="oemigmp"/>) offenbaren sich jedoch eine Reihe von Problemen des Formats:
+Die technische '''Beschreibung in der Fassung vor 2016''' ist die Definition eines proprietären Formats, das nur hierfür zusammengestellt wurde. Nach Analysen (unter anderem in <ref name="oemigmp"/>) offenbaren sich jedoch eine Reihe von Problemen des Formats:
 * es weist technische und inhaltliche Fehler auf, die zugrundeliegende Grammatik ist in der vorliegenden Definition problematisch (siehe auch <ref name="oemigmp">F. Oemig: AKdÄ-Medikationsplan - Felder aus dem AKdÄ-Medikationsplan, Grammatik und Probleme, http://wiki.hl7.de/index.php/IG:AKdÄ-Medikationsplan#Anhang</ref>)
 * es ist nicht spezifisch genug, was zu Missinterpretation der Softwarehersteller führt.