3.869
Bearbeitungen
Änderungen
→Zeitangaben
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.
==Annahmen==
Dieser Implementierungsleitfaden wurde von der Arbeitsgruppe unter folgenden Annahmen erstellt: * Der Leitfaden spezifiziert das "Endprodukt", ein Patient Summary Dokument, das in Österreich allgemein und speziell in ELGA verwendet werden kann und alle Daten und Strukturen enthält, um es auch für den grenzüberschreitenden Austausch von Gesundheitsdaten zu nutzen. To Do: Erläuterung * Die Erstellung des Patient Summary Dokuments wurde bewusst weitgehend ausgeklammert.* Fragen der Herangehensweise Finanzierung der AGUmsetzung wurden nicht betrachtet.* Das Patient Summary definiert eine Struktur, die notwendig ist, zB warum welche 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 welcher Detailtiefeder 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, Erwartung an Datenquellen das Dokumentenmanagement und –qualitätdie Darstellung definiert. * Der Leitfaden nutzt soweit möglich bereits in anderen Leitfäden definierte strukturierte Inhaltselemente ("Templates")* Die in diesem Leitfaden definierten Templates sollen baugleich in anderen Dokumenten verwendet werden.* Die Templates werden in Art-Decor unter Nutzung des internationalen Template Standards modelliert, Prüfregeln ("Schematron") können direkt aus Art-Decor abgeleitet werden.
==Umgang mit codierten Informationen und Terminologien==
===Codierte Information===
Eine Prämisse des Patient Summary-Leitfadens ist eine durchgängige Maschinenlesbarkeit der einzelnen medizinischen Informationen. Dazu ist es notwendig, die Informationen mit codierten Konzepten auszudrücken ("Codierung"). Codierte Informationen erlauben eine Übersetzung in andere Sprachen ("Translation") und eine Überführung in andere Terminologien oder Codesysteme ("Transcodierung").
Die Datentypen für codierte Informationen werden in [[elga-cdaalf-2.06.2:Datentypen#Codierungs-Elemente| Allgemeiner Leitfaden: Codierte Elemente]] beschrieben.
Wenn die erwünschten Informationen nicht vorliegen oder nicht mit codierten Konzepten ausgedrückt werden können, kommen die im Folgenden vorgestellten Methoden zum Einsatz.
===Unbekannte und keine Information===
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 genutztweitgehend 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 in durch temporäre Platzhalter-Codes dargestellt, die alle mit 'X-' beginnen (z.B. X-AllergicDispositionNotKnown).
====Darstellung von unbekannter und bekannt fehlender Information im Text====
======Codebeispiel für den lesbaren Text======
Tabellarische Darstellung gilt auch für unbekannte und fehlende Informationen, Zusätzlich zusätzlich soll die Nicht-Information optisch hervorgehoben werden (Stylecode).
<pre class="orange">
</text>
</pre>
===Uncodierte Information===
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 mit in keiner bekannten Terminologie enthalten ist, beziehungsweise der Inhalt nicht codiert wurde.
Diese erste Situation wird mit dem folgenden Beispiel verdeutlicht.
</code>
</pre>
Für die Information ist kein geeigneter Code im vorgegebenen Codesystem vorhanden (im Beispiel ICD-10 BMGF 2018). Der konkrete Inhalt wird im Section-Text angegeben und vom Code-Element nur referenziert (value im reference-Element). Diese Variante kann für ''coding strength'' CNE (coded no extensions) eingesetzt werden. Der Elementname kann auch anders sein, zB Value.
Hinweis: Mit den zugrunde liegenden Datentpyen Datentypen (HL7 V3 Data Types R1) kann nicht angegeben werden, dass Codes zwar im Codesystem, aber nicht im referenzierten Value Set verfügbar sind. Spätere Versionen dieses Leitfadens können gegebenenfalls auf Data Types R2 aufbauen, mit denen um diese Angabe zu unterstützen.
<pre class="orange">
Im zweiten Beispiel wird der allgemeinste NullFlavor "NI" (No Information) verwendet; es gilt sowohl für ''coding strength'' CNE (coded no extensions) and CWE (coded with extensions). Wie im ersten Beispiel wird der konkrete Inhalt im Section-Text angegeben und vom Code-Element nur referenziert (value im reference-Element).
Die zweite Variante ist die häufiger eingesetzte Variante. Hinweis: Der geeignetste NullFlavor wäre eigentlich "UNC" (Uncoded), aber dieser NullFlavor ist aber in der RIM-Version, auf der HL7 CDA Rel.2 aufbaut, nicht verfügbar. Daher muss der allgemeinere NullFlavor "NI" (No Information) verwendet werden.
===Nicht zugeordnete codierte Information===
</pre>
Die eckigen Klammern deuten an, dass Elemente optional sind.
Hinweis: Mit den zugrunde liegenden Datentpyen (HL7 V3 Data Types R1) kann nicht angegeben werden, dass Codes zwar im Codesystem, aber nicht im referenzierten Value Set verfügbar sind. Spätere Versionen dieses Leitfadens können gegebenenfalls auf Data Types R2 aufbauen, mit denen um diese Angabe zu unterstützen.
Im Falle der ''coding strength'' CWE (coded with extensions) wird der nullFlavor "NI" vorgeschlagen und ebenso die Angabe des den korrekten Codes im <translation>-Teilelement. Dies ermöglicht die Angabe, dass eine Zuordnung zu dem Referenz-Value Set versucht wurde, aber keine geeigneten Zielcodes identifiziert wurden.
<pre class="orange">
<pre class="orange">
<value xsi:type="CD" code="422479008C50.9" codeSystem="1.2.16.84040.10.11388334.65.96171" codeSystemName="SNOMED CTICD-10 BMGF" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMABösartige Neubildung: Brustdrüse, STAGE 2nicht näher bezeichnet">
[
<originalText>
displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
</translation>
<translation code="422479008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2"/> </translation></value></pre>
Die eckigen Klammern deuten an, dass Elemente optional sind.
</pre>
Hinweis: Die R1 Datentyp-Definition versteht die <translation> nur als Mapping zwischen unterschiedlichen Codesystemen ("a set of other concept descriptors that translate this concept descriptor into other code systems"). Es hat sich aber die Interpretation durchgesetzt, dass auch dasselbe Konzept in mehreren Repräsentationen ausgedrückt werden kann, wie es einige Codesysteme (z.B. SNOMED CT erlauben).
==Mehrsprachigkeit==
Codierte Informationen können einfach in unterschiedlichen Sprachen ausgedrückt werden. Für einen zuverlässigen und sicheren grenzüberschreitenden Datenaustausch ([http://ec.europa.eu/health/ehealth/policy/network_en EU eHealth Network]) ist dies eine funktionelle Notwendigkeit.
Beispiel 1: Ohnne Ohne Code-Mapping
<pre class="orange">
<pre class="orange">
<value xsi:type="CD" code="42338000" codeSystem="2.16.840.1.113883.6.96"
displayName="Salmonella-gastroenteritgastroenteritis"> <ips:designation lang="da-DK" value=" Salmonella-gastroenteritgastroenteritis"/>
<ips:designation lang="en" value="Salmonella gastroenteritis (disorder)" type="FSN"/>
[
====Ü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 (FreitetxtFreitext, 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)
</section>
</pre>
==Herkunft der Information==
===Herkunftsangabe auf Section-Ebene===
Für jeden Dokumentationsabschnitt (Section) können jeweils mehrere Autoren und Informanten angegeben werden. Da die Zuordnung der Einzelinformation bei Angabe mehrerer Autoren und Informanten uneindeutig ist, wird empfohlen, die Herkunft auf Entry-Ebene anzugeben.
* Autor (PersonGesundheits-Fachperson, die die Information erstellt hat mit Name und Organisation).
* Informant (Person, auf deren Angabe die Information beruht: der Patient selbst oder eine dem Patienten verwandte oder bekannte Person)
===Herkunftsangabe auf Entry-Ebene===
* Autor (PersonGesundheits-Fachperson, die die Information erstellt hat mit Name und Organisation)
* Informant (Person, auf deren Angabe die Information beruht: der Patient selbst oder eine dem Patienten verwandte oder bekannte Person)
* Dokumentverweis (externalDocument): für jedes Entry kann eine ID angegeben werden, die auf ein externes Dokument verweist, aus dem die Information stammt.
==Zeitangaben==
Gemäß [[elga-cdaalf-2.06.2:Datentypen#Zeit-Elemente|Allgemeinem CDA-Leitfaden]] dürfen Zeitpunkte nur auf zweierlei Arten angegeben werden:
* '''Datum''' im Format '''YYYYMMDD'''
* '''Datum und Uhrzeit mit Zeitzone''' im Format '''YYYYMMDDhhmmss[+/-]HHMM'''
Ist nur eine eine weniger genaue Zeitangabe verfügbar, sind die fehlenden Stellen mit der Ziffer Null aufzufüllen. Also zum Beispiel ist für "September 2017" die Zeichenfolge 20170900 anzugeben. Die HL7 V3 Datentypen interpretieren Datumswerte so, als ob alle möglichen, aber nicht angegebenen Stellen mit 0 befüllt wären.
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:
<pre class="orange">
<low value="20171201"/>
<high value="20171202"/>
</pre>
Für mehr Klarheit empfiehlt sich daher die zusätzliche Angabe der Zeit mit Zeitzone:
<pre class="orange">
<low value="20171201000000+0100"/>
<high value="20171201235959+0100"/>
</pre>
