Informationsmodell der EFA Geschäftsobjekte
 |
Dieses Dokument gibt wieder:
Implementierungsleitfaden Informationsmodell der EFA Geschäftsobjekte (0.9). Die Teilmaterialien gehören der Kategorie cdaefa an. |
February 2013
Jörg Caumanns, Raik Kuhlisch , Ben Kraufmann
| Version: | 0.9 |
| Datum: | March 2013 |
| Status: | xxx |
| Verfahren: | {{{Verfahren}}} |
| Realm: |  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".
Inhaltsverzeichnis
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.
document
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.10}
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}
Die Klasse ecrInfo umfasst die Metadaten zu einer Fallakte. In der EFA-Version 2.0 ist diese Klasse leer und lediglich ein auf der logischen Ebene definierter Platzhalter für zukünftige Erweiterungen oder in einer Versorgungsdomäne definierte spezielle Profile dieser Spezifikation.
 |
Der Verzicht auf normativ vorgegebene Metadaten zu einer Akte bringt den Vorteil einer deutlich einfacheren und flexibleren Umsetzbarkeit der Spezifikation auf bestehenden Standards (gängige Aktenstandards wie IHE XDS unterstützen keine logischen Konstrukte oberhalb eines weitgehend semantikfreien Ordner, d.h. ein Container für Metadaten einer Fallakte wäre in jedem Fall eine proprietäre Ergänzung). Um dieses zu realisieren wurde im Vergleich zur EFA-1.2-Spezifikation das Konstrukt der Partitionen deutlich gestärkt und auch die Funktionalität stärker auf dieses Konstrukt fokussiert:
|
consentInfo
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.04}
Die Klasse consentInfo bildet den Inhalt einer Patienteneinwilligung in so weit maschinenlesbar ab, als dass darüber eine automatische Konfiguration einer Fallakte und ihrer Zugriffsrechte möglich ist. consentInfo ist ein EFA-2.0-Profil auf dem im Domänenmodell "Einwilligung zur zweckgebundenen Kommunikation" definierten Konzeptmodell und dem daraus abgeleiteten Informationsmodell einer Einwilligungserklärung. Im Einzelnen umfasst dieses Profil die folgenden Einschränkungen zu dem im Leitfaden "Einwilligung" definierten Informationsmodell:
- Die Kodierung des Zwecks unterliegt den im Abschnitt zur Klasse "purpose" definierten Vorgaben. Es müssen die im EFA-2.0-XDS-Binding festgelegten Codesysteme verwendet werden.
- Die maschinenlesbare Darstellung einer Einwilligung muss eine Umsetzung der im Interaktionsmuster "Fallakte anlegen" beschriebenen Ausnahmeszenarien erlauben. Dies bedeutet, dass per Konvention oder per expliziter Aussage erkennbar sein muss, wie die Anlage einer Akte realisiert wird, wenn bereits eine Akte zu den benannten Zweck besteht.
Die technischen Umsetzung der Klasse consentInfo kann über jedes Binding erfolgen, dass den Leitfaden "Einwilligung" umsetzt. Hierbei sind die benannten Einschränkungen aus dem Informationsmodell in das Binding zu übernehmen.
Es kann zu jedem Zeitpunkt nur eine aktuelle gültige Einwilligung geben, d.h. mit dem Einstellen eines validen consentInfo-Objekts in eine Fallakte werden automatisch alle zuvor eingestellten consentInfo-Objekte ungültig.
consentDoc
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.05}
Die Klasse consentDoc ist eine Spezialisierung der Klasse document und umfasst ein vom EFA-Provider inhaltlich nicht weiter verarbeitetes Dokument, dessen Gegenstand eine Patienteneinwilligung ist.
Es kann zu jedem Zeitpunkt nur eine aktuelle gültige Einwilligung geben, die dem EFA-Provider gegenüber über die Klasse consentInfo dargestellt wird. Zusammen mit der Bekanntmachung einer Einwilligung über ein consentInfo-Objekt kann eine Instanz der Klasse consentDoc als menschenlesbares Pendant in die betroffene Akte eingestellt werden. Das consentDoc-Objekt wird dabei als Ergänzung des consentInfo-Objekts deklariert.
Ein Einstellen eines consentInfo-Objekts ohne korrespondierendes consentDoc-Objekt ist möglich. Das Einstellen eines consentDoc-Objekts ist nur möglich, wenn dieses über eine Ergänzt-Beziehung mit einem consentInfo-Objekt verknüpft ist.
partitionID
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.06}
Die Klasse partitionID beschreibt eine eindeutige Referenz auf eine Partition einer Fallakte. Bestandteil der Referenz sind
- ein Verweis auf den EFA-Provider, der die Partition verwaltet, sowie
- ein von diesem Provider eindeutig auflösbarer Identifizierer.
partitionList
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.07}
Die Klasse partitionList beschreibt eine Menge von Partitionen, die Fallakten des selben Patienten zugeordnet sind. Jede Partition wird durch ein partition-Objekt repräsentiert. Mit diesem Objekt müssen vom EFA-Provider im Rahmen der Operation listPartitions die folgenden Informationen zu einer Partition verknüpft sein:
- partitionID
- Identifizierer der Partition, über den diese Partition eindeutig referenziert werden kann. Eine solche Referenzierung ist vor allem zum Einstellen von Daten in eine Partition und zum Auslesen einer Partition erforderlich.
- ecrRef
- Verweis auf die Fallakte, der die Partition zugeordnet ist. Jede Partition ist genau einer Fallakte zugeordnet.
- Metadaten der Partition
- Die genaue Festlegung der von einem EFA-Provider zu einer Partition verwalteten Metadaten ist vom konkreten Binding abhängig. Jedes Binding muss aber mindestens die in der Klasse partitionInfo enthaltenen Angaben unterstützen und als Teil des eine Partition repräsentierenden partition-Objekts bei der Abfrage der Partitionen einer Fallakte an den Aufrufer zurück liefern.
ecrRef
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.08}
In der EFA-2.0-Spezifikation ist kein orginärer Identifier für Fallakten definiert. Wie schon im Zusammenhang mit der Klasse ecrInfo beschrieben, wird durch die Möglichkeit eines vollständigen Verzichts auf ein manifestiertes Fallakten-Objekt eine flexiblere und einfachere Umsetzung der EFA-Spezifikation über bestehende Standards unterstützt.
Um dennoch Fallakten eindeutig referenzieren zu können, wird die Tatsache ausgenutzt, dass pro Patient (patientID) und Zweck (purpose) per Definition nur eine Fallakte existieren darf. Hiermit bilden die in der Klasse ecrRef zusammengefassten Angaben zu Patient und Zweck zusammen eine eindeutige Referenz auf eine Fallakten.
partitionInfo
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.09}
Der Zugriff auf die Inhalte einer Fallakte erfolgt durch Auflisten der Partitionen der Akte und anschließendes Browsing bzw. Suchen/Filtern über den in den einzelnen Partitionen enthaltenen Daten. Damit die IT-Systeme der EFA-Teilnehmer dieses Ablauf optimieren und an verschiedene Zugriffsmetaphern (z.B. Anzeigen seit dem letzten Zugriff neu hinzugekommener Daten) anpassen können, werden Partitionen mit Metadaten versehen. Hierbei muss ein Binding zumindest die folgenden Metadaten unterstützen:
| Attribut | Beschreibung | Verwendung |
|---|---|---|
| partitionID | Eindeutiger Identifizierer der Partition | Die ID der Partition wird beim Anlegen einer Partition abhängig vom genutzten Binding durch den EFA-Teilnehmer oder den EFA-Provider festgelegt. Sie muss beim Auslesen der Partitionsdaten vom EFA-Provider zurück geliefert werden. Die ID der Partition wird zum Abruf von Daten aus einer Partition und zum Einstellen von Daten in eine Partition benötigt. |
| Titel (mandatory) | Für den EFA-Teilnehmer verständliche Bezeichnung der Partition, aus der hervorgeht, welche Daten in der Partition zu erwarten sind (z.B. "Nachsorge nach Bypass-Operation"). Aus Datenschutzgründen darf dieser Titel keine identifizierenden Angaben zum Patient enthalten. | Der Titel wird beim Anlegen einer Partition gesetzt und unverändert beim Auslesen der Partitionsdaten vom EFA-Provider zurück geliefert. Dieses Attribut kann z.B. genutzt werden, um einem EFA-Teilnehmer beim Browsing über einer Akte zunächst die verfügbaren Partitionen anzuzeigen und nur Daten aus vom Teilnehmer als für die aktuelle Behandlungssituation relevant markierten Partitionen abzurufen. |
| Klassifizierung (optional) | In Ergänzung zum Titel kann eine Partition auch eine maschinenlesbare Klassifizierung enthalten. Beispiele hierfür finden sind administrative Informationen, z.B. ob es sich um Daten zu einem Krankenhausaufenthalt handelt. | Klassifizierungen müssen beim Anlegen einer Partition gesetzt und vom EFA-Provider unverändert beim Auslesen der Partitionsdaten vom EFA-Provider zurück geliefert werden. |
| Erfasster Behandlungszeitraum (mandatory) | Zeitraum der über die Partition unterstützten Behandlungsepisode. Hierbei werden das Anfangsdatum der Episode sowie das Datum der letzten Änderung der Inhalte der Partition verwaltet. | Das Anfangsdatum der Episode wird beim beim Anlegen einer Partition gesetzt. Fehlt diese Angabe, wird das Datum der Anlage der Partition als Anfang der begleiteten Episode angenommen. Das Datum der letzten Änderung wird vom EFA-Provider bei jeder Einstellen von Daten in die Partition neu gesetzt und beim Auslesen der Partitionsdaten mitgegeben. Ein EFA-Teilnehmersystem kann Partitionen anhand dieser Angaben in eine chronologische Reihenfolge bringen oder effizient nach den aktuellsten Daten durchsuchen. |
| Verantwortliche Organisation (optional) | Bezeichner der Organisation, die für die Anlage der Partition und die Pflege der darin enthaltenen Inhalte verantwortlich ist. | Sofern diese Information nicht beim Anlegen einer Partition gesetzt wird, gilt die Organisation des die Partition anlegenden Leistungserbringers als für die Partition verantwortlich. Diese Information muss beim Auslesen der Partitionsdaten bereit gestellt werden. |
Ein EFA-Binding kann weitere Attribute für Partitionen definieren. Diese müssen jedoch von einem clientseitigen Teilnehmersystem nicht zwingend verarbeitet werden.
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}
