elga-cdaps-2.06.2:Grundsätze und Regeln

1 Grundsätze und Regeln

1.1 Allgemeines

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).

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.

Im Falle von SNOMED CT wird erwartet, dass die IHTSDO (SNOMED International) und die Republik Österreich, vertreten durch das Bundesministerium für Gesundheit und Frauen, eine Vereinbarung treffen werden, um den Einsatz von SNOMED CT für den Einsatz in Österreich zu ermöglichen. In diesem Sinne wird SNOMED CT als bevorzugte Terminologie und für die Mehrheit der Wertmengen (Value Sets) verwendet.

Andere bevorzugte Terminologien, die in dieser Spezifikation verwendet werden, sind LOINC für Beobachtungen (z.B. Labortests) und Dokumentabschnitte (Sections), UCUM für Maßeinheiten und EDQM für Dosisformen und Einnahmearten.

Diese Spezifikation verwendet das HL7-Template-Austauschformat [1] und ART-DECOR® [www.art-decor.org] als Spezifikationsplattform. Nutzer dieses Leitfadens können die IPS-Projektseite in ART-DECOR® besuchen, um die Template-Spezifikationen zu durchsuchen und Beispiele zu überprüfen.

1.2 Annahmen

To Do: Erläuterung der Herangehensweise der AG, zB warum welche Daten in welcher Detailtiefe, Erwartung an Datenquellen und –qualität.

1.3 Unbekannte und fehlende Informationen

Nicht immer können für bestimmte erwünschte Inhalte (Erkrankungen, Zustände, Eigenschaften, ... ) auch tatsächlich Angaben gemacht werden. Der Leitfaden unterscheidet 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 (der Patient nimmt tatsächlich keine Medikamente ein)

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. Das soll die Inhalte unabhängig von einem bestimmten technischen Standard machen, die Implementierungen robuster und einfacher machen sowie die Transformation in andere Standards wie z.B. FHIR erleichtern.

In einigen Fällen fehlten 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).

1.3.1 Darstellung von unbekannter und 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.)

1.3.1.1 Anwendungsbeispiele

Es liegt keine Information über Allergien oder Intoleranzen vor:

Es wurden keine Impfungen durchgeführt:

1.3.1.2 Codebeispiel für den lesbaren Text

Tabellarische Darstellung gilt auch für unbekannte und fehlende Informationen, Zusätzlich soll die Nicht-Information optisch hervorgehoben werden (Stylecode).

 <title>Allergien und Intoleranzen</title>
 <text>
  <table>
   <tbody>
    <tr ID="al-1">
     <td>
      <content styleCode="xELGA_blue">Es liegt keine Information über Allergien oder Intoleranzen vor</content>
     </td>
    </tr>
   </tbody>
  </table>
 </text>

1.4 Codierte Information

Siehe IPS Design Conventions and Principles

1.5 Uncodierte Information

Bei der Erstellung des Dokumentes können möglicherweise bestimmte Informationen vorliegen, die nicht codiert werden können, weil

1. die Information nicht mit den im Leitfaden zugelassenen Terminologien (Value Sets) dargestellt werden kann oder
2. die Information mit keiner bekannten Terminologie enthalten ist.

Diese erste Situation wird mit dem folgenden Beispiel verdeutlicht.

<code codeSystem="1.2.40.0.34.5.174" nullFlavor="OTH">
  <originalText>
    <reference value="#ref1"/>
  </originalText>
</code>

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)

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 diese Angabe zu unterstützen.

Dieses Beispiel bezieht sich auf die zweite Situation:

<value xsi:type="CD" nullFlavor="NI">
  <originalText>
    <reference value="#ref1"/>
  </originalText>
</value>

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).

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.

1.6 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.

Wenn das codierte Element mit de coding strength CNE (coded no extensions) angegeben ist, wird der nullFlavor "OTH" verwendet; bei coding strength CWE (coded with extensions) der nullFlavor "NI".

<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH"> 
  [
    <originalText>
      <reference value="#ref1"/>
    </originalText>
  ] 
  <translation code="A02.9" codeSystem="1.2.40.0.34.5.174"
    displayName="Salmonelleninfektion, nicht näher bezeichnet"/>
</value>

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 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.

<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor="NI"> 
  [
    <originalText>
      <reference value="#ref1"/>
    </originalText>
  ] 
  <translation code="A02.9" codeSystem="1.2.40.0.34.5.174"
    displayName="Salmonelleninfektion, nicht näher bezeichnet"/>
</value>

1.7 Zugeordnete codierte Information (Übersetzung)

<code codeSystem="1.2.40.0.34.5.174" nullFlavor="OTH">
  <originalText>
    <reference value="#ref1"/>
  </originalText>
</code>

1.9 Herkunft der Information

Die Angabe der Quelle einer Information kann für die klinische Bewertung dieser Information maßgeblich sein, besonders wenn ein Dokument aus mehreren Quellen (automatisch) zusammengestellt wurde. Daher erlaubt dieser Leitfaden eine systematische und durchgängige Angabe der Herkunft der elektronischen Daten.

1.9.1 Herkunftsangabe auf Dokument-Ebene

Der Autor des Patient Summary-Dokuments MUSS verpflichtend im Header angegeben werden. Dabei kann es sich um eine Person ("human curated") oder um eine Software ("software assembled") handeln.

1.9.2 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 (Person, 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)

1.9.3 Herkunftsangabe auf Entry-Ebene

• Autor (Person, 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.