Quelltext der Seite Implementation Guidelines: Digital Consent Option for EFA Provider Actors

== Trigger Event ==
[[Datei:Add-Folder-with-Document.png|550px|right]]
A EFA Provider receives an EFA Initialization request within an IHE ITI-41 message. This incoming message is a valid ITI-41 transaction that uses a submission set to place a single document into a newly created XDS folder. The structure of this message is a shown in the example (see right):
* the message contains a single submission set registry object. 
* the message contains a single XDSFolder registry object. The folder is newly created through the message. It is linked from the submission set through a "hasMember" registry object. The folder is marked with two classifications: one signalingthat this folder is an EFA folder and one signaling the concrete purpose of the EFA. 
* the message contains a single XDSDocumentEntry registry object. This object is newly created through the message. It is linked from the submission set through a "hasMember" registry object. Additionally it is linked from the XDSFolder registry object through another "hasMember" registry object. This "hasMember" registry object again is included into the submission set through a forth "hasMember" registry object.
* the XDSDocument registry object refers to a CDA document that is inluded with the message by the means of MTOM/XOP. This CDA document shall comply to the [http://wiki.hl7.de/images/EPPC-G_Draft_for_Comment_v04.pdf EPPC-G specification] for a digital consent document.

== Constraints ==
The incoming message shall comply to the constraints as defined on IHE ITI-41 for initializing an EFA instance. It shall be piggybacked by a SAML Assertion that complies to the constraints as defined on IHE ITI-40 for EFA Identity Assertions.
In addition the following conditions shall be met:
* The patient taking the patientRole within the CDA document shall be the same as the patient referenced in the registry objects that are included with the IHE ITI-41 message. Implementations shall validate this be ensuring that the patient identifier is the same.
* The custodian organization referenced in the CDA document shall be the organization that is stated as responsible for the registry objects that are included with the IHE ITI-41 message. Implementations shall validate this be ensuring that the organization ID is the same.
* The CDA document shall carry a single XACML policy set. This XACML policy set provides authorization to identified subjects (persons or organizations) for accessing XDSFolders that are marked by specific classification (EFA Folder code and EFA purpose code). In particular the the following constraints shall be considered:
** The EFA purpose code classification assigned to the newly created XDSFolder shall be listed in the policy as a mandatory resource attribute.
** The identifier of the patient as given in the CDA header and the XDS registry objects shall be listed in the policy as a mandatory resource attribute.
** At least one valid subject shall be listed in the policy. 
** The policy shall contain an expiration time.

== Expected Behaviour ==
The EFA Proivder accepts the incoming message and verifies its validity by checking IHE ITI-41 conformance and implementation of EFA-defined constraints. If the message is valid, the EFA Provider 
# stores and registers the document as defined for the IHE ITI-41 transaction
# extracts the XACML policy set from the provided CDA document
# registers the XACML policy set with its internal access control system (e.g. within a policy registry)

For all future requests to the newly created EFA the XACML policy set shall be enforded. This ensures that only persons and organizations listed in the patient's consent are allowed to access EFA Folders that make up this specific EFA instance.