Krebsregistermeldungen

1 Informationen über dieses Dokument

Übernahme der Inhalte von bestehenden Leitfäden.

3 Einleitung

3.1 Ausgangssituation

Dieses Projekt erarbeitet Inhalte und ein elektronisches Austauschformat für die Krebsregistermeldungen (KR Meldungen) in Form eines Implementierungsleitfadens, ähnlich der ELGA-CDA-Implementierungsleitfäden.

Zugrundeliegende Datensätze für die Erstellung des Implementierungsleitfadens sind:

• Krebsstatistikgesetz Variablen und Codelisten 20170619
• Bundesgesetzblatt zur Krebsstatistikverordnung

Eine Grundlage dieses Projekt ist das Krebs-Rahmenprogramm November 2014. Für die Krebsregistermeldungen ist vor allem das Kapitel "5.6 Epidemiologie, Krebsstatistik und krankheitsbezogenes Verlaufsregister" zu beachten.

Die in den KR Meldungen enthaltenen medizinischen Informationen können in weiteren Projektphasen auch im Survivorship Passport (SUPP) verwendet werden. Die Umsetzung des SUPP ist als operatives Ziel im Krebs-Rahmenprogramm 2014 enthalten. Siehe auch BMGF, Onkologiebeirat

5 Administrative Daten (CDA Header)

Dieses Kapitel basiert auf dem entsprechenden Kapitel im „Allgemeinen Implementierungsleitfaden“ und beschreibt die darüberhinausgehenden Spezifikationen zum Thema Krebsregistermeldung.

5.1 Elemente ohne spezielle Vorgaben

Folgende Elemente erfordern keine speziellen Vorgaben:

• XML Metainformationen
• Wurzelelement
• Hoheitsbereich („realmCode“)
• Dokumentformat („typeId“)
• Dokumenten-Id („id”)
• Erstellungsdatum des Dokuments („effectiveTime“)
• Vertraulichkeitscode („confidentialityCode“)
• Sprachcode des Dokuments („languageCode“)
• Versionierung des Dokuments („setId“ und „versionNumber“)

Verweis auf den Allgemeinen Leitfaden:
Das Element erfordert keine speziellen Vorgaben. Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“.

Auszug aus dem Allgemeinen Implementierungsleitfaden

5.2 XML Metainformationen

5.2.1 Zeichencodierung

CDA-Dokumente MÜSSEN mit UTF-8 (8-Bit Universal Character Set Transformation Format, nach RFC 3629 / STD 63 (2003)) codiert werden.

<?xml version="1.0" encoding="UTF-8" standalone=”yes”?>
<ClinicalDocument xmlns="urn:hl7-org:v3">
:

5.2.2 Hinterlegung eines Stylesheets

Um ein CDA-Dokument in einem Webbrowser anzeigen zu können, muss es nach HTML tranformiert werden. Das kann durch eine XSLT-Transformation (ein so genanntes „Stylesheet“) geschehen. Ist das Stylesheet im angegebenen Pfad erreichbar, wird dieses beim Öffnen des CDA-Dokuments mit einem Browser üblicherweise automatisch auf das CDA-Dokument angewandt und die Darstellung gerendert.

ELGA stellt zur einheitlichen Darstellung von CDA-Dokumenten ein „Referenz-Stylesheet“ zur Verfügung (Download ist von der ELGA Website http://www.elga.gv.at/cda möglich). Da der Zugriff auf XSLT-Programme von den meisten Browsern eingeschränkt ist, wird kein absoluter Pfad auf eine Webressource angegeben.

<?xml version="1.0" encoding="UTF-8" standalone=”yes”?>
<?xml-stylesheet type="text/xsl" href="ELGA_Stylesheet_v1.0.xsl"?>
<ClinicalDocument xmlns="urn:hl7-org:v3">
:

Das Stylesheet „ELGA_Stylesheet_v1.0.xsl“ MUSS angegeben werden [M]. Die Angabe eines Pfades ist NICHT ERLAUBT. Ausnahmen können für automatisiert erstellte Dokumente notwendig sein, diese müssen im allgemeinen und speziellen Leitfäden beschrieben werden.

5.3 Wurzelelement

Der XML-Namespace für CDA Release 2.0 Dokumente ist urn:hl7-org:v3 (Default-Namespace). Dieser MUSS in geeigneter Weise in jeder CDA XML Instanz genannt werden. In speziellen Leitfäden können weitere namespace-Präfixe angegeben werden.

Für ELGA CDA-Dokumente MUSS der Zeichensatz UTF-8 verwendet werden.

CDA-Dokumente beginnen mit dem Wurzelelement ClinicalDocument, der grobe Aufbau ist im folgenden Übersichtsbeispiel gegeben.

<ClinicalDocument xmlns="urn:hl7-org:v3">
   <!-- CDA Header -->
      … siehe Beschreibung CDA R2 Header …
   <!-- CDA Body -->
   <component>
      <structuredBody>
         … siehe Beschreibung CDA R2 Body …
      </structuredBody>
   </component>
</ClinicalDocument>

5.4 Hoheitsbereich des Dokuments („realmCode“)

Dieses Element kennzeichnet, dass das Dokument aus dem Hoheitsbereich Österreich (bzw. Bereich der HL7 Affiliate Austria, Code „AT“) stammt.

5.4.1 Strukturbeispiel

<realmCode code="AT'"/>

5.4.2 Spezifikation

Element/Attribut	DT	Kard	Konf	Beschreibung
realmCode	CS CNE	1..1	M	Hoheitsbereich des Dokuments Fester Wert: @code = AT (aus ValueSet „ELGA_RealmCode“)

5.5 Dokumentformat („typeId“)

Dieses Element kennzeichnet, dass das Dokument im Format CDA R2 vorliegt.

5.5.1 Strukturbeispiel

<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>

5.5.2 Spezifikation

Element/Attribut	DT	Kard	Konf	Beschreibung
typeId	II	1..1	M	Dokumentformat CDA R2 Feste Werte: @root = 2.16.840.1.113883.1.3' @extension = POCD_HD000040

5.6 Dokumenten-Id („id”)

Die Dokumenten-Id eines CDA-Dokuments ist ein eindeutiger Instanzidentifikator, der das Dokument weltweit eindeutig und für alle Zeit identifiziert. Ein CDA-Dokument hat genau eine Id.

5.6.1 Strukturbeispiel

<id
  root="1.2.40.0.34.99.111.1.1"
  extension="134F989"
  assigningAuthorityName="Amadeus Spital"/>

5.6.2 Spezifikation

Es MUSS eine gültige und innerhalb des ID-Pools eindeutige Dokumenten-ID angegeben werden.

Element/Attribut	DT	Kard	Konf	Beschreibung
id	II	1..1	M	Dokumenten-Id Grundsätzlich sind die Vorgaben gemäß „Identifikations-Elemente“ zu befolgen.

5.7 Erstellungsdatum des Dokuments („effectiveTime“)

5.7.1 Spezifikation

Id	1.2.40.0.34.11.90008 ref elgabbr-	Gültigkeit	2016‑07‑21 Andere Versionen mit dieser Id: CDeffectiveTime vom 2013‑11‑07
Status	Aktiv	Versions-Label
Name	CDeffectiveTime	Bezeichnung	CD effectiveTime
Beschreibung Mit Erstellungsdatum ist jenes Datum gemeint, welches normalerweise im Briefkopf eines Schriftstückes angegeben wird. (z.B.: Wien, am …). Das Erstellungsdatum dokumentiert den Zeitpunkt, an dem das Dokument inhaltlich fertiggestellt wurde. Bemerkung: Das Erstellungsdatum des Dokuments muss nicht mit dem Datum der rechtli-chen Unterzeichnung (oder „Vidierung“) übereinstimmen.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz elgagab-data​element-8  Erstellungsdatum  Datensatz
Beziehung	Version: Template 1.2.40.0.34.11.90008 CD effectiveTime (2016‑07‑21) ref elgabbr-
Beispiel	Nur Datum: Zeitpunkt als Datum (ohne Zeit) im Format YYYYMMDD <effectiveTime value="20081224"/>
Beispiel	Datum, Zeit und Zeitzone: Zeitpunkt als Datum mit Zeit und Zeitzone im Format YYYYMMDDhhmmss[+/-]HHMM <effectiveTime value="20081224082015+0100"/>
Item DT Kard Konf Beschreibung Label hl7:effectiveTime TS.AT.TZ 1 … 1 M Erstellungsdatum des Dokuments. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. (CDe...ime)   elgagab-data​element-8  Erstellungsdatum  Datensatz

5.8 Vertraulichkeitscode („confidentialityCode“)

5.8.1 Spezifikation

Id	1.2.40.0.34.11.90009 ref elgabbr-	Gültigkeit	2013‑11‑07
Status	Aktiv	Versions-Label
Name	CDconfidentialityCode	Bezeichnung	CD confidentialityCode
Beschreibung “Vertraulichkeitscode” (im CDA das Element ClinicalDocument/confidentialityCode) bezeichnet die Vertraulichkeitsstufe dieses Dokuments. Der tatsächliche Zugriff auf das Dokument muss von der übergeordneten Infrastrukturschicht geregelt werden. Die Information des Vertraulichkeitscodes im Dokument selbst, dient nur der reinen Information und hat keine technischen Konsequenzen. Da Dokumente nach der Vidierung weder technisch noch legistisch geändert werden dürfen, kann der Vertraulichkeitscode keine konkreten Zugriffsrechte auf das Dokument regeln, sondern nur auf „Metaebenen“, wie beispielsweise „geltendes Recht XY“ oder weiterführende Verwendungen über das IHE BPPC Profil, verweisen.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz elgagab-data​element-266  Vertraulichkeitscode  Datensatz
Beziehung	Version: Template 1.2.40.0.34.11.90009 CD confidentialityCode (2013‑11‑07) ref elgabbr-
Beispiel	Beispiel <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25" displayName="normal"/>
Item DT Kard Konf Beschreibung Label hl7:confidentialityCode CE 1 … 1 M (CDc...ode)   elgagab-data​element-266  Vertraulichkeitscode  Datensatz @code CONF 1 … 1 F N @codeSystem 1 … 1 F 2.16.840.1.113883.5.25 (BasicConfidentialityKind) @displayName 1 … 1 F normal

5.9 Sprachcode des Dokuments („languageCode“)

5.9.1 Spezifikation

Id	1.2.40.0.34.11.90010 ref elgabbr-	Gültigkeit	2013‑11‑07
Status	Aktiv	Versions-Label
Name	CDlanguageCode	Bezeichnung	CD languageCode
Beschreibung Die Sprache des Dokuments wird in diesem Attribut gemäß IETF (Internet Engineering Task Force), RFC 1766: Tags for the Identification of Languages nach ISO-639-1 (zweibuchstabige Codes für Sprachen, Kleinbuchstaben) und ISO 3166 (hier: zweibuchstabige Ländercodes, Großbuchstaben) festgelegt. Das Format ist entsprechend ss-CC, mit ss, zwei Kleinbuchstaben für den Sprachencode gemäß ISO-639-1, und CC, zwei Großbuchstaben für den Ländercode gemäß ISO 3166 (Tabelle mit zwei Buchstaben).
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz elgagab-data​element-265  Sprachcode  Datensatz
Beziehung	Version: Template 1.2.40.0.34.11.90010 CD languageCode (2013‑11‑07) ref elgabbr-
Beispiel	Beispiel <languageCode code="de-AT"/>
Item DT Kard Konf Beschreibung Label hl7:language​Code CS.LANG 1 … 1 M Sprachcode des Dokuments. (CDl...ode)   elgagab-data​element-265  Sprachcode  Datensatz @code CONF 1 … 1 F de-AT

5.10 Versionierung des Dokuments („setId“ und „versionNumber“)

5.10.1 Spezifikation

Es MÜSSEN immer beide Elemente (setID und versionNumber) angegeben werden.

Id	1.2.40.0.34.11.90007 ref elgabbr-	Gültigkeit	2015‑09‑18 Andere Versionen mit dieser Id: CDsetIdversionNumber vom 2015‑05‑29 CDsetIdversionNumber vom 2013‑11‑07
Status	Aktiv	Versions-Label
Name	CDsetIdversionNumber	Bezeichnung	SetId VersionNumber
Beschreibung Der CDA-Header repräsentiert ebenfalls die Beziehungen zu anderen Dokumenten mit Referenz auf die oben genannte Dokumenten-Identifikation. Mittels der Attribute setId und versionNumber kann eine Versionskennung des Dokuments erreicht werden. Für ELGA-CDA-Dokumente MÜSSEN immer beide Elemente angegeben werden. Die setId bezeichnet das Set von Dokumenten, die zu einer Reihe von Versionen gehören. Sie bleibt über alle Versionen der Dokumente gleich (initialer Wert bleibt erhalten). Die versionNumber ist eine natürliche Zahl für die fortlaufende Versionszählung. Mit einer neuen Version wird diese Zahl hochgezählt, die setId bleibt gleich.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Beziehung	Version: Template 1.2.40.0.34.11.90007 SetId VersionNumber (2015‑09‑18) ref elgabbr-
Beispiel	Beispiel für die 1.Version eines Dokuments <!-- Die bei setId angegebene ID SOLLTE nicht gleich sein wie die id des Dokuments.--> <art:placeholder>   <id root="1.2.40.0.34.99.111.1.1" extension="AAAAAAAAAAAAAAA"/>  <setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZ"/>  <versionNumber value="1"/></art:placeholder>
Beispiel	Beispiel für die 2.Version eines Dokuments <!--Die bei setId angegebene ID MUSS mit der setId der Vorversion übereinstimmen.--> <art:placeholder>   <id root="1.2.40.0.34.99.111.1.1" extension="BBBBBBBBBBBBBBB"/>  <setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZ"/>  <versionNumber value="2"/></art:placeholder>
Item DT Kard Konf Beschreibung Label hl7:setId II 1 … 1 M Eindeutige Id des Dokumentensets. Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen. Hinweis: Bestimmte Systeme, die bei der Übernahme der SetID in die XDS-Metadaten mit dem V2-Datentyp CX arbeiten, könnten ein Problem mit @Extension-Attributen haben, die länger als 15 Zeichen sind. Die SetID sollte unterschiedlich zur clinicalDocument.id sein. (CDs...ber)   Beispiel <setId extension="D1127" root="1.2.276.0.76.3.1.139.2.427"/> hl7:versionNumber INT.​NONNEG 1 … 1 M Versionsnummer des Dokuments. (CDs...ber)   Beispiel <versionNumber value="1"/>

Für die setId sind grundsätzlich die Vorgaben gemäß Kapitel „id-Element II“ zu befolgen. Die versionNumber von neuen Dokumenten wird mit 1 festgelegt.

Anhänge oder Ersetzungen von Vordokumenten MÜSSEN ebenfalls diese zusätzlichen Angaben enthalten.

Der genaue Zusammenhang zwischen diesen Attributen finden Sie im „Bezug zu vorgehenden Dokumenten“.

Achtung: Manche Validatoren erkennen es als Fehler, wenn die SetID und ID gleich sind.

5.11 Elemente mit speziellen Vorgaben

5.11.1 ELGA Implementierungsleitfaden-Kennzeichnung („templateId“)

Mit Angabe dieses Elements wird ausgesagt, dass das vorliegende CDA-Dokument zu diesem Implementierungsleitfaden konform ist. Ein Dokument, welches dem vorliegenden Implementierungsleitfaden folgt, muss auch dem übergeordneten Allgemeinen Implementierungsleitfaden folgen.

5.11.1.1 Spezielle Vorgaben für die Krebsregistermeldung

Die templateId-Elemente für diesen Implementierungsleitfaden sind anzugeben. Die Krebsregistermeldung erfolgt ausschließlich im ELGA Interoperabilitäts Level (EIS) "full support".

5.11.1.2 Strukturbeispiel

<ClinicalDocument xmlns="urn:hl7-org:v3"> 
  :
   <!-- ELGA CDA Dokumente -->
   <templateId root="1.2.40.0.34.11.1"/> 
  
   <!-- ELGA CDA Krebsregistermeldung EIS "full support" -->
   <templateId root="1.2.40.0.34.11.99"/>
  :
</ClinicalDocument>

5.11.1.3 Spezifikation

Element/Attribut	DT	Kard	Konf	Beschreibung
templateId	II	1..1	M	ELGA TemplateId für den Allgemeinen Implementierungsleitfaden Fester Wert: @root = 1.2.40.0.34.11.1
templateId	II	1..1	M	ELGA TemplateId für den speziellen Implementierungsleitfaden Krebsregistermeldung in EIS "full support" Fester Wert: @root = 1.2.40.0.34.11.99

5.11.2 Dokumentenklasse (“code”)

Alle im Zuge der Krebsregistermeldung entstehenden Dokumente haben verpflichtend den selben Code zur Codierung der Dokumentenklasse zu führen.

5.11.2.1 Spezielle Vorgaben für Entlassungsbriefe (Pflege)

Alle Krebsregistermeldungen werden mit dem folgenden LOINC Code codiert:

XXX, TODO_Code

5.11.2.2 Strukturbeispiel

<ClinicalDocument xmlns="urn:hl7-org:v3">
	:
  <code code="XXX"
        displayName="TODO_Code"
        codeSystem="2.16.840.1.113883.6.1"
        codeSystemName="LOINC" />
	:
</ClinicalDocument>

5.11.2.3 Spezifikation

Element/Attribut		DT	Kard	Konf	Beschreibung
code		CE CWE	1..1	M	Code des Dokuments
	@code	cs	1..1	M	Fester Wert: XXX
	@displayName	st	1..1	M	Fester Wert: TODO_Code
	@codeSystem	uid	1..1	M	Fester Wert: 2.16.840.1.113883.6.1
	@codeSystemName	st	1..1	M	Fester Wert: LOINC

5.11.3 Titel des Dokuments („title“)

Der Titel des Dokuments ist für den lesenden Dokumentempfänger das sichtbare Element. Dieser wird nicht dem Attribut displayName des Elements code entnommen, sondern dem (verpflichtenden) Element title.

5.11.3.1 Spezielle Vorgaben die Krebsregistermeldung

Der Title für die Dokumente der Krebsregistermeldung MUSS "Meldung an das Krebsregister" lauten.

8 Anhang

8.1 Treffen/Workshops - Protokolle

Siehe AG Krebsregistermeldungen

9 Datensätze

Datensätzle laut zugrundeliegender Codeliste in Excel:

9.1 Daten in ELGA CDA vorhanden

• bPK-AS: -> im recordTarget-Element
• Kontaktdatum: -> EncompassingEncounter und ServiceEvents
• Geburtsdatum
• OID laut GDA Index
• Krankanstaltennummer und Abteilungsnummer inkl. möglichem Subcode (bis zu welcher Stufe ist eine Codierung notwendig)
• Diagnosesicherungsdatum: Datum bei Diagnose Element
• Todesdatum -> in EMS Meldung definiert
• Kommentar

9.2 Daten als CDA vorhanden - außerhalb von ELGA

• Obduktionsdatum
• Lokalisation des Tumors. Definiert in Pathology Structured Report
  • Textuelle Beschreibung als originalText bei observation
  • Seite bei paarigen Organen schon definiert
• Histologie (Morphologie) des Tumors. Definiert in Pathology Structured Report
  • Textuelle Beschreibung als originalText bei observation
• Verhalten: Definiert in Pathologie Structured Report
• Angaben zum Primärtumor
  • in Pathology Structured Report definiert. Angaben ob klinisch oder pathologisch werden als qualifier angegeben.
• WHO Grading bei Hirntumoren. Entspricht dies strukturell der histopathologischen Gradierung?

Klarstellung von M. Hackl: Nein, die Struktur unterscheidet sich von der histopathologischen Gradierung.

Data set TNM

Template TNM-Stage Observation des Pathology Structured Reports

9.3 Inhaltlich noch zu klären

• Rückfrageobjekt: ist die DokumentenId hierzu ausreichend? Schon in ELGA definiert
  • Ergebnis WS 4.10.: NEIN, die DokumentenId alleine ist nicht ausreichend. Im Falle, dass eine Meldunge unterlassen worden ist, wird von Stat. Austria eine Nachfrage zu dem spezifischen Fall an die Organisation, welche die Meldung verabsäumte, geschickt. Da ist die DokumentenId nicht zielführend, da bis dato noch keine Dokument eingemeldet wurde. Ähnliches gilt für die gewünschte Tumorzahl - welche sonst eine Rückfrage deutlich vereinfachen würde! Somit bleibt für die Rückfrage oftmals nur das bPK.
  • add Meldung verabsäumt: Stat. Austria kann aus durch Inputs aus anderen Quellen (z.b. Sterberegister) erkennen, dass eine Meldung unterlassen worden wurde. Hierzu wird ein "leeres" Dokument in den spezifischen Bereich des GDAs eingestellt mit der Aufforderung die Meldung durchzuführen.
• Geschlecht: in ELGA derzeit nur das administrative Geschlecht mit den Ausprägungen männlich, weiblich, unbekannt
• Registrierungsdatum: "Datum der ersten Verfügbarkeit eines Falles in einem regionalen Tumorregisters". Wie kann der behandelnde Arzt auf das Register zugreifen? Was ist wenn der Patient in zwischen zwei Meldungen den Wohnort gewechselt hat? Welches ist dann das reginale Register?
  • Ergebnis WS 4.10.: Dieses Registrierungsdatum stellt den Zeitpunkt dar wann die Meldung in ein regionales Register erfolgt. Diese regionlen Register leiten dann zu einem anderen (definierten) Zeitpunkt die Meldungen weiter. Um statistischen Auswertung (Flow-Analyse) zu ermöglichen muss das Datum wann die Meldung an das regionle Register erfolgte mitgeführt werden.
• Meldungsauslöser: NOCH OFFEN
• Vertragspartnernummers des HBVs: Ist hier die Identifikation des Versicherungsträgers gemeint? In ELGA wäre dies schon abgebildet

Klarstellung von M. Hackl: Die Vertragspartnernummer des HBVs ist die Identifikation des Melders (im niedergelassenen Bereich) gedacht. Relevant für Use Case 2 (Rückfrage) und Use Case 3 (Rückmeldung).

• Diagnoseanlass: Ist hier ein qualifier vom Diagnosecode angebracht (Semantik)?
• Methode der Diagnosestellung: Hier gibt es zwei Codelisten? Welche Konzepte sind relevant -> Valueset. Darstellung der Methode als qualifier bei Diagnose?
• Datensätze zur Palliative Betreung: Sind bis dato nicht umgesetzt und wurden auch bei weiteren Recherchen nicht gefunden

Input von M. Hackl: "Hier ist angedacht bei STAT aus den Angaben des Melders (Krankenanstaltennummer und Abteilungsnummer eine Zuordnung der Fälle zur Palliative Betreuung zu erstellen). Wurde allerding noch nicht geprüft ob das möglich ist."

10 Mapping der Variablen laut Excel in CDA

Bezeichnung lt. Excel	Dataset von Art Decor	Template Art Decor	Anmerkungen
bPK-AS	Patient	recordTarget	derzeit nur GH (lt. Hr. Hölzel (KAV-IT) wird bPK praktisch nicht verwendet, für Statistikmeldung darf kein bPK-GH vorkommen sondern nur bPK-AS, strukturell in CDA gleich abgebildet Hackl: in der Krebsregistermeldung muss das bPK-GH in verschlüsselter Form enthalten sein (use case 2,3,4) / das darf rechtlich auch so sein. FRAGE: Ist die Angabe des bPK-GH in verschlüsselter Form sinnvoll? Es würde bedeuten, dass ein Service vorhanden ist, welches die Verschlüsselung durchführt. Wenn so ein Service vorhanden ist könnte es jedoch auch für die Umwandlung der bPKs (zwischen GH und AS und vice versa) genutzt werden wenn die Dokumente zwischen den Domains GH und AS ausgetauscht werden.
Rückfrageobjekt			derzeitiger Stand: als Rückfrageobjekt dient die Dok-ID, TODO: zu klären was das Rückfrageobjekt bei Anwendungsfall "Meldungseinforderung bei Verdacht auf Unterlassung einer Meldung"
Kontaktdatum	Patientenkontakt	encompassingEncounter	lt. Excel Ersatzdatum wenn kein Diagnosesicherungsdatum vorhanden ist
Geburtsdatum	Patient	recordTarget
Geschlecht	Patient	recordTarget	hierbei handelt es sich derzeit um das administrative Geschlecht mit den Ausprägungen "männlich", "weiblich" und "nicht zugewiesen"
Registrierungsdatum			Vorschlag: Nutzung des CDA-Elements "informant" auf clinical document Ebene
Meldungsauslöser			TODO: zu diskutieren (als observation zu kodieren?)
Vertragspartnernummer des HVBs			ID-Element! ZB. beim Autor, TODO: zu diskutieren
OID			sind lt. allgemeinem ELGA-Impl.leitfaden bei den unterschiedlichsten Entitäten vorhanden
Krankenanstaltennummer			ID-Element! ZB. beim Autor, TODO: zu diskutieren
Abteilungsnummer			ID-Element! ZB. beim Autor, TODO: zu diskutieren
Subcode der Abteilung			ID-Element! ZB. beim Autor, TODO: zu diskutieren
Diagnoseanlass			TODO: zu diskutieren (als observation zu kodieren?)
Datum der Diagnosesicherung			die in Excel ersichtlichen Daten wären im ELGA-Impl.leitfaden Labor schon definiert, sind diese ausreichend? Werden alle benötigt?
Methode der Diagnosestellung			TODO: work in progress
Todesdatum			Dokument "Reporting Death Information from the EHR to Vital Records, HL7 Public Health and Emergency Response WG"
Obduktionsdatum			Dokument "Reporting Death Information from the EHR to Vital Records, HL7 Public Health and Emergency Response WG"

11 ICD-O

Laut Dokument "IHE Pathology and Laboratory Medicine Technical Framework Supplement, Anatomic Pathology Structured Report". Achtung: die Templates schreiben fixe englische Bezeichnungen (section/title) vor, wodurch eigene Templates zu definieren sind.

Bezeichnung lt. Excel	Dataset von Art Decor	Template Art Decor	Anmerkungen
Beispiel	Beispiel	Beispiel	Beispiel

12 Weitere Diskussionspunkte

• Frage zum "informationRecipient": soll hier fix Statistik Austria aufscheinen? Derzeit sieht der Impl.leitfaden vor, dass nebst einer Organisation auch eine natürliche Person angegeben wird.

Histopatologische Gradierung: Frage zu ValueSet UICC Grade? Liste ist auf Vollständigkeit zu überprüfen!

Residualtumorklassifizierung: Frage zu ValueSet Residual Tumor Classification? Liste ist auf Vollständigkeit zu überprüfen!

13 Dateien

• IHE_PaLM_Suppl_APSR_2.0_PC_2017-09-27.pdf
• HL7 Public Health and Emergency Response WG.pdf
• BGBLA_1978_171_0_Krebsstatistikverordnung.pdf
• Krebsstatistikgesetz_Variablen und Codelisten_20170619.xlsx
• BGBLA_1969_138_0_Krebsstatistik.pdf
• BGBLA_1969_425_0_Abaenderung_des_Krebsstatistikgesetzes.pdf
• incidger.pdf

• Krebsstatistikgesetz: Excel mit Variablen und Codelisten (20180312) inklusive Beispieldaten [1]
• CDA Beispiel Krebsmeldung inkl. ELGA Stylesheet [2]