cdaab2:Konformität - Versionsgeschichte

Maschhoff: /* Konformität */

2015-07-01T08:01:11Z

‎Konformität

Foemig am 18. Juni 2015 um 14:35 Uhr

2015-06-18T14:35:00Z

Foemig am 29. Januar 2014 um 17:12 Uhr

2014-01-29T17:12:25Z

Foemig: Die Seite wurde neu angelegt: „{{DocumentPart}} ==Konformität== Ein zu diesem Implementation Guide konformer Arztbrief ist zunächst ein valides CDA Release 2 XML-Dokument mit Header und B…“

2013-11-29T10:28:41Z

Die Seite wurde neu angelegt: „{{DocumentPart}} ==Konformität== Ein zu diesem Implementation Guide konformer Arztbrief ist zunächst ein valides CDA Release 2 XML-Dokument mit Header und B…“

Neue Seite

{{DocumentPart}}

==Konformität==
Ein zu diesem Implementation Guide konformer Arztbrief ist zunächst ein valides CDA Release 2 XML-Dokument mit Header und Body. Ein kon¬former "stationärer Entlassbrief" kann weiterhin fehlerfrei gegen das CDA Schema (xsd) validiert werden und erfüllt außerdem alle „Geschäftsregeln" im weiteren Text dieses Dokuments.

Dies spiegelt ein generelles Konzept im Umgang mit Dokumenten (und Nachrichten) wieder: die '''Validierung in zwei Schritten'''. Im ersten Schritt stellt dies die Validierung gegen zugehörige W3C Schemas dar. Das zum Arztbrief gehörige Schema ist das unveränderte generische, offizielle CDA Release 2 Schema (siehe Anhang 8.1). Darüber hinaus sind eine Reihe von Schematron Skripts denkbar (und im Rahmen dieses Leitfadens auch erstellt), die für einen zweiten „Validierungsschritt" genutzt werden und letztlich die Detailregelungen in diesem Leitfaden wiedergeben sowie die Einhaltung der Geschäftsregeln sicherstellen können. Diese Schritte werden auch als Templates bezeichnet, allgemeine Arbeiten zu diesem Thema sind zurzeit in Gange, jedoch noch nicht abgeschlossen, so dass wir hier auf bewährte Techniken (W3C Schema und Schematron) zurückgreifen.
Eine XML-Instanz, die kein valides CDA-Dokument ist oder sich nicht gegen das XSD-Schema validieren lässt, oder im Widerspruch zu den angegebenen Geschäftsregeln steht, ist kein gültiger Arztbrief im Sinne dieses Implementierungsleitfadens.

Die hier verwendeten Constraints basieren zum Teil auf extern kontrollierten Vokabularen, die sich nach Verabschiedung dieses Implementierungsleitfadens ändern könnten.

Solange der HL7-Template-Formalismus noch in Arbeit ist, ermöglicht CDA die Identifikation der verwendeten Templates bzw Implementation Guides vom CDA-Dokument aus mittels eines eindeutigen – noch von SCIPHOX zu vergebenden – Identifikators. Der Einsatz von so genannten „temp¬lateId" Elementen sichert zu, dass eine CDA-Instanz nicht nur CDA-konform ist, sondern auch dem referenzierten Template oder Implementierungsleitfaden entspricht. Mit Zusicherung ist dabei nur eine informelle Behauptung des Verfassers gemeint und nicht notwendigerweise auch eine erfolgreich durchgeführte Validierung bzw. Zertifizierung.

[[Kategorie:cdaab2|Konformität]]

@@ Zeile 2: / Zeile 2: @@
 ==Konformität==
-Ein zu diesem Implementation Guide konformer Arztbrief ist zunächst ein valides CDA Release 2 XML-Dokument mit Header und Body. Ein konformer "stationärer Entlassbrief" kann weiterhin fehlerfrei gegen das CDA Schema (xsd) validiert werden und erfüllt außerdem alle „Geschäftsregeln" im weiteren Text dieses Dokuments.
+Ein zu diesem Implementierungsleitfaden (engl. Implementation Guide) konformer Arztbrief ist zunächst ein valides CDA Release 2 XML-Dokument mit Header und Body. Ein konformer "stationärer Entlassbrief" kann weiterhin fehlerfrei gegen das CDA Schema (xsd) validiert werden und erfüllt außerdem alle „Geschäftsregeln" im weiteren Text dieses Dokuments.
 Dies spiegelt ein generelles Konzept im Umgang mit Dokumenten (und Nachrichten) wieder: die '''Validierung in zwei Schritten'''. Im ersten Schritt stellt dies die Validierung gegen zugehörige W3C Schemas dar. Das zum Arztbrief gehörige Schema ist das unveränderte generische, offizielle CDA Release 2 Schema (siehe Anhang). Darüber hinaus sind eine Reihe von Schematron Skripts denkbar (und im Rahmen dieses Leitfadens auch erstellt), die für einen zweiten „Validierungsschritt" genutzt werden und letztlich die Detailregelungen in diesem Leitfaden wiedergeben sowie die Einhaltung der Geschäftsregeln sicherstellen können. Diese Schritte werden auch als Templates bezeichnet, allgemeine Arbeiten zu diesem Thema sind zurzeit in Gange, jedoch noch nicht abgeschlossen, so dass wir hier auf bewährte Techniken (W3C Schema und Schematron) zurückgreifen.

@@ Zeile 9: / Zeile 9: @@
 Die hier verwendeten Constraints basieren zum Teil auf extern kontrollierten Vokabularen, die sich nach Verabschiedung dieses Implementierungsleitfadens ändern könnten.
-Solange der HL7-Template-Formalismus noch in Arbeit ist, ermöglicht CDA die Identifikation der verwendeten Templates bzw Implementation Guides vom CDA-Dokument aus mittels eines eindeutigen – noch von SCIPHOX zu vergebenden – Identifikators. Der Einsatz von so genannten „templateId" Elementen sichert zu, dass eine CDA-Instanz nicht nur CDA-konform ist, sondern auch dem referenzierten Template oder Implementierungsleitfaden entspricht. Mit Zusicherung ist dabei nur eine informelle Behauptung des Verfassers gemeint und nicht notwendigerweise auch eine erfolgreich durchgeführte Validierung bzw. Zertifizierung.
+CDA ermöglicht die Identifikation der verwendeten Templates mithilfe eines eindeutigen Identifikators. Der Einsatz von so genannten „templateId" Elementen sichert zu, dass eine CDA-Instanz nicht nur CDA-konform ist, sondern auch dem referenzierten Template oder Implementierungsleitfaden entspricht. Mit Zusicherung ist dabei nur eine informelle Behauptung des Verfassers gemeint und nicht notwendigerweise auch eine erfolgreich durchgeführte Validierung bzw. Zertifizierung.
 [[Kategorie:cdaab2|Konformität]]