cdaefa:EFA Projectathon 2017

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: Organizational Information

Required IHE Conformance Statements

A prerequisite for eCR Projectathon registration is that the vendor has registered for interoperability testing of the XDS, ATNA and XUA profile with the IHE Europe 2017 Connectathon.

Projectathon Registration Fee

The additional registration fee of 1.500 € per vendor for eCR Projectathon participation will be charged independently from the Connectathon fee. The registration fee will be paid to Fraunhofer FOKUS for pre-projectathon support and monitoring the EFA projectathon tests in Venice.

EFA Projectathon: Technical 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

The EFA test cases for the 2017 projectathon are under development and will be published soon. To get an orientation about what will be tested, you may take a looks at the Projectathon 2016 test cases.

Pre-Projectathon-Testing

Fraunhofer FOKUS will provide an online validation service for EFA messages once the test cases have been completed. A webinar will be offered for all Projectathon participants once the validator is online.

Links and Documents

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.

Action Items

What	Who	When	Status/Result
Agree with participants on relevant change proposals	FOKUS (Ben)	TCon scheduled for Jan 31	Protocol of the TCon will be published
Setup of online EFA test interfaces. Registered vendors shall be able to connect to the EFA test services via internet.	FOKUS	February 2017
Provisioning of Schematrons for all relevant EFA transactions.	FOKUS	February 2017
Register for EFA Actors within gazelle	Vendors	22. January 2016 (extended deadline)	done. Registration closed.
Setup a Google Group for EFA Projectathon participants	FOKUS	2016 Projectathon group still active...	done
List contact data of FOKUS technical support team on the Projectathon Wiki.	FOKUS	asap	done. See Contact section on this page.

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.

---