Gegenstand der Konformitätsprüfung

Aus Hl7wiki
(Teildokument von CDA für die elektronische Fallakte)
Wechseln zu: Navigation, Suche
(→‎Gegenstand des EFAv2.0 Konformitätsnachweises)
K (Markup-Fehler behoben)
 
(8 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
−
= Gegenstand des EFAv2.0 Konformitätsnachweises =
+
{{DocumentPart
 +
}}
 +
 
 +
== Gegenstand des EFAv2.0 Konformitätsnachweises ==
 
Das Verfahren zur Ausstellung von Konformitätsnachweisen für EFAv2.0 konforme Produkte ist für vier Produktgruppen anwendbar. Diese sind in der nachfolgenden Abbildung im Überblick dargestellt und werden in den folgenden Abschnitten genauer beschrieben.
 
Das Verfahren zur Ausstellung von Konformitätsnachweisen für EFAv2.0 konforme Produkte ist für vier Produktgruppen anwendbar. Diese sind in der nachfolgenden Abbildung im Überblick dargestellt und werden in den folgenden Abschnitten genauer beschrieben.
  
Zeile 5: Zeile 8:
  
  
−
== EFA-Provider ==
+
=== EFA-Provider ===
 
Ein Produkt, das einen EFAv2.0 konformen „EFA Provider“ realisiert, besitzt die folgenden Eigenschaften:
 
Ein Produkt, das einen EFAv2.0 konformen „EFA Provider“ realisiert, besitzt die folgenden Eigenschaften:
−
* Das Produkt MUSS die logischen EFA-Komponenten „ECR Resource Manager“, „ECR Document Registry“ und „ECR Document Repository“ umsetzen. Das Verhalten dieser Komponenten MUSS den für diese Komponenten definierten Kommunikationsmustern und Service Functional Models entsprechen.
+
* Das Produkt MUSS die [[cdaefa:EFA_Dienste|logischen EFA-Komponenten]] „ECR Resource Manager“, „ECR Document Registry“ und „ECR Document Repository“ umsetzen. Das Verhalten dieser Komponenten MUSS den für diese Komponenten definierten [[cdaefa:EFA_Kommunikationsmuster|Kommunikationsmustern]] und [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|Service Functional Models]] entsprechen.
 
* Das Produkt KANN die logischen EFA-Komponenten „Identity Provider“ und „Policy Provider“ umsetzen. Das Verhalten dieser Komponenten MUSS den für diese Komponenten definierten Kommunikationsmustern und Service Functional Models entsprechen.
 
* Das Produkt KANN die logischen EFA-Komponenten „Identity Provider“ und „Policy Provider“ umsetzen. Das Verhalten dieser Komponenten MUSS den für diese Komponenten definierten Kommunikationsmustern und Service Functional Models entsprechen.
−
* Das Produkt MUSS die folgenden EFAv2.0-Interaktionsmuster funktional und mit der definierten Anwendungssemantik unterstützen:
+
* Das Produkt MUSS die folgenden [[cdaefa:Interaktionsmuster_der_EFA|EFAv2.0-Interaktionsmuster]] funktional und mit der definierten Anwendungssemantik unterstützen:
−
** Anlegen einer Fallakte
+
** [[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
−
** Anlegen und Registrieren einer Partition
+
** [[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
−
** Einstellen von Datenobjekten
+
** [[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
−
** Auffinden der Fallakten eines Patienten
+
** [[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
−
** Browsing über eine Akte oder eine Partition
+
** [[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte oder eine Partition]]
−
** Abruf von Datenobjekten
+
** [[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
−
** Schließen einer Fallakte
+
** [[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
−
** optional: Invalidieren von Datenobjekten
 
−
** optional: Ändern der Einwilligung
 
−
** optional: Autorisierung eines weiteren Teilnehmers
 
−
** Client Authentisierung (Nutzer kann sich über das Produkt gegenüber dem Provider authentisieren)
 
  
−
* Das Produkt MUSS für alle umgesetzten Service Functional Models die in der EFAv2.0-Spezifikation definierten Bindings implementieren:
+
* Das Produkt MUSS mindestens die folgenden, in der EFAv2.0-Spezifikation definierten [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|Service Functional Models]] mitsamt der zugehörigen [[cdaefa:EFA_XDS/XDR_Bindings|IHE-Bindings]] implementieren:
−
** optional: createECR
+
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#createPartition|createPartition]]
−
** createPartition  
+
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listPartitions|listPartitions]]
−
** optional: closeECR
+
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listPartitionContent|listPartitionContent]]
−
** listPartitions
+
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|provideData]]
−
** optional: registerConsent
+
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#retrieveData|retrieveData]]
−
** optional: registerData
+
** [[cdaefa:EFA_Identity_Provider_SFM|requestHPIdentityAssertion]] (nur wenn ein Identity Provider Bestandteil des Produkts ist)
−
** listPartitionContent
 
−
** provideData
 
−
** retrieveData
 
−
** requestHPIdentityAssertion (nur wenn Client-Authentisierung Bestandteil des Produkts ist)
 
−
** optional: requestPolicy
 
  
 
* Das Produkt MUSS die folgenden Eigenschaften in Bezug auf Sicherheit und Datenschutz besitzen:
 
* Das Produkt MUSS die folgenden Eigenschaften in Bezug auf Sicherheit und Datenschutz besitzen:
−
** Bei allen Aufrufen wird eine EFA Identity Assertion gemäß EFAv2.0 Spezifikation im SOAP Header erwartet und geprüft (Anmerkung: Abweichungen in der Kodierung der Attribute sind zulässig). Die Prüfung stellt Integrität, Authentizität und Validität der Assertions sicher.
+
** Bei allen Aufrufen wird eine [[cdaefa:EFA_Identity_Assertion_SAML2_Binding|EFA Identity Assertion]] gemäß EFAv2.0 Spezifikation im SOAP Header erwartet und geprüft (Anmerkung: Abweichungen in der Kodierung der Attribute sind zulässig). Die Prüfung stellt Integrität, Authentizität und Validität der Assertions sicher.
−
** optional: Eine im SOAP Header enthaltene EFA Policy Assertion kann verarbeitet werden.  
+
** optional: Eine im SOAP Header enthaltene [[cdaefa:EFA_Policy_Assertion_SAML2_Binding|EFA Policy Assertion]] kann verarbeitet werden.  
 
** Bei allen Anfragen werden die Existenz einer Einwilligung und die Berechtigung des Aufrufers geprüft
 
** Bei allen Anfragen werden die Existenz einer Einwilligung und die Berechtigung des Aufrufers geprüft
 
** Für Anfragen akzeptierte Patienten-IDs (XPID) können durch Dritte nicht einer Person zugeordnet werden
 
** Für Anfragen akzeptierte Patienten-IDs (XPID) können durch Dritte nicht einer Person zugeordnet werden
Zeile 45: Zeile 39:
 
** Vorgaben für den sicheren Betrieb der EFA-Consumer-Funktionalität des Produkts sind definiert und liegen schriftlich vor.
 
** Vorgaben für den sicheren Betrieb der EFA-Consumer-Funktionalität des Produkts sind definiert und liegen schriftlich vor.
  
−
== EFA-Consumer ==
+
=== EFA-Consumer ===
 
Ein EFA-Consumer (EFA-Client) kann entweder direkt auf die Dienste des EFA-Providers zugreifen oder hierzu die vereinfachte Schnittstelle eines EFA-Connectors nutzen. Beide Produktvarianten können EFAv2.0-konform realisiert werden.
 
Ein EFA-Consumer (EFA-Client) kann entweder direkt auf die Dienste des EFA-Providers zugreifen oder hierzu die vereinfachte Schnittstelle eines EFA-Connectors nutzen. Beide Produktvarianten können EFAv2.0-konform realisiert werden.
 +
 +
==== Direkte Anbindung eines EFA-Consumer an einen EFA-Provider ====
 
Ein Produkt, das einen EFAv2.0 konformen „EFA Consumer (direkte Anbindung an EFA-Provider)“ realisiert, besitzt die folgenden Eigenschaften:
 
Ein Produkt, das einen EFAv2.0 konformen „EFA Consumer (direkte Anbindung an EFA-Provider)“ realisiert, besitzt die folgenden Eigenschaften:
−
- Das Produkt MUSS die logischen EFA-Komponenten „EFA Teilnehmersystem“ und „EFA Kontext Manager“ umsetzen. Das Verhalten dieser Komponenten MUSS den für diese Komponenten definierten Kommunikationsmustern und Service Functional Models entsprechen.
+
* Das Produkt MUSS die [[cdaefa:EFA_Dienste|logischen EFA-Komponenten]] „EFA Teilnehmersystem“ und „EFA Kontext Manager“ umsetzen. Das Verhalten dieser Komponenten MUSS den für diese Komponenten definierten [[cdaefa:EFA_Kommunikationsmuster|Kommunikationsmustern]] und [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|Service Functional Models]] entsprechen.
−
- Das Produkt MUSS die in Anhang B1 dieses Dokuments aufgeführten EFAv2.0-Interaktionsmuster funktional und mit der definierten Anwendungssemantik unterstützen.
+
* Das Produkt MUSS die folgenden [[cdaefa:Interaktionsmuster_der_EFA|EFAv2.0-Interaktionsmuster]] funktional und mit der definierten Anwendungssemantik unterstützen:
−
- Das Produkt MUSS eine grafische Benutzerschnittstelle bereitstellen, über die ein Nutzer die umgesetzten Interaktionsmuster nutzen kann.
+
** [[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
−
- Das Produkt MUSS für alle umgesetzten Service Functional Models die in der EFAv2.0-Spezifikation definierten und in Anhang B1 dieses Dokuments aufgeführten Bindings implementieren.
+
** [[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
−
- Das Produkt MUSS die in Anhang B1 dieses Dokuments aufgeführten Eigenschaften in Bezug auf Sicherheit und Datenschutz besitzen.  
+
** [[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
 +
** [[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
 +
** [[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte oder eine Partition]]
 +
** [[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
 +
** [[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
 +
** Client Authentisierung (Nutzer kann sich über das Produkt gegenüber dem Provider authentisieren)
 +
* Das Produkt MUSS eine grafische Benutzerschnittstelle bereitstellen, über die ein Nutzer die umgesetzten Interaktionsmuster nutzen kann.
 +
* Das Produkt MUSS mindestens die folgenden, in der EFAv2.0-Spezifikation definierten [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|Service Functional Models]] mitsamt der zugehörigen [[cdaefa:EFA_XDS/XDR_Bindings|IHE-Bindings]] implementieren:
 +
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#createPartition|createPartition]]
 +
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listPartitions|listPartitions]]
 +
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listPartitionContent|listPartitionContent]]
 +
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|provideData]]
 +
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#retrieveData|retrieveData]]
 +
** [[cdaefa:EFA_Identity_Provider_SFM|requestHPIdentityAssertion]]
 +
* Das Produkt MUSS die folgenden Eigenschaften in Bezug auf Sicherheit und Datenschutz besitzen:
 +
** Bei allen Aufrufen wird eine [[cdaefa:EFA_Identity_Assertion_SAML2_Binding|EFA Identity Assertion]] gemäß EFAv2.0 Spezifikation im SOAP übermittelt (Anmerkung: Abweichungen in der Kodierung der Attribute sind zulässig). Der Erstellung der Assertion liegt eine sichere Authentisierung zugrunde.
 +
** Für Anfragen genutzte Patienten-IDs (XPID) können durch Dritte nicht einer Person zugeordnet werden
 +
** Die Anbindung von EFA Providern erfolgt ausschließlich über einen sicheren, verschlüsselten Transportkanal. Maßnahmen gegen Man-in-the-Middle Angriffe sind implementiert
 +
** Für alle implementierten Funktionalitäten (Interaktionsmuster) werden Audit Trail Einträge gemäß der Vorgaben in den zugehörigen Bindings geschrieben
 +
** Audit Trails sind vor Zugriffen Unberechtigter geschützt (entfällt, sofern eine Umsetzung des ATNA Audit Writers nicht Bestandteil des Produkts ist)
 +
** Vorgaben für den sicheren Betrieb der EFA-Consumer-Funktionalität des Produkts sind definiert und liegen schriftlich vor.
 +
 
 +
==== Anbindung eines EFA-Providers über einen EFA-Connector ====
 +
 
 
Ein Produkt, das einen EFAv2.0 konformen „EFA Consumer (Anbindung über EFA-Connector)“ realisiert, besitzt die folgenden Eigenschaften:
 
Ein Produkt, das einen EFAv2.0 konformen „EFA Consumer (Anbindung über EFA-Connector)“ realisiert, besitzt die folgenden Eigenschaften:
−
- Das Produkt MUSS die logische EFA-Komponente „EFA Teilnehmersystem“ umsetzen.  
+
* Das Produkt MUSS die [[cdaefa:EFA_Dienste|logische EFA-Komponente]] „EFA Teilnehmersystem“ umsetzen.  
−
- Das Produkt MUSS die in Anhang B2 dieses Dokuments aufgeführten EFAv2.0-Interaktionsmuster funktional und mit der definierten Anwendungssemantik unterstützen.
+
* Das Produkt MUSS die folgenden [[cdaefa:Interaktionsmuster_der_EFA|EFAv2.0-Interaktionsmuster]] funktional und mit der definierten Anwendungssemantik unterstützen:
−
- Das Produkt MUSS eine grafische Benutzerschnittstelle bereitstellen, über die ein Nutzer die umgesetzten Interaktionsmuster nutzen kann.
+
** [[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
−
- Das Produkt MUSS für alle umgesetzten Interaktionsmuster Zugriffe auf den EFA-Provider ausschließlich über die in Anhang B2 zu diesem Dokument aufgeführten und in der EFAv1.2-Connector-Spezifikation definierten Schnittstellen realisieren.  
+
** [[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
−
- Das Produkt MUSS die in Anhang B2 dieses Dokuments aufgeführten Eigenschaften in Bezug auf Sicherheit und Datenschutz besitzen.  
+
** [[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
 +
** [[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
 +
** [[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte oder eine Partition]]
 +
** [[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
 +
** [[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
 +
* Das Produkt MUSS eine grafische Benutzerschnittstelle bereitstellen, über die ein Nutzer die umgesetzten Interaktionsmuster nutzen kann.
 +
* Das Produkt MUSS für alle umgesetzten Interaktionsmuster Zugriffe auf den EFA-Provider ausschließlich über die in der EFAv1.2-Connector-Spezifikation definierten Schnittstellen realisieren. Zumindest die folgenden Schnittstellen müssen implementiert sein:
 +
** openSession, closeSession
 +
** Get All Metadata
 +
** Get Record Metadata List
 +
** Get Folder Metadata List
 +
** Get Information Objects
 +
** Provide Information Object
 +
* Das Produkt MUSS die folgenden Eigenschaften in Bezug auf Sicherheit und Datenschutz besitzen:
 +
** Für Anfragen genutzte Patienten-IDs (XPID) können durch Dritte nicht einer Person zugeordnet werden
 +
** Die Anbindung an den EFA-Connector kann über einen sicheren, verschlüsselten Transportkanal erfolgen. Maßnahmen gegen Man-in-the-Middle Angriffe sind implementiert
 +
** Vorgaben für den sicheren Betrieb der EFA-Consumer-Funktionalität des Produkts sind definiert und liegen schriftlich vor.
  
−
== EFA-Connector ==
+
=== EFA-Connector ===
 
Ein EFA-Connector vermittelt Aufrufe an einen EFA-Provider über eine einfache Programmierschnittstelle. Durch Kapselung der EFA-Sicherheitsfunktionalitäten im EFA-Connector kann so die Umsetzung von EFA-Consumer-Systemen signifikant vereinfacht werden.
 
Ein EFA-Connector vermittelt Aufrufe an einen EFA-Provider über eine einfache Programmierschnittstelle. Durch Kapselung der EFA-Sicherheitsfunktionalitäten im EFA-Connector kann so die Umsetzung von EFA-Consumer-Systemen signifikant vereinfacht werden.
 +
 
Ein Produkt, das einen EFAv2.0 konformen „EFA Connector“ realisiert, besitzt die folgenden Eigenschaften:
 
Ein Produkt, das einen EFAv2.0 konformen „EFA Connector“ realisiert, besitzt die folgenden Eigenschaften:
−
- Das Produkt MUSS die logische EFA-Komponente „EFA Kontext Manager“ umsetzen. Das Verhalten dieser Komponente MUSS den für diese Komponente definierten Service Functional Models entsprechen.
+
* Das Produkt MUSS die logische EFA-Komponente „EFA Kontext Manager“ umsetzen. Das Verhalten dieser Komponente MUSS den für diese Komponente definierten Service Functional Models entsprechen.
−
- Das Produkt MUSS die in Anhang C zu diesem Dokument aufgeführten Schnittstellen zu EFA-Consumer- und EFA-Provider-Systemen gemäß der benannten Spezifikationen umsetzen
+
* Das Produkt MUSS mindestens die folgenden, in der EFAv2.0-Spezifikation definierten [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|Service Functional Models]] mitsamt der zugehörigen [[cdaefa:EFA_XDS/XDR_Bindings|IHE-Bindings]] an der Schnittstelle zum EFA-Provider implementieren:
−
- Das Produkt MUSS die in Anhang C dieses Dokuments aufgeführten Eigenschaften in Bezug auf Sicherheit und Datenschutz besitzen.
+
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#createPartition|createPartition]]
 +
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listPartitions|listPartitions]]
 +
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listPartitionContent|listPartitionContent]]
 +
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|provideData]]
 +
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#retrieveData|retrieveData]]
 +
* Das Produkt muss die folgenden Schnittstellen zum EFA-Consumer gemäß der Spezifikation „ECR Connector v1.2“ realisieren:
 +
** openSession, closeSession
 +
** Get All Metadata
 +
** Get Record Metadata List
 +
** Get Folder Metadata List
 +
** Get Information Objects
 +
** Provide Information Object
 +
* Das Produkt MUSS die folgenden Eigenschaften in Bezug auf Sicherheit und Datenschutz besitzen:
 +
** Bei allen Aufrufen wird eine EFA Identity Assertion gemäß EFAv2.0 Spezifikation im SOAP übermittelt (Anmerkung: Abweichungen in der Kodierung der Attribute sind zulässig). Der Erstellung der Assertion liegt eine sichere Authentisierung zugrunde.
 +
** Eine lokale Authentisierung wird über eine Guarantor Assertion vermittelt (optional) 
 +
** Für Anfragen genutzte Patienten-IDs (XPID) können durch Dritte nicht einer Person zugeordnet werden
 +
** Die Anbindung von EFA Providern erfolgt ausschließlich über einen sicheren, verschlüsselten Transportkanal. Maßnahmen gegen Man-in-the-Middle Angriffe sind in Richtung Consumer und Provider vorgesehen.
 +
** Die Anbindung von EFA Consumern kann über einen sicheren, verschlüsselten Transportkanal erfolgen
 +
** Für alle implementierten Funktionalitäten (Interaktionsmuster) werden Audit Trail Einträge gemäß der Vorgaben in den zugehörigen Bindings geschrieben
 +
** Audit Trails sind vor Zugriffen Unberechtigter geschützt (entfällt, sofern eine Umsetzung des ATNA Audit Writers nicht Bestandteil des Produkts ist)
 +
** Vorgaben für den sicheren Betrieb der EFA-Connector-Funktionalität des Produkts sind definiert und liegen schriftlich vor.
 +
 
 +
 
 +
 
 +
----
 +
 
 +
 
 +
{{NoteBox|'''Referenzen und Querverweise'''
 +
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
 +
<nowiki></nowiki>
 +
}}

Aktuelle Version vom 26. Januar 2015, 16:13 Uhr

Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
  • 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 .

Gegenstand des EFAv2.0 Konformitätsnachweises

Das Verfahren zur Ausstellung von Konformitätsnachweisen für EFAv2.0 konforme Produkte ist für vier Produktgruppen anwendbar. Diese sind in der nachfolgenden Abbildung im Überblick dargestellt und werden in den folgenden Abschnitten genauer beschrieben.

Ausprägungen EFAv2.0-konformer Produkte


EFA-Provider

Ein Produkt, das einen EFAv2.0 konformen „EFA Provider“ realisiert, besitzt die folgenden Eigenschaften:

  • Das Produkt MUSS die folgenden Eigenschaften in Bezug auf Sicherheit und Datenschutz besitzen:
    • Bei allen Aufrufen wird eine EFA Identity Assertion gemäß EFAv2.0 Spezifikation im SOAP Header erwartet und geprüft (Anmerkung: Abweichungen in der Kodierung der Attribute sind zulässig). Die Prüfung stellt Integrität, Authentizität und Validität der Assertions sicher.
    • optional: Eine im SOAP Header enthaltene EFA Policy Assertion kann verarbeitet werden.
    • Bei allen Anfragen werden die Existenz einer Einwilligung und die Berechtigung des Aufrufers geprüft
    • Für Anfragen akzeptierte Patienten-IDs (XPID) können durch Dritte nicht einer Person zugeordnet werden
    • Die Anbindung von EFA Consumern erfolgt ausschließlich über einen sicheren, verschlüsselten Transportkanal
    • Für alle implementierten Funktionalitäten (Interaktionsmuster) werden Audit Trail Einträge gemäß der Vorgaben in den zugehörigen Bindings geschrieben
    • Audit Trails sind vor Zugriffen Unberechtigter geschützt (entfällt, sofern eine Umsetzung des ATNA Audit Writers nicht Bestandteil des Produkts ist)
    • Vorgaben für den sicheren Betrieb der EFA-Consumer-Funktionalität des Produkts sind definiert und liegen schriftlich vor.

EFA-Consumer

Ein EFA-Consumer (EFA-Client) kann entweder direkt auf die Dienste des EFA-Providers zugreifen oder hierzu die vereinfachte Schnittstelle eines EFA-Connectors nutzen. Beide Produktvarianten können EFAv2.0-konform realisiert werden.

Direkte Anbindung eines EFA-Consumer an einen EFA-Provider

Ein Produkt, das einen EFAv2.0 konformen „EFA Consumer (direkte Anbindung an EFA-Provider)“ realisiert, besitzt die folgenden Eigenschaften:

Anbindung eines EFA-Providers über einen EFA-Connector

Ein Produkt, das einen EFAv2.0 konformen „EFA Consumer (Anbindung über EFA-Connector)“ realisiert, besitzt die folgenden Eigenschaften:

  • Das Produkt MUSS die logische EFA-Komponente „EFA Teilnehmersystem“ umsetzen.
  • Das Produkt MUSS die folgenden EFAv2.0-Interaktionsmuster funktional und mit der definierten Anwendungssemantik unterstützen:
  • Das Produkt MUSS eine grafische Benutzerschnittstelle bereitstellen, über die ein Nutzer die umgesetzten Interaktionsmuster nutzen kann.
  • Das Produkt MUSS für alle umgesetzten Interaktionsmuster Zugriffe auf den EFA-Provider ausschließlich über die in der EFAv1.2-Connector-Spezifikation definierten Schnittstellen realisieren. Zumindest die folgenden Schnittstellen müssen implementiert sein:
    • openSession, closeSession
    • Get All Metadata
    • Get Record Metadata List
    • Get Folder Metadata List
    • Get Information Objects
    • Provide Information Object
  • Das Produkt MUSS die folgenden Eigenschaften in Bezug auf Sicherheit und Datenschutz besitzen:
    • Für Anfragen genutzte Patienten-IDs (XPID) können durch Dritte nicht einer Person zugeordnet werden
    • Die Anbindung an den EFA-Connector kann über einen sicheren, verschlüsselten Transportkanal erfolgen. Maßnahmen gegen Man-in-the-Middle Angriffe sind implementiert
    • Vorgaben für den sicheren Betrieb der EFA-Consumer-Funktionalität des Produkts sind definiert und liegen schriftlich vor.

EFA-Connector

Ein EFA-Connector vermittelt Aufrufe an einen EFA-Provider über eine einfache Programmierschnittstelle. Durch Kapselung der EFA-Sicherheitsfunktionalitäten im EFA-Connector kann so die Umsetzung von EFA-Consumer-Systemen signifikant vereinfacht werden.

Ein Produkt, das einen EFAv2.0 konformen „EFA Connector“ realisiert, besitzt die folgenden Eigenschaften:

  • Das Produkt MUSS die logische EFA-Komponente „EFA Kontext Manager“ umsetzen. Das Verhalten dieser Komponente MUSS den für diese Komponente definierten Service Functional Models entsprechen.
  • Das Produkt MUSS mindestens die folgenden, in der EFAv2.0-Spezifikation definierten Service Functional Models mitsamt der zugehörigen IHE-Bindings an der Schnittstelle zum EFA-Provider implementieren:
  • Das Produkt muss die folgenden Schnittstellen zum EFA-Consumer gemäß der Spezifikation „ECR Connector v1.2“ realisieren:
    • openSession, closeSession
    • Get All Metadata
    • Get Record Metadata List
    • Get Folder Metadata List
    • Get Information Objects
    • Provide Information Object
  • Das Produkt MUSS die folgenden Eigenschaften in Bezug auf Sicherheit und Datenschutz besitzen:
    • Bei allen Aufrufen wird eine EFA Identity Assertion gemäß EFAv2.0 Spezifikation im SOAP übermittelt (Anmerkung: Abweichungen in der Kodierung der Attribute sind zulässig). Der Erstellung der Assertion liegt eine sichere Authentisierung zugrunde.
    • Eine lokale Authentisierung wird über eine Guarantor Assertion vermittelt (optional)
    • Für Anfragen genutzte Patienten-IDs (XPID) können durch Dritte nicht einer Person zugeordnet werden
    • Die Anbindung von EFA Providern erfolgt ausschließlich über einen sicheren, verschlüsselten Transportkanal. Maßnahmen gegen Man-in-the-Middle Angriffe sind in Richtung Consumer und Provider vorgesehen.
    • Die Anbindung von EFA Consumern kann über einen sicheren, verschlüsselten Transportkanal erfolgen
    • Für alle implementierten Funktionalitäten (Interaktionsmuster) werden Audit Trail Einträge gemäß der Vorgaben in den zugehörigen Bindings geschrieben
    • Audit Trails sind vor Zugriffen Unberechtigter geschützt (entfällt, sofern eine Umsetzung des ATNA Audit Writers nicht Bestandteil des Produkts ist)
    • Vorgaben für den sicheren Betrieb der EFA-Connector-Funktionalität des Produkts sind definiert und liegen schriftlich vor.



Information icon.svg Referenzen und Querverweise
Abgerufen von „https://wiki.hl7.de/index.php?title=cdaefa:Gegenstand_der_Konformitätsprüfung&oldid=22142“