EFA XDS Document Registry Binding
K (→EFA Document Registry XDS Binding) |
|||
| Zeile 37: | Zeile 37: | ||
|- | |- | ||
!Transaction | !Transaction | ||
| − | |registerData | + | |[[cdaefa:EFA_Document_Registry_SFM#registerData|registerData]] |
|Register Document Set ITI-42 | |Register Document Set ITI-42 | ||
|- | |- | ||
!Transaction | !Transaction | ||
| − | | | + | |[[cdaefa:EFA_Document_Registry_SFM#listData|listData]] |
|Registry Stored Query ITI-18 | |Registry Stored Query ITI-18 | ||
|} | |} | ||
| − | |||
== EFA XDS Binding: registerData == | == EFA XDS Binding: registerData == | ||
Version vom 6. April 2013, 19:48 Uhr
 |
Dieses Dokument gibt wieder:
Implementierungsleitfaden EFA XDS Document Registry Binding (0.9). Die Teilmaterialien gehören der Kategorie cdaefa an. |
February 2013
Jörg Caumanns, Raik Kuhlisch
| Version: | 0.9 |
| Datum: | March 2013 |
| Status: | xxx |
| Verfahren: | {{{Verfahren}}} |
| Realm: |  Deutschland
|
Inhaltsverzeichnis
EFA Document Registry XDS Binding
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 | listData | Registry Stored Query ITI-18 |
EFA XDS Binding: registerData
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
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 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 (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
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 ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.
Response Message (Full Success Scenario)
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)
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
The XDS Document Registry MUST write an audit trail entry according to the respective constraints defined in [IHE ITI TF-2b].
- zurück zur EFA-2.0-Spezifikation
