EFA XDS ResourceManager

Aus Hl7wiki
(Teildokument von CDA für die elektronische Fallakte)
Wechseln zu: Navigation, Suche
(→‎EFA Resource Manager XDR/XDS Binding)
K (→‎Example)
 
(102 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
−
{{Infobox Dokument
+
{{DocumentPart
−
|Title    = EFA XDS Resource Manager Binding
 
−
|Short    = EFA XDS Resource Manager Binding
 
−
|Namespace = cdaefa
 
−
|Type      = Implementierungsleitfaden
 
−
|Version  = 0.9
 
−
|Submitted = February 2013
 
−
|Author    = Jörg Caumanns, Raik Kuhlisch
 
−
|Date      = March 2013
 
−
|Copyright = 2012-2013
 
−
|Status    = Draft
 
−
|Period    = xxx
 
−
|OID      = n.n.
 
−
|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.<br>Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".''
 +
----
  
−
Status: [[Datei:Icon_33_percent.png]]
+
=== EFA Resource Manager XDR/XDS Binding ===
−
 
+
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.01}</tt>
−
Offene Punkte:
 
−
* EFA Anlegen
 
−
* Partition anlegen
 
−
* EFA schließen
 
−
 
 
−
== EFA Resource Manager XDR/XDS Binding ==
 
  
−
Within EFA the actors and transactions of the IHE XDR integration profile are mapped onto EFA Resource Manager actors and operations as follows:
+
Within EFA the actors and transactions of the IHE XDS integration profile are mapped onto EFA Resource Manager actors and operations as follows:
  
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
!Role
 
!Role
 
!EFA Resource Manager Service
 
!EFA Resource Manager Service
−
!IHE XDR
+
!IHE XDS
 +
!Binding
 
|-
 
|-
 
!Actor
 
!Actor
−
|EFA Client
+
|EFA Consumer
−
|Document Source
+
|
 +
* Document Source (for createECR, createPartition, closeECR, registerConsent)
 +
* Document Consumer (for listPartitions)
 +
| -
 
|-
 
|-
 
!Actor
 
!Actor
−
|EFA Provider
+
|EFA Resource Manager
−
|Document Recipient
+
|
 +
* Document Repository (for createECR, createPartition, closeECR, registerConsent)
 +
* Document Registry (for listPartitions)
 +
* Initiating Gateway (for listRecordLocations out-bound)
 +
* Responding Gateway (for listRecordLocations in-bound)
 +
* Patient Identity Source (for registerRecordLocation out-bound)
 +
* Patient Identifier Cross-reference Manager (for registerRecordLocation in-bound)
 +
* Document Metadata Notification Broker (for notifyOfConsent out-bound)
 +
* Document Metadata Notification Recipient (for notifyOfConsent in-bound)
 +
| -
 
|-
 
|-
 
!Transaction
 
!Transaction
 
|createECR
 
|createECR
 
|Provide and Register Document Set ITI-41
 
|Provide and Register Document Set ITI-41
 +
|[[cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_createECR|createECR]]
 
|-
 
|-
 
!Transaction
 
!Transaction
 
|createPartition
 
|createPartition
 
|Provide and Register Document Set ITI-41
 
|Provide and Register Document Set ITI-41
 +
|[[cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_createPartition|createPartition]]
 
|-
 
|-
 
!Transaction
 
!Transaction
 
|closeECR
 
|closeECR
−
|...
+
|Provide and Register Document Set ITI-41
 +
|[[cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_closeECR|closeECR]]
 +
|-
 +
!Transaction
 +
|listPartitions
 +
|Registry Stored Query ITI-18
 +
|[[cdaefa:EFA_XDS_ResourceManager#EFA_XDS_Binding:_listPartitions|listPartitions]]
 +
|-
 +
!Transaction
 +
|registerConsent
 +
|Provide and Register Document Set ITI-41
 +
|[[cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_registerConsent|registerConsent]]
 +
|-
 +
!Transaction
 +
|[[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listRecordLocations|listRecordLocations]]
 +
|Patient Location Query ITI-56
 +
|
 +
|-
 +
!Transaction
 +
|[[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#registerRecordLocation|registerRecordLocation]]
 +
|Patient Identity Feed HL7 V3 ITI-44
 +
|
 +
|-
 +
!Transaction
 +
|[[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#notifyOfConsent|notifyOfConsent]]
 +
|Document Metadata Notify ITI-53
 +
|
 +
|}
 +
 
 +
==== EFA XDS/XDR Binding: createECR ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.02}</tt>
 +
 
 +
The initialization of a new ECR is performed by creating a new XDS folder for the patient. The folder is classified by the ECR purpose codes and as such implicitly linked to all other folders (ECR: partitions) which are assigned to the same purpose.
 +
 +
This EFA binding introduces the following extensions and restrictions on the IHE XDR actor and transaction definitions in order to properly cover the EFA createECR operation and to align with the EFA security framework:
 +
* A new folder shall be created and purpose codes shall be provided for the newly created folder as codeList.
 +
* A consent information document containing the list of authorized subjects shall be provided through BPPC. A scanned consent document may be additionaly provided.
 +
* Additional error messages are defined that cover specific failure conditions of the EFA use cases
 +
* The availability of data fields is aligned to EFA privacy requirements
 +
* The application of security measures and the contents of the SOAP security header are specified normatively
 +
 +
===== Constraints on the Request Message =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.02.01}</tt>
 +
 
 +
The createECR request message implements the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE ITI TF-2b]
 +
 
 +
The following table shows how the [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#createECR|createECR]] Service Functional Model is mapped onto the ITI-41 transaction:
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!colspan="2"|[[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#createECR|createECR]]
 +
!ITI-41
 +
!Constraints
 +
|-
 +
|colspan="2"|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 +
|SAML Identity Assertion within the SOAP Security Header
 +
|see IHE Cookbook
 +
|-
 +
|rowspan="3"|[[cdaefa:EFA_Business_Informationsmodell#ecrInfo|ecrInfo]]
 +
|[[cdaefa:EFA_Business_Informationsmodell#patientID|patientID]]
 +
|XDS Folder Attribute: patientID
 +
|The same patient identifier SHALL be used throughout all metadata
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#purpose|purpose]]
 +
|XDS Folder Attribute: codeList
 +
|see [[cdaefa:EFA_XDS_Folder_Metadata_Binding|EFA XDS Folder Metadata Binding]] for details
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#ecrStatus|ecrStatus]]
 +
|XDS Folder Attribute: availabilityStatus
 +
|SHALL be "approved".
 +
|-
 +
|colspan="2"|[[cdaefa:EFA_Business_Informationsmodell#consentInfo|consentInfo]]
 +
|XDS Document
 +
|Definition of validity and authorized participants (see Interaction Pattern "[[cdaefa:CIM_Anlegen_einer_Fallakte#Interaktionsmuster:_Fallakte_anlegen|Creation of a new ECR]]") is covered within the consentInfo object.
 +
|-
 +
|colspan="2"|[[cdaefa:EFA_Business_Informationsmodell#consentDoc|consentDoc]] (optional)
 +
|XDS Document
 +
|If this argument is given, a scanned document SHALL be provided acc. to the XDS SD Integration Profile.
 
|}
 
|}
  
−
== EFA XDS/XDR Binding: createECR ==
+
Following this, implementations SHALL satisfy
 +
* the [[cdaefa:EFA_XDS/XDR_Bindings#Common_constraints_on_ITI-41|Common constraints on ITI-41]],
 +
* the distinct set of constraints which trigger this binding, given in the table below (R = required, O = optional, - = forbidden).
  
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Constraints
 +
!createECR binding
 +
|-
 +
|One XDS Document is a consentInfo which gives a new consent or does not revoke all active consents
 +
| align="center"|R
 +
|-
 +
|One XDS Document is a consentInfo, which revokes all active consents
 +
| align="center"|-
 +
|-
 +
|The provided XDS Folder and a registered XDS Folder  have the XDSFolder.codeList and XDSFolder.patientID in common (i.e. the EFA exists)
 +
| align="center"|-
 +
|-
 +
|The XDS Folder is not registered (uniqueID)
 +
| align="center"|R
 +
|-
 +
|The XDSFolder is registered (uniqueID)
 +
| align="center"|-
 +
|-
 +
|}
  
 +
===== Expected Actions =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.02.02}</tt>
  
 +
The XDS Document Repository SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.
  
−
The initialization
+
The XDS Document Repository MUST verify that the requesting service user has sufficient rights to setup a new ECR at this EFA Provider. This includes that the service user is registered with the provider and familiar with using ECRs. Additionaly the EFA Provider SHALL verify the completeness and consistency of the provided ''consentInfo'' document. It SHALL verify that all named ECR participants are either registered with the provider or identifiable through a shared healthcare provider directory.
−
This EFA binding introduces minor extensions and restrictions on the IHE XDR actor and transaction definitions in order to properly cover the EFA use cases and to align with the EFA security framework:
 
−
* Additional error messages are defined that cover specific failure conditions of the EFA use cases
 
−
* The availability of data fields is aligned to EFA privacy requirements
 
−
* Documents cannot be copied by reference (Permissions are assigned to folders and therefore there is no easy way for an ECR Provider to verify the legitimacy for linking a document with another case record)
 
−
* The application of security measures and the contents of the SOAP security header are specified normatively
 
  
−
=== Constraints on the Request Message ===
+
The EFA Provider SHALL check if an ECR for the given patient and purpose already has been registered with this provider.  
−
The ProvideAndRegisterDocument request message is issued by an EFA client at the point of care for providing and registering a medical document to an existing EFA instance. Each transmission carries one or more documents. All provided documents will be registered with the same folder within the same logical EFA
 
−
The request message implements the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE ITI TF-2b] considering the following constraints:
 
−
* The requestor (EFA Client) SHOULD embrace the provided documents as a single IHE XDS submission set acc. to [IHE ITI TF-2a].
 
−
* The EFA provider SHOULD ignore this grouping and MUST ignore all associations between documents and submission sets.
 
−
* The EFA provider MUST NOT process any metadata assigned to the submission set, it MUST solely rely on the document metadata and contents.
 
−
* The EFA provider MUST NOT register documents that are only provided through associations.
 
  
−
=== Expected Actions ===
+
If no ECR with the given purpose exists for the given patient, the EFA Provider SHALL
−
The EFA Document Registry Service provider SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator. It SHALL forward the received documents to the EFA Document Repository Service using any internal mechanism.
+
* setup a folder as specified in the request message
 +
* translate the provided ''consentInfo'' document into an access control policy which can be automatically enforced for each request to the newly setup ECR
 +
* store the provided documents within the XDS Document Repository
 +
* forward the metadata of the received documents to the XDS Document Registry for registration
  
−
The EFA Document Registry Service provider MUST verify that the requesting service user has sufficient rights to submit the given kind of documents for the identified patient and into the identified folder.  
+
If an ECR with the given purpose already exists for the given patient, the EFA Provider SHALL
 +
* verify that EFA participant is allowed to modify the consent of the ECR. If this access is denied an error status SHALL be returned.
 +
* setup a folder as specified in the request message
 +
* extract the identified ECR participants from the provided ''consentInfo'' document and add them as authorized users to the existing access control policy.
 +
* store the provided documents within the XDS Document Repository
 +
* forward the metadata of the received documents to the XDS Document Registry for registration
 +
 +
In case of an error that relates to the transmission of the request or the processing of the EFA security token, the EFA Resource Manager MUST respond with the respective error status.
  
−
In case of an error that relates to the transmission of the request or the processing of the EFA security token, the EFA Document Registry Service provider MUST respond with a fault message according to section xx.
+
===== Response Message (Full Success Scenario) =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.02.03}</tt>
  
−
=== Response Message (Full Success Scenario) ===
+
If the XDS Document Registry is able to decode the received message and to properly initialize the new ECR and its initial partition it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"
−
If the EFA Document Registry Service provider is able to decode the received message and to properly process/forward all transmitted documents it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"
 
  
−
If the service provider wants to respond with further information on the processing of the transmitted data or with a non-critical warning it SHOULD include an additional <RegistryErrorList> element. The severity MUST be set to “urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”:   
+
If the XDS Document Registry wants to respond with further information on the processing of the transmitted data or with a non-critical warning it SHOULD include an additional <RegistryErrorList> element. The severity MUST be set to “urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”:   
  
 
<syntaxhighlight lang="xml">
 
<syntaxhighlight lang="xml">
Zeile 91: Zeile 189:
 
           severity=”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”  
 
           severity=”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”  
 
           errorCode=”....”
 
           errorCode=”....”
−
           codeContext=”Processing deferred”
+
           codeContext=”Partition linked with existing ECR”
 
           location="" />
 
           location="" />
 
     </rs:RegistryErrorList>  
 
     </rs:RegistryErrorList>  
Zeile 105: Zeile 203:
 
!Action to be taken
 
!Action to be taken
 
|-
 
|-
−
|Documents were received but not processed
+
|Request was received but not processed; e.g. because a manual intervention by the EFA Provider is required to initalize a new ECR
 
|Processing deferred
 
|Processing deferred
 
|2201
 
|2201
 
|None
 
|None
 +
|-
 +
|An ECR with the given purpose already exists for the patient. Instead of initalizing a new ECR a partition has been added to the existing ECR.
 +
|Partition linked with existing ECR
 +
|2202
 +
|None
 +
|}
 +
 +
===== Response Message (Failure or Partial Failure Scenario) =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.02.04}</tt>
 +
 +
If the XDS Document Repository is able to decode the received message but the processing of the request failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.
 +
 +
The instantiation of an ECR is an All-or-Nothing operation. Therefore in any case of failure the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”.
 +
 +
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for EFA:
 +
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Condition and Severity
 +
!Location
 +
!Message
 +
!Code
 +
!Action to be taken
 +
|-
 +
|The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR)
 +
| -
 +
|Weak Authentication
 +
|4702
 +
|If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion.
 +
|-
 +
|The EFA Provider only accepts ''consentInfo'' documents if they are digitally signed by an HP. (ERROR)
 +
|OID of the consentInfo document
 +
|No Signature
 +
|4704
 +
|If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP.
 +
|-
 +
|The requestor has not sufficient permission to perform the requested operation (ERROR)
 +
| -
 +
|No Consent
 +
|4701
 +
|The request MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent.
 +
|-
 +
|An ECR of the given purpose already exists for the patient. The requestor does not have sufficient permissions to create a new partiton and to register new participants (ERROR)
 +
| -
 +
|No Consent
 +
|4701
 +
|The request MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent for the existing ECR.
 +
|-
 +
|The EFA Provider is unable to identify one or more of the participants that are listed in the consentInfo document (ERROR)
 +
|OID of the participant that cannot be identified
 +
|Unknown HP Identity
 +
|4111
 +
|The request MUST NOT be processed by the service provider. The requestor SHOULD first resolve the participants' identities into identifiers which are resolvable to the EFA Provider.
 +
|}
 +
 +
===== Security Considerations =====
 +
 +
See [[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]].
 +
 +
==== EFA XDS/XDR Binding: createPartition ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.03}</tt>
 +
 +
The linkage of a new partition to an existing ECR is performed by creating a new XDS folder for the patient. The folder is classified by the ECR purpose codes of the existing ECR and as such implicitly linked to all other folders (ECR: partitions) which are already assigned to the same ECR.
 +
 +
This EFA binding introduces the following extensions and restrictions on the IHE XDR actor and transaction definitions in order to properly cover the EFA createPartition operation and to align with the EFA security framework:
 +
* A new folder shall be created and purpose codes shall be provided for the newly created folder as codeList
 +
* Additional error messages are defined that cover specific failure conditions of the EFA use cases
 +
* The availability of data fields is aligned to EFA privacy requirements
 +
* The application of security measures and the contents of the SOAP security header are specified normatively
 +
 +
===== Constraints on the Request Message =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.03.01}</tt>
 +
 +
The createPartition request message implements the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE ITI TF-2b]
 +
 +
The following table shows how the createPartition SFM is mapped onto the ITI-41 transaction:
 +
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!createPartition
 +
!ITI-41
 +
!Constraints
 +
|-
 +
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 +
|SAML Identity Assertion within the SOAP Security Header
 +
|see IHE Cookbook
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
 +
|
 +
XDS Folder Attribute: patientID<br>
 +
XDS Folder Attribute: codeList<br>
 +
XDS Document Attribute: patientID
 +
|The codeList shall contain all purpose codes as assigned to the existing ECR the new partition is to be linked with
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#partitionInfo|partitionInfo]]
 +
|XDS Folder Attribute: title<br>
 +
XDS Folder Attribute: uniqueID
 +
|Further elements of the partitionInfo structure MAY be set by the ECR provider.
 +
|-
 +
|initialDoc
 +
|XDS Document
 +
|At least a single document shall be provided when a new partition is initialized.
 +
|}
 +
 +
Following this, implementations SHALL satisfy
 +
* the [[cdaefa:EFA_XDS/XDR_Bindings#Common_constraints_on_ITI-41|Common constraints on ITI-41]],
 +
* the distinct set of constraints which trigger this binding, given in the table below (R = required, O = optional, - = forbidden).
 +
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Constraints
 +
!createPartition binding
 +
|-
 +
|One XDS Document is a consentInfo which gives a new consent or does not revoke all active consents
 +
| align="center"|-
 +
|-
 +
|One XDS Document is a consentInfo, which revokes all active consents
 +
| align="center"|-
 +
|-
 +
|The provided XDS Folder and a registered XDS Folder  have the XDSFolder.codeList and XDSFolder.patientID in common (i.e. the EFA exists)
 +
| align="center"|R
 +
|-
 +
|The XDS Folder is not registered (uniqueID)
 +
| align="center"|R
 +
|-
 +
|The XDSFolder is registered (uniqueID)
 +
| align="center"|-
 +
|-
 
|}
 
|}
  
−
=== Response Message (Failure or Partial Failure Scenario) ===
+
{{AlertBox|
−
If the EFA Document Registry Service provider is able to decode the received message but the processing/forwarding of one or more documents failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.
+
The SFM method createPartition of the EFA Resource Manager allows for creating empty partitions. In contrast an XDS Document Source shall submit one or more documents (see ITI-TF-2b 3.41.6.1). From this it follows that the createPartition binding requires the initialDoc parameter.}}
 +
 
 +
===== Expected Actions =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.03.02}</tt>
 +
 
 +
The XDS Document Repository provider SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.
 +
 
 +
The provider of the XDS Document Repository provider MUST verify that the requesting service user has sufficient rights to setup a new partition at this ECR Provider ant to link this partiton with an existing ECR. 
 +
 
 +
In processing of this request the ECR Provider SHALL
 +
* assess the access control policy of the ECR with the "create partition" operation
 +
* setup a folder as specified in the request message
 +
* store the provided documents within the XDR Document Repository
 +
* forward the metadata of the received documents to the XDS Document Registry for registration
 +
 
 +
In case of an error that relates to the transmission of the request or the processing of the EFA security token, the XDS Document Repository MUST respond with the respective error status.
 +
 
 +
===== Response Message (Full Success Scenario) =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.03.03}</tt>
 +
 
 +
If the EFA Document Registry Service provider is able to decode the received message and to properly initialize the new partition it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"
 +
 
 +
===== Response Message (Failure or Partial Failure Scenario) =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.03.04}</tt>
 +
 
 +
If the XDS Document Repository is able to decode the received message but the processing of the request failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.
  
−
If none of the documents was processed succesfully, the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”. If at least one document was processed successfully, the response status MUST be set to “urn:ihe:iti:2007:ResponseStatusType:PartialSuccess”.  
+
If the partiton could not be created or if none of the provided documents was processed succesfully, the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”. If the partition was successfully initialized and at least one document was processed successfully, the response status MUST be set to “urn:ihe:iti:2007:ResponseStatusType:PartialSuccess”. A failure location MUST be provided if the error does not apply to all provided documents. It MUST NOT be given if the error applies to all provided documents.  
−
A failure location MUST be provided if the error does not apply to all provided documents. It MUST NOT be given if the error applies to all provided documents.
 
  
 
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for EFA:
 
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for EFA:
Zeile 132: Zeile 379:
 
|If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion.
 
|If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion.
 
|-
 
|-
−
|The EFA Document Registry service provider only accepts data of the given kind if it is digitally signed by an HCP. (ERROR)
+
|An ECR of the given purpose does not exist for the patient (ERROR)
−
|OID of the document that caused the error.
+
| -
 +
|Policy Violation
 +
|4109
 +
|The request MUST NOT be processed by the service provider.
 +
|-
 +
|The ECR provider only accepts medical documents if they are digitally signed by an HP. (ERROR)
 +
|OID of the consentInfo document
 
|No Signature
 
|No Signature
 
|4704
 
|4704
 
|If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP.
 
|If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP.
 +
|-
 +
|The requestor has not sufficient permission to perform the requested operation (ERROR)
 +
| -
 +
|No Consent
 +
|4701
 +
|The request MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent.
 
|-
 
|-
 
|For data of the given kind the EFA provider only accepts PDF coded documents (ERROR)
 
|For data of the given kind the EFA provider only accepts PDF coded documents (ERROR)
Zeile 146: Zeile 405:
 
|A document of the provided kind does not comply with the EFA policy or the patient consent (ERROR)
 
|A document of the provided kind does not comply with the EFA policy or the patient consent (ERROR)
 
|OID of the document
 
|OID of the document
 +
|No Consent
 +
|4701
 +
|The provided document MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent.
 +
|}
 +
 +
===== Security Considerations =====
 +
 +
See [[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]].
 +
 +
==== EFA XDS/XDR Binding: closeECR ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.04}</tt>
 +
 +
The explicit shutdown of an ECR is performed by placing a consentInfo document that invalidates all previously given permissions into one of the ECR's partitions (folders). This may either be a newly created folder of an existing folder that is classified by the ECR purpose codes and as such implicitly represents the ECR that is to be closed.
 +
 +
This EFA binding introduces the following extensions and restrictions on the IHE XDR actor and transaction definitions in order to properly cover the EFA closeECR operation and to align with the EFA security framework:
 +
* A new folder may be created. Purpose codes shall be provided for the newly created folder as codeList
 +
* A consent information document that invalidates all previously given permissions shall be provided through BPPC. A scanned consent revocation document may be additionaly provided.
 +
* Additional error messages are defined that cover specific failure conditions of the EFA use cases
 +
* The availability of data fields is aligned to EFA privacy requirements
 +
* The application of security measures and the contents of the SOAP security header are specified normatively
 +
 +
===== Constraints on the Request Message =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.04.01}</tt>
 +
 +
The closeECR request message implements the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE ITI TF-2b]
 +
 +
The following table shows how the closeECR SFM is mapped onto the ITI-41 transaction:
 +
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!closeECR
 +
!ITI-41
 +
!Constraints
 +
|-
 +
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 +
|SAML Identity Assertion within the SOAP Security Header
 +
|see IHE Cookbook
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
 +
|XDS Folder Attribute: patientID<br>
 +
XDS Folder Attribute: codeList<br>
 +
|The codeList shall contain all purpose codes as assigned to the ECR that is to be closed
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#consentInfo|consentInfo]]
 +
|XDS Document
 +
|
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#consentDoc|consentDoc]] (optional)
 +
|XDS Document
 +
|Scaned documents SHALL be provided acc. to the XDS SD Integration Profile.
 +
|}
 +
 +
Following this, implementations SHALL satisfy
 +
* the [[cdaefa:EFA_XDS/XDR_Bindings#Common_constraints_on_ITI-41|Common constraints on ITI-41]],
 +
* the distinct set of constraints which trigger this binding, given in the table below (R = required, O = optional, - = forbidden).
 +
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Constraints
 +
!closeECR binding
 +
|-
 +
|One XDS Document is a consentInfo which gives a new consent or does not revoke all active consents
 +
| align="center"|-
 +
|-
 +
|One XDS Document is a consentInfo, which revokes all active consents
 +
| align="center"|R
 +
|-
 +
|The provided XDS Folder and a registered XDS Folder  have the XDSFolder.codeList and XDSFolder.patientID in common (i.e. the EFA exists)
 +
| align="center"|R
 +
|-
 +
|The XDS Folder is not registered (uniqueID)
 +
| align="center"|O
 +
|-
 +
|The XDSFolder is registered (uniqueID)
 +
| align="center"|O
 +
|-
 +
|}
 +
 +
{{AlertBox|
 +
The Resource Manager SFM allows for closing partitions without providing any arguments but the ECR identifer. This binding makes the consentInfo document mandatory because ITI-41 provides more comfortable means for closing an ECR as other transactions that may be considered instead.}}
 +
 +
===== Expected Actions =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.04.02}</tt>
 +
 +
The XDS Document Repository provider SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.
 +
 +
The provider of the XDS Document Repository MUST verify that the requesting service user has sufficient rights to close an ECR at this ECR Provider. This includes that the service user is registered with the provider and familiar with using ECRs. Additionaly the ECR provider SHALL verify the completeness and consistency of the provided ''consentInfo'' document. 
 +
 +
In processing this request the ECR Provider SHALL
 +
* assess the access control policy of that ECR with the "modify consent" operation. If this access is denied an error status SHALL be returned.
 +
* setup a folder as specified in the request message
 +
* store the provided documents within the XDR Document Repository
 +
* forward the metadata of the received documents to the XDS Document Registry for registration
 +
* change the status of the ECR and all its partitions (folders) to "grace"
 +
* Adapt all permissions to the new status of the ECR
 +
 +
In case of an error that relates to the transmission of the request or the processing of the EFA security token, the EFA Resource Manager Service provider MUST respond with the respective error status.
 +
 +
===== Response Message (Full Success Scenario) =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.04.03}</tt>
 +
 +
If the EFA Document Registry Service provider is able to decode the received message and to properly change the status of the ECR and its partitions it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"
 +
 +
If the service provider wants to respond with further information on the processing of the transmitted data or with a non-critical warning it SHOULD include an additional <RegistryErrorList> element. The severity MUST be set to “urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”.
 +
 +
The following warning messages and codes are defined:
 +
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Condition and Severity
 +
!Message
 +
!Code
 +
!Action to be taken
 +
|-
 +
|Request was received but not processed; e.g. because a manual intervention by the ECR provider is required to close an ECR
 +
|Processing deferred
 +
|2201
 +
|None
 +
|}
 +
 +
===== Response Message (Failure or Partial Failure Scenario) =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.04.04}</tt>
 +
 +
If the XDS Document Repository is able to decode the received message but the processing of the request failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.
 +
 +
The shutdown of an ECR is an All-or-Nothing operation. Therefore in any case of failure the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”.
 +
 +
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for EFA:
 +
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Condition and Severity
 +
!Location
 +
!Message
 +
!Code
 +
!Action to be taken
 +
|-
 +
|The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR)
 +
| -
 +
|Weak Authentication
 +
|4702
 +
|If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion.
 +
|-
 +
|The ECR provider only accepts ''consentInfo'' documents if they are digitally signed by an HP. (ERROR)
 +
|OID of the consentInfo document
 +
|No Signature
 +
|4704
 +
|If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP.
 +
|-
 +
|The requestor has not sufficient permission to perform the requested operation (ERROR)
 +
| -
 +
|No Consent
 +
|4701
 +
|The request MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent.
 +
|-
 +
|An ECR of the given purpose does not exist for the patient (ERROR)
 +
| -
 +
|Policy Violation
 +
|4109
 +
|The request MUST NOT be processed by the service provider.
 +
|}
 +
 +
===== Security Considerations =====
 +
 +
See [[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]].
 +
 +
==== EFA XDS Binding: listPartitions ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.05}</tt>
 +
 +
ECR partitions are bound as XDS folders. Therefore listing partitions corresponds to listing  accessible folders which
 +
* are assigned to a given patient, and
 +
* are ECR-classified, and
 +
* are classified with the given purpose.
 +
 +
This EFA binding introduces the following extensions and restrictions on the IHE XDS actor and transaction definitions in order to properly cover the EFA listPartitions operation and to align with the EFA security framework:
 +
* The query is restricted to folder metadata and does not return any data contained within that folders.
 +
* Additional error messages are defined that cover specific failure conditions of the EFA use cases
 +
* The availability of data fields is aligned to EFA privacy requirements
 +
* The application of security measures and the contents of the SOAP security header are specified normatively
 +
 +
===== Constraints on the Request Message =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.05.01}</tt>
 +
 +
The listPartitions request message implements the FindFolder flavor of the IHE Registry Stored Query transaction (ITI-18) request message as defined in [IHE ITI TF-2b#3.18.4.1.2.3.7.3].
 +
 +
The following table shows how the listPartitions SFM is mapped onto the ITI-18 transaction's query arguments:
 +
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!listPartitions
 +
!ITI-18
 +
!Constraints
 +
|-
 +
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 +
|SAML Identity Assertion within the SOAP Security Header
 +
|see IHE Cookbook
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#patientID|patientID]]
 +
|$XDSFolderPatientId
 +
|The patient ID used must be resolvable by the ECR Provider.
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#purpose|purpose]]
 +
|$XDSFolderCodeList
 +
|The codeList MUST contain the ECR-Folder classification code (see [[cdaefa:EFA_XDS_Folder_Metadata_Binding|EFA XDS Folder Metadata Binding]] for the respective code). The codeList MUST contain exactly one purpose code, which restricts the query to the partitons of a specific ECR. With regard to the parameter $XDSFolderCodeList solely the AND-semantics (see IHE-ITI-TF2a#3.18.4.1.2.3.5) MUST be used.
 +
|}
 +
 +
In addition the following constrains must be considered:
 +
* The $XDSFolderLastUpdateTimeFrom and/or $XDSFolderLastUpdateTimeTo query arguments MAY be used. If given, they MUST be considered by the Document Registry.
 +
* The $XDSFolderStatus query arguent SHALL be set to "Approved".
 +
 +
====== Example ======
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.05.01.01}</tt>
 +
 +
<syntaxhighlight lang="xml">
 +
<query:AdhocQueryRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 +
  xsi:schemaLocation="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0 ../schemas/query.xsd"
 +
  xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
 +
  xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
 +
  xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
 +
  <query:ResponseOption returnComposedObjects="true" returnType="LeafClass"/>
 +
  <rim:AdhocQuery id="urn:uuid:958f3006-baad-4929-a4de-ff1114824431">
 +
      <rim:Slot name="$XDSFolderPatientId">
 +
        <rim:ValueList>
 +
            <rim:Value>'90378912821^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO'</rim:Value>
 +
        </rim:ValueList>
 +
      </rim:Slot>
 +
      <rim:Slot name="$XDSFolderStatus">
 +
        <rim:ValueList>
 +
            <rim:Value>'urn:oasis:names:tc:ebxml-regrep:StatusType:Approved'</rim:Value>
 +
        </rim:ValueList>
 +
      </rim:Slot>
 +
      <rim:Slot name="$XDSFolderCodeList">
 +
        <rim:ValueList>
 +
            <rim:Value>'ECR^^^IHE-D-Cookbook-FolderClassCode'</rim:Value>
 +
        </rim:ValueList>
 +
      </rim:Slot>
 +
      <rim:Slot name="$XDSFolderCodeList">
 +
        <rim:ValueList>
 +
            <rim:Value>'K70.0^^^1.2.276.0.76.5.311'</rim:Value>
 +
        </rim:ValueList>
 +
      </rim:Slot>
 +
  </rim:AdhocQuery>
 +
</query:AdhocQueryRequest>
 +
</syntaxhighlight>
 +
 +
===== Expected Actions =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.05.02}</tt>
 +
 +
The XDS Document Registry provider SHALL respond to a Registry Stored Query request message with the Registry Stored Query response message containing a success indicator and listing XDS metadata of all folders that match the given query. The provider of the XDS Document Registry provider MUST verify that the requesting service user has sufficient rights to access the discovered XDS folders. 
 +
 +
In processing of this request the ECR Provider SHALL
 +
* assess the access control policy of all folders assigned to the given patient
 +
* discover all folders that match the query and the policy
 +
* respond to the requestor with the metadata of the discovered folders. Metadata provided SHALL comply to the [[cdaefa:EFA_XDS_Folder_Metadata_Binding|EFA XDS Folder Metadata Binding]].
 +
 +
In case of an error that relates to the transmission of the request or the processing of the EFA security token, the XDS Document Registry MUST respond with the respective error status.
 +
 +
===== Response Message (Full Success Scenario) =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.05.03}</tt>
 +
 +
If the EFA Document Registry Service provider
 +
* is able to decode and process the received message and
 +
* at least one partition exists for the given patient that is accessible to the requestor
 +
it responds with the registry metadata of the discovered partitions.
 +
 +
===== Response Message (Failure or Partial Failure Scenario) =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.05.04}</tt>
 +
 +
If the XDS Document Registry is unable to successfuly process the query request it MUST respond with a ListResponse message that only contains a <AdhocQueryResponse/RegistryResponse> element.
 +
 +
If no matching folder is discovered or an error occured during the processing of the request, the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”. If partitons of the patient are discovered but may be incomplete (e.g. due to a not-responding peer in an ECR P2P network), the response status MUST be set to “urn:ihe:iti:2007:ResponseStatusType:PartialSuccess”.
 +
 +
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for ECR:
 +
 +
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Condition and Severity
 +
!Message
 +
!Code
 +
!Action to be taken
 +
|-
 +
|The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR)
 +
|Weak Authentication
 +
|4702
 +
|If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion.
 +
|-
 +
|The ECR provider is unable to verify the identity and/or the authenticity of the requestor (ERROR)
 +
|Invalid Subject
 +
|4703
 +
|The request MUST NOT be processed by the service provider.
 +
|-
 +
|The patient is unknown to the ECR provider.
 +
|No Data
 +
|1102
 +
| -
 +
|-
 +
|No partitions are registered for the given patient.
 +
|No Data
 +
|1102
 +
| -
 +
|-
 +
|None of the patient's partitions is accessible to the requestor.
 +
|No Data
 +
|1102
 +
| -
 +
|}
 +
 +
===== Security Considerations =====
 +
 +
See [[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]].
 +
 +
==== EFA XDS/XDR Binding: registerConsent ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.06}</tt>
 +
 +
The registration and enforcement of a new patient consent to an existing ECR is performed by placing a consentInfo document that expresses the new consent into one of the ECR's partitions (folders). This may either be a newly created folder of an existing folder that is classified by the ECR purpose codes and as such implicitly represents the ECR that is to be aligned to a new treatment setup.
 +
 +
This EFA binding introduces the following extensions and restrictions on the IHE XDR actor and transaction definitions in order to properly cover the EFA registerConsent operation and to align with the EFA security framework:
 +
* A new folder may be created. Purpose codes shall be provided for the newly created folder as codeList
 +
* A consent information document that expresses the new permissions shall be provided through BPPC. A scanned consent revocation document may be additionaly provided.
 +
* Additional error messages are defined that cover specific failure conditions of the EFA use cases
 +
* The availability of data fields is aligned to EFA privacy requirements
 +
* The application of security measures and the contents of the SOAP security header are specified normatively
 +
 +
===== Constraints on the Request Message =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.06.01}</tt>
 +
 +
The registerConsent request message implements the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE ITI TF-2b]
 +
 +
The following table shows how the registerConsent SFM is mapped onto the ITI-41 transaction:
 +
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
|-
 +
!registerConsent
 +
!ITI-41
 +
!Constraints
 +
|-
 +
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 +
|SAML Identity Assertion within the SOAP Security Header
 +
|see IHE Cookbook
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
 +
|XDS Folder Attribute: patientID<br/>
 +
XDS Folder Attribute: codeList<br/>
 +
|The codeList shall contain all purpose codes as assigned to the ECR that is to be aligned
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#consentInfo|consentInfo]]
 +
|XDS Document
 +
|
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#consentDoc|consentDoc]] (optional)
 +
|XDS Document
 +
|Scaned documents SHALL be provided acc. to the XDS SD Integration Profile.
 +
|-
 +
|docRelationship
 +
|RPLC-Association
 +
|The given consentInfo SHALL be associated with the approved consentInfo-DocumentEntry of the case record.
 +
 +
A given consentDoc SHALL be associated with the approved consentDoc-DocumentEntry of the case record.
 +
|}
 +
Following this, implementations SHALL satisfy
 +
* the [[cdaefa:EFA_XDS/XDR_Bindings#Common_constraints_on_ITI-41|Common constraints on ITI-41]],
 +
* the distinct set of constraints which trigger this binding, given in the table below (R = required, O = optional, - = forbidden).
 +
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Constraints
 +
!registerConsent binding
 +
|-
 +
|One XDS Document is a consentInfo which gives a new consent or does not revoke all active consents
 +
| align="center"|R
 +
|-
 +
|One XDS Document is a consentInfo, which revokes all active consents
 +
| align="center"|-
 +
|-
 +
|The provided XDS Folder and a registered XDS Folder  have the XDSFolder.codeList and XDSFolder.patientID in common (i.e. the EFA exists)
 +
| align="center"|R
 +
|-
 +
|The XDS Folder is not registered (uniqueID)
 +
| align="center"|O
 +
|-
 +
|The XDSFolder is registered (uniqueID)
 +
| align="center"|O
 +
|-
 +
|}
 +
 +
===== Expected Actions =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.06.02}</tt>
 +
 +
The XDS Document Repository provider SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.
 +
 +
The provider of the XDS Document Repository MUST verify that the requesting service user has sufficient rights to register a consent document at this ECR Provider. This includes that the service user is registered with the provider and familiar with using ECRs. Additionaly the ECR provider SHALL verify the completeness and consistency of the provided ''consentInfo'' document. 
 +
 +
In processing this request the ECR Provider SHALL
 +
* assess the access control policy of that ECR with the "modify consent" operation. If this access is denied an error status SHALL be returned.
 +
* setup a folder as specified in the request message
 +
* store the provided documents within the XDR Document Repository
 +
* forward the metadata of the received documents to the XDS Document Registry for registration
 +
* adapt all permissions that are assigned to the ecrRef to the care team setting as described in the newly provided consent. All previously set permissions must be invalidated.
 +
* if the validity date is changed by the consent: register the new validity with the access control system
 +
* if the purpose is aligned by the new consent: change the eventList codes of all containers that are assigned to the eCR to the new purpose
 +
 +
In case of an error that relates to the transmission of the request or the processing of the EFA security token, the EFA Resource Manager Service provider MUST respond with the respective error status.
 +
 +
===== Response Message (Full Success Scenario) =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.06.03}</tt>
 +
 +
If the EFA Document Registry Service provider is able to decode the received message and to properly change the settings of the ECR and its partitions it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"
 +
 +
If the service provider wants to respond with further information on the processing of the transmitted data or with a non-critical warning it SHOULD include an additional <RegistryErrorList> element. The severity MUST be set to “urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”.
 +
 +
The following warning messages and codes are defined:
 +
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Condition and Severity
 +
!Message
 +
!Code
 +
!Action to be taken
 +
|-
 +
|Request was received but not processed; e.g. because a manual intervention by the ECR provider is required to change the security settings of an ECR
 +
|Processing deferred
 +
|2201
 +
|None
 +
|}
 +
 +
===== Response Message (Failure or Partial Failure Scenario) =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.06.04}</tt>
 +
 +
If the XDS Document Repository is able to decode the received message but the processing of the request failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.
 +
 +
The modification of an ECR's security settings is an All-or-Nothing operation. Therefore in any case of failure the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”.
 +
 +
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for EFA:
 +
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Condition and Severity
 +
!Location
 +
!Message
 +
!Code
 +
!Action to be taken
 +
|-
 +
|The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR)
 +
| -
 +
|Weak Authentication
 +
|4702
 +
|If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion.
 +
|-
 +
|The ECR provider only accepts ''consentInfo'' documents if they are digitally signed by an HP. (ERROR)
 +
|OID of the consentInfo document
 +
|No Signature
 +
|4704
 +
|If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP.
 +
|-
 +
|The requestor has not sufficient permission to perform the requested operation (ERROR)
 +
| -
 +
|No Consent
 +
|4701
 +
|The request MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent.
 +
|-
 +
|An ECR of the given purpose does not exist for the patient (ERROR)
 +
| -
 
|Policy Violation
 
|Policy Violation
 
|4109
 
|4109
−
|The provided document MUST NOT be processed by the service provider. The HP MAY request the patient to exted the consent.
+
|The request MUST NOT be processed by the service provider.  
 +
|}
 +
 
 +
===== Security Considerations =====
 +
 
 +
See [[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]].
 +
 
 +
==== EFA IHE-ITI-Binding: listRecordLocations ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.07}</tt>
 +
 
 +
The operation listRecordLocations of the Resource Manager is bound to the transaction Cross Gateway Query [ITI-38] of the XCA profile.
 +
 
 +
===== Constraints on the request message =====
 +
The input of ''listRecordLocations'' SHALL be bound to ITI-56 ''Cross Gateway Query'' as follows:
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!listRecordLocations
 +
!ITI-38 Request
 +
!Constraints
 +
|-
 +
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 +
|SAML Identity Assertion within the SOAP Security Header
 +
|see IHE Cookbook
 
|-
 
|-
−
|A document is provided by-reference. The ECR provider is unable to assess the legitamicity of this action or cannot copy the document into the given destination (ERROR)
+
|[[cdaefa:EFA_Business_Informationsmodell#patientID|patientID]]
−
|OID of the document
+
|$XDSFolderPatientId
−
|Unresolvable Reference
+
|The patient-ID SHALL be known by Document Recipient.  
−
|4110
+
|-
−
|The provided reference MUST NOT be processed by the service provider. The HP MUST first obtain the document from its current source and then copy it into the destination folder.
+
|[[cdaefa:EFA_Business_Informationsmodell#purpose|purpose]]
 +
|$XDSFolderCodeList
 +
|The codeList MUST contain the purpose code, which restricts the query to the partitons of a specific ECR.
 
|}
 
|}
  
−
=== Security Audit Considerations ===
+
Futhermore, the query parameter $XDSFolderCodeList must contain the EFA-MountPoint classification code.
−
The EFA Provider MUST write an audit trail entry according to the EFA v1.2 Audit Trail specification.
+
 
−
The following table defines which categories MUST be filled (R), which MAY be filled (O) and which categories MUST NOT be used (X).
+
===== Response Message (Full Success Scenario) =====
 +
The output of ''listRecordLocations'' SHALL be bound to ITI-38 ''Cross Gateway Query Response'' as follows:
  
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
−
!category
 
−
!Opt.
 
−
!Description
 
 
|-
 
|-
−
|Event
+
!listRecordLocations
−
|R
+
!ITI-38 Response
−
|Audited event
+
!Constraints
 
|-
 
|-
−
|Requesting Point of Care
+
|[[cdaefa:EFA_Business_Informationsmodell#MountPoint|MountPoint]]*
−
|R
+
|see [[cdaefa:EFA_Metadata_Bindings#MountPoint|Binding of MountPoint]]
−
|Health professional organization that issued the original request.  
+
|The responder SHALL return only XDSFolder-Elements, that have been registered for this ECR with the [[cdaefa:EFA_Metadata_Bindings#MountPoint|Mount-Point classification]]. The responder SHALL return all XDSDocumentEntry-Elements, that are a member of these XDSFolder-Elements.
 +
|}
 +
 
 +
===== Response Message (Failure or Partial Failure Scenario) =====
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Condition and Severity
 +
!Location
 +
!Message
 +
!Code
 +
!Action to be taken
 
|-
 
|-
−
|Human Requestor
+
|The cross-community trust has not been established by means of a mutually authenticated channel or message authentication. (ERROR)
−
|R
+
| -
−
|HP that triggered the request
+
|Policy Violation
 +
|4109
 +
|The request MUST NOT be processed by the Responding Gateway.
 +
|}
 +
 
 +
===== Security Considerations =====
 +
The request and response messages SHALL be exchanged using a mutually authenticated channel or message authentication.
 +
 
 +
As for mutually authenticated channels, pairs of EFA-Providers SHOULD negotiate a protocol (f.e. SSH/TSL, VPN, KV-SafeNet) in the scope of contract conclusion.
 +
 
 +
As for message authentication, the SOAP-Body of the request and response messages SHALL be signed or encrypted using X.509 certificates.
 +
 
 +
==== EFA IHE-ITI-Binding: registerRecordLocation ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.08}</tt>
 +
 
 +
The operation registerRecordLocation SHALL be bound to the transaction ''Provide and Register Document Set'' ITI-41 [IHE ITI TF-2b#3.41] of the XDR profile.
 +
 
 +
===== Constraints on the request message =====
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
|-
 
|-
−
|Source Gateway
+
!registerRecordLocation
−
|R
+
!ITI-41
−
|EFA Client node address at the point of Care
+
!Constraints
 
|-
 
|-
−
|Target Gateway
+
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
−
|R
+
|SAML Identity Assertion within the SOAP Security Header
−
|EFA provider node address
+
|see IHE Cookbook
 
|-
 
|-
−
|Audit Source
+
|[[cdaefa:EFA_Business_Informationsmodell#patientID|MountPoint.patientID]]
−
|R
+
|XDSFolder.patientId
−
|Legal entity that ensures the uniqueness of the identifiers that are used to identify active participants
+
|The patientId SHALL be know at the target community.
 
|-
 
|-
−
|Patient
+
|[[cdaefa:EFA_Business_Informationsmodell#purpose|MountPoint.purpose]]
−
|R
+
|XDSFolder.codeList
−
|Patient
+
|The codeList SHALL contain the purpose code.
 
|-
 
|-
−
|Event Target
+
|MountPoint.sourcePatientID
−
|R
+
|XDSDocumentEntry.sourcePatientId
−
|References to the provided documents (see below)
+
|The sourcePatientId SHALL be the patientId known at the requesters community.
 
|-
 
|-
−
|Error Message
+
|[[cdaefa:EFA_Business_Informationsmodell#communityID|MountPoint.communityID]]
−
|O
+
|XDSFolder.homeCommunityId
−
|Only used in case that the request handling was not completed successfully
+
|The homeCommunityId SHALL be the requester's ID.
 
|}
 
|}
 +
Furthermore, XDSFolder.codeList SHALL contain the EFA-classification code and the Mount-Point-classification code. The attribute XDSFolder.sourcePatientId SHALL contain the patientId known in the requester's community.
  
−
For the Event Target Category the following fields MUST be provided:
+
===== Expected Actions =====
  
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
−
!Field Name
+
!Condition and Severity
−
!Opt.
+
!Location
−
!Value Constraints
+
!Message
 +
!Code
 +
!Action to be taken
 
|-
 
|-
−
|ParticipantObjectTypeCode
+
|The cross-community trust has not been established by means of a mutually authenticated channel or message authentication. (ERROR)
−
|R
+
| -
−
|MUST be “2” (System Object)
+
|Policy Violation
 +
|4109
 +
|The Patient Identifier Cross-reference Manager MUST NOT process the message.
 +
|}
 +
 
 +
===== Security Considerations =====
 +
 
 +
The message SHALL be exchanged using a mutually authenticated channel or message authentication.
 +
 
 +
As for mutually authenticated channels, pairs of EFA-Providers SHOULD negotiate a protocol (f.e. SSH/TSL, VPN, KV-SafeNet) in the scope of contract conclusion.
 +
 
 +
As for message authentication, the SOAP-Body of the message SHALL be signed or encrypted using X.509 certificates.
 +
 
 +
==== EFA IHE-ITI-Binding: notifyOfConsent ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDesa.08}</tt>
 +
 
 +
This binding implements the operation notifyOfConsent of the Resource Manager. It profiles the transaction Document Metadata Notify ITI-53 [IHE ITI Suppl. DSUB].
 +
 
 +
===== Constraints on the message =====
 +
The input of ''notifyOfConsent'' SHALL be bound to the Notify Message [IHE ITI TF-2#3.53.4.1] as follows:
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!notifyOfConsent
 +
!Notify Message
 +
!Constraints
 +
|-
 +
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 +
|SAML Identity Assertion within the SOAP Security Header
 +
|see IHE Cookbook
 
|-
 
|-
−
|ParticipantObjectTypeCodeRole
+
|[[cdaefa:EFA_Business_Informationsmodell#patientID|patientID]]
−
|R
+
| XDSDocumentEntry.patientId
−
|MUST be “4” (Resource)
+
|
 
|-
 
|-
−
|ParticipantObjectIDTypeCode
+
|[[cdaefa:EFA_Business_Informationsmodell#purpose|purpose]]
−
|R
+
| XDSDocumentEntry.eventCodeList
−
|MUST be “12” (URI)
+
|
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#documentID|documentID]]
 +
|
 +
* XDSDocumentEntry.uniqueID
 +
* XDSDocumentEntry.repositoryUniqueID
 +
|
 +
|}
 +
 
 +
===== Expected Actions =====
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Condition and Severity
 +
!Location
 +
!Message
 +
!Code
 +
!Action to be taken
 
|-
 
|-
−
|ParticipantObjectID
+
|The cross-community trust has not been established by means of a mutually authenticated channel or message authentication. (ERROR)
−
|R
+
| -
−
|MUST be string-encoded UUIDs of the provided documents
+
|Policy Violation
 +
|4109
 +
|The Document Metadata Notification Recipient MUST NOT process the message.
 
|}
 
|}
 +
 +
===== Security Considerations =====
 +
 +
The message SHALL be exchanged using a mutually authenticated channel or message authentication.
 +
 +
As for mutually authenticated channels, pairs of EFA-Providers SHOULD negotiate a protocol (f.e. SSH/TSL, VPN, KV-SafeNet) in the scope of contract conclusion.
 +
 +
As for message authentication, the SOAP-Body of the message SHALL be signed or encrypted using X.509 certificates.
  
  
Zeile 231: Zeile 1.052:
 
----
 
----
  
−
* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
+
 
 +
{{NoteBox|'''Referenzen und Querverweise'''
 +
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
 +
* [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=280|HL7 Implementation Guide for CDA®, Release 2: Consent Directives, Release 1]
 +
}}

Aktuelle Version vom 2. November 2015, 09:21 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".

Inhaltsverzeichnis

EFA Resource Manager XDR/XDS Binding

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.01}

Within EFA the actors and transactions of the IHE XDS integration profile are mapped onto EFA Resource Manager actors and operations as follows:

Role EFA Resource Manager Service IHE XDS Binding
Actor EFA Consumer
  • Document Source (for createECR, createPartition, closeECR, registerConsent)
  • Document Consumer (for listPartitions)
 -
Actor EFA Resource Manager
  • Document Repository (for createECR, createPartition, closeECR, registerConsent)
  • Document Registry (for listPartitions)
  • Initiating Gateway (for listRecordLocations out-bound)
  • Responding Gateway (for listRecordLocations in-bound)
  • Patient Identity Source (for registerRecordLocation out-bound)
  • Patient Identifier Cross-reference Manager (for registerRecordLocation in-bound)
  • Document Metadata Notification Broker (for notifyOfConsent out-bound)
  • Document Metadata Notification Recipient (for notifyOfConsent in-bound)
 -
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 listRecordLocations Patient Location Query ITI-56
Transaction registerRecordLocation Patient Identity Feed HL7 V3 ITI-44
Transaction notifyOfConsent Document Metadata Notify ITI-53

EFA XDS/XDR Binding: createECR

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.02}

The initialization of a new ECR is performed by creating a new XDS folder for the patient. The folder is classified by the ECR purpose codes and as such implicitly linked to all other folders (ECR: partitions) which are assigned to the same purpose.

This EFA binding introduces the following extensions and restrictions on the IHE XDR actor and transaction definitions in order to properly cover the EFA createECR operation and to align with the EFA security framework:

  • A new folder shall be created and purpose codes shall be provided for the newly created folder as codeList.
  • A consent information document containing the list of authorized subjects shall be provided through BPPC. A scanned consent document may be additionaly provided.
  • Additional error messages are defined that cover specific failure conditions of the EFA use cases
  • The availability of data fields is aligned to EFA privacy requirements
  • The application of security measures and the contents of the SOAP security header are specified normatively
Constraints on the Request Message

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.02.01}

The createECR request message implements the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE ITI TF-2b]

The following table shows how the createECR Service Functional Model is mapped onto the ITI-41 transaction:

createECR ITI-41 Constraints
context SAML Identity Assertion within the SOAP Security Header see IHE Cookbook
ecrInfo patientID XDS Folder Attribute: patientID The same patient identifier SHALL be used throughout all metadata
purpose XDS Folder Attribute: codeList see EFA XDS Folder Metadata Binding for details
ecrStatus XDS Folder Attribute: availabilityStatus SHALL be "approved".
consentInfo XDS Document Definition of validity and authorized participants (see Interaction Pattern "Creation of a new ECR") is covered within the consentInfo object.
consentDoc (optional) XDS Document If this argument is given, a scanned document SHALL be provided acc. to the XDS SD Integration Profile.

Following this, implementations SHALL satisfy

  • the Common constraints on ITI-41,
  • the distinct set of constraints which trigger this binding, given in the table below (R = required, O = optional, - = forbidden).
Constraints createECR binding
One XDS Document is a consentInfo which gives a new consent or does not revoke all active consents R
One XDS Document is a consentInfo, which revokes all active consents -
The provided XDS Folder and a registered XDS Folder have the XDSFolder.codeList and XDSFolder.patientID in common (i.e. the EFA exists) -
The XDS Folder is not registered (uniqueID) R
The XDSFolder is registered (uniqueID) -
Expected Actions

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.02.02}

The XDS Document Repository SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.

The XDS Document Repository MUST verify that the requesting service user has sufficient rights to setup a new ECR at this EFA Provider. This includes that the service user is registered with the provider and familiar with using ECRs. Additionaly the EFA Provider SHALL verify the completeness and consistency of the provided consentInfo document. It SHALL verify that all named ECR participants are either registered with the provider or identifiable through a shared healthcare provider directory.

The EFA Provider SHALL check if an ECR for the given patient and purpose already has been registered with this provider.

If no ECR with the given purpose exists for the given patient, the EFA Provider SHALL

  • setup a folder as specified in the request message
  • translate the provided consentInfo document into an access control policy which can be automatically enforced for each request to the newly setup ECR
  • store the provided documents within the XDS Document Repository
  • forward the metadata of the received documents to the XDS Document Registry for registration

If an ECR with the given purpose already exists for the given patient, the EFA Provider SHALL

  • verify that EFA participant is allowed to modify the consent of the ECR. If this access is denied an error status SHALL be returned.
  • setup a folder as specified in the request message
  • extract the identified ECR participants from the provided consentInfo document and add them as authorized users to the existing access control policy.
  • store the provided documents within the XDS Document Repository
  • forward the metadata of the received documents to the XDS Document Registry for registration

In case of an error that relates to the transmission of the request or the processing of the EFA security token, the EFA Resource Manager MUST respond with the respective error status.

Response Message (Full Success Scenario)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.02.03}

If the XDS Document Registry is able to decode the received message and to properly initialize the new ECR and its initial partition it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"

If the XDS Document Registry wants to respond with further information on the processing of the transmitted data or with a non-critical warning it SHOULD include an additional <RegistryErrorList> element. The severity MUST be set to “urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”: 

  <rs:RegistryResponse
           status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success">
     <rs:RegistryErrorList>
       <rs:RegistryError 
           severity=”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning” 
           errorCode=”....”
           codeContext=”Partition linked with existing ECR” 
           location="" />
     </rs:RegistryErrorList> 
   </rs:RegistryResponse>

The following warning messages and codes are defined:

Condition and Severity Message Code Action to be taken
Request was received but not processed; e.g. because a manual intervention by the EFA Provider is required to initalize a new ECR Processing deferred 2201 None
An ECR with the given purpose already exists for the patient. Instead of initalizing a new ECR a partition has been added to the existing ECR. Partition linked with existing ECR 2202 None
Response Message (Failure or Partial Failure Scenario)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.02.04}

If the XDS Document Repository is able to decode the received message but the processing of the request failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.

The instantiation of an ECR is an All-or-Nothing operation. Therefore in any case of failure the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”.

The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for EFA:

Condition and Severity Location Message Code Action to be taken
The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR) - Weak Authentication 4702 If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion.
The EFA Provider only accepts consentInfo documents if they are digitally signed by an HP. (ERROR) OID of the consentInfo document No Signature 4704 If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP.
The requestor has not sufficient permission to perform the requested operation (ERROR) - No Consent 4701 The request MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent.
An ECR of the given purpose already exists for the patient. The requestor does not have sufficient permissions to create a new partiton and to register new participants (ERROR) - No Consent 4701 The request MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent for the existing ECR.
The EFA Provider is unable to identify one or more of the participants that are listed in the consentInfo document (ERROR) OID of the participant that cannot be identified Unknown HP Identity 4111 The request MUST NOT be processed by the service provider. The requestor SHOULD first resolve the participants' identities into identifiers which are resolvable to the EFA Provider.
Security Considerations

See Security Considerations.

EFA XDS/XDR Binding: createPartition

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.03}

The linkage of a new partition to an existing ECR is performed by creating a new XDS folder for the patient. The folder is classified by the ECR purpose codes of the existing ECR and as such implicitly linked to all other folders (ECR: partitions) which are already assigned to the same ECR.

This EFA binding introduces the following extensions and restrictions on the IHE XDR actor and transaction definitions in order to properly cover the EFA createPartition operation and to align with the EFA security framework:

  • A new folder shall be created and purpose codes shall be provided for the newly created folder as codeList
  • Additional error messages are defined that cover specific failure conditions of the EFA use cases
  • The availability of data fields is aligned to EFA privacy requirements
  • The application of security measures and the contents of the SOAP security header are specified normatively
Constraints on the Request Message

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.03.01}

The createPartition request message implements the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE ITI TF-2b]

The following table shows how the createPartition SFM is mapped onto the ITI-41 transaction:

createPartition ITI-41 Constraints
context SAML Identity Assertion within the SOAP Security Header see IHE Cookbook
ecrRef

XDS Folder Attribute: patientID
XDS Folder Attribute: codeList
XDS Document Attribute: patientID

The codeList shall contain all purpose codes as assigned to the existing ECR the new partition is to be linked with
partitionInfo XDS Folder Attribute: title

XDS Folder Attribute: uniqueID

Further elements of the partitionInfo structure MAY be set by the ECR provider.
initialDoc XDS Document At least a single document shall be provided when a new partition is initialized.

Following this, implementations SHALL satisfy

  • the Common constraints on ITI-41,
  • the distinct set of constraints which trigger this binding, given in the table below (R = required, O = optional, - = forbidden).
Constraints createPartition binding
One XDS Document is a consentInfo which gives a new consent or does not revoke all active consents -
One XDS Document is a consentInfo, which revokes all active consents -
The provided XDS Folder and a registered XDS Folder have the XDSFolder.codeList and XDSFolder.patientID in common (i.e. the EFA exists) R
The XDS Folder is not registered (uniqueID) R
The XDSFolder is registered (uniqueID) -
Attention icon.svg The SFM method createPartition of the EFA Resource Manager allows for creating empty partitions. In contrast an XDS Document Source shall submit one or more documents (see ITI-TF-2b 3.41.6.1). From this it follows that the createPartition binding requires the initialDoc parameter.
Expected Actions

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.03.02}

The XDS Document Repository provider SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.

The provider of the XDS Document Repository provider MUST verify that the requesting service user has sufficient rights to setup a new partition at this ECR Provider ant to link this partiton with an existing ECR.

In processing of this request the ECR Provider SHALL

  • assess the access control policy of the ECR with the "create partition" operation
  • setup a folder as specified in the request message
  • store the provided documents within the XDR Document Repository
  • forward the metadata of the received documents to the XDS Document Registry for registration

In case of an error that relates to the transmission of the request or the processing of the EFA security token, the XDS Document Repository MUST respond with the respective error status.

Response Message (Full Success Scenario)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.03.03}

If the EFA Document Registry Service provider is able to decode the received message and to properly initialize the new partition it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"

Response Message (Failure or Partial Failure Scenario)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.03.04}

If the XDS Document Repository is able to decode the received message but the processing of the request failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.

If the partiton could not be created or if none of the provided documents was processed succesfully, the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”. If the partition was successfully initialized and at least one document was processed successfully, the response status MUST be set to “urn:ihe:iti:2007:ResponseStatusType:PartialSuccess”. A failure location MUST be provided if the error does not apply to all provided documents. It MUST NOT be given if the error applies to all provided documents.

The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for EFA:

Condition and Severity Location Message Code Action to be taken
The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR) - Weak Authentication 4702 If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion.
An ECR of the given purpose does not exist for the patient (ERROR) - Policy Violation 4109 The request MUST NOT be processed by the service provider.
The ECR provider only accepts medical documents if they are digitally signed by an HP. (ERROR) OID of the consentInfo document No Signature 4704 If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP.
The requestor has not sufficient permission to perform the requested operation (ERROR) - No Consent 4701 The request MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent.
For data of the given kind the EFA provider only accepts PDF coded documents (ERROR) OID of the document PDF required 4107 The provided document MUST NOT be processed by the EFA provider. The EFA Client MUST re-transmit the document in PDF format.
A document of the provided kind does not comply with the EFA policy or the patient consent (ERROR) OID of the document No Consent 4701 The provided document MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent.
Security Considerations

See Security Considerations.

EFA XDS/XDR Binding: closeECR

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.04}

The explicit shutdown of an ECR is performed by placing a consentInfo document that invalidates all previously given permissions into one of the ECR's partitions (folders). This may either be a newly created folder of an existing folder that is classified by the ECR purpose codes and as such implicitly represents the ECR that is to be closed.

This EFA binding introduces the following extensions and restrictions on the IHE XDR actor and transaction definitions in order to properly cover the EFA closeECR operation and to align with the EFA security framework:

  • A new folder may be created. Purpose codes shall be provided for the newly created folder as codeList
  • A consent information document that invalidates all previously given permissions shall be provided through BPPC. A scanned consent revocation document may be additionaly provided.
  • Additional error messages are defined that cover specific failure conditions of the EFA use cases
  • The availability of data fields is aligned to EFA privacy requirements
  • The application of security measures and the contents of the SOAP security header are specified normatively
Constraints on the Request Message

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.04.01}

The closeECR request message implements the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE ITI TF-2b]

The following table shows how the closeECR SFM is mapped onto the ITI-41 transaction:

closeECR ITI-41 Constraints
context SAML Identity Assertion within the SOAP Security Header see IHE Cookbook
ecrRef XDS Folder Attribute: patientID

XDS Folder Attribute: codeList

 The codeList shall contain all purpose codes as assigned to the ECR that is to be closed
consentInfo XDS Document
consentDoc (optional) XDS Document Scaned documents SHALL be provided acc. to the XDS SD Integration Profile.

Following this, implementations SHALL satisfy

  • the Common constraints on ITI-41,
  • the distinct set of constraints which trigger this binding, given in the table below (R = required, O = optional, - = forbidden).
Constraints closeECR binding
One XDS Document is a consentInfo which gives a new consent or does not revoke all active consents -
One XDS Document is a consentInfo, which revokes all active consents R
The provided XDS Folder and a registered XDS Folder have the XDSFolder.codeList and XDSFolder.patientID in common (i.e. the EFA exists) R
The XDS Folder is not registered (uniqueID) O
The XDSFolder is registered (uniqueID) O
Attention icon.svg The Resource Manager SFM allows for closing partitions without providing any arguments but the ECR identifer. This binding makes the consentInfo document mandatory because ITI-41 provides more comfortable means for closing an ECR as other transactions that may be considered instead.
Expected Actions

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.04.02}

The XDS Document Repository provider SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.

The provider of the XDS Document Repository MUST verify that the requesting service user has sufficient rights to close an ECR at this ECR Provider. This includes that the service user is registered with the provider and familiar with using ECRs. Additionaly the ECR provider SHALL verify the completeness and consistency of the provided consentInfo document.

In processing this request the ECR Provider SHALL

  • assess the access control policy of that ECR with the "modify consent" operation. If this access is denied an error status SHALL be returned.
  • setup a folder as specified in the request message
  • store the provided documents within the XDR Document Repository
  • forward the metadata of the received documents to the XDS Document Registry for registration
  • change the status of the ECR and all its partitions (folders) to "grace"
  • Adapt all permissions to the new status of the ECR

In case of an error that relates to the transmission of the request or the processing of the EFA security token, the EFA Resource Manager Service provider MUST respond with the respective error status.

Response Message (Full Success Scenario)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.04.03}

If the EFA Document Registry Service provider is able to decode the received message and to properly change the status of the ECR and its partitions it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"

If the service provider wants to respond with further information on the processing of the transmitted data or with a non-critical warning it SHOULD include an additional <RegistryErrorList> element. The severity MUST be set to “urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”.

The following warning messages and codes are defined:

Condition and Severity Message Code Action to be taken
Request was received but not processed; e.g. because a manual intervention by the ECR provider is required to close an ECR Processing deferred 2201 None
Response Message (Failure or Partial Failure Scenario)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.04.04}

If the XDS Document Repository is able to decode the received message but the processing of the request failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.

The shutdown of an ECR is an All-or-Nothing operation. Therefore in any case of failure the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”.

The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for EFA:

Condition and Severity Location Message Code Action to be taken
The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR) - Weak Authentication 4702 If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion.
The ECR provider only accepts consentInfo documents if they are digitally signed by an HP. (ERROR) OID of the consentInfo document No Signature 4704 If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP.
The requestor has not sufficient permission to perform the requested operation (ERROR) - No Consent 4701 The request MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent.
An ECR of the given purpose does not exist for the patient (ERROR) - Policy Violation 4109 The request MUST NOT be processed by the service provider.
Security Considerations

See Security Considerations.

EFA XDS Binding: listPartitions

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.05}

ECR partitions are bound as XDS folders. Therefore listing partitions corresponds to listing accessible folders which

  • are assigned to a given patient, and
  • are ECR-classified, and
  • are classified with the given purpose.

This EFA binding introduces the following extensions and restrictions on the IHE XDS actor and transaction definitions in order to properly cover the EFA listPartitions operation and to align with the EFA security framework:

  • The query is restricted to folder metadata and does not return any data contained within that folders.
  • Additional error messages are defined that cover specific failure conditions of the EFA use cases
  • The availability of data fields is aligned to EFA privacy requirements
  • The application of security measures and the contents of the SOAP security header are specified normatively
Constraints on the Request Message

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.05.01}

The listPartitions request message implements the FindFolder flavor of the IHE Registry Stored Query transaction (ITI-18) request message as defined in [IHE ITI TF-2b#3.18.4.1.2.3.7.3].

The following table shows how the listPartitions SFM is mapped onto the ITI-18 transaction's query arguments:

listPartitions ITI-18 Constraints
context SAML Identity Assertion within the SOAP Security Header see IHE Cookbook
patientID $XDSFolderPatientId The patient ID used must be resolvable by the ECR Provider.
purpose $XDSFolderCodeList The codeList MUST contain the ECR-Folder classification code (see EFA XDS Folder Metadata Binding for the respective code). The codeList MUST contain exactly one purpose code, which restricts the query to the partitons of a specific ECR. With regard to the parameter $XDSFolderCodeList solely the AND-semantics (see IHE-ITI-TF2a#3.18.4.1.2.3.5) MUST be used.

In addition the following constrains must be considered:

  • The $XDSFolderLastUpdateTimeFrom and/or $XDSFolderLastUpdateTimeTo query arguments MAY be used. If given, they MUST be considered by the Document Registry.
  • The $XDSFolderStatus query arguent SHALL be set to "Approved".
Example

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.05.01.01} 

 
<query:AdhocQueryRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0 ../schemas/query.xsd"
   xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
   xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
   xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
   <query:ResponseOption returnComposedObjects="true" returnType="LeafClass"/>
   <rim:AdhocQuery id="urn:uuid:958f3006-baad-4929-a4de-ff1114824431">
      <rim:Slot name="$XDSFolderPatientId">
         <rim:ValueList>
            <rim:Value>'90378912821^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO'</rim:Value>
         </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="$XDSFolderStatus">
         <rim:ValueList>
            <rim:Value>'urn:oasis:names:tc:ebxml-regrep:StatusType:Approved'</rim:Value>
         </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="$XDSFolderCodeList">
         <rim:ValueList>
            <rim:Value>'ECR^^^IHE-D-Cookbook-FolderClassCode'</rim:Value>
         </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="$XDSFolderCodeList">
         <rim:ValueList>
            <rim:Value>'K70.0^^^1.2.276.0.76.5.311'</rim:Value>
         </rim:ValueList>
      </rim:Slot>
   </rim:AdhocQuery>
</query:AdhocQueryRequest>
Expected Actions

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.05.02}

The XDS Document Registry provider SHALL respond to a Registry Stored Query request message with the Registry Stored Query response message containing a success indicator and listing XDS metadata of all folders that match the given query. The provider of the XDS Document Registry provider MUST verify that the requesting service user has sufficient rights to access the discovered XDS folders.

In processing of this request the ECR Provider SHALL

  • assess the access control policy of all folders assigned to the given patient
  • discover all folders that match the query and the policy
  • respond to the requestor with the metadata of the discovered folders. Metadata provided SHALL comply to the EFA XDS Folder Metadata Binding.

In case of an error that relates to the transmission of the request or the processing of the EFA security token, the XDS Document Registry MUST respond with the respective error status.

Response Message (Full Success Scenario)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.05.03}

If the EFA Document Registry Service provider

  • is able to decode and process the received message and
  • at least one partition exists for the given patient that is accessible to the requestor

it responds with the registry metadata of the discovered partitions.

Response Message (Failure or Partial Failure Scenario)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.05.04}

If the XDS Document Registry is unable to successfuly process the query request it MUST respond with a ListResponse message that only contains a <AdhocQueryResponse/RegistryResponse> element.

If no matching folder is discovered or an error occured during the processing of the request, the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”. If partitons of the patient are discovered but may be incomplete (e.g. due to a not-responding peer in an ECR P2P network), the response status MUST be set to “urn:ihe:iti:2007:ResponseStatusType:PartialSuccess”.

The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for ECR:


Condition and Severity Message Code Action to be taken
The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR) Weak Authentication 4702 If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion.
The ECR provider is unable to verify the identity and/or the authenticity of the requestor (ERROR) Invalid Subject 4703 The request MUST NOT be processed by the service provider.
The patient is unknown to the ECR provider. No Data 1102 -
No partitions are registered for the given patient. No Data 1102 -
None of the patient's partitions is accessible to the requestor. No Data 1102 -
Security Considerations

See Security Considerations.

EFA XDS/XDR Binding: registerConsent

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.06}

The registration and enforcement of a new patient consent to an existing ECR is performed by placing a consentInfo document that expresses the new consent into one of the ECR's partitions (folders). This may either be a newly created folder of an existing folder that is classified by the ECR purpose codes and as such implicitly represents the ECR that is to be aligned to a new treatment setup.

This EFA binding introduces the following extensions and restrictions on the IHE XDR actor and transaction definitions in order to properly cover the EFA registerConsent operation and to align with the EFA security framework:

  • A new folder may be created. Purpose codes shall be provided for the newly created folder as codeList
  • A consent information document that expresses the new permissions shall be provided through BPPC. A scanned consent revocation document may be additionaly provided.
  • Additional error messages are defined that cover specific failure conditions of the EFA use cases
  • The availability of data fields is aligned to EFA privacy requirements
  • The application of security measures and the contents of the SOAP security header are specified normatively
Constraints on the Request Message

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.06.01}

The registerConsent request message implements the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE ITI TF-2b]

The following table shows how the registerConsent SFM is mapped onto the ITI-41 transaction:

registerConsent ITI-41 Constraints
context SAML Identity Assertion within the SOAP Security Header see IHE Cookbook
ecrRef XDS Folder Attribute: patientID

XDS Folder Attribute: codeList

 The codeList shall contain all purpose codes as assigned to the ECR that is to be aligned
consentInfo XDS Document
consentDoc (optional) XDS Document Scaned documents SHALL be provided acc. to the XDS SD Integration Profile.
docRelationship RPLC-Association The given consentInfo SHALL be associated with the approved consentInfo-DocumentEntry of the case record.

A given consentDoc SHALL be associated with the approved consentDoc-DocumentEntry of the case record.

Following this, implementations SHALL satisfy

  • the Common constraints on ITI-41,
  • the distinct set of constraints which trigger this binding, given in the table below (R = required, O = optional, - = forbidden).
Constraints registerConsent binding
One XDS Document is a consentInfo which gives a new consent or does not revoke all active consents R
One XDS Document is a consentInfo, which revokes all active consents -
The provided XDS Folder and a registered XDS Folder have the XDSFolder.codeList and XDSFolder.patientID in common (i.e. the EFA exists) R
The XDS Folder is not registered (uniqueID) O
The XDSFolder is registered (uniqueID) O
Expected Actions

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.06.02}

The XDS Document Repository provider SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.

The provider of the XDS Document Repository MUST verify that the requesting service user has sufficient rights to register a consent document at this ECR Provider. This includes that the service user is registered with the provider and familiar with using ECRs. Additionaly the ECR provider SHALL verify the completeness and consistency of the provided consentInfo document.

In processing this request the ECR Provider SHALL

  • assess the access control policy of that ECR with the "modify consent" operation. If this access is denied an error status SHALL be returned.
  • setup a folder as specified in the request message
  • store the provided documents within the XDR Document Repository
  • forward the metadata of the received documents to the XDS Document Registry for registration
  • adapt all permissions that are assigned to the ecrRef to the care team setting as described in the newly provided consent. All previously set permissions must be invalidated.
  • if the validity date is changed by the consent: register the new validity with the access control system
  • if the purpose is aligned by the new consent: change the eventList codes of all containers that are assigned to the eCR to the new purpose

In case of an error that relates to the transmission of the request or the processing of the EFA security token, the EFA Resource Manager Service provider MUST respond with the respective error status.

Response Message (Full Success Scenario)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.06.03}

If the EFA Document Registry Service provider is able to decode the received message and to properly change the settings of the ECR and its partitions it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"

If the service provider wants to respond with further information on the processing of the transmitted data or with a non-critical warning it SHOULD include an additional <RegistryErrorList> element. The severity MUST be set to “urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”.

The following warning messages and codes are defined:

Condition and Severity Message Code Action to be taken
Request was received but not processed; e.g. because a manual intervention by the ECR provider is required to change the security settings of an ECR Processing deferred 2201 None
Response Message (Failure or Partial Failure Scenario)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.06.04}

If the XDS Document Repository is able to decode the received message but the processing of the request failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.

The modification of an ECR's security settings is an All-or-Nothing operation. Therefore in any case of failure the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”.

The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for EFA:

Condition and Severity Location Message Code Action to be taken
The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR) - Weak Authentication 4702 If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion.
The ECR provider only accepts consentInfo documents if they are digitally signed by an HP. (ERROR) OID of the consentInfo document No Signature 4704 If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP.
The requestor has not sufficient permission to perform the requested operation (ERROR) - No Consent 4701 The request MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent.
An ECR of the given purpose does not exist for the patient (ERROR) - Policy Violation 4109 The request MUST NOT be processed by the service provider.
Security Considerations

See Security Considerations.

EFA IHE-ITI-Binding: listRecordLocations

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.07}

The operation listRecordLocations of the Resource Manager is bound to the transaction Cross Gateway Query [ITI-38] of the XCA profile.

Constraints on the request message

The input of listRecordLocations SHALL be bound to ITI-56 Cross Gateway Query as follows:

listRecordLocations ITI-38 Request Constraints
context SAML Identity Assertion within the SOAP Security Header see IHE Cookbook
patientID $XDSFolderPatientId The patient-ID SHALL be known by Document Recipient.
purpose $XDSFolderCodeList The codeList MUST contain the purpose code, which restricts the query to the partitons of a specific ECR.

Futhermore, the query parameter $XDSFolderCodeList must contain the EFA-MountPoint classification code.

Response Message (Full Success Scenario)

The output of listRecordLocations SHALL be bound to ITI-38 Cross Gateway Query Response as follows:

listRecordLocations ITI-38 Response Constraints
MountPoint* see Binding of MountPoint The responder SHALL return only XDSFolder-Elements, that have been registered for this ECR with the Mount-Point classification. The responder SHALL return all XDSDocumentEntry-Elements, that are a member of these XDSFolder-Elements.
Response Message (Failure or Partial Failure Scenario)
Condition and Severity Location Message Code Action to be taken
The cross-community trust has not been established by means of a mutually authenticated channel or message authentication. (ERROR) - Policy Violation 4109 The request MUST NOT be processed by the Responding Gateway.
Security Considerations

The request and response messages SHALL be exchanged using a mutually authenticated channel or message authentication.

As for mutually authenticated channels, pairs of EFA-Providers SHOULD negotiate a protocol (f.e. SSH/TSL, VPN, KV-SafeNet) in the scope of contract conclusion.

As for message authentication, the SOAP-Body of the request and response messages SHALL be signed or encrypted using X.509 certificates.

EFA IHE-ITI-Binding: registerRecordLocation

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.08}

The operation registerRecordLocation SHALL be bound to the transaction Provide and Register Document Set ITI-41 [IHE ITI TF-2b#3.41] of the XDR profile.

Constraints on the request message
registerRecordLocation ITI-41 Constraints
context SAML Identity Assertion within the SOAP Security Header see IHE Cookbook
MountPoint.patientID XDSFolder.patientId The patientId SHALL be know at the target community.
MountPoint.purpose XDSFolder.codeList The codeList SHALL contain the purpose code.
MountPoint.sourcePatientID XDSDocumentEntry.sourcePatientId The sourcePatientId SHALL be the patientId known at the requesters community.
MountPoint.communityID XDSFolder.homeCommunityId The homeCommunityId SHALL be the requester's ID.

Furthermore, XDSFolder.codeList SHALL contain the EFA-classification code and the Mount-Point-classification code. The attribute XDSFolder.sourcePatientId SHALL contain the patientId known in the requester's community.

Expected Actions
Condition and Severity Location Message Code Action to be taken
The cross-community trust has not been established by means of a mutually authenticated channel or message authentication. (ERROR) - Policy Violation 4109 The Patient Identifier Cross-reference Manager MUST NOT process the message.
Security Considerations

The message SHALL be exchanged using a mutually authenticated channel or message authentication.

As for mutually authenticated channels, pairs of EFA-Providers SHOULD negotiate a protocol (f.e. SSH/TSL, VPN, KV-SafeNet) in the scope of contract conclusion.

As for message authentication, the SOAP-Body of the message SHALL be signed or encrypted using X.509 certificates.

EFA IHE-ITI-Binding: notifyOfConsent

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.08}

This binding implements the operation notifyOfConsent of the Resource Manager. It profiles the transaction Document Metadata Notify ITI-53 [IHE ITI Suppl. DSUB].

Constraints on the message

The input of notifyOfConsent SHALL be bound to the Notify Message [IHE ITI TF-2#3.53.4.1] as follows:

notifyOfConsent Notify Message Constraints
context SAML Identity Assertion within the SOAP Security Header see IHE Cookbook
patientID XDSDocumentEntry.patientId
purpose XDSDocumentEntry.eventCodeList
documentID
  • XDSDocumentEntry.uniqueID
  • XDSDocumentEntry.repositoryUniqueID
Expected Actions
Condition and Severity Location Message Code Action to be taken
The cross-community trust has not been established by means of a mutually authenticated channel or message authentication. (ERROR) - Policy Violation 4109 The Document Metadata Notification Recipient MUST NOT process the message.
Security Considerations

The message SHALL be exchanged using a mutually authenticated channel or message authentication.

As for mutually authenticated channels, pairs of EFA-Providers SHOULD negotiate a protocol (f.e. SSH/TSL, VPN, KV-SafeNet) in the scope of contract conclusion.

As for message authentication, the SOAP-Body of the message SHALL be signed or encrypted using X.509 certificates.



Information icon.svg HL7 Implementation Guide for CDA®, Release 2: Consent Directives, Release 1]
Abgerufen von „https://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_ResourceManager&oldid=26680“