Appendix

Aus Hl7wiki
(Teildokument von Medikationsplan)
Wechseln zu: Navigation, Suche
 
(15 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
 
{{DocumentPart}}
 
{{DocumentPart}}
−
=Appendix (nicht normativ)=
+
=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.
 
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 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.
 
* es ist nicht spezifisch genug, was zu Missinterpretation der Softwarehersteller führt.
 
* es stellt keine moderne Schnittstellenbeschreibung dar und unterlag keiner formalen Konsentierung, z.B. nach ISO/TR 28380-1:2014<ref>ISO/TR 28380-1:2014 Health informatics -- IHE global standards adoption -- Part 1: Process, http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63383</ref>
 
* es stellt keine moderne Schnittstellenbeschreibung dar und unterlag keiner formalen Konsentierung, z.B. nach ISO/TR 28380-1:2014<ref>ISO/TR 28380-1:2014 Health informatics -- IHE global standards adoption -- Part 1: Process, http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63383</ref>
 
* es nutzt keine gängigen IT-Standards
 
* es nutzt keine gängigen IT-Standards
−
* es nutzt kaum offizielle Terminologien, die meisten Kode-Listen sind proprietär
+
* es nutzt kaum offizielle Terminologien, die meisten Kode-Listen sind proprietär; in der jüngsten vorliegenden Fassung sind Kodes selbst überwiegend verbannt, was zu weiteren Problemen führen kann
 
* als proprietäres Format kann es nur in diesem Kontext verwendet werden, eine Interoperabilität mit anderen Anwendungen (selbst AMTS-Anwendungen zum Beispiel) ist schwer herzustellen
 
* als proprietäres Format kann es nur in diesem Kontext verwendet werden, eine Interoperabilität mit anderen Anwendungen (selbst AMTS-Anwendungen zum Beispiel) ist schwer herzustellen
 
* es ist abzusehen, dass die Implementierung dieses Formats vermeidbare Kosten verursacht.
 
* es ist abzusehen, dass die Implementierung dieses Formats vermeidbare Kosten verursacht.
  
 
Hinzu kommen noch grundsätzlich orientierte Probleme, die bei der Umsetzung von proprietären Formaten zu erwarten sind:
 
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.
 
#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.
 
#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.
  
−
Aus diesen Gründen wird auch im NRW-Projekt vom technischen teil abgesehen und das dort entwickelte Ultrakurzformat XML verwendet.
+
Aus diesen Gründen wird auch im NRW-Projekt vom technischen Teil abgesehen und das dort entwickelte Ultrakurzformat XML verwendet.
 +
 
 +
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 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="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==
 
==Aspekte zur Mehrsprachigkeit==
Zeile 41: Zeile 46:
  
 
Dabei ist Folgendes zu beachten: Es ist untersagt, den amtlichen ATC-Index mit DDD-Angaben darüber hinausgehend – auch nur teilweise –für andere Zwecke, insbesondere für kommerzielle Zwecke zu nutzen, Änderungen oder Manipulationen im amtlichen ATC-Index mit DDD-Angaben vorzunehmen. Der Nutzer ist verpflichtet, bei wissenschaftlichen Veröffentlichungen und insbesondere bei wissenschaftlich genutzten abgeleiteten Werken in digitaler Form an prominenter Stelle folgenden Hinweis zu platzieren „Datenquelle des amtlichen ATC-Index mit DDD-Angaben: GKV-Arzneimittelindex im Wissenschaftlichen Institut der AOK (WIdO), AOK Bundesverband GbR Stand „Datum““. Der Nutzer verpflichtet sich dem Wissenschaftlichen Institut der AOK (WIdO) etwaige Publikationen, die auf der Anwendung der Daten des GKV-Arzneimittelindex basieren, dem WIdO unverzüglich nach der Veröffentlichung in zwei Exemplaren unentgeltlich zur Verfügung zu stellen und gegebenenfalls eine Lizenz zur kostenfreien Nutzung der Datenbank zur Verfügung zu stellen.
 
Dabei ist Folgendes zu beachten: Es ist untersagt, den amtlichen ATC-Index mit DDD-Angaben darüber hinausgehend – auch nur teilweise –für andere Zwecke, insbesondere für kommerzielle Zwecke zu nutzen, Änderungen oder Manipulationen im amtlichen ATC-Index mit DDD-Angaben vorzunehmen. Der Nutzer ist verpflichtet, bei wissenschaftlichen Veröffentlichungen und insbesondere bei wissenschaftlich genutzten abgeleiteten Werken in digitaler Form an prominenter Stelle folgenden Hinweis zu platzieren „Datenquelle des amtlichen ATC-Index mit DDD-Angaben: GKV-Arzneimittelindex im Wissenschaftlichen Institut der AOK (WIdO), AOK Bundesverband GbR Stand „Datum““. Der Nutzer verpflichtet sich dem Wissenschaftlichen Institut der AOK (WIdO) etwaige Publikationen, die auf der Anwendung der Daten des GKV-Arzneimittelindex basieren, dem WIdO unverzüglich nach der Veröffentlichung in zwei Exemplaren unentgeltlich zur Verfügung zu stellen und gegebenenfalls eine Lizenz zur kostenfreien Nutzung der Datenbank zur Verfügung zu stellen.
 +
 +
===Pharmazentralnummern===
 +
Informationsstelle für Arzneispezialitäten (IFA)
  
 
==Projektträger und -kontributoren==
 
==Projektträger und -kontributoren==
−
{| class="hl7table" border="0"
+
{| class="hl7table" border="0" cellpadding="2"
 
|-
 
|-
 
| width=300px valign=top | Ärztekammer Nordrhein
 
| width=300px valign=top | Ärztekammer Nordrhein
Zeile 64: Zeile 72:
 
|-
 
|-
 
| valign=top |ART-DECOR Expert Group
 
| valign=top |ART-DECOR Expert Group
−
| style="background:#fff;" |[[Datei:Art-Decor-Logo.png|150px]]
+
| style="background:#fff;" |[[Datei:Art-Decor-Logo.jpg|150px]]
 
|}
 
|}

Aktuelle Version vom 3. August 2017, 17:38 Uhr

Dieses Material ist Teil des Leitfadens Medikationsplan.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Appendix (nicht normativ)

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

Die „Bundeseinheitlicher Medikationsplan“[1] 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 in der Fassung vor 2016 ist die Definition eines proprietären Formats, das nur hierfür zusammengestellt wurde. Nach Analysen (unter anderem in [2]) 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 [2])
  • es ist nicht spezifisch genug, was zu Missinterpretation der Softwarehersteller führt.
  • es stellt keine moderne Schnittstellenbeschreibung dar und unterlag keiner formalen Konsentierung, z.B. nach ISO/TR 28380-1:2014[3]
  • es nutzt keine gängigen IT-Standards
  • es nutzt kaum offizielle Terminologien, die meisten Kode-Listen sind proprietär; in der jüngsten vorliegenden Fassung sind Kodes selbst überwiegend verbannt, was zu weiteren Problemen führen kann
  • als proprietäres Format kann es nur in diesem Kontext verwendet werden, eine Interoperabilität mit anderen Anwendungen (selbst AMTS-Anwendungen zum Beispiel) ist schwer herzustellen
  • es ist abzusehen, dass die Implementierung dieses Formats vermeidbare Kosten verursacht.

Hinzu kommen noch grundsätzlich orientierte Probleme, die bei der Umsetzung von proprietären Formaten zu erwarten sind:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Aus diesen Gründen wird auch im NRW-Projekt vom technischen Teil abgesehen und das dort entwickelte Ultrakurzformat XML verwendet.

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 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[4] entspricht.

Aspekte zur Mehrsprachigkeit

In Deutschland leben laut einem Bericht der Bundesregierung[5] ca. 20% Ausländer oder Deutsche mit Migrationshintergrund. Um sprachlichen Problemen abzuhelfen, setzen daher einige Leistungserbringer mit ihren Medikationsplänen im Routinebetrieb auf mehrsprachige Ausdrucke, vor allem in Bezug auf die Patientenhinweise und –instruktionen (vgl. [6]).

Voraussetzung für eine korrekte Zuordnung und Interoperabilität der einzelnen Angaben in einem Medikationsplan ist eine weit gehende Kodierung der Angaben, Hinweise und Instruktionen. Mit der Version vom 18. Dezember 2014 hat allerdings die Koordinierungsgruppe der Arzneimittelkommission der deutschen Ärzteschaft beschlossen, gerade diese Kodierungen (zunächst) aus der Spezifikation zu streichen.

Die Hersteller von Software, insbesondere Arzneimitteldatenbank-Anbieter, haben bereits Listen solcher Angaben, Hinweise und Instruktionen – teilweise auch mehrsprachig – und könnten somit wertvolle Beiträge bei der Aufstellung solcher in Deutschland einheitlicher Kataloge (Listen) leisten. Wenn diese Listenelemente entsprechend kodiert und einheitlich zur Verfügung stehen würden, käme man optimalen Möglichkeiten von mehrsprachigen Medikationsplänen ein großes Stück näher.

Lizenzen

HL7

Health Level Seven® International (HL7) standards and other "Material," as defined below, and Material acquired through any channel (including through any HL7 Affiliate) are governed by the terms of this HL7 policy. All such Material are copyrighted by HL7 and protected by the Copyright Law of the United States and copyright provisions of various international treaties. See HL7 Policy governing the use of HL7® international standards and other intellectual property at http://www.hl7.org/legal/ippolicy.cfm

Logical Observation Identifiers Names and Codes LOINC

This material contains content from LOINC® (http://loinc.org). The LOINC table, LOINC codes, and LOINC panels and forms file are copyright © 1995-2014, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and available at no cost under the license at http://loinc.org/terms-of-use.

SNOMED Clinical Terms® (SNOMED CT®)

This material includes SNOMED Clinical Terms® (SNOMED CT®) which may not be used without permission of the International Health Terminology Standards Development Organisation (IHTSDO). All rights reserved. SNOMED CT®, was originally created by The College of American Pathologists. “SNOMED” and “SNOMED CT” are registered trademarks of the IHTSDO.

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.

Dabei ist Folgendes zu beachten: Es ist untersagt, den amtlichen ATC-Index mit DDD-Angaben darüber hinausgehend – auch nur teilweise –für andere Zwecke, insbesondere für kommerzielle Zwecke zu nutzen, Änderungen oder Manipulationen im amtlichen ATC-Index mit DDD-Angaben vorzunehmen. Der Nutzer ist verpflichtet, bei wissenschaftlichen Veröffentlichungen und insbesondere bei wissenschaftlich genutzten abgeleiteten Werken in digitaler Form an prominenter Stelle folgenden Hinweis zu platzieren „Datenquelle des amtlichen ATC-Index mit DDD-Angaben: GKV-Arzneimittelindex im Wissenschaftlichen Institut der AOK (WIdO), AOK Bundesverband GbR Stand „Datum““. Der Nutzer verpflichtet sich dem Wissenschaftlichen Institut der AOK (WIdO) etwaige Publikationen, die auf der Anwendung der Daten des GKV-Arzneimittelindex basieren, dem WIdO unverzüglich nach der Veröffentlichung in zwei Exemplaren unentgeltlich zur Verfügung zu stellen und gegebenenfalls eine Lizenz zur kostenfreien Nutzung der Datenbank zur Verfügung zu stellen.

Pharmazentralnummern

Informationsstelle für Arzneispezialitäten (IFA)

Projektträger und -kontributoren

Ärztekammer Nordrhein Aekno.jpg
Ärztekammer Westfalen-Lippe Aekwl.jpg
Ministerium für Gesundheit, Emanzipation, Pflege und Alter des Landes Nordrhein-Westfalen, Düsseldorf Mgepa.jpg
Hochschule Niederrhein, Krefeld Hsn.jpg
HL7 Deutschland e. V. Logo-hl7.jpg
Interoperabilitätsforum Logo-interoperabilitaetsforum.png
ART-DECOR Expert Group Art-Decor-Logo.jpg
  1. ↑ Referenzfehler: Es ist ein ungültiger <ref>-Tag vorhanden: Für die Referenz namens mpakdae20 wurde kein Text angegeben.
  2. ↑ 2,0 2,1 F. Oemig: AKdÄ-Medikationsplan - Felder aus dem AKdÄ-Medikationsplan, Grammatik und Probleme, http://wiki.hl7.de/index.php/IG:AKdÄ-Medikationsplan#Anhang
  3. ↑ ISO/TR 28380-1:2014 Health informatics -- IHE global standards adoption -- Part 1: Process, http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63383
  4. ↑ Addendum zum Implementierungsleitfaden Patientenbezogener Medikationsplan: Ultrakurzformat für kapazitätslimitierte Datenträger (UKFPMP) http://wiki.hl7.de/index.php?title=IG:Ultrakurzformat_Patientenbezogener_Medikationsplan
  5. ↑ 10. Bericht der Beauftragten der Bundesregierung für Migration, Flüchtlinge und Integration über die Lage der Ausländerinnen und Ausländer in Deutschland (Oktober 2014)
  6. ↑ Referenzfehler: Es ist ein ungültiger <ref>-Tag vorhanden: Für die Referenz namens heidelberg2014 wurde kein Text angegeben.
Abgerufen von „https://wiki.hl7.de/index.php?title=cdamedp:Appendix&oldid=41754“