elga-cdaps-2.06.2:Grundsätze und Regeln - Versionsgeschichte

Klostermann: /* Zeitangaben */

2018-07-17T11:57:37Z

‎Zeitangaben

Klostermann: /* Zeitangaben */

2018-07-17T11:56:44Z

‎Zeitangaben

Klostermann: /* Übersetzung des narrativen Textes */

2018-07-17T11:22:19Z

‎Übersetzung des narrativen Textes

Klostermann: /* Allgemeines */

2018-07-17T11:10:20Z

‎Allgemeines

Klostermann: /* Annahmen */

2018-07-17T11:07:45Z

‎Annahmen

Klostermann: /* Unbekannte und keine Information */

2018-07-17T11:04:42Z

‎Unbekannte und keine Information

Sabutsch: /* Uncodierte Information */

2018-06-28T13:28:19Z

‎Uncodierte Information

Lahnsteiner: Lahnsteiner verschob die Seite Ps-Grundsätze und Regeln nach elga-cdaps-2.06.2:Grundsätze und Regeln und überschrieb dabei eine Weiterleitung: zurück verschieben

2018-04-19T07:16:18Z

Lahnsteiner verschob die Seite Ps-Grundsätze und Regeln nach elga-cdaps-2.06.2:Grundsätze und Regeln und überschrieb dabei eine Weiterleitung: zurück verschieben

Lahnsteiner: Lahnsteiner verschob die Seite elga-cdaps-2.06.2:Grundsätze und Regeln nach Ps-Grundsätze und Regeln

2018-04-18T11:00:22Z

Lahnsteiner verschob die Seite elga-cdaps-2.06.2:Grundsätze und Regeln nach Ps-Grundsätze und Regeln

Sabutsch am 5. Januar 2018 um 14:32 Uhr

2018-01-05T14:32:41Z

@@ Zeile 284: / Zeile 284: @@
 Achtung bei Zeitintervallen:
-Ein Datum, das mit yyyymmdd angegeben wurde, wird standardgemäß interpretiert als yyyymmdd000000 – also der Tag um 0:00:00 Uhr. Wenn also als Zeitraum z.B.: der ganze 1.Dezember 2017 angegeben werden soll, MUSS das so erfolgen:
+Ein Datum, das mit yyyymmdd angegeben wurde, wird standardgemäß interpretiert als yyyymmdd000000 – also der Tag um 0:00:00 Uhr. Wenn also als Zeitraum z.B.: der ganze 1. Dezember 2017 angegeben werden soll, MUSS das so erfolgen:
 <pre class="orange">

@@ Zeile 284: / Zeile 284: @@
 Achtung bei Zeitintervallen:
-Ein Datum, das mit yyyymmdd angegeben wurde, wird standardgemäß interpretiert als yyyymmdd000000 – also der Tag um 0:00:00 Uhr. Wenn also als Zeitraum z.B.: der ganze 1.Dezember 2013 angegeben werden soll, MUSS das so erfolgen:
+Ein Datum, das mit yyyymmdd angegeben wurde, wird standardgemäß interpretiert als yyyymmdd000000 – also der Tag um 0:00:00 Uhr. Wenn also als Zeitraum z.B.: der ganze 1.Dezember 2017 angegeben werden soll, MUSS das so erfolgen:
 <pre class="orange">

@@ Zeile 235: / Zeile 235: @@
 ====Übersetzung des narrativen Textes====
 Bei einer Übersetzung eines Dokuments muss vor allem der lesbare Text in anderen Sprachen dargestellt werden können. Die Übersetzung muss dazu bereits im Dokument vorhanden sein, wobei die Übersetzung von einer Person durchgeführt werden kann oder aber automatisch aus den maschinenlesbaren Elementen abgeleitet werden kann.
-Bei der Darstellung muss (a) die Sprache der Ausgabe identifiziert werden und (b) angegeben werden, ob es sich um das Original handelt oder die Übersetzung. Außerdem sollte die Quelle (Freitext, maschinenlesbare Elemente) und Art der Übersetzung (Übersetzer, automatisch, ...) angegeben werden.
+Bei der Darstellung muss (a) die Sprache der Ausgabe identifiziert werden und (b) angegeben werden, ob es sich um das Original handelt oder die Übersetzung. Außerdem sollte die Quelle (Freitext, maschinenlesbare Elemente) und Art der Übersetzung (Übersetzer, automatisch, etc.) angegeben werden.
 Die hier verwendete Methode enthält das Original im <text>-Element der Section und die optionalen Übersetzungen in einem <text>-Element einer Subsection, wobei pro Übersetzung eine Subsection angegeben wird. (specified in template 2.16.840.1.113883.10.22.3.15)

← Nächstältere Version		Version vom 17. Juli 2018, 11:10 Uhr
Zeile 3:		Zeile 3:


−	~~Dieser~~ Dokument spezifiziert eine HL7 CDA R2 Implementierung, ist aber in den Grundzügen kompatibel mit dem FHIR-Standard. In einigen Fällen folgt es eher der FHIR Stilistik, um Konzepte zu repräsentieren und weicht daher von der in CDA bzw HL7 Version 3 üblichen Art ab. Das betrifft hauptsächlich die Mechanismen für Negation, unbekannte und fehlende Informationen (NullFlavors).	+	Dieses Dokument spezifiziert eine HL7 CDA R2 Implementierung, ist aber in den Grundzügen kompatibel mit dem in Entwicklung befindlichen FHIR-Standard. In einigen Fällen folgt es eher der FHIR Stilistik, um Konzepte zu repräsentieren und weicht daher von der in CDA bzw HL7 Version 3 üblichen Art ab. Das betrifft hauptsächlich die Mechanismen für Negation, unbekannte und fehlende Informationen (NullFlavors).

	Um grenzüberschreitend austauschbar und verständlich zu sein, muss das Patient Summary so weit wie möglich auf strukturierte Daten und mehrsprachige internationale Referenzterminologien stützen, die für das Patient Summary ohne Kosten für die globale Nutzung lizenziert werden.		Um grenzüberschreitend austauschbar und verständlich zu sein, muss das Patient Summary so weit wie möglich auf strukturierte Daten und mehrsprachige internationale Referenzterminologien stützen, die für das Patient Summary ohne Kosten für die globale Nutzung lizenziert werden.

@@ Zeile 18: / Zeile 18: @@
 * Die Erstellung des Patient Summary Dokuments wurde bewusst weitgehend ausgeklammert.
 * Fragen der Finanzierung der Umsetzung wurden nicht betrachtet.
-* Das Patient Summary definiert eine Mindeststruktur, um Daten elektronisch und automatisch in anderen GDA-IT-Systemen weiterzuverarbeiten, zu aggregieren und zu übersetzen. Die Arbeitsgruppe hat die Vorgaben im Bewusstsein definiert, dass die notwendigen Quelldaten nicht immer vorliegen, und wenn sie vorliegen, nicht immer in der erforderlichen Struktur und Detailgenauigkeit. Das Patient Summary dient als "Leuchtturm", um künftige Dokumentationen entsprechend diesem Mindeststandard anzupassen.
+* Das Patient Summary definiert eine Struktur, die notwendig ist, um Daten elektronisch und automatisch in anderen GDA-IT-Systemen weiterzuverarbeiten, zu aggregieren und zu übersetzen. Die Arbeitsgruppe hat die Vorgaben im Bewusstsein definiert, dass die notwendigen Quelldaten nicht immer vorliegen, und wenn sie vorliegen, nicht immer in der erforderlichen Struktur und Detailgenauigkeit. Das Patient Summary dient als "Leuchtturm", um künftige Dokumentationen entsprechend diesem Mindeststandard anzupassen.
 * Der Leitfaden bezieht sich auf die allgemeinen ELGA-Richtlinien für Dokumente (Allgemeiner CDA-Implementierungsleitfaden). Damit werden die Mechanismen für den Austausch, das Dokumentenmanagement und die Darstellung definiert.
 * Der Leitfaden nutzt soweit möglich bereits in anderen Leitfäden definierte strukturierte Inhaltselemente ("Templates")

@@ Zeile 31: / Zeile 31: @@
 ===Unbekannte und keine Information===
-Nicht immer können für bestimmte erwünschte Inhalte (Erkrankungen, Zustände, Eigenschaften, ... ) auch tatsächlich Angaben gemacht werden. Der Leitfaden unterscheidet dabei zwischen zwei Situationen:
+Nicht immer können für bestimmte erwünschte Inhalte (Erkrankungen, Zustände, Eigenschaften, etc.) auch tatsächlich Angaben gemacht werden. Der Leitfaden unterscheidet dabei zwischen zwei Situationen:
 * Der erwünschte Inhalt ist unbekannt (z.B. wenn die Medikation eines Patienten unbekannt ist)
 * Der erwünschte Inhalt liegt bekanntlich nicht vor (z.B. wenn der Patient tatsächlich keine Medikamente einnimmt)
 Spezifischere Formen abwesender Information oder Negation wurden nicht als relevant erachtet, wie zum Beispiel die Abwesenheit einer Allergie auf ein bestimmtes Antigen, der Ausschluss einer bestimmten Krankheit oder die Tatsache, dass eine bestimmte Impfung nicht durchgeführt wurde.
-Für die semantische Repräsentation dieser Situationen werden SNOMED-CT-Codes verwendet; die sonst in CDA üblichen Mechanismen (nullFlavor, negationInd) werden hier nicht genutzt. So sollen die Inhalte unabhängig von einem bestimmten technischen Standard ausgedrückt werden, die Implementierungen robuster und einfacher gemacht sowie die Transformation in andere Standards wie z.B. FHIR erleichtert werden.
+Für die semantische Repräsentation dieser Situationen werden SNOMED-CT-Codes verwendet; die sonst in CDA üblichen Mechanismen (nullFlavor, negationInd) werden hier weitgehend vermieden. So sollen die Inhalte unabhängig von einem bestimmten technischen Standard ausgedrückt werden, die Implementierungen robuster und einfacher gemacht sowie die Transformation in andere Standards wie z.B. FHIR erleichtert werden.
 In einigen Fällen fehlen zum Zeitpunkt der Erstellung des Leitfadens die benötigten SNOMED-CT-Konzepte, z. B. "Allergische Disposition nicht bekannt (Situation)". Diese Konzepte wurden bereits beantragt und harren der Aufnahme in eine zukünftige Version von SNOMED CT International Edition. Zwischenzeitlich werden diese Konzepte durch temporäre Platzhalter-Codes dargestellt, die alle mit 'X-' beginnen (z.B. X-AllergicDispositionNotKnown).

@@ Zeile 75: / Zeile 75: @@
 Bei der Erstellung des Dokumentes können möglicherweise bestimmte Informationen vorliegen, die nicht codiert werden können, weil
 # die Information nicht mit den im Leitfaden zugelassenen Terminologien (Value Sets) dargestellt werden kann oder
-# die Information in keiner bekannten Terminologie enthalten ist.
+# die Information in keiner bekannten Terminologie enthalten ist, beziehungsweise der Inhalt nicht codiert wurde.
 Diese erste Situation wird mit dem folgenden Beispiel verdeutlicht.

← Nächstältere Version	Version vom 19. April 2018, 07:16 Uhr
(kein Unterschied)

← Nächstältere Version	Version vom 18. April 2018, 11:00 Uhr
(kein Unterschied)

@@ Zeile 286: / Zeile 286: @@
 Ein Datum, das mit yyyymmdd angegeben wurde, wird standardgemäß interpretiert als yyyymmdd000000 – also der Tag um 0:00:00 Uhr. Wenn also als Zeitraum z.B.: der ganze 1.Dezember 2013 angegeben werden soll, MUSS das so erfolgen:
-   <low value="20131201"/>
+<pre class="orange">
-   <high value="20131202"/>
+   <low value="20171201"/>
 Für mehr Klarheit empfiehlt sich daher die zusätzliche Angabe der Zeit mit Zeitzone:
+<pre class="orange">
-   <low value="20131201000000+0100"/>
+   <low value="20171201000000+0100"/>
-   <high value="20131201235959+0100"/>
+   <high value="20171201235959+0100"/>