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>

Die eckigen Klammern deuten an, dass Elemente optional sind.

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

1. Fall: Ein einzelner lokaler Code wird auf einen Code im Referenz-Value Set gemappt

<value xsi:type="CD" code="42338000" codeSystem="2.16.840.1.113883.6.96"
  displayName="Salmonella gastroenteritis">
  [
    <originalText>
      <reference value="#ref1"/>
    </originalText>
  ] 
  <translation code="003.0" codeSystem="2.16.840.1.113883.6.103"
    displayName="Gastroenterite da Salmonella"/>
</value>

Die eckigen Klammern deuten an, dass Elemente optional sind.

2. Fall: Mehrere lokale Codes werden auf das Referenz-Value Set gemappt

<value xsi:type="CD" code="422479008" codeSystem="2.16.840.1.113883.6.96"
  codeSystemName="SNOMED CT"
  displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
  [
    <originalText>
       <reference value="#problem4name"/>
    </originalText>
  ]
  <translation code="code-example" codeSystem="1.999.999"
    codeSystemName="this is only an example"
    displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
    <translation code="174.9" codeSystem="2.16.840.1.113883.6.103"
      codeSystemName="ICD-9CM"
      displayName="Malignant neoplasm of breast (female), unspecified"/>
    <translation code="C50.919" codeSystem="2.16.840.1.113883.6.90"
      codeSystemName="ICD-10-CM"
      displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
 </translation>
</value>

Die eckigen Klammern deuten an, dass Elemente optional sind.

3. Fall: Ein lokaler Code entstammt derselben Terminologie wie das Referenz-Value Set, besitzt aber eine unterschiedliche Granularität.

<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"
  codeSystemName="LOINC" displayName="Patient Summary">
  <translation code="60592-3" codeSystem="2.16.840.1.113883.6.1"
    displayName="Patient summary unexpected contact"/>
</code>

Die eckigen Klammern deuten an, dass Elemente optional sind.

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

1.8 Mehrsprachigkeit

Codierte Informationen können einfach in unterschiedlichen Sprachen ausgedrückt werden. Für einen zuverlässigen und sicheren grenzüberschreitenden Datenaustausch (EU eHealth Network) ist dies eine funktionelle Notwendigkeit.

Im zugrunde liegenden Standard HL7 CDA Rel. 2 gibt es keine native Möglichkeit, eine Anzeigetext zu einem codierten Konzept in mehreren Sprachen anzugeben. Dieser Leitfaden übernimmt daher als optionales Element die Erweiterung (extension) 'ips:designation', die im HL7 IPS Leitfaden dafür vorgeschlagene wird.

Beispiele:

No code mapping

 <ips:designation lang="it-IT" value="Profilo Sanitario Sintetico"/> 
 <ips:designation lang="fr-FR" value="Patient Summary"/>
 <ips:designation lang="en" value="Patient Summary"/>

Codes mapping

<value xsi:type="CD" code="42338000" codeSystem="2.16.840.1.113883.6.96"

 displayName="Salmonella-gastroenterit">
 <ips:designation lang="da-DK" value=" Salmonella-gastroenterit"/> 
 <ips:designation lang="en" value="Salmonella gastroenteritis (disorder)" type="FSN"/> 
 [
   <originalText>
     <reference value="#ref1"/>
   </originalText>
 ]
 <translation code="003.0" codeSystem="2.16.840.1.113883.6.103"
   displayName="Gastroenterite da Salmonella"/>

</value>

Narrative Translations

With “narrative translation” is meant both the translation of the original narrative text, that can be human curated or automatically performed and the generation of a translated narrative based on the coded entries.

The functional requirements associated to this process are described in the Designations’ Translation under the Functional requirements and high-level use cases and can be summarized in two main points : (a) language identification and (b) distinguishable original and translated narratives. Moreover, the methodology applied for the narrative translation (e.g. derived from the coded entries; translated by a generic service;..) should be noted.

Regarding translation of section narrative <text>, this guide recommends to provide this translation on purely textual subordinate sections (one per translation) as specified in template 2.16.840.1.113883.10.22.3.15

Hereafter an example:

<section>

 <templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
  <id root="..." extension="..."/>
  <code code="48765-2" codeSystem="2.16.840.1.113883.6.1"
     displayName="Allergies and adverse reactions"/>
  <title>Allergies and Intolerances</title>
  <text>No known Allergies</text>
  <component>
     <section>
       <title>Allergie ed Intolleranze</title>
       <text>Nessuna Allergia Nota</text>
       <languageCode code="it-IT"/>
     </section>
   </component>

</section>

---

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.