cdaefa:EFA Business Informationsmodell

Informationsmodell der EFA Geschäftsobjekte

Informationsmodell der EFA Geschäftsobjekte

Implementierungsleitfaden

vorgelegt von:
February 2013
Jörg Caumanns, Raik Kuhlisch , Ben Kraufmann

Draft

Version:	0.9
Datum:	March 2013
Status:	xxx
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2012-2013: HL7 Deutschland

Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

---

EFA Informationsmodell

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.01}

Die folgende Abbildung zeigt das aus der Definition der EFA-Geschäftsobjekte abgeleitete und über HL7 RIM Klassen ausgedrückte Informationsmodell des EFA-Konstrukts.

Prinzipiell schreibt die EFA-Spezifikation keine bestimmte interne Umsetzung dieses Informationsmodells vor, d.h. ein Hersteller kann dieses über beliebige Technologien abbilden. Normative Vorgaben bestehen jedoch bezüglich der Aussen-Semantik und der über Operationen der EFA-Dienste ausgetauschten Instanzen (von Ausschnitten) dieses Informationsmodells.

Die Aussen-Semantik kann dabei über die folgenden, in der obigen Darstellung enthaltenen Aussagen zusammengefasst werden:

• Jede Fallakte ist genau einem Patienten zugeordnet. Diese Beziehung ist für Berechtigte bidirektional auflösbar, d.h. zu einem Patienten können die zugehörigen Fallakten und zu einer gegebenen Fallakte der betroffene Patient ermittelt werden.
• Jede Fallakte dient genau einem klar abgrenzbaren Zweck. Pro Patient und Zweck kann es nur eine Fallakte geben.
• Zu jeder Fallakte gibt es zu jeder Zeit genau eine gültige Einwilligung des betroffenen Patienten. Die Fallakte ist von der Einwilligung abhängig, d.h. eine Rücknahme der Einwilligung bedingt das Schließen der Fallakte.
• Zu jeder Fallakte sind berechtigte EFA-Teilnehmer benannt, deren Berechtigungen sich aus ihren definierten Rollen der EFA-Nutzung ableiten.
• Eine Fallakte besteht aus einer oder mehr Partitionen. Jede Partition ist genau einer Fallakte zugeordnet. Auch hier besteht eine Abhängigkeitsbeziehung; mit Schließen der Fallakte werden auch die abhängigen Partitionen geschlossen und sind nicht mehr zugreifbar.
• Jede Partition wird bei einem EFA-Provider angelegt und verwaltet. Dieser ist für die sichere Speicherung der daran hängenden Daten sowie die Durchsetzung der definierten Berechtigungen bei Zugriffen auf die Partition verantwortlich.
• Datenobjekte der EFA werden in Partitionen verwaltet. Ein Datenobjekt kann mehreren Partitionen zugeordnet sein, sofern diese beim selben EFA-Provider angelegt sind.

PIM Data Structures

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02}

Die nachfolgend beschriebenen Objektklassen beschreiben die über Operationen der EFA-Dienste ausgetauschten Instanzen (von Ausschnitten) des EFA-Informationsmodells. Diese Klassen werden nachfolgend in der Abstraktionsstufe des EFA Service Functional Model unabhängig von einer konkreten technischen Umsetzung definiert.

patientID

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.01}

Die patientID ist ein eindeutiger Identifizierer eines Patienten innerhalb einer von einem EFA-Provider realisierten Affinity Domain. Sie bildet damit in der IHE-Semantik die "XAD-PID" ab (siehe IHE Cookbook).

Wenn eine patientID bei einem Operationsaufruf von einem EFA-Teilnehmer an einen EFA-Dienst übergeben wird, muss diese ID in der Affinity Domain des EFA-Providers registriert sein, d.h. das Clientsystem des EFA-Teilnehmers muss ggf. vor dem Dienstaufruf eine Abbildung der lokal genutzten Patienten-ID auf die EFA patientID der Domäne des EFA-Providers vornehmen.

Im Fall von in einem Peer-to-Peer-Verbund verteilt verwalteten Fallakten ist es nicht unwahrscheinlich, dass jeder Provider den selben Patienten unter einer anderen patientID führt. Um eine sichere Verknüpfung der verteilt verwalteten Partitionen einer Fallakte realisieren zu können, muss jeder Provider bei einer verteilten Akte eine Abbildung der von ihm genutzten patientID auf die von sämtlichen anderen beteiligten Providern genutzten patientIDs realisieren können. Analog zu der Nutzung der patientID in einem Single-Peer-Szenario gilt auch hier die Regel "Sender does it right", d.h. bevor eine Anfrage von einem Peer an einen anderen weitergeleitet wird, muss der initierende Peer die Überführung der patientID in die Domäne des Ziel-Peers vornehmen.

Da jede Fallakte eindeutig einem Patienten zugeordnet ist und jede Partition zu genau einer Fallakte gehört, ist auch jede Partition eindeutig einem Patienten zugeordnet. D.h. aus Sicht des Informationsmodells spielt es keine Rolle, ob eine EFA-Umsetzung die Patientenzuordnung ausschließlich auf Ebene der Fallakten verwaltet oder auch auf die Ebene der Partitionen herunter zieht.

purpose

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.02}

Die Klasse purpose kodiert den Zweck einer Fallakte und referenziert damit eindeutig auf einen "medizinischen Fall" des Patienten. Die Kodierung des Zwecks kann entweder über einen standardisierten Diagnosecode (z.B. ICD-10) oder die Referenzierung eines Vertrags (DMP, IV, etc.) erfolgen. Instanzen der Klasse purpose müssen den Zweck einer Akte ausschließlich über kodierte Werte aus einem vorab innerhalb einer Versorgungdomäne definierten Vokabular verwenden.

Da jede Fallakte eindeutig einem Zweck dient und jede Partition zu genau einer Fallakte gehört, ist auch jede Partition eindeutig einem Zweck zugeordnet. D.h. aus Sicht des Informationsmodells spielt es keine Rolle, ob eine EFA-Umsetzung die Zweckbindung ausschließlich auf Ebene der Fallakten verwaltet oder auch auf die Ebene der Partitionen herunter zieht.

ecrInfo

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.03}

consentInfo

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.04}

consentDoc

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.05}

partitionID

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.06}

partitionList

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.07}

ecrRef

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.08}

partitionInfo

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.09}

document

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.10}

docMetadata

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.11}

Attribut	Beschreibung
ID	Der im Kontext eines EFA-Providers eindeutige Bezeichner des Dokuments.
Externe ID	Der im Kontext des Quellsystems verwendete Bezeichner des Dokuments.
Dokumentklasse	Bezeichner für die grobe Einordnung des Dokuments in ein Klassifikationsschema.
Dokumenttyp	Bezeichner für die feine Einordnung des Dokuments in ein Klassifikationsschema.
Fachrichtung	Bezeichnung der Fachrichtung, in der das Dokument erstellt wurde.
Zeitraum der Leistungserbringung	Benennung des Zeitraums der Leistungserbringung, in deren Rahmen das Dokument erstellt wurde.
Dokumentformat	Verweis auf die innere Struktur des Dokuments und das Dateiformat. Dient der Dokumentdarstellung oder Dokumentverarbeitung.
Erstellungszeitpunkt	Benennt den Zeitpunkt, zu dem das Dokument erstellt wurde.
Dateigröße	Benennt die Datenmenge des Dokuments.
Fehlererkennender Code	Enthält einen Code, der zur Erkennung von Fehlern bei der Datenübertragung und Datenspeicherung verwendet werden kann.

docRelationship

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.12}

Querverweise und Referenzen

• EFA-2.0-Spezifikation