elga-cdaps-2.06.2:Grundsätze und Regeln

Aus HL7 Austria MediaWiki
Wechseln zu: Navigation, Suche

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 liegt keine Information über Allergien oder Intoleranzen vor
Es wurden keine Impfungen durchgeführt:
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

1.6 Codierte, aber nicht gemappte Information

1.7 Translation of designations

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