EFA Dienste
(Teildokument von CDA für die elektronische Fallakte)
K (Markup-Fehler behoben) |
|||
| (9 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| − | {{ | + | {{DocumentPart |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
}} | }} | ||
| − | |||
''Anmerkung: Die Kürzel unter den einzelnen Überschriften 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.<br>Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".'' | ''Anmerkung: Die Kürzel unter den einzelnen Überschriften 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.<br>Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".'' | ||
---- | ---- | ||
| − | == Akteure der EFA | + | == Technische Akteure der EFA == |
| + | <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eist.01}</tt> | ||
Die logische Anwendungsebene einer Fallakten-Infrastruktur besteht im einfachsten Fall aus fünf Klassen von Akteuren: | Die logische Anwendungsebene einer Fallakten-Infrastruktur besteht im einfachsten Fall aus fünf Klassen von Akteuren: | ||
* Ein EFA-Kontext-Manager ('''eCR Context Manager''') baut den Sicherheitskontext zur Nutzung von Fallakten auf und verwaltet die darin bereit gestellten Sicherheitsnachweise des EFA-Teilnehmers. | * Ein EFA-Kontext-Manager ('''eCR Context Manager''') baut den Sicherheitskontext zur Nutzung von Fallakten auf und verwaltet die darin bereit gestellten Sicherheitsnachweise des EFA-Teilnehmers. | ||
* Ein EFA-Ressource-Manager('''eCR Resource Manager''') stellt ein Verzeichnis zur Verwaltung von Fallakten und EFA-Partitionen bereit. Mit dem selben Patienten und dem selben Zweck verbundene Partitionen bilden eine Fallakte. | * Ein EFA-Ressource-Manager('''eCR Resource Manager''') stellt ein Verzeichnis zur Verwaltung von Fallakten und EFA-Partitionen bereit. Mit dem selben Patienten und dem selben Zweck verbundene Partitionen bilden eine Fallakte. | ||
| − | * Ein EFA-Daten-Register ('''eCR Document Registry''') stellt ein | + | * Ein EFA-Daten-Register ('''eCR Document Registry''') stellt ein Verzeichnis zur Verwaltung von Dokumenten bereit. In einem regionalen Gesundheitsnetz kann ein einzelner EFA-Provider das EFA-Register für das gesamte Netzwerk anbieten. |
| − | * Ein EFA-Speichersystem ('''eCR Repository''') hält die registrierten Dokumente vor und stellt sie für berechtigte Nutzer zum Abruf bereit. Jeder EFA- | + | * Ein EFA-Speichersystem ('''eCR Document Repository''') hält die registrierten Dokumente vor und stellt sie für berechtigte Nutzer zum Abruf bereit. Jeder EFA-Provider kann ein eigenes EFA-Speichersystem bereitstellen und an das EFA-Register anbinden. |
| − | * Ein EFA-Teilnehmersystem ('''eCR Consumer''') bildet eine Nutzerschnittstelle ab, über die ein Arzt Behandlungsdaten anderer Ärzte aus an einem EFA-Register registrierten Speichersystemen abrufen kann bzw. in einem Speichersystem verwaltete Behandlungsdaten am EFA-Register registrieren kann. | + | * Ein EFA-Teilnehmersystem ('''eCR Consumer''') bildet eine Nutzerschnittstelle ab, über die ein Arzt Behandlungsdaten anderer Ärzte aus an einem EFA-Daten-Register registrierten Speichersystemen abrufen kann bzw. in einem Speichersystem verwaltete Behandlungsdaten am EFA-Register registrieren kann. |
Hinzu kommen zwei Klassen von Sicherheitstoken-Diensten, die jeweils Sicherheitsnachweise zum Aufbau eines zwischen EFA-Teilnehmersystem und EFA-Fachdienst (Register bzw. Speichersystem) geteilten Sicherheitskontextes bereit stellen: | Hinzu kommen zwei Klassen von Sicherheitstoken-Diensten, die jeweils Sicherheitsnachweise zum Aufbau eines zwischen EFA-Teilnehmersystem und EFA-Fachdienst (Register bzw. Speichersystem) geteilten Sicherheitskontextes bereit stellen: | ||
| Zeile 35: | Zeile 22: | ||
[[Datei:PIM_EFA_Dienste.png|480px]] | [[Datei:PIM_EFA_Dienste.png|480px]] | ||
| − | |||
| + | == Umsetzungsoptionen für EFA-Speichersysteme (Informativ) == | ||
| + | <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eist.02}</tt> | ||
| + | |||
| + | Die EFA nutzt zur Umsetzung der einzelnen Systemkomponenten das IHE Profil "Cross-Enterprise Document Sharing (XDS)", das in Bezug auf die Verteilung von Datenspeichern vielfältige Umsetzungsoptionen erlaubt. Die EFAv2.0 Spezifikation gibt hier kein festes Deployment von Datenspeichern vor, sondern erlaubt alle in IHE XDS vorgesehenen Umsetzungen der Datenspeicher, sofern | ||
| + | * die Regeln für den Aufbau einer [[cdaefa:EFA_Provider|Affinity Domain] nicht verletzt werden und | ||
| + | * der Datenspeicher nur Dokumente an dem EFA-Daten-Register registriert, die den Vorgaben einer von diesem Register unterstützten [[cdaefa:EFA_Provider|Versorgungsdomäne]] entsprechen. | ||
| + | |||
| + | Die nachfolgende Grafik skizziert vier mögliche Szenarien, wie medizinische Dokumente in einer EFA Affinity Domain verwaltet werden können. | ||
| + | |||
| + | [[Datei:EFA_Repository_Deployment.png|600px]] | ||
| + | |||
| + | ;EFA-Teilnehmer mit eigenem XDS DocumentRepository (links außen) | ||
| + | :Ein EFA-Teilnehmer kann ein eigenes XDS DocumentRepository betreiben, in dem er - z.B. zur einrichtungsinternen Integration der Daten aus vorhandenen Subsystemen - EFA-relevate Dokumente ablegt. Diese werden über die Mechansimen der EFA bei einem EFA-Provider registriert. Alle Suchanfragen laufen über das Register beim EFA-Provider, der Abruf der Dokumenten erfolgt jedoch direkt aus dem XDS DocumentRepository des Teilnehmers. In diesem Szenario verbleiben die medizinischen Daten in der Einrichtung in der sie erstellt wurden. Eine Mehrfachnutzung der Daten für interne Behandlungsabläufe und einrichtungsübergreifende Kooperationen ist möglich, sofern dieses über den Behandlungsvertrag (interne Nutzung) und die Einwilligung des Patienten zur EFA-Nutzung abgedeckt ist. | ||
| + | ;EFA-Teilnehmer mit EFA-Facade vor internem Speichersystem (mitte links) | ||
| + | :Eine interne Vorhaltung der EFA-relevanten Dokumente ist auch ohne dediziertes XDS DocumentRepository möglich, sofern das datenhaltende System die Schnittstelle des EFA Datenspeichers bereit stellt. Hiermit kann eine redundante Datenhaltung vollständig vermieden werden. Die Abläufe im Zusammenspiel mit dem EFA-Daten-Register und anderen EFA-Teilnehmern sind analog zu dem oben skizzierten Szenario umzusetzen. | ||
| + | ;EFA-Teilnehmer ohne eigenes EFA-Speichersystem | ||
| + | :Arztpraxen und Krankenhäuser können alternativ auch ein vom EFA-Provider bereitzustellendes Speichersystem nutzen und ihre EFA-relevanten Daten über von der EFA bereitgestellte Mechanismen in dieses einspielen. Die Registrierung der Daten am EFA-Daten-Register wird in diesem Fall vom Speichersystem übernommen. Bei diesem Szenario liegt eine Auftragsdatenverarbeitung durch den EFA-Provider vor, die entsprechend über eine Zustimmung des Patienten autorisiert werden muss. | ||
| + | |||
| + | Ein Szenario, in dem ein Krankenhaus als EFA-Provider gleichzeitig auch EFA-Teilnehmer ist, kann gemäß der auf der linken Seite der Abbildung dargestellten Umsetzungsoptionen realisiert werden: | ||
| + | * ein ggf. schon bestehendes XDS DocumentRepository wird an das EFA-Daten-Register als EFA-Speichersystem angebunden. Dieses Speichersystem zur Vorhaltung der eigenen Daten muss von dem Speichersystem für die Vorhaltung externer Daten (Optionen auf der rechten Seite der Abbildung) getrennt sein, da für die Umsetzung der Auftragsdatenverarbeitung zur Speicherung externer Daten andere Regularien gelten, die ggf. auch andere technische Sicherheitsmechanismen erfordern. | ||
| + | * IHE XDS erlaubt die Integration von Quellsystem und Datenspeicher (''Integrated Document Source and Document Repository''). Über diesen Mechanismus kann z.B. ein EFA-Daten bereitstellendes IT-System des Krankenhauses direkt an das EFA-Daten-Register angebunden werden und seine EFA-relevanten Daten an diesem registrieren ohne dass dabei die Daten selbst aus dem Quellsystem ausgespielt werden müssten. Für den Abruf der Daten muss das Quellsystem jedoch logisch als EFA-Datenspiecher agieren können, d.h. die in der EFA-Spezifikation definierten Schnittstellen und Sicherheitsmaßnahmen eines EFA-Datenspeichers implementieren. | ||
| + | |||
| + | |||
| + | |||
| + | ---- | ||
| + | |||
| + | |||
| + | {{NoteBox|'''Referenzen und Querverweise''' | ||
* [[cdaefa:EFA_Kommunikationsmuster|EFA Kommunikationsmuster]] | * [[cdaefa:EFA_Kommunikationsmuster|EFA Kommunikationsmuster]] | ||
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]] | * [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]] | ||
| + | <nowiki></nowiki> | ||
| + | }} | ||
Aktuelle Version vom 26. Januar 2015, 16:02 Uhr
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
Anmerkung: Die Kürzel unter den einzelnen Überschriften 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".
Technische Akteure der EFA
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eist.01}
Die logische Anwendungsebene einer Fallakten-Infrastruktur besteht im einfachsten Fall aus fünf Klassen von Akteuren:
- Ein EFA-Kontext-Manager (eCR Context Manager) baut den Sicherheitskontext zur Nutzung von Fallakten auf und verwaltet die darin bereit gestellten Sicherheitsnachweise des EFA-Teilnehmers.
- Ein EFA-Ressource-Manager(eCR Resource Manager) stellt ein Verzeichnis zur Verwaltung von Fallakten und EFA-Partitionen bereit. Mit dem selben Patienten und dem selben Zweck verbundene Partitionen bilden eine Fallakte.
- Ein EFA-Daten-Register (eCR Document Registry) stellt ein Verzeichnis zur Verwaltung von Dokumenten bereit. In einem regionalen Gesundheitsnetz kann ein einzelner EFA-Provider das EFA-Register für das gesamte Netzwerk anbieten.
- Ein EFA-Speichersystem (eCR Document Repository) hält die registrierten Dokumente vor und stellt sie für berechtigte Nutzer zum Abruf bereit. Jeder EFA-Provider kann ein eigenes EFA-Speichersystem bereitstellen und an das EFA-Register anbinden.
- Ein EFA-Teilnehmersystem (eCR Consumer) bildet eine Nutzerschnittstelle ab, über die ein Arzt Behandlungsdaten anderer Ärzte aus an einem EFA-Daten-Register registrierten Speichersystemen abrufen kann bzw. in einem Speichersystem verwaltete Behandlungsdaten am EFA-Register registrieren kann.
Hinzu kommen zwei Klassen von Sicherheitstoken-Diensten, die jeweils Sicherheitsnachweise zum Aufbau eines zwischen EFA-Teilnehmersystem und EFA-Fachdienst (Register bzw. Speichersystem) geteilten Sicherheitskontextes bereit stellen:
- Ein Identity Provider stellt einen von allen anderen EFA-Akteuren als vertrauenswürdig akzeptierten Identitätsnachweis für authentifizierte Nutzer aus. Der Identity Provider unterstützt potenziell beliebige Verfahren der Authentifizierung (z. B. mittels Passwort, HBA oder SMC-B).
- Ein Policy Provider liefert die für den aufrufenden Nutzer gültigen Berechtigungsregeln (Policy) auf einer spezifischen Fallakte.
Der Aufruf der Sicherheitstoken-Dienste und die Verwaltung der von diesen abgerufenen Sicherheitsnachweise wird gegenüber dem EFA-Teilnehmersystem über den EFA-Kontext-Manager gekapselt.
Umsetzungsoptionen für EFA-Speichersysteme (Informativ)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eist.02}
Die EFA nutzt zur Umsetzung der einzelnen Systemkomponenten das IHE Profil "Cross-Enterprise Document Sharing (XDS)", das in Bezug auf die Verteilung von Datenspeichern vielfältige Umsetzungsoptionen erlaubt. Die EFAv2.0 Spezifikation gibt hier kein festes Deployment von Datenspeichern vor, sondern erlaubt alle in IHE XDS vorgesehenen Umsetzungen der Datenspeicher, sofern
- die Regeln für den Aufbau einer [[cdaefa:EFA_Provider|Affinity Domain] nicht verletzt werden und
- der Datenspeicher nur Dokumente an dem EFA-Daten-Register registriert, die den Vorgaben einer von diesem Register unterstützten Versorgungsdomäne entsprechen.
Die nachfolgende Grafik skizziert vier mögliche Szenarien, wie medizinische Dokumente in einer EFA Affinity Domain verwaltet werden können.
- EFA-Teilnehmer mit eigenem XDS DocumentRepository (links außen)
- Ein EFA-Teilnehmer kann ein eigenes XDS DocumentRepository betreiben, in dem er - z.B. zur einrichtungsinternen Integration der Daten aus vorhandenen Subsystemen - EFA-relevate Dokumente ablegt. Diese werden über die Mechansimen der EFA bei einem EFA-Provider registriert. Alle Suchanfragen laufen über das Register beim EFA-Provider, der Abruf der Dokumenten erfolgt jedoch direkt aus dem XDS DocumentRepository des Teilnehmers. In diesem Szenario verbleiben die medizinischen Daten in der Einrichtung in der sie erstellt wurden. Eine Mehrfachnutzung der Daten für interne Behandlungsabläufe und einrichtungsübergreifende Kooperationen ist möglich, sofern dieses über den Behandlungsvertrag (interne Nutzung) und die Einwilligung des Patienten zur EFA-Nutzung abgedeckt ist.
- EFA-Teilnehmer mit EFA-Facade vor internem Speichersystem (mitte links)
- Eine interne Vorhaltung der EFA-relevanten Dokumente ist auch ohne dediziertes XDS DocumentRepository möglich, sofern das datenhaltende System die Schnittstelle des EFA Datenspeichers bereit stellt. Hiermit kann eine redundante Datenhaltung vollständig vermieden werden. Die Abläufe im Zusammenspiel mit dem EFA-Daten-Register und anderen EFA-Teilnehmern sind analog zu dem oben skizzierten Szenario umzusetzen.
- EFA-Teilnehmer ohne eigenes EFA-Speichersystem
- Arztpraxen und Krankenhäuser können alternativ auch ein vom EFA-Provider bereitzustellendes Speichersystem nutzen und ihre EFA-relevanten Daten über von der EFA bereitgestellte Mechanismen in dieses einspielen. Die Registrierung der Daten am EFA-Daten-Register wird in diesem Fall vom Speichersystem übernommen. Bei diesem Szenario liegt eine Auftragsdatenverarbeitung durch den EFA-Provider vor, die entsprechend über eine Zustimmung des Patienten autorisiert werden muss.
Ein Szenario, in dem ein Krankenhaus als EFA-Provider gleichzeitig auch EFA-Teilnehmer ist, kann gemäß der auf der linken Seite der Abbildung dargestellten Umsetzungsoptionen realisiert werden:
- ein ggf. schon bestehendes XDS DocumentRepository wird an das EFA-Daten-Register als EFA-Speichersystem angebunden. Dieses Speichersystem zur Vorhaltung der eigenen Daten muss von dem Speichersystem für die Vorhaltung externer Daten (Optionen auf der rechten Seite der Abbildung) getrennt sein, da für die Umsetzung der Auftragsdatenverarbeitung zur Speicherung externer Daten andere Regularien gelten, die ggf. auch andere technische Sicherheitsmechanismen erfordern.
- IHE XDS erlaubt die Integration von Quellsystem und Datenspeicher (Integrated Document Source and Document Repository). Über diesen Mechanismus kann z.B. ein EFA-Daten bereitstellendes IT-System des Krankenhauses direkt an das EFA-Daten-Register angebunden werden und seine EFA-relevanten Daten an diesem registrieren ohne dass dabei die Daten selbst aus dem Quellsystem ausgespielt werden müssten. Für den Abruf der Daten muss das Quellsystem jedoch logisch als EFA-Datenspiecher agieren können, d.h. die in der EFA-Spezifikation definierten Schnittstellen und Sicherheitsmaßnahmen eines EFA-Datenspeichers implementieren.
 |
Referenzen und Querverweise |
