EFA XDS Resource Manager Binding
 |
Dieses Dokument gibt wieder:
Implementierungsleitfaden EFA XDS Resource Manager 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
|
Status: 
Offene Punkte:
- EFA schließen
- Beispiele
Inhaltsverzeichnis
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:
| Role | EFA Resource Manager Service | IHE XDS |
|---|---|---|
| Actor | EFA Client | Document Source |
| Actor | EFA Resource Manager | Document Repository |
| Transaction | createECR | Provide and Register Document Set ITI-41 |
| Transaction | createPartition | Provide and Register Document Set ITI-41 |
| Transaction | closeECR | Provide and Register Document Set ITI-41 |
EFA XDS/XDR Binding: createECR
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 eventCodes
- 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
- 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 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 SFM is mapped onto the ITI-41 transaction:
| createECR | ITI-41 | Constraints |
|---|---|---|
| context | SAML Identity Assertion within the SOAP Security Header | see IHE Cookbook |
| patientID | XDS Folder Attribute: patientID XDS Document 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 |
| ecrInfo | XDS Folder Attribute: title XDS Folder Attribute: uniqueID |
Further elements of the ecrInfo structure MAY be set by the ECR provider. |
| consentInfo | XDS Document | |
| consentDoc (optional) | XDS Document | Scaned documents SHALL be provided acc. to the XDS SD Integration Profile. |
Following this, implementations SHALL consider the following constraints:
- All provided documents SHALL be associated with a newly created XDS folder. Folder metadata SHALL be used as specified in the EFA XDS Folder Metadata Binding.
- The request carries one or more documents. One of these documents SHALL be a consent information document.
- All document metadata SHALL be provided as specified in the EFA XDS Document Metadata Binding.
- 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 the submission set 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
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 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. It SHALL verify that all named ECR participants are either registered with the provider or identifiable through a shared healthcare provider directory.
The ECR 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 ECR 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 XDR 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 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
- 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 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 EFA Resource Manager Service provider MUST respond with the respective error status.
Response Message (Full Success Scenario)
If the EFA Document Registry Service provider 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 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=”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 ECR 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)
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 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) | - | Policy Violation | 4109 | The request MUST NOT be processed by the service provider. The HP MAY request the patient to exted 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) | - | Policy Violation | 4109 | The request MUST NOT be processed by the service provider. The HP MAY request the patient to exted the consent for the existing ECR. |
| The ECR 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 | 4110 | 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 ECR provider. |
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 | Reference to the newly instantiated partition (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 newly instantiated partition and all provided documents |
EFA XDS/XDR Binding: createPartition
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 eventCodes
- 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 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:
| createECR | 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 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 consider the following constraints:
- All provided documents SHALL be associated with a newly created XDS folder. Folder metadata SHALL be used as specified in the EFA XDS Folder Metadata Binding.
- The request shall provide one or more documents to the newly created folder.
- All document metadata SHALL be provided as specified in the EFA XDS Document Metadata Binding.
- 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 the submission set 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.
 |
The Resource Manager SFM allows for initializing empty partitions while XDS requires at least a single document to be provided whenever a new folder is created. |
Expected Actions
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)
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)
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. |
| 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) | - | Policy Violation | 4109 | The request MUST NOT be processed by the service provider. The HP MAY request the patient to exted 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 | 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 | Reference to the newly instantiated partition (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 newly instantiated partition and all provided documents |
EFA XDS/XDR Binding: closeECR
The explicit shutdown of a new ECR is performed by linking a new XDS folder to the ECR where the folder carries a consentInfo document that invalidates all previously given permissions. The folder 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 shall be created and purpose codes shall be provided for the newly created folder as eventCodes
- 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
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 createECR SFM is mapped onto the ITI-41 transaction:
| createECR | 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 consider the following constraints:
- All provided documents SHALL be associated with a newly created XDS folder or with a folder that is already part of the ECR. Folder metadata SHALL be used as specified in the EFA XDS Folder Metadata Binding.
- The request carries one or more documents. One of these documents SHALL be a consent information document.
- All document metadata SHALL be provided as specified in the EFA XDS Document Metadata Binding.
- 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 the submission set 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
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)
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)
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) | - | Policy Violation | 4109 | The request MUST NOT be processed by the service provider. The HP MAY request the patient to exted 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 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 all partitions that are affected by this operation (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 all partitions that belong the the closed ECR |
- zurück zur EFA-2.0-Spezifikation
