EFA XDS Document Registry Binding

EFA XDS Document Registry Binding

EFA XDS Document Registry Binding

Implementierungsleitfaden

vorgelegt von:
February 2013
Jörg Caumanns, Raik Kuhlisch

Draft

Version:	0.9
Datum:	March 2013
Status:	xxx
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2012-2013: HL7 Deutschland

EFA Document Registry XDS Binding

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: registerData

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:

• Documents must be associated with folders in order to reflect that each ECR data element must be placed within a partition which in turn is part of a case record that carries the permissions for accessing data
• 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 ProvideAndRegisterDocument request message is issued by an EFA client at the point of care for providing and registering a medical document to an existing folder which is bound to an 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:

• Each provided document SHALL be associated with a folder.
• The target folder SHALL be available in advance to this transaction. All provided documents SHALL be associated withthe same folder (these restrictions ensure the proper implementation of the EFA Document Repository SFM which implies the existence of a partition and only allows for a single partitionID to be included with the request).
• 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.
• 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 XDS Document Repository

SHALL forward the received documents to the EFA Document Repository Service using the 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 folder.

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)

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”:

  <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=”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)

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.

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 exted 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 destination folder.

Security Audit Considerations

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).

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:

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

---

• zurück zur EFA-2.0-Spezifikation