EFA XDS/XDR Bindings

Aus Hl7wiki
(Teildokument von CDA für die elektronische Fallakte)
Wechseln zu: Navigation, Suche
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.
  • 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 .

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

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.