cdaefa:EFA Projectathon 2016 - Versionsgeschichte

Jcaumanns: /* Validation with EFA-EVS at Fraunhofer FOKUS */ Hint for downtime

2016-04-06T22:07:10Z

‎Validation with EFA-EVS at Fraunhofer FOKUS: Hint for downtime

Jcaumanns: /* Test Steps */ Hint about "parts"

2016-04-06T20:58:25Z

‎Test Steps: Hint about "parts"

Jcaumanns: /* Test Data */ Codes für Folder.codeList korrigiert.

2016-04-06T20:55:26Z

‎Test Data: Codes für Folder.codeList korrigiert.

Jcaumanns: /* Test Data */ Codes für Folder.codeList korrigiert.

2016-04-06T20:52:16Z

‎Test Data: Codes für Folder.codeList korrigiert.

Jcaumanns: /* Test Case 2: EFA Initialization */ Removed Variant 1

2016-04-06T20:50:08Z

‎Test Case 2: EFA Initialization: Removed Variant 1

Jcaumanns: /* Test Steps Variant 2 */ Removed Variant 2.

2016-04-06T20:49:28Z

‎Test Steps Variant 2: Removed Variant 2.

Jcaumanns: /* Test Data */ Codes für Folder.codeList und DocumentEntry.formatCode korrigiert. EPPC-SD entfernt.

2016-04-06T20:47:56Z

‎Test Data: Codes für Folder.codeList und DocumentEntry.formatCode korrigiert. EPPC-SD entfernt.

Jcaumanns: /* Further details */ Removed deprecated information.

2016-04-06T20:39:10Z

‎Further details: Removed deprecated information.

Jcaumanns: /* IHE XUA Get X-User Assertion */ Replaced deprecated information about FOKUS STS.

2016-04-06T20:34:25Z

‎IHE XUA Get X-User Assertion: Replaced deprecated information about FOKUS STS.

Jcaumanns: /* IHE ITI-19 (Node Authentication) */ Hint TLS at Projectathon

2016-04-06T20:28:27Z

‎IHE ITI-19 (Node Authentication): Hint TLS at Projectathon

← Nächstältere Version		Version vom 6. April 2016, 22:07 Uhr
Zeile 265:		Zeile 265:

	=== Validation with EFA-EVS at Fraunhofer FOKUS ===		=== Validation with EFA-EVS at Fraunhofer FOKUS ===
		+
		+	{{FAQBox\| Currently, this service is not operational. We try to fix this problem as soon as possible.}}

	Fraunhofer FOKUS provides an online validation service for EFA. The service consumes ITI request messages and responds with an SVRL report. Compared to validation with Schematron this service provides enhanced validation features for the operation InitializeECR:		Fraunhofer FOKUS provides an online validation service for EFA. The service consumes ITI request messages and responds with an SVRL report. Compared to validation with Schematron this service provides enhanced validation features for the operation InitializeECR:

@@ Zeile 217: / Zeile 217: @@
 # Verify, that Gazelle EVS Schematron BrowseECR did not fail.
 # Verify, that the EFA Client actor received a Success response containing a single Folder (TC3-V2) and a single DocumentEntry (TC3-V2).
 === Test Case 5: Fetching a Document from an Existing EFA ===

@@ Zeile 193: / Zeile 193: @@
 ;FindFolders Params
 :$XDSFolderPatientId = TC2 Folder.patientId
-:$XDSFolderCodeList = ECR^^^IHE-D-Cookbook-FolderClassCode AND ???^^^1.2.276.0.76.3.1.81.81.5.6 (equal to TC2 Folder.codeList)
+:$XDSFolderCodeList = ''ECR^^1.3.6.1.4.1.19376.3.276.1.5.7'' AND ''Test:Connectathon-2016:Sinusitis-Demo^^1.2.276.0.76.3.1.81.81.5.6'' (equal to TestCase2 Folder.codeList)
 ;GetFolderAndContents Params Folder 1
-:$XDSFolderEntryUUID or $XDSFolderUniqueId = equal to TC2 Folder.entryUUID and Folder.uniqueId respectively
+:$XDSFolderEntryUUID or $XDSFolderUniqueId = equal to TestCase2 Folder.entryUUID and Folder.uniqueId respectively
 ;GetFolderAndContents Params Folder 2
-:$XDSFolderEntryUUID or $XDSFolderUniqueId = equal to TC3V2 Folder.entryUUID and Folder.uniqueId respectively
+:$XDSFolderEntryUUID or $XDSFolderUniqueId = equal to TestCase3Variant2 Folder.entryUUID and Folder.uniqueId respectively
 ==== Test Steps ====

@@ Zeile 154: / Zeile 154: @@
 :The X-User Assertion must be obtained by running Test Case 1.
 ;Folder
-:Folder.codeList = [( code=ECR, codesystem=IHE-D-Cookbook-FolderClassCode ), ( code=???, codesystem=1.2.276.0.76.3.1.81.81.5.6 )]
+:Folder.codeList = [( code=''ECR'', codesystem=''1.3.6.1.4.1.19376.3.276.1.5.7'' ), ( code=''Test:Connectathon-2016:Sinusitis-Demo'', codesystem=''1.2.276.0.76.3.1.81.81.5.6'' )]
 :Folder.patientId = The ID of a patient that is shared using https://gazelle.ihe.net/EU-CAT/testing/patients/updatePatient.seam
 ;Folder-Document-HasMember

@@ Zeile 105: / Zeile 105: @@
 === Test Case 2: EFA Initialization ===
 A new EFA instance is set up by creating a respectively classified XDS folder at the EFA Provider and uploading a machine readable consent document into this folder. The constraints to be implemented are defined at http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_createECR
 {{FAQBox|This test case requires the EFA Provider actor to drop data stored and registered in previous test runs.}}
@@ Zeile 134: / Zeile 132: @@
 : PolicySet/Policy[2]/Target/Subjects/Subject contains SubjectMatches matching any applicable X-User subject with role ''health record management''.
-==== Test Steps ''Variant 1'' ====
+==== Test Steps ====
 Initialize an EFA using an EPPC document.
 # The EFA Client actor sends an InitializeECR request message to the EFA Provider actor. The SOAP part contains given test data X-User Assertion, Folder, and EPPC DocumentEntry. The SOAP attachement contains test data EPPC document with embedded XACML-Policy.

@@ Zeile 140: / Zeile 140: @@
 # Verify, that EFA Client received a ''Success'' response.
 # The EFA Client actor sends an InitializeECR request message to the EFA Provider actor. The SOAP part contains given test data X-User Assertion, Folder, and EPPC DocumentEntry. The SOAP attachement contains test data EPPC document with embedded XACML-Policy.
 # Verify, that EFA Client received a ''Failure'' response containing the Policy Violation error code.

@@ Zeile 114: / Zeile 114: @@
 : The X-User Assertion must be obtained by running Test Case 1.
 ;Folder
-: Folder.codeList = [( code=''ECR'', codesystem=''IHE-D-Cookbook-FolderClassCode'' ), ( code=???, codesystem=''1.2.276.0.76.3.1.81.81.5.6'' )]
+: Folder.codeList = [( code=''ECR'', codesystem=''1.3.6.1.4.1.19376.3.276.1.5.7'' ), ( code=''Test:Connectathon-2016:Sinusitis-Demo'', codesystem=''1.2.276.0.76.3.1.81.81.5.6'' )]
 : Folder.patientId = The ID of a patient that is shared using https://gazelle.ihe.net/EU-CAT/testing/patients/updatePatient.seam
 ;EPPC DocumentEntry
@@ Zeile 120: / Zeile 120: @@
 : DocumentEntry.classCode = ( code=''57016-8'', codesystem=''2.16.840.1.113883.6.1'', display=''Privacy Policy Acknowledgement Document'' )
 : DocumentEntry.confidentialityCode = ''N''
-: DocumentEntry.formatCode = ( code=''urn:ihe-d:ig:eppc:2015'', codesystem=''1.3.6.1.4.1.19376.3.276.5.4'', display=''Enhanced Patient Privacy Consent'' )
+: DocumentEntry.formatCode = ( code=''urn:ihe-d:ig:eppc-g:2015'', codesystem=''1.3.6.1.4.1.19376.3.276.1.5.6'', display=''Enhanced Patient Privacy Consent'' )
 : DocumentEntry.typeCode = ( code=''59284-0'', codesystem=''2.16.840.1.113883.6.1'', display=''Consent Document Patient'' )
 : DocumentEntry.patientId = The ID of a patient that is shared using https://gazelle.ihe.net/EU-CAT/testing/patients/updatePatient.seam
@@ Zeile 141: / Zeile 133: @@
 : PolicySet/Policy[1]/Target/Subjects/Subject contains SubjectMatches matching given X-User Assertion subject or any other applicable X-User subject with role ''112247003'' (medical doctor). '''This is a knowing violation.''' See Test Case 1.
 : PolicySet/Policy[2]/Target/Subjects/Subject contains SubjectMatches matching any applicable X-User subject with role ''health record management''.
 ==== Test Steps ''Variant 1'' ====

@@ Zeile 97: / Zeile 97: @@
 EFA Client actors shall piggyback each request with a valid EFA Identity Assertion by using the means of the IHE ITI-40 transactions. EFA Provider actors shall be able to validate the provided assertion and to match the contained attributes with the access control policy of the EFA instance that is to be accessed through the request.
 * Example: EFA Identity Assertion: see [[cdaefa:EFA_Projectathon_2016#Validation_with_SoapUI|SoapUI test suite]].
 * Example: WS Trust RST Request for obtaining an EFA Identity Assertion: see [[cdaefa:EFA_Projectathon_2016#Validation_with_SoapUI|SoapUI test suite]].

@@ Zeile 27: / Zeile 27: @@
 Regarding user authentication, two options will be offered for the EFA Projectathon:
 # EFA Clients may perform a local authentication which is asserted through an IHE XUA compliant X-User Assertion. EFA constraints the IHE XUA specification by requiring the provisioning of the ''Subject ID'' and ''Subject Organization ID'' attributes within this assertion.
-# EFA Clients may authenticate the user with an external WS Trust Identity Provider which will be set up by Fraunhofer FOKUS for the EFA Projectathon. Authentication will be performed by user ID and password. For obtaining the X-User Assertion WS Trust v1.2 RST/RSTR messages will be supported by the Identity Provider. A test server will be set up in advance to the Projectathon. ('''to be discussed: Version 1.2 of WS Trust acceptable for the vendors?''')
+# The EFA-Client sends an IHE XUA Get X-User Assertion to X-Assertion Provider URL with a WSSE-UsernameToken containing username and password. See [https://gazelle.ihe.net/content/security-token-service-sts|Gazelle Security Token Service].
-For the Projectathon only ''SAML Bearer Subject Confirmation Method'' will be tested.
+{{FAQBox|At Projectathon 2016, ''SAML Bearer Subject Confirmation Method'' must be used.}}
 ==== IHE ITI-40 (Provide X-User Assertion) ====

@@ Zeile 17: / Zeile 17: @@
 ==== IHE ITI-19 (Node Authentication) ====
-EFA builds upon the same actors as the IHE ITI XDS, ATNA and XUA integration profiles. All actors will share messages using mutually authenticated TLS communication channels as defined in IHE ITI-19. For the EFA Projectathon the actors already tested with the IHE Connectathon tests will be used. Therefore there will be no additional requirements for vendors realated to ITI-19.
+EFA builds upon the same actors as the IHE ITI XDS, ATNA and XUA integration profiles. <strike>All actors will share messages using mutually authenticated TLS communication channels as defined in IHE ITI-19.</strike> For the EFA Projectathon the actors already tested with the IHE Connectathon tests will be used. Therefore there will be no additional requirements for vendors realated to ITI-19.
 ==== IHE ITI-20 (Record Audit Event) ====