Statisches Modell
Foemig (Diskussion | Beiträge) |
Foemig (Diskussion | Beiträge) K |
||
Zeile 202: | Zeile 202: | ||
==Handhabung von Korrekturen und Folgemeldungen== | ==Handhabung von Korrekturen und Folgemeldungen== | ||
− | |||
− | |||
− | |||
{{FAQBox| | {{FAQBox| | ||
Eine Korrekturmeldung ist kein eigener Dokumenttyp, sondern wird als Korrektur einer entsprechenden Meldung gehandhabt. Damit muss das empfangende System bereits erhaltene Daten korrigieren, weil sich an den vorherigen Informationen etwas als falsch herausgestellt hat. | Eine Korrekturmeldung ist kein eigener Dokumenttyp, sondern wird als Korrektur einer entsprechenden Meldung gehandhabt. Damit muss das empfangende System bereits erhaltene Daten korrigieren, weil sich an den vorherigen Informationen etwas als falsch herausgestellt hat. | ||
Zeile 211: | Zeile 208: | ||
Eine Differenzierung zwischen Folge- und Korrekturmeldung ist nicht immer klar möglich. Aus diesem Grund wird nicht differentiell übermittelt, sondern immer das komplette Dokument. Innerhalb des kompletten Dokumentes kann dann über Identifikatoren erfolgen. | Eine Differenzierung zwischen Folge- und Korrekturmeldung ist nicht immer klar möglich. Aus diesem Grund wird nicht differentiell übermittelt, sondern immer das komplette Dokument. Innerhalb des kompletten Dokumentes kann dann über Identifikatoren erfolgen. | ||
}} | }} | ||
− | |||
− | |||
Zeile 305: | Zeile 300: | ||
Die Meldeanlässe und Inhalte können je nach Umfang und Länge des überschauten Zeitraum und ggf. dem vorgesehenen Empfänger kombiniert werden. Dies betrifft insbesondere auch den Abgleich von Tumordokumentationssystemen unterschiedlicher Stufen (z.B. Spezialsystemen in Organzentren und regionalen Krebsregistern) | Die Meldeanlässe und Inhalte können je nach Umfang und Länge des überschauten Zeitraum und ggf. dem vorgesehenen Empfänger kombiniert werden. Dies betrifft insbesondere auch den Abgleich von Tumordokumentationssystemen unterschiedlicher Stufen (z.B. Spezialsystemen in Organzentren und regionalen Krebsregistern) | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Zeile 553: | Zeile 334: | ||
</Clinicaldocument> | </Clinicaldocument> | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | |||
− | |||
− | |||
Aktuelle Version vom 28. November 2013, 15:50 Uhr
Dieses Material ist Teil des Leitfadens Übermittlung onkologischer Daten.
|
Inhaltsverzeichnis
- 1 Statisches Modell
- 1.1 Einleitung
- 1.2 Grundsätzliche Anforderungen an die Dokumentstruktur
- 1.3 Beispiel für groben Aufbau
- 1.4 Identifikation von Informationseinheiten
- 1.5 Referenzen auf andere Informationseinheiten
- 1.6 Referenzen auf Beteiligte
- 1.7 Handhabung von Negationen
- 1.8 Handhabung von Korrekturen und Folgemeldungen
- 1.9 Meldeanlässe und Inhalte
- 1.10 offene Punkte
Statisches Modell
Einleitung
Dieser Leitfaden setzt auf dem VHitG-Arztbrief auf. Daher werden auch die dortigen Spezifikationen übernommen. Die nachfolgende Tabelle gibt Aufschluss über die in einer Meldung enthaltenen Daten. Die Umsetzung in Form von Abschnitten erfolgt anhand des Analysemodells. Die Spalte „Klasse" referenziert auf die Information in dem Modell. Die letzte Spalte reflektiert in dem Modell dann die Beziehungen der Klassen untereinander.
Dabei kann eine Klasse sowohl aus inhaltlichen als auch nur aus Referenzzwecken übermittelt werden. Wird zum Beispiel eine Erkrankung erstmalig gemeldet, so wird diese Klasse als Inhalt übermittelt. In folgenden Meldungen wird die Erkrankung nur noch als Referenz zur korrekten Herstellung von Bezügen übermittelt. Ein weiterer zu bedenkender Fall wäre eine Korrektur . Über einen noch zu definierenden Mechanismus (Zeitstempel? Extra Attribut?) sollte das empfangende System in der Lage sein, diese Anlässe auseinanderzuhalten.
Abbildung 11: vereinfachte Gesamtübersicht
Grundsätzliche Anforderungen an die Dokumentstruktur
Dokumente setzen sich grundsätzlich aus folgenden Komponenten zusammen:
- dem eigentlichen Inhalt
- der Kontextinformation
Die Kontextinformation soll der korrekten Handhabung des Inhalts dienen. Korrekte Handhabung beinhaltet
- Die Zuordnung zum Patienten, zur Erkrankung und ggf. der gegenwärtigen therapeutischen Situation
- Die Übermittlung von Meldebegründungen, die Aussagen zur weiteren Nutzbarkeit von Daten erlauben
Im Grundsatz ist davon auszugehen, dass zum Patient die Personen identifizierenden Daten übermittelt werden. Dies ist insbesondere anzunehmen, wenn der Datenfluss der Betreuung folgt und natürlich wenn es die Meldebegründungen entsprechend vorsehen. Die Personenidentifikation kann um Zusatzidentifikatoren zum Aufbau und zur Nutzung eines Master-Patient-Index (MPI) erweitert werden, um den Abgleich (Record Linkage) schneller und sicherer zu machen. Bei bestimmten Empfängern ist eine Pseudo¬nymisierung, unter Umständen im Sinne einer Kontrollnummernbildung, erforderlich. Diese kann sowohl bereits bei Absendung der Daten erfolgen als auch erst in einer Vertrauensstelle. Dabei kann es erforderlich werden, dass Teile der Daten kryptographisch geschützt werden (Beispiel Krebsregister Baden-Württemberg).
Beispiel für groben Aufbau
<?xml version="1.0" encoding="UTF-8" ?>
<ClinicalDocument>
<!-- CDA Header -->
... siehe Beschreibung CDA R2 Header
<!-- CDA Body -->
<component>
<structuredBody>
... siehe Beschreibung CDA R2 Body
</structuredBody>
</component>
</ClinicalDocument>
Nachfolgend ein Beispiel, in dem der Header ausführlicher dargestellt ist:
<?xml version="1.0" encoding"UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="?????.xsl"?>
<ClinicalDocument
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:hl7-org:v3">
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<templateId root="1.2.276.0.76.3.5.7">
<id extension="60467049" root="1.2.276.0.58"/>
<code code="???????" codeSystem="2.16.840.1.113883.6.1"
displayName="???????"/>
<title>Meldung an klinisches Krebsregister</title>
<effectiveTime value="20060924"/>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<languageCode code="de"/>
<setId extension="D1" root="2.16.840.1.113883.3.933"/>
<versionNumber value="1"/>
...
<!-- CDA -->
<component>
<structuredBody>
<!-- Meldebegründung -->
<component>
<section>
<templateId root="1.2.276.0.76.3.1.131.1.10.????"/>
...
<!-- Referenz auf Participant -->
</section>
</component>
...
<!-- Erkrankungsdaten -->
<component>
<section>
<templateId root="1.2.276.0.76.3.1.131.1.10.?????"/>
...
<!-- Referenz auf Phänomendaten -->
</section>
</component>
</structuredBody>
</component>
</ClinicalDocument>
Identifikation von Informationseinheiten
Mechanismen
Ein Informationsobjekt kann grundsätzlich über zwei Mechanismen identifiziert werden
- über ein „neutrale" Identifikationsmerkmal (automatisch vergebene, eindeutige ID)
- über unveränderliche Eigenschaften des Informationsobjektes, die eine eindeutige Identifikation ermöglichen
Während die erste Möglichkeit keine Aussage über das Objekt selbst erlaubt, ist die zweite Möglichkeit unter Umständen nicht gegeben. So können bspw. weder bei Patienten die Namen noch bei Tumoren die Diagnose zur Identifikation herangezogen werden.
Natürlich reicht eine ID alleine nicht aus, um ein Objekt (z.B. eine Erkrankung) zu beschreiben, ermöglicht aber die Übermittlung von Beziehungen und damit die Zuordnung von Korrektur¬informationen.
Zeitstempel der Information
Zeitstempel informieren das Zielsystem über den Zeitpunkt der Entstehung oder Veränderung der Daten. Hierdurch kann das Zielsystem Entscheidungen über notwendige Bearbeitungsschritte treffen (Beispiel siehe unten). Die in den einzelnen Klassen enthaltenen Zeitangaben beziehen sich aber auf die Information selbst und nicht den Zeitpunkt der Veränderung. Eine solche Information müsste im Attribut participant@Time zu der Rolle Author ausgedrückt werden. Diese optionale Information wird nicht immer verfügbar sein. Daher sind grundsätzlich alle Informationen auf Aktualität zu überprüfen und dann ggf. zu korrigieren.
Beispiel Organzentrumssystem (OZ) - Klinisches Krebsregister (KKR)
Übermittlung OZ => KKR | Aktion im KKR |
---|---|
18.3.2010: (Patient) Erkrankung-ID 3456 / Diagnose-ID 456, Diagnosedatum 1.3.2010 / Diagnosecode C50.9 / Seite rechts | Kennt Erkrankung-ID 3456 noch nicht, legt eigene Erkrankung an kennt Diagnose noch nicht, wird ebenfalls angelegt merkt sich Referenz Erkrankung-ID |
25.3.2010: (Patient) Erkrankung-ID 3456 / Diagnose-ID 456, Diagnosedatum 1.3.2010 / Diagnosecode C50.4 / Seite rechts | Kennt Erkrankung-ID 3456 bereits, legt keine neue Erkrankung an, kennt Diagnose bereits, korrigiert Diagnosecode |
1.4.2010: (Patient) Erkrankung-ID 3456 / Diagnose-Id 456, Diagnosedatum 1.3.2010 / Diagnosecode C50.4 / Seite rechts Operation brusterhaltend am 27.3.2010, Operation/Prozedur-ID 3478237 | Kennt Erkrankung-ID 3456 bereits, macht keine Korrektur der Erkrankungsdaten verarbeitet Information zu Operation und ordnet sie der korrekten Erkrankung zu |
8.4.2010: (Patient) Erkrankung-ID 3456 / Diagnose-ID 456, Diagnosedatum 1.3.2010 / Diagnosecode C50.4 / Seite rechts Operation Brusterhaltend am 27.3.2010, Operation/Prozedur-ID 3478237 Phänomen Wundheilungsstörung 2.4.2010, Phänomen-ID 574547 | Kennt Erkrankung-ID 3456 und Prozedur-ID 3478237 bereits, macht keine Korrektur
verarbeitet Information zur Wund¬heilungs¬störung und ordnet sie der korrekten Operation zu, speichert sich Phänomen-ID |
Referenzen auf andere Informationseinheiten
Die Meldung verwendet interne Referenzen gemäß des Analysemodells. Die Funktionsweise soll hier kurz erläutert werden.
Abbildung 12: Handhabung von Referenzen auf Aktivitäten
Über eine Entry-Relationship wird eine Beziehung zu einer anderen Instanz ausgedrückt. Im obigen Beispiel verweist ein Detail einer Maßnahme (Beobachtung) auf eine andere Beobachtung. Welche das konkret ist, kann aus der ID entnommen werden. Im obigen Beispiel verweist die Beobachtung mit der ID=1 (unten) auf die Beobachtung mit den Detailinformationen (oben).
An dieser Stelle sei darauf hingewiesen, dass eine ID sich normalerweise aus zwei Teilen zusammensetzt. Das ist die eigentliche ID, die dann auch alphanumerisch sein kann, sowie eine root-Angabe, die dann auf das ausgebende System sowie die Art der ID verweist. Letzteres wird durch eine OID realisiert. Näheres dazu regelt die FAQ \[DIMDI, FAQ OID\].
Je nach Spezifikation können für Instanzen auch mehrere IDs vergeben werden.
Referenzen auf Beteiligte
Die Handhabung der Referenzen auf die Beteiligten erfolgt gemäß nachfolgendem Schema:
Abbildung 13: Handhabung von Referenzen auf Personen
Im Bereich des Clinical Statement Patterns besteht die Möglichkeit, Informationen über Personen einzubinden. Grundsätzlich können hier von einer Aktivität mehrere Verweise (Participations) auf Rollen eingebunden werden. Die Rollen können wiederum weitere Details über Verweise auf Personen bzw. Organisationen realisieren. Hierbei müssen aber keine weiteren Details übermittelt werden. Dieser Mechanismus erlaubt somit, beim ersten Vorkommen alle Details zu den Entities zu übermitteln und bei allen anderen bei den Rollen aufzuhören. Der contextControlCode bestimmt, ob diese Information dem übergeordneten Bereich (Header oder einer anderen hierarchisch übergeordneten Struktur) entspricht. Berichtet z.B. jemand über die Maßnahme eines Dritten, so kann hier dieser Dritte berichtet werden. Grundlage ist hierbei die Nutzung entsprechender Identifikatoren. Nachfolgende Abbildung verdeutlicht dies:
Abbildung 14: Beispiel für die Nutzung von Identifikatoren zwecks Referenzierung
Durch die Wiederholung der ID (hier: „1") wird deutlich, dass bei der zweiten Aktivität (id=B) dieselbe Person („Meier") eingebunden ist wie in der ersten Aktivität (id=A). Hierbei spielt es keine Rolle, welche Beziehung die beiden Aktivitäten zueinander haben. @typeCode Beteiligung CD CWE \[0..1\] Der typeCode der Participation bestimmt hierbei, um welche Art der Beteiligung es sich handelt.
Lvl | Code | Bedeutung | Erläuterung |
---|---|---|---|
1 | PRF | performer | Ausführender |
2 | PPRF | primary performer | 1. Ausführender |
2 | SPRF | secondary performer | 2. Ausführender |
VRF | verifier | Verifizierender | |
ENT | data entry person | Datentypist | |
CON | consultant | Berater | |
DIS | discharger | Entlassender | |
REF | referrer | Überweiser | |
ADM | admitter | Aufnehmender | |
ATT | attender | Beisitzer | |
AUTHEN | authenticator | ||
LA | legal authenticator | Unterzeichnender | |
AUT | author | Autor | |
RCT | record target | Akte |
Tabelle 3: Vocabulary Domain für die Beteiligung
@contextControlCode Kontext übernehmen BL Dieses Attribut bestimmt, ob der übergeordnete Kontext übernommen wird oder nicht.
Handhabung von Negationen
HL7 V3 stellt hierzu Mechanismen (Negation-Indikator und Null-Flavor) zur Verfügung, die hier jetzt nicht in aller Tiefe erklärt werden können. Deshalb sei hier auf die entsprechenden Materialien verwiesen.
??????????
Handhabung von Korrekturen und Folgemeldungen
Meldeanlässe und Inhalte
Grundsätze:
- Eine Meldung sollte dann ausgelöst werden, wenn eine Betreuungsepisode beendet und alle zu verantwortenden Informationen verfügbar sind.
- Grundsätzlich werden nur die Inhalte übermittelt, die mit eigenen diagnostischen oder therapeutischen Maßnahmen zusammenhängen. Davon sollte nur abgewichen werden, wenn andernfalls Lücken in der Erfassung auftreten würden.
Beispiel: Grundsätzlich ist eine chirurgische Abteilung verantwortlich für die Darstellung der operativen Therapie, des Therapieerfolgs und der Komplikationen. Informationen über eine außerhäusige Diagnosestellung müssten nur insofern übermittelt werden, dass das empfangende System in der Lage ist, die Therapie korrekt einem Tumor zuzuordnen. Wenn bekannt ist, dass dies aus irgendeinem Grund regelhaft nicht funktioniert oder vereinbart wurde, dass diese Informationen im Rahmen der operativen Therapie übermittelt werden sollen, hat die chirurgische Abteilung diese Eingabe zu verantworten.
Nachfolgend eine Liste der Meldeanlässe:
Lvl | Code | Anlass | Details |
---|---|---|---|
1 | Diagnose |
| |
1 | Therapie | ||
2 | Operative Therapie |
| |
2 | Strahlentherapie |
| |
2 | Systemische Therapie |
| |
1 | Verlauf |
| |
2 | Life-Status (Meldeamt) |
| |
1 | Sterbemeldung (Gesundheitsamt, Epid. Register) |
|
Die Meldeanlässe und Inhalte können je nach Umfang und Länge des überschauten Zeitraum und ggf. dem vorgesehenen Empfänger kombiniert werden. Dies betrifft insbesondere auch den Abgleich von Tumordokumentationssystemen unterschiedlicher Stufen (z.B. Spezialsystemen in Organzentren und regionalen Krebsregistern)
graphische Übersicht
Abbildung: Abschnittsübersicht (TODO: Diagramm muss aktualisiert werden!)
<Clinicaldocument>
...
<component>
<structuredBody>
<!-- Erkrankungsdaten -->
<component>
<section>
...
</section>
</component>
<!-- Meldebegründung -->
<component>
<section>
...
</section>
</component>
...
<!-- weitere Abschnitte -->
...
</structuredBody>
</component>
</Clinicaldocument>
offene Punkte
TODO: Phänomen und Erkrankungsdaten, Spezifikation Diagnoseleitfaden - ist noch nicht ausgearbeitet Dieser Abschnitt muss weiter nach hinten. |
- Phänomen => über entryRelationship/observation
- Erkankungsdaten => über entryRelationship/observation
- Participant => über participation