cdaefa:EFA Projectathon 2016

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 .

About Elektronische FallAkte (EFA)

The electronic Case Record (Elektronische FallAkte, EFA) is an initiative launched by German hospitals in 2006. Electronic case records provide a structured and integrated viewpoint of medical data that can be associated with an individual case. A case begins with an initial diagnosis and integrates as many in-stances of billing or treatment as required. A physician oversees the eCR, with the various attending physicians being responsible for the case records contents and completeness.

The decentralized handling and maintenance of case records is based on the metaphor of a supply network as a community of interest composed of autonomous actors working on a specific task. Since it is generally preferred that the actual place at which medical data and administrative information (e.g. user accounts) remains constant, the case record may be implemented quickly and efficiently in existing networks, and may furthermore facilitate the initiation of co-operation at a regional level as well as at a national scope.

The further development of the EFA technical specifications is sponsored by German hospitals, private hospital chains, and regional care networks who are organized within the EFA Verein (EFA Association). The recent release version 2.0 of EFA is fully compliant to IHE profiles and has been developed as a joint effort between EFA Verein, German IT vendors and Fraunhofer FOKUS. The IHE white paper "Access Control" was highly influenced by the EFA security architecture and the initiative that resulted in the forthcoming IHE profile supplement on digital patient consent was originally fueled by respective EFA requirements.

All EFA technical specification are open and available to the public at http://wiki.hl7.de/index.php?title=cdaefa:EFA_Spezifikation_v2.0.

EFA Projectathon: General Information

EFA Constraints and Extensions

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.

IHE ITI-20 (Record Audit Event)

All EFA actors record audit events to an Audit Repository actor. All EFA actors shall be able to issue IHE ITI-20 messages for all EFA transactions. These messages are fully compliant to the audit trail specifications of the underlying IHE transactions but contain an additional eventTypeCode element that signals the logical EFA transaction. For details see EFA Audit Trail Binding.

IHE XUA Get X-User Assertion

Regarding user authentication, two options will be offered for the EFA Projectathon:

1. 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.
2. 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 Security Token Service.

IHE ITI-40 (Provide X-User Assertion)

Each EFA transaction shall by piggybacked with an X-User Assertion. The assertion shall comply to the constraints described above. The integration of the assertion into SOAP messages and the validation of the assertion are to be inmplemented as defined for IHE ITI-20.

IHE ITI-41 (Provide and Register Document Set-b)

EFA utilizes IHE ITI-41 for setting up a new EFA instance and for providing documents to an existing EFA.

For setting up a new EFA

The ITI-41 message shall

• create a new XDS folder. The folder shall be contained within the submission set. The folder metadata shall include a codeList element with two classification codes. The codes to be used will be provided by Fraunhofer FOKUS as part of the test case configuration.
• contain a digital consent consent document that complies to the EPPC-G specification. EFA Client actors who implement the EFA Digital Consent Option shall provide means to assemble such a document based on the Projectathon test case definition. For other clients Fraunhofer FOKUS will provide a pre-defined consent document together with XDS metadata that shall be integrated with the ITI-41 message as-is. In both scenarios the consent document shall be associated with the newly created XDS folder.

EFA Provider actors that implement the EFA Digital Consent Option shall validate the consent document and configure access permissions to the newly created EFA acordingly. Provider actors that do not implement this option will be provided by an XACML-coded access control configuration by Fraunhofer FOKUS. This configuration shall only be activated after a valid ITI-41 message containing a consent document within a newly created XDS folder (containing a defined classification code and patient ID) was received.

For placing documents into an existing EFA

the EFA Client actor shall be aware of the folder classification codes which were set when the EFA was set up (see above). In case the actor is not the one who created the EFA, the Client actor shall browse the EFA prior to providing new documents (see below).

The ITI-41 message for providing a document to an existing EFA shall

• contain a has-member association to an XDS folder which either
  • is contained within the submission set. In this case the folder shall contain the same classifications within the codeList element as the folder that was created when the EFA was set up.
  • already exists as part of the EFA.

contain one or more documents according to the IHE ITI-41 specification. The sourcePatientInfo metadata element shall not be used. The confidentialityCode shall be "N".

IHE ITI-18 (Registry Stored Query)

EFA Client and Provider actors shall implement the FindFolders and GetFolderAndContents queries of IHE ITI-18:

• for FindFolders the patient ID and the folder classification (codeList) shall be provided by the EFA Client.
• the EFA Provider shall enforce the permissions on the EFA as set within the patient's consent during EFA initialization.

Other queries shall not provide any documents that are part of an EFA. EFA providers may respond to such requests with an access permission error. Remark: The EFA specification demands for supporting GetAssociations queries. This will be obsolet with the next EFA release and will therefore not be tested at the EFA Projectathon.

IHE ITI-43 (Retrieve Document Set)

The only constraints EFA imposes on the ITI-43 transaction are

• EFA Provider actors shall enforce the permissions on the EFA the capsules the requested documents as set within the patient's consent during EFA initialization,
• all requested documents shall be associated with the same XDS folder.

EFA Projectathon Test Cases

Test Case 1: User Authentication

The EFA-Client actor obtains an X-User Assertion. In all subsequent test cases, the EFA-Client actor provides this X-User Assertion to the EFA-Provider actor. Only of the given variants of test steps is required.

Test Data

username

Xuagood

password

see https://gazelle.ihe.net/content/security-token-service-sts

X-Assertion Provider URL

https://gazelle.ihe.net/picketlink-sts?wsdl

Test Steps Variant 1

1. The EFA-Client sends an IHE XUA Get X-User Assertion to X-Assertion Provider URL with a WSSE-UsernameToken containing username and password.
2. The EFA-Client sets up its security context with the returned X-User Assertion.

Test Steps Variant 2

1. The EFA-Client sef-issues an X-User Assertion. The X-User Assertion must be signed using the Gazelle PKI. The X-User Assertion has the same characteristics as the X-User Assertion issued by Gazelle picketlink-sts with regard to subject, conditions, and attribute statement.
2. The EFA-Client sets up its security context with the issued X-User Assertion.

Further details

The EFA Identity Assertion is a X-User Assertion that shall follow the constraints as defined at http://wiki.hl7.de/index.php?title=cdaefa:EFA_Identity_Assertion_SAML2_Binding.

However, for EFA-Projectathon testing vendors shall rely on the SAML-Assertion semantics used with Gazelle picketlink-sts, as voted (see protocol).

This implies knowing violations of EFA2.0 specification:

• XUA SubjectConfirmation/@Method: restricted to bearer
• XUA NameID/@Format: not required, fallback to unspecified
• XUA AuthnStatement: @AuthnInstant not required
• XUA Attribute XSPA Role: Uses structured hl7:Role value instead string value from ASTM catalogue

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 SoapUI test suite.
• Example: WS Trust RST Request for obtaining an EFA Identity Assertion: see SoapUI test suite.
• Example: EFA Identity Assertion inside SOAP header: see InitalizeECR request message in gitlab.
• Online Test Tool: EFA Identity Provider: we use Gazelle picketlink-sts.
• Online Test Tool: EFA Identity Assertion Validator: we use Gazelle picketlink-sts.

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

Test Data

X-User Assertion

The X-User Assertion must be obtained by running Test Case 1.

Folder

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

DocumentEntry.mimeType = text/xml

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-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

DocumentEntry.soucePatientInfo must not be used

EPPC document

confidentialityCode/@code=N

recordTarget/patientRole/id = The ID of a patient that is shared using https://gazelle.ihe.net/EU-CAT/testing/patients/updatePatient.seam

observation/value = CDATA-encoded XACML-Policy

XACML-Policy

PolicySet/Target/Resources/Resource contains ResourceMatch for given Folder.codeList

PolicySet/Target/Resources/Resource contains ResourceMatch for given patient ID.

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

Initialize an EFA using an EPPC document.

1. 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.
2. Verify, that Gazelle EVS Schematron InitializeECR did not fail.
3. Verify, that EFA Client received a Success response.
4. 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.
5. Verify, that EFA Client received a Failure response containing the Policy Violation error code.

Test Case 3: Writing a Document to an Existing EFA

A new document is added to an existing EFA.

Prerequisites

Test Case 2 has been executed within the same test run.

Both given variants of test steps are required.

The eCR transaction for providing a document to an EFA instance is a constrained implementation of IHE ITI-41. The constraints to be implemented are defined at http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRepository#EFA_XDS_Binding:_provideData.

Test Data

X-User Assertion

The X-User Assertion must be obtained by running Test Case 1.

Folder

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

References the Folder registered with Test Case 2.

DocumentEntry

Any document metadata that does not indicate an EPPC document.

Document

Any document.

Test Steps Variant 1

A new document is added to an existing Folder of an EFA.

1. The EFA Client actor sends an ProvideDocument request message to the EFA Provider actor. The SOAP part contains given test data X-User Assertion, Folder-Document-HasMember, and DocumentEntry. The SOAP attachment contains test data Document.
2. Verify, that Gazelle EVS Schematron ProvideDocument did not fail.
3. Verify, that EFA Client actor received a Success response.

Test Steps Variant 2

A new document and a new Folder containing this document are added to an EFA.

1. The EFA Client actor sends an ProvideDocument request message to the EFA Provider actor. The SOAP part contains given test data X-User Assertion, Folder, and DocumentEntry. The SOAP attachment contains test data Document.
2. Verify, that Gazelle EVS Schematron ProvideDocument did not fail.
3. Verify, that EFA Client actor received a Success response.

Test Case 4: BrowseECR

An EFA and its registry objects are queried.

Prerequisites

Test Case 3 has been run within the same test run.

The constraints to be implemented are defined at http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_ResourceManager#EFA_XDS_Binding:_listPartitions and http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRegistry#EFA_XDS_Binding:_listPartitionContent.

Test Data

X-User Assertion

The X-User Assertion must be obtained by running Test Case 1.

FindFolders Params

$XDSFolderPatientId = TC2 Folder.patientId

$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 TestCase2 Folder.entryUUID and Folder.uniqueId respectively

GetFolderAndContents Params Folder 2

$XDSFolderEntryUUID or $XDSFolderUniqueId = equal to TestCase3Variant2 Folder.entryUUID and Folder.uniqueId respectively

Test Steps

Part 1: Find Folders

1. The EFA Client actor sends a BrowseECR (ITI-18 FindFolders) request message to the EFA Provider actor. The SOAP part contains given test data X-User Assertion and FindFolders Params.
2. Verify, that Gazelle EVS Schematron BrowseECR did not fail.
3. Verify, that the EFA Client actor received a Success response containing two Folders: one from TC2-V1, one from TC3-V2.

Part 2: Get Contents of first Folder

1. The EFA Client actor sends a BrowseECR (ITI-18 GetFolderAndContents) request message to the EFA Provider actor. The SOAP part contains given test data X-User Assertion and GetFolderAndContents Params Folder 1.
2. Verify, that Gazelle EVS Schematron BrowseECR did not fail.
3. Verify, that the EFA Client actor received a Success response containing a single Folder (TC2-V1) and two DocumentEntries (TC2-V1, TC3-V1).

Part 3: Get Contents of second Folder

1. The EFA Client actor sends a BrowseECR (ITI-18 GetFolderAndContents) request message to the EFA Provider actor. The SOAP part contains given test data X-User Assertion and GetFolderAndContents Params Folder 2.
2. Verify, that Gazelle EVS Schematron BrowseECR did not fail.
3. 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

Retrieve a Document that was added to an EFA.

Prerequisites

Test Case 4 has been executed within the same test run.

This is done through a constrained implementation of IHE ITI-43. The constraints to be implemented are defined at http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRepository#EFA_XDS_Binding:_retrieveData.

Test Data

X-User Assertion

The X-User Assertion must be obtained by running Test Case 1.

DocumentEntry.entryUUID

Equal to an DocumentEntry.entryUUID used in TC2 or TC3.

Test Steps

1. The EFA Client actor send a RetrieveDocument request message to the EFA Provider actor. The SOAP part contains given test data X-User Assertion and DocumentEntry.entryUUID.
2. Verify, that Gazelle EVS Schematron RetrieveDocument did not fail.
3. Verify, that the EFA Client actor received a Success response message containing a SOAP attachment equal to Document identified with DocumentEntry.entryUUID.

Option: Digital Consent

While Release 1 of the EFAv2.0 specification did not make any assumptions on the structure and coding of EFA consents, the forthcoming Release 2 (January 2016) demands for a structed HL7v3 CDA coded consent that implements the HL7 Implementation Guide for CDA® Release 2: Privacy Consent Directives, Release 1. An EFA profile of this implementation guide has been workedout in 2015 by bvitg, EFA-Verein and Fraunhofer FOKUS. As this extension to the EFA specification was just recently published, its implementation is not mandatory for successfully passing the EFA Projectathon. Nevertheless vendors that already implement this feature may receive a respective conformance declaration by choosing the EFA Digital Consent option.

• Implementation Guidelines: Digital Consent Option for EFA Client Actors (coming soon)
• Implementation Guidelines: Digital Consent Option for EFA Provider Actors
• Example: EFA Digital Consent Document
• Example: EFA compliant IHE ITI-41 Transaction including EFA Digital Consent

Option: Peer-2-Peer Networking of EFA Providers

At EFA-Projectathon 2016, this option is omitted as there won't be a sufficient number of test partners.

Pre-Projectathon-Testing

Validation with Schematron

Schematron files for validating EFA request messages are available at both locations

Fraunhofer FOKUS git-Repository

https://gitlab.fokus.fraunhofer.de/EFA-2.0/efa2-schematron

IHE Gazelle EVS Front-End

https://gazelle.ihe.net/EVSClient/xml/validator.seam?extension=XDS%20-%20IHE%20Germany&cid=1917

Validation with EFA-EVS at Fraunhofer FOKUS

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:

• Validates alignment of SOAP message and EPPC document.
• Validates alignment of SOAP message and computable policy included in the EPPC document.
• Validates alignment of EPPC document and computable policy.

The EFA-EVS is published here (HTTP POST):

• http://ehealth-g1.fokus.fraunhofer.de/efa-evs/initializeECR
• http://ehealth-g1.fokus.fraunhofer.de/efa-evs/browseECR
• http://ehealth-g1.fokus.fraunhofer.de/efa-evs/provideDocument
• http://ehealth-g1.fokus.fraunhofer.de/efa-evs/retrieveDocument

Validation with SoapUI

Fraunhofer FOKUS provides a SoapUI test suite that contains various EFA request messages and response validation.

Download EFAv2 SoapUI-Project: https://owncloud.fokus.fraunhofer.de/index.php/s/HAsto9oGL4r32jR/download

First, run the test case named Request SAML Assertion. This test case requests an identity assertion from Gazelle's picketlink-sts for user Xuagood and stores in the SoapUI project context.

Also, update the endpoint URI according to your needs. The endpoints default to:

• http://localhost:8080/xdsregistryb and
• http://localhost:8080/xdsrepositoryb

Also, you may want to provide a list of valid patient identifiers. In order to set the list:

1. Click on SoapUI-Project EFA-2.0.
2. Click on Custom Properties.
3. Update properties with names patientIdRoot and patientIdList.

Examples of request messages

Please find examples of request messages as well as EPPC documents at:

Fraunhofer FOKUS git-Repository

https://gitlab.fokus.fraunhofer.de/EFA-2.0/efa2-schematron

This repository contains both, valid messages and documents as well as invalid messages.

Links and Documents

EFA Projectathon

In preparation for the 2016 EFA Projectathon EFA Verein and Fraunhofer FOKUS prepared several documents on the overal procedures and the EFA specific test cases:

• Projectathon Concept Paper (PDF, German): This paper sets the overall framing for the EFA Projectathon by documenting all agreements that have been made among the affected parties (EFA Verein, IHE Europe, bvitg, Fraunhofer FOKUS)
• Sketch of the Storyboard (PDF, English): This document sketches the storyboard that will be used as a baseline for the EFA Projectathon tests. For each step of the stroyboard the relevant links to the EFAv2.0 specification are given.
• Actors and Transactions (PDF, English): This document was used by IHE Europe for registering the EFA actors and transactions into gazelle. It defines the certifiable actors and EFA transactions that have to be implemented by EFA-compliant solutions. For each EFA transaction the underlying IHE transactions and EFA constraintes on these transactions are referenced.

IHE Connectathon

IHE Europe set up a Google Group for Connectathon participants. All webinar announcements and Connectathon-related news will be posted to this group by IHE Europe.

Additionally IHE provides vendors with various Connectathon Training Materials. For many IHE Profiles links to existing testing tools are given on that site which enable vendors to tests their solutions in advance to the Connectathon.

IHE Webinars

IHE is offering a series of webinars for Connectathon participants:

14. December 2015 (Connectathon registration and important dates)

• Presentation
• Audio-Recording

Action Items

What	Who	When	Status/Result
Resolve open issues related to Projectathon organization (see Tcon protocols)	FOKUS to contact IHE Europe	ongoing activity. News will be distributed via Google Group.
provide XDS-folder eventCodes that shall be used for the EFA Projectathon	FOKUS. Register eventCodes with NIST.	22. January 2016	delayed. Will be available mid February.
Setup of an EFA Provider actor for testing. Registered vendors shall be able to connect to the EFA Provider via internet.	FOKUS	1. February 2016	EFA-EVS: done. SoapUI-TestSuite for IntitalizeECR operation: done.
Provisioning of sample policy data for vendors who do not implement the "digital consent" option	FOKUS	12. February 2016	Sample policies: done. Final on-site policies: delayed.
Provisioning of Schematrons for all relevant EFA transactions.	FOKUS	12. February 2016	done. See section Pre-Connectathon-Testing.
Provide a list of validation tests that EFA Provider vendors need to perform on EFA Identity Assertions.	FOKUS	29. January 2016	obsolete. EFA tests will not request for validations beyond the ones mandated for IHE XUA.
Setup of an EFA Identity Provider for obtainig EFA-compliant XUA assertions. Registered vendors shall be able to connect to the Identity Provider via an open WS Trust interface.	FOKUS	29. January 2016	obsolete. For EFA Projectathon the XUA Identity Provider integrated with gazelle will be used.
Register for EFA Actors within gazelle	Vendors	22. January 2016 (extended deadline)	done. Registration closed.
Setup a doodle for finding a time slot for the next tcon	FOKUS	15. January 2016	done
Setup a Google Group for EFA Projectathon participants	FOKUS	15. January 2016	done
Resolve accepted change proposals to the EFA specification	FOKUS	15. January 2016	done
Provide an overview on the gaps between IHE "standard" profiles and EFA extensions/constraints	FOKUS	7. January 2016	done (see EFA Constraints and Extensions)
Provide further information and sample document/policy for "Digital Consent" Option	FOKUS	29. December 2015	done. See Digital Consent
Distribution of contact data for all EFA Projectathon participants	FOKUS	29. December 2015	done (sent out by Mail)
List contact data of FOKUS technical support team on the Projectathon Wiki.	FOKUS	asap	done. See Contact section on this page.

EFA Projectathon TCons

• TCon - 15.12.15, 10.00 Uhr (protocol, German)
• TCon - 18.12.15, 10.00 Uhr (protocol, German)
• TCon - 11.01.16, 10.00 Uhr (protocol, German)
• TCon - 03.02.16, 13.00 Uhr (protocol, German)
• TCon - 10.03.16, 10.00 Uhr (protocol, German)
• TCon - 11.03.16, 14.00 Uhr (protocol, German)

Contact

For questions about EFA in general and the EFA Projectathon organization please contact joerg.caumanns@fokus.fraunhofer.de.

For questions related to EFA technical specifications, EFA Projectathon technical implementation, EFA transaction samples and pre-projectathon testing support please contact ben.kraufmann@fokus.fraunhofer.de or raik.kuhlisch@fokus.fraunhofer.de.

News, questions and hints that may be relevant to all EFA Projectathon participants should be discussed in the EFA Projectathon Google Group.

---