EFA Projectathon 2016
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
Inhaltsverzeichnis
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 Test Cases
Test Case 1: 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.
Creating an EFA-compliant XDS folder and uploading the coded consent document is performed through a constrained implementation of IHE ITI-41 transaction. The constraints to be implemented are defined at http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_createECR
Each request shall be piggybacked with an ITI-40 transaction. The provided SAML identity assertion shall follow the constraints as defined at http://wiki.hl7.de/index.php?title=cdaefa:EFA_Identity_Assertion_SAML2_Binding
Further details about this test case will be provided as soon as the concrete test scenario is finalized.
Test Case 2: Writing a Document to an Existing EFA
EFA documents are always stored to EFA folders (which are in fact just classified XDS folders). A new document may either be stored to an already existing folder or into a newly created folder. For the EFA projectathon vendors must demonstrate both of these scnearios.
The eCR transaction for providing a document to an EFA isnatsnce 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.
Each request shall be piggybacked with an ITI-40 transaction. The provided SAML identity assertion shall follow the constraints as defined at http://wiki.hl7.de/index.php?title=cdaefa:EFA_Identity_Assertion_SAML2_Binding
Further details about this test case will be provided as soon as the concrete test scenario is finalized.
Test Case 3: Loading an Existing EFA's Table of Content
Each EFA instance is made up from one or more folders that hold the documents that are shared for a patient's treatment. When opening a EFA a physician's IT system first loads the table of contents of an identified EFA by
- discovering the folders that belong to the selected EFA instance (IHE ITI-18 FindFolder query) and then
- loading the metadata for each document within each of the EFA folders (IHE ITI-18 GetFolderAndContents query on each folder).
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.
Each request shall be piggybacked with an ITI-40 transaction. The provided SAML identity assertion shall follow the constraints as defined at http://wiki.hl7.de/index.php?title=cdaefa:EFA_Identity_Assertion_SAML2_Binding
Further details about this test case will be provided as soon as the concrete test scenario is finalized.
Test Case 4: Fetching a Document from an Existing EFA
Once the table of content is read, the physican may select a document and download it for display or for storing it to his local case documentation.
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.
Each request shall be piggybacked with an ITI-40 transaction. The provided SAML identity assertion shall follow the constraints as defined at http://wiki.hl7.de/index.php?title=cdaefa:EFA_Identity_Assertion_SAML2_Binding
Further details about this test case will be provided as soon as the concrete test scenario is finalized.
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 (coming soon)
- Example: EFA Digital Consent Document
- Example: EFA compliant IHE ITI-41 Transaction including EFA Digital Consent
Option: Peer-2-Peer Networking of EFA Providers
Further details about this option will be provided as soon as the concrete test scenario is finalized.
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)
Action Items
| What | Who | When | Status/Result |
|---|---|---|---|
| Provide further information and sample document/policy for "Digital Consent" Option | FOKUS | 29. December 2015 | |
| Provide an overview on the gaps between IHE "standard" profiles and EFA extensions/constraints | FOKUS | 7. January 2016 | |
| Register for EFA Actors within gazelle | Vendors | 15. January 2016 | |
| Resolve accepted change proposals to the EFA specification | FOKUS | 15. January 2016 | Progress can be tracked here |
| 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 | |
| Provide a list of validation tests that EFA Provider vendors need to perform on EFA Identity Assertions. | FOKUS | 29. January 2016 | |
| 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 | |
| Provisioning of Schematrons for all relevant EFA transactions. | FOKUS | 12. February 2016 | |
| List contact data of FOKUS technical support team on the Projectathon Wiki. | FOKUS | asap | done. See Contact section on this page. |
| Distribution of contact data for all EFA Projectathon participants | FOKUS | 29. December 2015 | done (sent out by Mail) |
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 (dial-in numbers)
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.
 |
Back References |
