Einleitung

Aus Hl7wiki
(Teildokument von Arztbrief 2.x)
Wechseln zu: Navigation, Suche
(Konzept der Templates)
K
Zeile 1: Zeile 1:
 
{{DocumentPart}}
 
{{DocumentPart}}
 +
 
=Einleitung=
 
=Einleitung=
  
Zeile 48: Zeile 49:
  
 
HL7 CDA basiert komplett auf HL7 Version 3, so dass dessen Verständnis hilfreich ist.
 
HL7 CDA basiert komplett auf HL7 Version 3, so dass dessen Verständnis hilfreich ist.
 
==Konzept der Templates==
 
 
Wie aus den vorhergehenden Erläuterungen ersichtlich ist, setzt sich ein Dokument aus verschiedenen Komponenten zusammen, die flexibel miteinander kombiniert werden können. Für ein Zusammensetzen der Einzelteile auf den unterschiedlichen Ebenen gibt es detaillierte „Baupläne“, die in CDA auch Templates – oder Schablonen oder auch Muster – genannt werden.
 
 
Tabelle 1: CDA-Templates
 
 
{| class="hl7table"
 
|-
 
!Template
 
!Beschreibung
 
!Inhalt
 
|-
 
|Document Level Template
 
|Angabe der benötigten Einzelteile für eine bestimmte Art von Dokument. So legt die Schabl-ne für einen Arztbrief beispielsweise fest, dass ein Arzt das Dokument für einen anderen Arzt erstellt und somit sowohl eine Anrede und eine Grußformel enthalten sollte. Bei einem einfachen Meldebogen ist letzteres nicht der Fall.
 
|Festlegung der Header und Section-Level-Templates sowie weiterer Header-Metadaten
 
|-
 
|Header Level Template
 
|Angabe, wie die größeren Blöcke im Header eines Dokumentes konkret aussehen sollen, zum Beispiel  welche Details zu einem Patienten hinterlegt werden können.
 
|Patient, Autor, Unterzeichner, weitere Beteiligte, ..
 
|-
 
|Section Level Template
 
|Angabe, wie ein bestimmter Abschnitt konkret aussehen soll. Hier können auch Vorgaben gemacht werden, wie zum Beispiel Diagnosen in einer tabellarischen Form textuell aufbereitet werden sollen, damit sie einheitlich durch ein Stylesheet zur Anzeige gebracht werden können.
 
Des weiteren kann hier auf die optionale oder verpflichtende Nutzung von Entry-Level-Templates hingewiesen werden.
 
|Anrede, Diagnose, Maßnahme, ..
 
|-
 
|Entry Level Template
 
|Angabe, wie die Einzelinformationen in struktierter und kodierter Form hinterlegt werden sollen, damit sie durch ein Programm ausgewertet und weiter verarbeitet werden können.
 
|ICD-Diagnose, Maßnahmen, Scores&Assessments, Meldeanlässe, ..
 
|-
 
|Datentypen
 
|Hier handelt es sich genau genommen nicht um Templates, sondern um sog. „Datentypen-Flavors“, jedoch beschreiben diese wie ein Datentyp in einem bestimmten Use Case genutzt werden soll. So kann es beispielsweise zwei unterschiedliche Ausprägungen für Adressen geben, die vollständige Adresse lässt Straßennamen oder Postfächer zu, der Geburtsort wird auf die Stadt inklusive Land eingeschränkt.
 
|Diese Datentypen werden in den drei vorgenannten Arten von Templates genutzt. Verwendung von Namen und Adressen, Telefonnummern, ..
 
|}
 
Templates stellen somit sog. „Profile Components“ dar, sind also selber konkrete Ausprägungen allgemeiner Vorgaben für einen bestimmten Use Case. Derartige Ausprägungen können hierarchisch vorgenommen werden. Nachfolgend sei das einmal an einem Beispiel erläutert.
 
 
Tabelle 2: Beispiel für eine Template-Hierarchie
 
 
{| class="hl7table"
 
|-
 
!Hierarchie
 
!Inhalt
 
!Einschränkung
 
|-
 
|Author ||Originäre Spezifikation aus dem CDA-Header ||Keine
 
|-
 
|  Author allgemein ||Ausdifferenzierung inklusiver aller Details ||Anwendung von Datentypen-Flavors
 
|-
 
|    Author Person ||Reduzierung auf eine Person als Autor ||Streichung der Auswahlmöglichkeit
 
|-
 
|    Author Gerät ||Reduzierung auf ein Gerät als Autor ||Streichung der Auswahlmöglichkeit
 
|}
 
 
Eine weitere wichtige Eigenschaft ist die Feststellung, ob Templates „offen“ oder „geschlossen“ sind, d.h. ob nicht angekündigte Erweiterungen in einer weiteren Hierarchiestufe erlaubt sind oder nicht. Hier gibt es unterschiedliche Vorgehensweisen. So macht es für die Angaben im Header durchaus Sinn, alle notwendigen Details soweit vorzugeben, so dass in Spezialisierungen nur die Auswahlmöglichkeiten gestrichen werden müssen, während für die Angaben im Body nur bedingt möglich ist, alle Eventualitäten vorzugeben.
 
  
 
==Wer sollte diesen Leitfaden lesen?==
 
==Wer sollte diesen Leitfaden lesen?==

Version vom 29. November 2013, 09:34 Uhr

Dieses Material ist Teil des Leitfadens Arztbrief 2.x.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Einleitung

Motivation

Dieser Leitfaden soll als generische Grundlage für Arztbriefe aller Art dienen und damit die Ablösung der papiergebundenen Arztbriefe ermöglichen. Ein Beispiel für ein entsprechendes Storyboard (Use Case) findet sich im Anhang dieses Leitfadens.

Die Spezifikation Arztbrief 2013 basiert auf dem VHitG-Arztbrief von 2006 (v1.5) und berücksichtigt hierbei die neueren Entwicklungen und Methodiken zur Erstellung von Leitfäden, bspw. die Nutzung von Templates oder speziellen Ausprägungen von Datentypen.

Aufbau dieses Implementierungsleitfadens

Dieser Implementierungsleitfaden verfolgt drei Ziele. Neben dem grundlegenden Konzept und dessen Begründung sollen die zugrunde liegenden Modelle ausführlich beschrieben werden, die für die Kommunikation genutzt werden. Aus ihnen leiten sich die Nachrichten/Dokumente in ihrem Aufbau und ihrer Semantik ab. Gleichzeitig können die Modelle Hinweise liefern für den Aufbau von Datenbanken oder Anwendungssystemen, die in diesem Kommunikationsszenario als Sender oder Empfänger fungieren. Zum dritten soll dieser Leitfaden praktische Implementierungshilfen geben. Dies kann bis zu einem gewissen Detaillierungsgrad geschehen und ist in der Regel mit Beispielen angereichert, so dass ein Programmierer einer Schnittstelle das nötige Wissen erlangen kann, wie die Schnittstelle aufzubauen ist. Auf dieser Basis werden schließlich die tatsächlichen Informationsinhalte beschrieben und die Beziehung an die entsprechenden Klassen und Attribute im Modell aufgezeigt. Daraus folgen dann Nachrichten und zugehörige Beispiele. Zudem sind in diesem Leitfaden einige Anhänge aufgenommen, die als Referenzmaterial dienen können und Hinweise geben für eine XML-basierte Implementierung.

HL7 Version 3 Referenz-Modell als Grundlage für CDA

Grundlage des Clinical Document Architecture (CDA) ist ein umfangreiches Objektmodell, das sogenannte Reference Information Model (RIM).

Allen Modellen bei HL7 Version 3 liegt das so genannte Referenz-Informations-Modell (RIM) zugrunde. Es beschreibt generisch zum Beispiel einen Behandlungsprozess. Dabei wird von einer Aktivität (Act) ausgegangen, an der Entitäten (z. B. Personen) in bestimmten Rollen (Arzt, Patient, Angehöriger) teilnehmen (Participation). Aktivitäten können miteinander in Beziehung (Kontext) stehen (Act Relationship), beispielsweise eine Laboranforderung und das daraus folgende Resultat. In der folgenden Abbildung sind die Basisklassen des RIM wiedergegeben. Darunter sind im Gesamt-RIM natürlich noch Spezialisierungen der Klassen zu finden. So ist eine Diagnose ein Sonderfall einer Beobachtung, diese wiederum eine Aktivität.

RIM Basisklassen

Abbildung: RIM Basisklassen

Diese Basisklassen erfahren - als Beispiel - folgende Spezialisierungen, die auch in diesem Leitfaden verwendet werden:

  • entity
    • Person
    • Organisation
    • Gerät
  • role
    • beabsichtigter Empfänger
    • verwaltende Organisation
    • Pate
    • ...
  • participation
    • recordTarget (Patient)
    • author
    • informant
    • participant
      • Hausarzt
      • ...
  • act
    • Beobachtung
      • Diagnose
    • Maßnahme
    • ..

HL7 CDA basiert komplett auf HL7 Version 3, so dass dessen Verständnis hilfreich ist.

Wer sollte diesen Leitfaden lesen?

Dieser Leitfaden ist für Produktmanager und Entwickler gedacht, die die elektronische Umsetzung des Arztbriefes realisieren sollen.

Darüber hinaus kann dieser Leitfaden weiter spezialisiert und damit die Grundlage anderer auszutauschender Dokumenttypen werden.

Hilfreiche Literatur

Folgende Literatur ist zum Verständnis des Leitfadens hilfreich:

  • "The CDA-Book", Keith Boone, Springer
  • HL7 V3 Primer, Andrew Hinchley
  • HL7 V3 Introduction
  • HL7 Datentypleitfaden
  • VHitG-Arztbrief, 2005