EFA XDS/XDR Bindings
K (Markup-Fehler behoben) |
(→Constraints and Triggers) |
||
Zeile 193: | Zeile 193: | ||
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.}} | 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.}} | ||
+ | === IHE XDS Options === | ||
+ | |||
+ | The table below shows which IHE XDS options apply to EFA. | ||
+ | |||
+ | {|class="wikitable" | ||
+ | !XDS Option | ||
+ | !Use for EFA | ||
+ | !Remarks | ||
+ | |- | ||
+ | |Document Replacement | ||
+ | |SHOULD NOT be used | ||
+ | |EFA clients may replace documents within any dedicated peer. In order to minimize complexity of peer-to-peer deployments, this option may only be used for replacing own documents. It must not be used for replacing documents that have been provided to EFA by another user. | ||
+ | |- | ||
+ | |Document Addendum | ||
+ | |MUST NOT be used | ||
+ | |This option does not work for EFA peer-to-peer deployments and therefore must not be used. | ||
+ | |- | ||
+ | |Document Transformation | ||
+ | |MUST NOT be used | ||
+ | |This option does not work for EFA peer-to-peer deployments and therefore must not be used. | ||
+ | |- | ||
+ | |Folder Management | ||
+ | |SHALL be implemented | ||
+ | |EFA access control builds upon folders. Therefore the implementation of this option is indispensible for EFA compliant systems. | ||
+ | |- | ||
+ | |Basic Patient Privacy Enforcement | ||
+ | |MUST NOT be used | ||
+ | |EFA requires full and written consent to be given by the patient. BPPC-style consents must not be used for EFA. Respective requests (e.g. providing or requesting a BPPC document) shall be ignored by all EFA actors. | ||
+ | |- | ||
+ | |Asynchronous Web Services Exchange | ||
+ | |MAY be used | ||
+ | |EFAv2.0 does not constrain the use of this option. | ||
+ | |- | ||
+ | |Reference-ID | ||
+ | |SHOULD be implemented | ||
+ | |EFA implementations may use the referenceIDList for linking related documents. In this case the FindDocumentsByReferenceId Query may be used for discovering related documents to a given document. | ||
+ | |- | ||
+ | |On-Demand Documents | ||
+ | |MAY be used | ||
+ | |EFAv2.0 does not constrain the use of this option. | ||
+ | |- | ||
+ | |Persistence of Retrieved Documents | ||
+ | |MAY be used | ||
+ | |EFAv2.0 does not constrain the use of this option. | ||
+ | |- | ||
+ | |Limited Metadata | ||
+ | |Not applicable because EFA builds upon IHE XDS for which limited metadata is not permitted. | ||
+ | | | ||
+ | |} | ||
Aktuelle Version vom 14. Februar 2016, 20:57 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".
EFA XDR/XDS Binding
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDXDg.01}
This section specifies the binding of the EFA components to IHE-ITI actors and the binding of the EFA operations to IHE-ITI transactions.
The EFA actors MUST be bound to IHE-ITI actors as follows:
EFA actor | IHE-ITI actors | Operations |
EFA Client | Document Source | out-bound: createECR, closeECR, registerConsent, createPartition, provideData |
Document Consumer | out-bound: listPartitions, listPartitionContents, retrieveData | |
EFA Resource Manager | Document Repository | in-bound: createECR, closeECR, registerConsent |
Document Source | out-bound: registerRecordLocation | |
Document Recipient | in-bound: registerRecordLocation | |
Initiating Gateway
with XDS Affinity Domain Option (see IHE-ITI-TF-Vol1#18.2.1) |
out-bound: listRecordLocations | |
Responding Gateway
grouped with Document Consumer (see IHE-ITI-TF-Vol1#18.2.3.2) |
in-bound: listRecordLocations | |
EFA Document Registry | Document Registry | in-bound: listPartitions, listPartitionContent, registerData |
Initiating Gateway
with XDS Affinity Domain Option (see IHE-ITI-TF-Vol1#18.2.1) |
in-bound: listPartitions, listPartitionContent
out-bound: listPartitions, listPartitionContent | |
Responding Gateway
grouped with Document Consumer (see IHE-ITI-TF-Vol1#18.2.3.2) |
in-bound: listPartitions, listPartitionContent
out-bound: listPartitions, listPartitionContent | |
EFA Document Repository | Document Repository | in-bound: createPartition, provideData, retrieveData
out-bound: registerData |
Initiating Gateway
with XDS Affinity Domain Option (see IHE-ITI-TF-Vol1#18.2.1) |
in-bound: retrieveData
out-bound: retrieveData | |
Responding Gateway
grouped with Document Consumer (see IHE-ITI-TF-Vol1#18.2.3.2) |
in-bound: listPartitions, listPartitionContent
out-bound: listPartitions, listPartitionContent |
There are no contraints on the grouping or composition of EFA actors and IHE-ITI actors. |
The EFA operations MUST be bound to IHE-ITI transactions as follows:
EFA Service Functional Model | IHE-ITI Profile | Binding |
createECR | Provide and Register Document Set ITI-41 | createECR |
createPartition | Provide and Register Document Set ITI-41 | createPartition |
closeECR | Provide and Register Document Set ITI-41 | closeECR |
listPartitions | Registry Stored Query ITI-18 | listPartitions |
registerConsent | Provide and Register Document Set ITI-41 | registerConsent |
listRecordLocations | Cross Gateway Query ITI-38 | listRecordLocations |
registerRecordLocation | Provide and Register Document Set-b ITI-41 | registerRecordLocation |
registerData | Register Document Set ITI-42 | registerData |
listPartitionContent | Registry Stored Query ITI-18 | listPartitionContent |
provideData | Provide and Register Document Set ITI-41 | provideData |
retrieveData | Retrieve Document Set ITI-43 | retrieveData |
Constraints and Triggers
All bindings to the ITI-41 transaction MUST satisfy a set of common constraints and a distinct set of constraints which triggers a certain binding.
The common constraints are:
- The SubmissionSet MUST NOT have EFA semantics.
- The HasMember(4)-Associations (SubmissionSet to XDSDocumentEntry) MUST have the SubmissionSetStatus-attribute set to "Original".
- The HasMember-Associations MUST reference exactly one XDSFolder.
- The XDSFolder MUST satisfy the EFA XDS Folder Metadata Binding.
- All XDSDocument-Elements MUST be associated with the XDSFolder.
- All XDSDocument-Elements MUST satisfy the EFA XDS Document Metadata Binding.
The distinct sets of constraints are defined in the table below (R = required, O = optional, - = forbidden).
Constraints | Triggers for bindings | ||||
---|---|---|---|---|---|
createECR | closeECR | registerConsent | createPartition | provideData | |
One XDSDocument is a consentInfo which gives a new consent or does not revoke all active consents | R | - | R | - | - |
One XDSDocument is a consentInfo, which revokes all active consents | - | R | - | - | - |
An XDSFolder is provided (uniqueID) | R | O | O | R | - |
An XDSFolder is referenced (uniqueID) | - | O | O | - | R |
IHE XDS Options
The table below shows which IHE XDS options apply to EFA.
XDS Option | Use for EFA | Remarks |
---|---|---|
Document Replacement | SHOULD NOT be used | EFA clients may replace documents within any dedicated peer. In order to minimize complexity of peer-to-peer deployments, this option may only be used for replacing own documents. It must not be used for replacing documents that have been provided to EFA by another user. |
Document Addendum | MUST NOT be used | This option does not work for EFA peer-to-peer deployments and therefore must not be used. |
Document Transformation | MUST NOT be used | This option does not work for EFA peer-to-peer deployments and therefore must not be used. |
Folder Management | SHALL be implemented | EFA access control builds upon folders. Therefore the implementation of this option is indispensible for EFA compliant systems. |
Basic Patient Privacy Enforcement | MUST NOT be used | EFA requires full and written consent to be given by the patient. BPPC-style consents must not be used for EFA. Respective requests (e.g. providing or requesting a BPPC document) shall be ignored by all EFA actors. |
Asynchronous Web Services Exchange | MAY be used | EFAv2.0 does not constrain the use of this option. |
Reference-ID | SHOULD be implemented | EFA implementations may use the referenceIDList for linking related documents. In this case the FindDocumentsByReferenceId Query may be used for discovering related documents to a given document. |
On-Demand Documents | MAY be used | EFAv2.0 does not constrain the use of this option. |
Persistence of Retrieved Documents | MAY be used | EFAv2.0 does not constrain the use of this option. |
Limited Metadata | Not applicable because EFA builds upon IHE XDS for which limited metadata is not permitted. |
Referenzen und Querverweise |