cdaefa:Gegenstand der Konformitätsprüfung

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 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:
  • 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

• 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:
  • createPartition
  • listPartitions
  • listPartitionContent
  • provideData
  • retrieveData
  • requestHPIdentityAssertion
• 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 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
• 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:
  • createPartition
  • listPartitions
  • listPartitionContent
  • provideData
  • 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.

---