EFA XDS DocumentRepository

Aus Hl7wiki
(Teildokument von CDA für die elektronische Fallakte)
Wechseln zu: Navigation, Suche
(Constraints on the Request Message: Metadata of Submission Set, Document-Reference)
K (Constraints on the Request Message)
 
(15 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
{{Infobox Dokument
+
{{DocumentPart
|Title    = EFA XDS Document Repository Binding
 
|Short    = EFA XDS Document Repository 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]]".''
 
''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]]".''
 
----
 
----
  
== EFA Document Repository XDS Binding ==
+
=== EFA Document Repository XDS Binding ===
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.01}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.01}</tt>
  
Zeile 46: Zeile 31:
 
|}
 
|}
  
== EFA XDS Binding: provideData ==
+
==== EFA XDS Binding: provideData ====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.02}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.02}</tt>
  
Providing a document to an ECR provider's repository service is bound to the IHE ''Provide and Register Document Set'' transaction (ITI-41). This EFA binding introduces minor extensions and restrictions on the respective XDS actor and transaction definitions in order to properly cover the EFA use cases and to align with the EFA security framework:
+
Providing a document to an ECR provider's repository service is bound to the IHE ''Provide and Register Document Set'' transaction (ITI-41). This ECR binding introduces minor extensions and restrictions on the respective XDS actor and transaction definitions in order to properly cover the EFA use cases and to align with the EFA security framework:
 
* Documents must be associated with an XDS Folders, i.e an ECR partition, which in turn is part of an ECR that carries the permissions for accessing data.
 
* Documents must be associated with an XDS Folders, i.e an ECR partition, which in turn is part of an ECR that carries the permissions for accessing data.
 +
* The requestor must be capable to register documents to the ECR provider that is targeted by this request. The ECR partition the provided document is associated with must be registered at this ECR provider.
 
* Additional error messages are defined that cover specific failure conditions of the EFA use cases  
 
* 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 availability of data fields is aligned to EFA privacy requirements
* Documents cannot be copied by reference (Permissions are assigned to XDS Folders and therefore there is no easy way for an ECR Provider to verify the legitimacy for linking a document with another ECR)
 
 
* The application of security measures and the contents of the SOAP security header are specified normatively  
 
* The application of security measures and the contents of the SOAP security header are specified normatively  
  
=== Constraints on the Request Message ===
+
===== Constraints on the Request Message =====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.02.01}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.02.01}</tt>
  
 
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 ECR partition. Each transmission carries one or more documents. All provided documents will be registered with the same XDS Folder within the same logical EFA.  
 
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 ECR partition. Each transmission carries one or more documents. All provided documents will be registered with the same XDS 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:
 
* Each provided document SHALL be associated with an XDS Folder.
 
* The target XDS Folder SHALL be available in advance to this transaction. All provided documents SHALL be associated with the same XDS Folder (these restrictions ensure the proper implementation of the [[cdaefa:EFA_Document_Repository_SFM|EFA Document Repository SFM]] which implies the existence of a ECR partition and only allows for a single partitionID to be included with the request).
 
* The requestor (EFA Client) SHOULD provide documents embraced by a single IHE XDS submission set acc. to [IHE ITI TF-2a].
 
* All metadata of the submission set and all associations between documents and submission sets MUST NOT have EFA semantics. The EFA Provider MUST solely rely on the document metadata and contents.
 
* Documents to be stored and registered SHALL be included with the request. The EFA provider MUST NOT register documents that are only provided through metadata and/or associations.
 
  
=== Expected Actions ===
+
The request message implements the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE ITI TF-2b]. 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
 +
!provideData 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"|-
 +
|-
 +
|The XDSFolder is registered (uniqueID)
 +
| align="center"|R
 +
|-
 +
|}
 +
 
 +
===== Expected Actions =====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.02.02}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.02.02}</tt>
  
The XDS Document Repository SHALL forward the received documents to the EFA Document Repository Service using the [[cdaefa:EFA_XDS_DocumentRegistry#EFA_XDS_Binding:_registerData|ECR profiled Register Documents transaction]].
+
The XDS Document Repository SHALL forward the received documents to the EFA Document Registry using the [[cdaefa:EFA_XDS_DocumentRegistry#EFA_XDS_Binding:_registerData|ECR profiled Register Documents transaction]].
  
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 XDS Folder.  
+
The EFA Document Registry 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 XDS Folder.  
  
 
After processing the request the XDS Document Repository actor SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.
 
After processing the request the XDS Document Repository actor SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.
Zeile 78: Zeile 82:
 
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.
 
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) ===
+
===== Response Message (Full Success Scenario) =====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.02.03}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.02.03}</tt>
  
Zeile 112: Zeile 116:
 
|}
 
|}
  
=== Response Message (Failure or Partial Failure Scenario) ===
+
===== Response Message (Failure or Partial Failure Scenario) =====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.02.04}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.02.04}</tt>
  
If the EFA Document Repository 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.
+
If the EFA Document Repository failed with processing all of the documents or failed with forwarding all documents to the EFA Document Registry, 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 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”.  
Zeile 152: Zeile 156:
 
|4109
 
|4109
 
|The provided document MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent.
 
|The provided document MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent.
|-
 
|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)
 
|OID of the document
 
|Unresolvable Reference
 
|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 target XDS Folder.
 
 
|}
 
|}
  
=== Security Considerations ===
+
===== Security Considerations =====
 
 
==== Audit Trail ====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.02.05.02}</tt>
 
 
 
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).
 
 
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
!category
 
!Opt.
 
!Description
 
|-
 
|Event
 
|R
 
|Audited event
 
|-
 
|Requesting Point of Care
 
|R
 
|Health professional organization that issued the original request.
 
|-
 
|Human Requestor
 
|R
 
|HP that triggered the request
 
|-
 
|Source Gateway
 
|R
 
|EFA Client node address at the point of Care
 
|-
 
|Target Gateway
 
|R
 
|EFA provider node address
 
|-
 
|Audit Source
 
|R
 
|Legal entity that ensures the uniqueness of the identifiers that are used to identify active participants
 
|-
 
|Patient
 
|R
 
|Patient
 
|-
 
|Event Target
 
|R
 
|References to the provided documents (see below)
 
|-
 
|Error Message
 
|O
 
|Only used in case that the request handling was not completed successfully
 
|}
 
  
For the Event Target Category the following fields MUST be provided:
+
See [[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]].
  
{|class="wikitable" style="text-align: left; cellpadding: 10;"
+
==== EFA XDS Binding: retrieveData ====
!Field Name
 
!Opt.
 
!Value Constraints
 
|-
 
|ParticipantObjectTypeCode
 
|R
 
|MUST be “2” (System Object)
 
|-
 
|ParticipantObjectTypeCodeRole
 
|R
 
|MUST be “4” (Resource)
 
|-
 
|ParticipantObjectIDTypeCode
 
|R
 
|MUST be “12” (URI)
 
|-
 
|ParticipantObjectID
 
|R
 
|MUST be string-encoded UUIDs of the provided documents
 
|}
 
 
 
 
 
== EFA XDS Binding: retrieveData ==
 
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.03}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.03}</tt>
  
Zeile 244: Zeile 171:
 
* The application of security measures and the contents of the SOAP security header are specified normatively  
 
* The application of security measures and the contents of the SOAP security header are specified normatively  
 
   
 
   
=== Constraints on the Request Message ===
+
===== Constraints on the Request Message =====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.03.01}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.03.01}</tt>
  
Zeile 261: Zeile 188:
 
|-
 
|-
 
|[[cdaefa:EFA_Business_Informationsmodell#documentID|documentID]]
 
|[[cdaefa:EFA_Business_Informationsmodell#documentID|documentID]]
|DocumentResponse/repositoryUniqueId<br>DocumentResponse/documentUniqueId
+
|DocumentRequest/RepositoryUniqueId<br>DocumentRequest/DocumentUniqueId
 
|The requestor SHALL provide these unique IDs as obtained when the contents of an ECR partition were intially listed.  
 
|The requestor SHALL provide these unique IDs as obtained when the contents of an ECR partition were intially listed.  
 
|-
 
|-
 
|[[cdaefa:EFA_Business_Informationsmodell#docData|docData]]
 
|[[cdaefa:EFA_Business_Informationsmodell#docData|docData]]
|DocumentResponse/document
+
|DocumentResponse/Document
 
| -  
 
| -  
 
|}
 
|}
Zeile 272: Zeile 199:
 
* The data to be retrieved SHALL all be associated with the same XDS Folder. It SHALL be classified as an ECR partition.
 
* The data to be retrieved SHALL all be associated with the same XDS Folder. It SHALL be classified as an ECR partition.
  
==== Example ====
+
====== Example ======
  
 
<syntaxhighlight lang="xml">  
 
<syntaxhighlight lang="xml">  
Zeile 283: Zeile 210:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
=== Expected Actions ===
+
===== Expected Actions =====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.03.02}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.03.02}</tt>
  
The XDS Document Repository SHALL respond to a Retrieve Document Set request message with the Retrieve Document Set response message containing a success indicator and listing all requested documents. The provider of the XDS Document Repository MUST verify that the requestor has sufficient rights to access the requested documents.
+
The XDS Document Repository SHALL respond to a Retrieve Document Set request message with the Retrieve Document Set response message containing a success indicator and listing all requested documents. The provider of the XDS Document Repository MUST verify that the requestor has sufficient rights to access the requested documents.
  
 
In processing of this request the ECR Provider SHALL
 
In processing of this request the ECR Provider SHALL
 +
* request the DocumentEntry.availabilityStatus for the given DocumentUniqueId (a health record manager is allowed to access documents with availabilityStatus "Deprecated"),
 
* assess the access control policy of the [[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]] object that is assigned with the XDS Folder that is associated to the requested documents. If a document is not associated with an XDS Folder or if no ecrRef object is assigned to the XDS Folder, the XDS Document Repository MUST respond with a "policy violation" error.
 
* assess the access control policy of the [[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]] object that is assigned with the XDS Folder that is associated to the requested documents. If a document is not associated with an XDS Folder or if no ecrRef object is assigned to the XDS Folder, the XDS Document Repository MUST respond with a "policy violation" error.
 
* respond to the requestor with the requested documents.  
 
* respond to the requestor with the requested documents.  
Zeile 294: Zeile 222:
 
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.
 
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) ===
+
===== Response Message (Full Success Scenario) =====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.03.03}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.03.03}</tt>
  
 
If the EFA Document Repository Service provider is able to decode and process the received message it responds with the discovered documents acc. to the specification of the ITI-43 response message.  
 
If the EFA Document Repository Service provider is able to decode and process the received message it responds with the discovered documents acc. to the specification of the ITI-43 response message.  
  
=== Response Message (Failure or Partial Failure Scenario) ===
+
===== Response Message (Failure or Partial Failure Scenario) =====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.03.04}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.03.04}</tt>
  
Zeile 341: Zeile 269:
 
|}
 
|}
  
=== Security Considerations ===
+
===== Security Considerations =====
  
==== Audit Trail ====
+
See [[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]].
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EXoce.03.05.02}</tt>
 
  
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).
 
  
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
!category
 
!Opt.
 
!Description
 
|-
 
|Event
 
|R
 
|Audited event
 
|-
 
|Requesting Point of Care
 
|R
 
|Health professional organization that issued the original request.
 
|-
 
|Human Requestor
 
|R
 
|HP that triggered the request
 
|-
 
|Source Gateway
 
|R
 
|EFA Client node address at the point of Care
 
|-
 
|Target Gateway
 
|R
 
|EFA provider node address
 
|-
 
|Audit Source
 
|R
 
|Legal entity that ensures the uniqueness of the identifiers that are used to identify active participants
 
|-
 
|Patient
 
|R
 
|Patient
 
|-
 
|Event Target
 
|R
 
|References to the documents that are provided by the response message (see below)
 
|-
 
|Error Message
 
|O
 
|Only used in case that the request handling was not completed successfully
 
|}
 
  
For the Event Target Category the following fields MUST be provided:
+
----
  
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
!Field Name
 
!Opt.
 
!Value Constraints
 
|-
 
|ParticipantObjectTypeCode
 
|R
 
|MUST be “2” (System Object)
 
|-
 
|ParticipantObjectTypeCodeRole
 
|R
 
|MUST be “4” (Resource)
 
|-
 
|ParticipantObjectIDTypeCode
 
|R
 
|MUST be “12” (URI)
 
|-
 
|ParticipantObjectID
 
|R
 
|MUST be string-encoded URNs of the documents that are provided by the response message
 
|}
 
 
== Querverweise und Referenzen ==
 
  
 +
{{NoteBox|'''Referenzen und Querverweise'''
 
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
 
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
 +
<nowiki></nowiki>
 +
}}

Aktuelle Version vom 2. November 2015, 15:30 Uhr

Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".


EFA Document Repository XDS Binding

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

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

Role EFA Document Repository Service IHE XDS
Actor EFA Client Document Source (for provideData)
Document Consumer (for retrieveData)
Actor EFA Document Repository XDS Document Repository
Transaction provideData Provide and Register Document Set ITI-41
Transaction retrieveData Retrieve Document Set ITI-43

EFA XDS Binding: provideData

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

Providing a document to an ECR provider's repository service is bound to the IHE Provide and Register Document Set transaction (ITI-41). This ECR binding introduces minor extensions and restrictions on the respective XDS actor and transaction definitions in order to properly cover the EFA use cases and to align with the EFA security framework:

  • Documents must be associated with an XDS Folders, i.e an ECR partition, which in turn is part of an ECR that carries the permissions for accessing data.
  • The requestor must be capable to register documents to the ECR provider that is targeted by this request. The ECR partition the provided document is associated with must be registered at this ECR provider.
  • 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 {EXoce.02.01}

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 ECR partition. Each transmission carries one or more documents. All provided documents will be registered with the same XDS 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]. 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 provideData 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) -
The XDSFolder is registered (uniqueID) R
Expected Actions

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

The XDS Document Repository SHALL forward the received documents to the EFA Document Registry using the ECR profiled Register Documents transaction.

The EFA Document Registry 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 XDS Folder.

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

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)

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

If the EFA Document Repository 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”:

  <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=”2201”
           codeContext=”Processing deferred” 
           location="" />
     </rs:RegistryErrorList> 
   </rs:RegistryResponse>

The following warning messages and codes are defined:

Condition and Severity Message Code Action to be taken
Documents were received but not processed Processing deferred 2201 None
Response Message (Failure or Partial Failure Scenario)

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

If the EFA Document Repository failed with processing all of the documents or failed with forwarding all documents to the EFA Document Registry, 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”. 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.
The EFA Document Registry service provider only accepts data of the given kind if it is digitally signed by an HCP. (ERROR) OID of the document that caused the error. No Signature 4704 If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP.
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 Policy Violation 4109 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 Binding: retrieveData

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

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

  • Constraints on the retrieved documents due to the ECR usage conventions for XDS 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 {EXoce.03.01}

The retrieveData request message implements the IHE Retrieve Document Set transaction (ITI-43) request message.

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

retrieveData ITI-43 Constraints
context SAML Identity Assertion within the SOAP Security Header see IHE Cookbook
documentID DocumentRequest/RepositoryUniqueId
DocumentRequest/DocumentUniqueId
The requestor SHALL provide these unique IDs as obtained when the contents of an ECR partition were intially listed.
docData DocumentResponse/Document -

In addition the following constrains must be considered:

  • The data to be retrieved SHALL all be associated with the same XDS Folder. It SHALL be classified as an ECR partition.
Example
 
<RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007">
   <DocumentRequest>
      <RepositoryUniqueId>1.19.6.24.109.42.1.5</RepositoryUniqueId>
      <DocumentUniqueId>1.42.20101110141555.15</DocumentUniqueId>
   </DocumentRequest>
</RetrieveDocumentSetRequest>
Expected Actions

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

The XDS Document Repository SHALL respond to a Retrieve Document Set request message with the Retrieve Document Set response message containing a success indicator and listing all requested documents. The provider of the XDS Document Repository MUST verify that the requestor has sufficient rights to access the requested documents.

In processing of this request the ECR Provider SHALL

  • request the DocumentEntry.availabilityStatus for the given DocumentUniqueId (a health record manager is allowed to access documents with availabilityStatus "Deprecated"),
  • assess the access control policy of the ecrRef object that is assigned with the XDS Folder that is associated to the requested documents. If a document is not associated with an XDS Folder or if no ecrRef object is assigned to the XDS Folder, the XDS Document Repository MUST respond with a "policy violation" error.
  • respond to the requestor with the requested documents.

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 {EXoce.03.03}

If the EFA Document Repository Service provider is able to decode and process the received message it responds with the discovered documents acc. to the specification of the ITI-43 response message.

Response Message (Failure or Partial Failure Scenario)

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

If the XDS Document Repository is unable to successfuly process the query request it MUST respond with a RetrieveDocumentSetResponse message that only contains a RegistryResponse element.

If no matching document 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”. The failure semantics is all-or-nothing; as soon as one of the requested documents cannot be provided the XDS Document Repository responds with a full failure by providing none of the requested 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 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.
One or more document identifiers are unknown to the ECR provider. No Data 1102 -
The requestor has insufficient permissions to access one or more of the requested documents. No Consent 4701 -
Multiple XDS Folders are associated with the requested documents or at least one of the associated XDS Folders is not classified as an ECR partition. Policy Violation 4109 -
Security Considerations

See Security Considerations.