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

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 Registry XDS Binding

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

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

Role	EFA Document Registry Service	IHE XDS
Actor	EFA Client	Document Consumer
Actor	EFA Document Registry	XDS Document Registry
Actor	EFA Document Repository	XDS Document Repository
Transaction	registerData	Register Document Set ITI-42
Transaction	listPartitionContent	Registry Stored Query ITI-18

EFA XDS Binding: registerData

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

While medical data is received and stored by the XDS Document Repository it is the responsibility of the Document Registry to register that data in a way that it can be queried through search and browse operations.

Such registration of a document to an ECR provider's registry service is bound to the IHE Register Document Set transaction (ITI-42). 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
• 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 {EDcui.02.01}

The RegisterDocument request message is issued by an ECR Document Repository actor for registering a medical document to an existing folder which is bound to an EFA instance. Each transmission carries metadata and associations for one or more documents. All referenced documents will be registered with the same folder within the same logical EFA.

The request message implements the IHE Register DocumentSet transaction (ITI-42) request message as profiled in [IHE ITI TF-2b] considering the following constraints:

• Each registered document SHALL be associated with a folder.
• The target folder SHALL be available in advance to this transaction. All documents SHALL be associated with the 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 (ECR Document Repository) 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 XDS Document Registy MUST NOT process any metadata assigned to the submission set, it MUST solely rely on the document metadata.

Expected Actions

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

The EFA Document Registry Service provider MUST verify that the requesting service is trustworthy in a way that the registry service can rely on the access control decision that has already been performed by the document repository in advance to this request. The EFA Document Registry Service SHALL respond to an RegisterDocumentSet request message with the RegisterDocumentSet response message containing a success indicator.

Response Message (Full Success Scenario)

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

If the EFA Document Registry Service provider is able to decode the received message and to properly register all documents 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 {EDcui.02.04}

If the EFA Document Registry Service provider is able to decode the received message but the registration 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 documents. It MUST NOT be given if the error applies to all 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. For a list of valid error codes and message see Table 4.1-11 of [IHE ITI TF-3].

Security Audit Considerations

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.02.05}

The XDS Document Registry MUST write an audit trail entry according to the respective constraints defined in [IHE ITI TF-2b].

EFA XDS Binding: listPartitionContent

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

ECR partitions are implemented as XDS folders. Therefore listing the content of a partition corresponds to listing all document metadata objects that are associated to a given XDS folder.

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

• The query is restricted to listing the content of a single folder
• 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 {EDcui.03.01}

The listData request message implements the GetFolderAndContents 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 listData SFM is mapped onto the ITI-18 transaction's query arguments:

listData	ITI-18	Constraints
context	SAML Identity Assertion within the SOAP Security Header	see IHE Cookbook
partitionID	$XDSFolderUniqueId	The requestor SHALL provide the unique folder ID as obtained when the partitions of an ECR were intially listed.
docMetadata	registryObjectList	document metadata SHALL comply to the ECR Document Metadata Binding

In addition the following constrains must be considered:

• Other query arguments than the $XDSFolderUniqueID SHALL NOT be used.

Example

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.03.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:b909a503-523d-4517-8acf-8e5834dfc4c7">
      <rim:Slot name="$XDSFolderUniqueId">
         <rim:ValueList>
            <rim:Value>'2871627126387^^^&amp;1.2.3.4.213.234.3.7&amp;ISO'</rim:Value>
         </rim:ValueList>
      </rim:Slot>
   </rim:AdhocQuery>
</query:AdhocQueryRequest>

Expected Actions

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.03.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 documents 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 given XDS folders.

In processing of this request the ECR Provider SHALL

• assess the access control policy of the ecrRef object that is assigned with the given folder. If no such object is assigned to the folder, the XDS Document Registry MUST respond with a "policy violation" error.
• respond to the requestor with the metadata of the discovered documents. Metadata provided SHALL comply to the EFA XDS Document 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 {EDcui.03.03}

If the EFA Document Registry Service provider is able to decode and process the received message it responds with the registry metadata of the discovered documents.

Response Message (Failure or Partial Failure Scenario)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.03.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 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 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 partition is unknown to the ECR provider.	No Data	1102	The requestor should use a MPI service to discovery an identifier for the patient that is known to the ECR provider.
The requestor has insufficient permissions to access the given partition.	No Consent	4701	-
The given partition is not classified as an ECR folder.	Policy Violation	4109	-

Security Considerations

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.03.05}

Audit Trail

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.03.05.02}

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 documents that are listed within 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:

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 referenced within the response message

Querverweise und Referenzen

• EFA-2.0-Spezifikation