EFA XDS DocumentRegistry

Aus Hl7wiki
(Teildokument von CDA für die elektronische Fallakte)
Wechseln zu: Navigation, Suche
(Die Seite wurde neu angelegt: „{{Infobox Dokument |Title = EFA XDS Document Registry Binding |Short = EFA XDS Document Registry Binding |Namespace = cdaefa |Type = Implementierungs…“)
 
(→‎EFA Document Registry XDS Binding)
 
(21 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
−
{{Infobox Dokument
+
{{DocumentPart
−
|Title    = EFA XDS Document Registry Binding
 
−
|Short    = EFA XDS Document Registry 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]]".''
 +
----
  
−
== EFA Document Registry XDS Binding ==
+
=== EFA Document Registry XDS Binding ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDcui.01}</tt>
  
−
Within EFA the actors and transactions of the IHE XDS integration profile are mapped onto EFA Document Repository actors and operations as follows:
+
Within EFA the actors and transactions of the IHE XDS integration profile are mapped onto EFA Document Registry actors and operations as follows:
  
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
!Role
 
!Role
−
!EFA Document Repository Service
+
!EFA Document Registry Service
 
!IHE XDS
 
!IHE XDS
 
|-
 
|-
 
!Actor
 
!Actor
 
|EFA Client
 
|EFA Client
−
|Document Source (for provideData)<br>Document Consumer (for retrieveData)
+
|Document Consumer
 +
|-
 +
!Actor
 +
|EFA Document Registry
 +
|XDS Document Registry
 
|-
 
|-
 
!Actor
 
!Actor
 
|EFA Document Repository
 
|EFA Document Repository
−
|XDS Document Repository  
+
|XDS Document Repository
 
|-
 
|-
 
!Transaction
 
!Transaction
−
|provideData
+
|[[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#registerData|registerData]]
−
|Provide and Register Document Set ITI-41
+
|Register Document Set ITI-42
 
|-
 
|-
 
!Transaction
 
!Transaction
−
|retrieveData
+
|[[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listPartitionContent|listPartitionContent]]
−
|Retrieve Document Set ITI-43
+
|Registry Stored Query ITI-18
 +
|-
 +
!Transaction
 +
|[[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#invalidateData|invalidateData]]
 +
|Update Document Set ITI-57
 
|}
 
|}
  
 +
==== EFA XDS Binding: registerData ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDcui.02}</tt>
  
−
== 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. 
  
−
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:
+
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  
 
* 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  
 +
* 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 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  
 
* 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 =====
−
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.  
+
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDcui.02.01}</tt>
−
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 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 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 [[cdaefa:EFA_Document_Repository_SFM|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 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 [[cdaefa:EFA_Document_Repository_SFM|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 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.  
+
* The XDS Document Registy MUST NOT process any metadata assigned to the submission set, it MUST solely rely on the document metadata.
−
* 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 =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDcui.02.02}</tt>
 +
 
 +
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) =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDcui.02.03}</tt>
  
−
=== Expected Actions ===
+
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"
−
The XDS Document Repository
 
  
−
SHALL forward the received documents to the EFA Document Repository Service using the ECR profiled Register Documents transaction.
+
===== Response Message (Failure or Partial Failure Scenario) =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDcui.02.04}</tt>
  
−
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.  
+
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.
  
−
SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.
+
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.
  
−
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.
+
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].
  
−
=== Response Message (Full Success Scenario) ===
+
===== Security Audit Considerations =====
−
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"
+
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDcui.02.05}</tt>
  
−
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”: 
+
See [[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]].
  
−
<syntaxhighlight lang="xml">
+
==== EFA XDS Binding: listPartitionContent ====
−
  <rs:RegistryResponse
+
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDcui.03}</tt>
−
          status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success">
+
 
−
    <rs:RegistryErrorList>
+
Listing the content of a partition corresponds to listing XDSDocumentEntry-Elements that are associated with a given XDSfolder.
−
      <rs:RegistryError
+
−
          severity=”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”
+
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:
−
          errorCode=”....”
+
* The query is restricted to listing the content of a single folder
−
          codeContext=”Processing deferred”
+
* Additional error messages are defined that cover specific failure conditions of the EFA use cases
−
          location="" />
+
* The availability of data fields is aligned to EFA privacy requirements
−
    </rs:RegistryErrorList>
+
* The application of security measures and the contents of the SOAP security header are specified normatively
−
  </rs:RegistryResponse>
+
−
</syntaxhighlight>
+
===== Constraints on the Request Message =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDcui.03.01}</tt>
 +
 
 +
This operation is bound to a sequence of ITI-18 transactions:
 +
# query GetFolderAndContents [IHE ITI TF-2a#3.18.4.1.2.3.7.11] to list XDSDocumentEntry-Elements,
 +
# query GetAssociations [IHE ITI TF-2a#3.18.4.1.2.3.7.7] to list document relationships.
  
−
The following warning messages and codes are defined:
+
The following table shows the operation parameter binding:
  
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
−
!Condition and Severity
+
!listPartitionContent
−
!Message
+
!ITI-18
−
!Code
+
!Constraints
−
!Action to be taken
+
|-
 +
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 +
|SAML Identity Assertion within the SOAP Security Header
 +
|see IHE Cookbook
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#partitionID|partitionID]]
 +
|$XDSFolderUniqueId
 +
|The requestor SHALL provide the unique folder ID as obtained when the partitions of an ECR were intially listed.
 
|-
 
|-
−
|Documents were received but not processed
+
|[[cdaefa:EFA_Business_Informationsmodell#docMetadata|docMetadata]] and [[cdaefa:EFA_Business_Informationsmodell#docRelationship|docRelationship]]
−
|Processing deferred
+
|registryObjectList
−
|2201
+
|document metadata SHALL comply to the [[cdaefa:EFA_XDS_Document_Metadata_Binding|ECR Document Metadata Binding]]. If returnType=ObjectRef is defined for the query then only the partition identifiers will be provided.
−
|None
 
 
|}
 
|}
  
−
=== Response Message (Failure or Partial Failure Scenario) ===
+
====== Example ======
−
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.
+
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDcui.03.01.01}</tt>
 +
 
 +
<syntaxhighlight lang="xml">
 +
<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>
 +
</syntaxhighlight>
 +
 
 +
===== Expected Actions =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDcui.03.02}</tt>
 +
 
 +
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 [[cdaefa:EFA_Business_Informationsmodell#ecrRef|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 [[cdaefa:EFA_XDS_Document_Metadata_Binding|EFA XDS Document Metadata Binding]].
  
−
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”.  
+
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.
−
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.
+
 
 +
===== Response Message (Full Success Scenario) =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDcui.03.03}</tt>
 +
 
 +
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) =====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDcui.03.04}</tt>
 +
 
 +
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:
  
−
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:
 
  
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
!Condition and Severity
 
!Condition and Severity
−
!Location
 
 
!Message
 
!Message
 
!Code
 
!Code
Zeile 120: Zeile 179:
 
|-
 
|-
 
|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)
 
|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
 
|Weak Authentication
 
|4702
 
|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.
 
|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)
+
|The ECR provider is unable to verify the identity and/or the authenticity of the requestor (ERROR)
−
|OID of the document that caused the error.
+
|Invalid Subject
−
|No Signature
+
|4703
−
|4704
+
|The request MUST NOT be processed by the service provider.
−
|If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP.
+
|-
 +
|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.
 
|-
 
|-
−
|For data of the given kind the EFA provider only accepts PDF coded documents (ERROR)
+
|The requestor has insufficient permissions to access the given partition.
−
|OID of the document
+
|No Consent
−
|PDF required
+
|4701
−
|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)
+
|The given partition is not classified as an ECR folder.
−
|OID of the document
 
 
|Policy Violation
 
|Policy Violation
 
|4109
 
|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 ===
+
===== Security Considerations =====
−
The EFA Provider MUST write an audit trail entry according to the EFA v1.2 Audit Trail specification.
+
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDcui.03.05}</tt>
−
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;"
+
See [[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]].
−
!category
+
 
−
!Opt.
+
 
−
!Description
+
==== EFA XDS Binding: invalidateData ====
−
|-
+
 
−
|Event
+
This binding realizes SFM operation ''[[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#invalidateData|invalidateData]]''.
−
|R
+
 
−
|Audited event
+
This binding conforms to IHE-ITI ''Update Document Set [ITI-57]'' and constrains it.
−
|-
+
 
−
|Requesting Point of Care
+
===== Constraints on the Request Message =====
−
|R
+
 
−
|Health professional organization that issued the original request.  
+
The request message SHALL conform to the metadata update operation ''Update DocumentEntry Status''.
−
|-
+
 
−
|Human Requestor
+
The request message SHALL contain an [[cdaefa:EFA_Identity_Assertion_SAML2_Binding|EFA Identity Assertion]]. It relates to parameter ''context'' of [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#invalidateData|SFM invalidateData]].
−
|R
+
 
−
|HP that triggered the request
+
The SFM parameter ''documentID'' is bound to the target object of the document relationship indirectly. Note: SFM ''documentID'' relates to DocumentEntry.uniqueID. Therefore, prior to invalidateData, an EFA Document Administrator must:
−
|-
+
# query the document entry by uniqueID, and
−
|Source Gateway
+
# use DocumentEntry.entryUUID as the reference to the target object.
−
|R
+
 
−
|EFA Client node address at the point of Care
+
The value of slot ''NewStatus'' shall be ''urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated''.
−
|-
+
 
−
|Target Gateway
+
===== Expected Actions =====
−
|R
+
 
−
|EFA provider node address
+
Any metadata update operation other than ''Update DocumentEntry Status'' SHALL cause the entire transaction to fail, returning an [[cdaefa:EFA_Error_Codes_and_Warning_Codes|Registry Error]] of type ''4109: Policy Violation''.
−
|-
+
 
−
|Audit Source
+
The EFA Document Registry SHALL enforce the access control policy of the EFA to which the to-be-invalidated document belongs to prior to updating its metadata.
−
|R
+
 
−
|Legal entity that ensures the uniqueness of the identifiers that are used to identify active participants
+
===== Response Message (Full Success Scenario) =====
−
|-
+
 
−
|Patient
+
No constraints.
−
|R
+
 
−
|Patient
+
===== Response Message (Failure or Partial Failure Scenario) =====
−
|-
+
 
−
|Event Target
+
No constraints.
−
|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:
+
===== Security Audit Considerations =====
  
−
{|class="wikitable" style="text-align: left; cellpadding: 10;"
+
See [[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]].
−
!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
 
−
|}
 
  
  
Zeile 224: Zeile 250:
 
----
 
----
  
−
* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
+
 
 +
{{NoteBox|'''Referenzen und Querverweise'''
 +
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
 +
<nowiki></nowiki>
 +
}}

Aktuelle Version vom 17. Februar 2016, 07:53 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 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
Transaction invalidateData Update Document Set ITI-57

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
  • 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 {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}

See Security Considerations.

EFA XDS Binding: listPartitionContent

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

Listing the content of a partition corresponds to listing XDSDocumentEntry-Elements that are associated with a given XDSfolder.

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}

This operation is bound to a sequence of ITI-18 transactions:

  1. query GetFolderAndContents [IHE ITI TF-2a#3.18.4.1.2.3.7.11] to list XDSDocumentEntry-Elements,
  2. query GetAssociations [IHE ITI TF-2a#3.18.4.1.2.3.7.7] to list document relationships.

The following table shows the operation parameter binding:

listPartitionContent 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 and docRelationship registryObjectList document metadata SHALL comply to the ECR Document Metadata Binding. If returnType=ObjectRef is defined for the query then only the partition identifiers will be provided.
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}

See Security Considerations.


EFA XDS Binding: invalidateData

This binding realizes SFM operation invalidateData.

This binding conforms to IHE-ITI Update Document Set [ITI-57] and constrains it.

Constraints on the Request Message

The request message SHALL conform to the metadata update operation Update DocumentEntry Status.

The request message SHALL contain an EFA Identity Assertion. It relates to parameter context of SFM invalidateData.

The SFM parameter documentID is bound to the target object of the document relationship indirectly. Note: SFM documentID relates to DocumentEntry.uniqueID. Therefore, prior to invalidateData, an EFA Document Administrator must:

  1. query the document entry by uniqueID, and
  2. use DocumentEntry.entryUUID as the reference to the target object.

The value of slot NewStatus shall be urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated.

Expected Actions

Any metadata update operation other than Update DocumentEntry Status SHALL cause the entire transaction to fail, returning an Registry Error of type 4109: Policy Violation.

The EFA Document Registry SHALL enforce the access control policy of the EFA to which the to-be-invalidated document belongs to prior to updating its metadata.

Response Message (Full Success Scenario)

No constraints.

Response Message (Failure or Partial Failure Scenario)

No constraints.

Security Audit Considerations

See Security Considerations.



Information icon.svg Referenzen und Querverweise
Abgerufen von „https://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRegistry&oldid=28813“