EFA XDS/XDR Binding
 |
Dieses Dokument gibt wieder:
Implementierungsleitfaden EFA XDS/XDR Binding (0.9). Die Teilmaterialien gehören der Kategorie cdaefa an. |
February 2013
Jörg Caumanns, Raik Kuhlisch
| Version: | 0.9 |
| Datum: | March 2013 |
| Status: | xxx |
| Verfahren: | {{{Verfahren}}} |
| Realm: |  Deutschland
|
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".
EFA XDR/XDS Binding
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDXDg.01}
Within EFA the actors and transactions of the IHE XDS/XDR integration profiles are mapped onto EFA logical services and operations as follows:
| Role | EFA Service Functional Model | IHE XDS/XDR | Binding |
|---|---|---|---|
| Actor | EFA Client | Document Source (for createECR, createPartition, closeECR, registerConsent, provideData) Document Consumer (for listPartitions, retrieveData) |
- |
| Actor | EFA Resource Manager | Document Repository implementing Document Recipient (for createECR, createPartition, closeECR, registerConsent) Document Registry (for listPartitions) |
- |
| Actor | EFA Document Registry | XDS Document Registry | - |
| Actor | EFA Document Repository | XDS Document Repository (implementing Document Recipient for provideData) | - |
| Transaction | createECR | Provide and Register Document Set ITI-41 | createECR |
| Transaction | createPartition | Provide and Register Document Set ITI-41 | createPartition |
| Transaction | closeECR | Provide and Register Document Set ITI-41 | closeECR |
| Transaction | listPartitions | Registry Stored Query ITI-18 | listPartitions |
| Transaction | registerConsent | Provide and Register Document Set ITI-41 | registerConsent |
| Transaction | registerData | Register Document Set ITI-42 | registerData |
| Transaction | listData | Registry Stored Query ITI-18 | listData |
| Transaction | provideData | Provide and Register Document Set ITI-41 | provideData |
| Transaction | retrieveData | Retrieve Document Set ITI-43 | retrieveData |
Constraints and Triggers
Multiple operations of the EFA Service Functional Model (logical perspective) are bound to the IHE transactions ITI-18 and ITI-41. The intended binding must be determined by the set of constraints which the ITI-18-request or ITI-41-request satisfies. The distinct sets of constraints for the bindings are defined in the table below (R = required, O = optional, - = forbidden).
ITI-18-requests or ITI-41-requests that do not satisfy one of the given sets of constraints are invalid. In this case the XDS Document Registry and XDS Document Repository respectively MUST respond with an error.
| Requirement set for EFA operation bindings | |||||
|---|---|---|---|---|---|
| Constraints on ITI-41 | createECR | closeECR | registerConsent | createPartition | provideData |
| Exactly one XDS-Folder is provided | R | R | R | R | R |
| All XDS-Documents are associated with an XDS-Folder | R | R | R | R | R |
| The XDS-Folder is classified as EFA-Folder via XDSFolder.codeList | R | R | R | R | R |
| One XDS-Document is a consentInfo which gives a new consent or does not revoke all active consents | R | - | R | - | - |
| One XDS-Document is a consentInfo, which revokes all active consents | - | R | - | - | - |
| The provided XDSFolder and a registered XDSFolder have the XDSFolder.codeList and XDSFolder.patientID in common (i.e. the EFA exists) | - | R | R | R | R |
| The XDSFolder is not registered (uniqueID) | R | O | O | R | - |
| The XDSFolder is registered (uniqueID) | - | O | O | - | R |
| Constraints on ITI-18 | listPartitions | listData | |||
| Flavor FindFolder | R | - | |||
| Flavor GetFolderAndContents | - | R | |||
 |
Hybrid EFA/non-EFA systems should verify that a request is an EFA request prior to processing it with EFA semantics. Non-EFA requests MUST be rejected with an error message if processed with EFA semantics. |
