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.
* Die Erstellung des Patient Summary Dokuments wurde bewusst weitgehend ausgeklammert.
* Fragen der Finanzierung der Umsetzung wurden nicht betrachtet.
* 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")
* 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.
===Unbekannte und fehlende Informationenkeine 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 nimmt tatsächlich keine Medikamente eineinnimmt)
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. Das soll So sollen die Inhalte unabhängig von einem bestimmten technischen Standard machenausgedrückt werden, die Implementierungen robuster und einfacher machen gemacht sowie die Transformation in andere Standards wie z.B. FHIR erleichternerleichtert werden.
In einigen Fällen fehlten 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====
Unbekannte und fehlende Information soll auch im menschenlesbaren Text (section.text) einheitlich dargestellt werden. Folgende Textbausteine sind VERPFLICHTEND zu verwenden:
* '''Es liegt keine Information über [X] vor''' (Bedeutung: die Informationen über [X] wurden nicht erhoben, können nicht erhoben werden oder sind nicht verfügbar)
* '''Keine [X]''' (Bedeutung: Es gibt tatsächlich keine Informationen über [X] oder [X] liegt nachweislich nicht vor.)
======Anwendungsbeispiele======
Es liegt keine Information über Allergien oder Intoleranzen vor:<br />
[[Datei:Textbaustein Keine.png|Es wurden keine Impfungen durchgeführt]]
======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">
</pre>
==Codierte Information==Siehe IPS Design Conventions and Principles ==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===
Bei der Erstellung des Dokumentes können möglicherweise bestimmte Informationen codiert in der Quelldokumentation vorliegen, aber die Codes sind nicht in den im Leitfaden zugelassenen Terminologien (Value Sets) verfügbar.
</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">
Die eckigen Klammern deuten an, dass Elemente optional sind.
===Zugeordnete codierte Information (Übersetzung)===
Es kann vorkommen, dass bestimmte Informationen codiert in der Quelldokumentation vorliegen, aber in einer anderen Terminologie als vom Leitfaden zugelassen. Wenn die codierten Konzepte korrekt von der einen in die andere Terminologie zugeordnet werden können (also "übersetzt" oder "gemappt"), ist es erlaubt, auch die originalen Codes zusätzlich anzugeben.
<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.
</code>
</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).
==Translation of designations 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.
<pre class="orange">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Patient Summary">
<ips:designation lang="en" value="Patient Summary"/>
</code>
</pre>
<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"/>
[
displayName="Gastroenterite da Salmonella"/>
</value>
</pre>
Die eckigen Klammern deuten an, dass Elemente optional sind.
Beispiel:
<pre class="orange">
<section>
<templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
</component>
</section>
==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>