cdaefa:Gegenstand der Konformitätsprüfung: Unterschied zwischen den Versionen
(→EFA-Provider) |
(→Gegenstand des EFAv2.0 Konformitätsnachweises) |
||
| Zeile 17: | Zeile 17: | ||
** [[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]] | ** [[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]] | ||
** [[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]] | ** [[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]] | ||
| − | |||
* 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: | * 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: | ||
| Zeile 25: | Zeile 24: | ||
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|provideData]] | ** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|provideData]] | ||
** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#retrieveData|retrieveData]] | ** [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#retrieveData|retrieveData]] | ||
| − | ** [[cdaefa:EFA_Identity_Provider_SFM|requestHPIdentityAssertion]] (nur wenn | + | ** [[cdaefa:EFA_Identity_Provider_SFM|requestHPIdentityAssertion]] (nur wenn ein Identity Provider Bestandteil des Produkts ist) |
* 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: | ||
| Zeile 39: | Zeile 38: | ||
== 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 [[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 folgenden [[cdaefa:Interaktionsmuster_der_EFA|EFAv2.0-Interaktionsmuster]] funktional und mit der definierten Anwendungssemantik unterstützen: | |
| − | + | ** [[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]] | |
| − | + | ** [[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]] | |
| − | + | ** [[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 logische EFA-Komponente „EFA Teilnehmersystem“ umsetzen. | ||
Version vom 14. September 2014, 14:56 Uhr
Inhaltsverzeichnis
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.
EFA-Provider
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 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 mindestens die folgenden, in der EFAv2.0-Spezifikation definierten Service Functional Models mitsamt der zugehörigen IHE-Bindings implementieren:
- createPartition
- listPartitions
- listPartitionContent
- provideData
- retrieveData
- requestHPIdentityAssertion (nur wenn ein Identity Provider Bestandteil des Produkts ist)
- 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:
- 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 folgenden EFAv2.0-Interaktionsmuster funktional und mit der definierten Anwendungssemantik unterstützen:
- Anlegen einer Fallakte
- Anlegen und Registrieren einer Partition
- Einstellen von Datenobjekten
- Auffinden der Fallakten eines Patienten
- Browsing über eine Akte oder eine Partition
- Abruf von Datenobjekten
- 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 Service Functional Models mitsamt der zugehörigen IHE-Bindings implementieren:
- 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.
- 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: - Das Produkt MUSS die 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 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 Anhang B2 zu diesem Dokument aufgeführten und in der EFAv1.2-Connector-Spezifikation definierten Schnittstellen realisieren. - Das Produkt MUSS die in Anhang B2 dieses Dokuments aufgeführten Eigenschaften in Bezug auf Sicherheit und Datenschutz besitzen.
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 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 die in Anhang C dieses Dokuments aufgeführten Eigenschaften in Bezug auf Sicherheit und Datenschutz besitzen.
