Hl7wiki - Benutzerbeiträge [de]

cdaefa:EFA Projectathon 2017

2017-02-01T20:44:02Z

Jcaumanns: /* EFA Projectathon */

{{DocumentPart
}}

== 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 [http://www.fallakte.de 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 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. <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) ====
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 [[cdaefa:EFA_Audit_Trail_Binding|EFA Audit Trail Binding]].

==== IHE XUA Get X-User Assertion ====
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.
# 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].

==== 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 [[cdaefa:EFA_Projectathon_2016#EFA_Projectathon_Test_Cases|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 ==

=== EFA Projectathon ===
In preparation for the 2017 EFA Projectathon, Fraunhofer FOKUS prepared several documents on the overal procedures and the EFA specific test cases:
* [http://wiki.hl7.de/images/ECR_Projectathon_2017.pdf Projectathon Overview] (PDF, English): This paper gives an overview on EFA and the 2017 projectathon.
* [http://wiki.hl7.de/images/ECR_Projectathon_2017_actors_and_transactions_v01.pdf Actors and Transaction] (PDF, English): Short overview on the EFA actors and transactions and how these map onto respective IHE entities.

=== IHE Connectathon ===

IHE Europe set up a [https://groups.google.com/forum/#!forum/eu_connectathon 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 [http://gazelle.ihe.net/training 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 ==

{| class="wikitable"
|-
! 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...
| [https://groups.google.com/forum/#!forum/efa-projectathon done]
|-
| List contact data of FOKUS technical support team on the Projectathon Wiki.
| FOKUS
| asap
| done. See [[#Contact|Contact]] section on this page.
|}

== EFA Projectathon TCons ==

== Contact ==

For questions about EFA in general and the EFA Projectathon organization please contact [mailto:joerg.caumanns@fokus.fraunhofer.de 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 [mailto:ben.kraufmann@fokus.fraunhofer.de ben.kraufmann@fokus.fraunhofer.de] or [mailto:raik.kuhlisch@fokus.fraunhofer.de raik.kuhlisch@fokus.fraunhofer.de].

News, questions and hints that may be relevant to all EFA Projectathon participants should be discussed in the [https://groups.google.com/forum/#!forum/efa-projectathon EFA Projectathon Google Group].
----

{{NoteBox|'''Back References'''
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Specification]]
<nowiki></nowiki>
}}

Datei:ECR Projectathon 2017 actors and transactions v01.pdf

2017-02-01T20:42:37Z

Jcaumanns:

cdaefa:EFA Projectathon 2017

2017-02-01T20:41:46Z

Jcaumanns: /* EFA Projectathon */

{{DocumentPart
}}

== 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 [http://www.fallakte.de 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 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. <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) ====
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 [[cdaefa:EFA_Audit_Trail_Binding|EFA Audit Trail Binding]].

==== IHE XUA Get X-User Assertion ====
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.
# 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].

==== 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 [[cdaefa:EFA_Projectathon_2016#EFA_Projectathon_Test_Cases|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 ==

=== EFA Projectathon ===
In preparation for the 2017 EFA Projectathon, Fraunhofer FOKUS prepared several documents on the overal procedures and the EFA specific test cases:
* [http://wiki.hl7.de/images/ECR_Projectathon_2017.pdf Projectathon Overview] (PDF, English): This paper gives an overview on EFA and the 2017 projectathon.
* [http://wiki.hl7.de/images/ECR_Projectathon_2017.pdf Projectathon Overview] (PDF, English): This paper gives an overview on EFA and the 2017 projectathon.

=== IHE Connectathon ===

IHE Europe set up a [https://groups.google.com/forum/#!forum/eu_connectathon 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 [http://gazelle.ihe.net/training 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 ==

{| class="wikitable"
|-
! 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...
| [https://groups.google.com/forum/#!forum/efa-projectathon done]
|-
| List contact data of FOKUS technical support team on the Projectathon Wiki.
| FOKUS
| asap
| done. See [[#Contact|Contact]] section on this page.
|}

== EFA Projectathon TCons ==

== Contact ==

For questions about EFA in general and the EFA Projectathon organization please contact [mailto:joerg.caumanns@fokus.fraunhofer.de 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 [mailto:ben.kraufmann@fokus.fraunhofer.de ben.kraufmann@fokus.fraunhofer.de] or [mailto:raik.kuhlisch@fokus.fraunhofer.de raik.kuhlisch@fokus.fraunhofer.de].

News, questions and hints that may be relevant to all EFA Projectathon participants should be discussed in the [https://groups.google.com/forum/#!forum/efa-projectathon EFA Projectathon Google Group].
----

{{NoteBox|'''Back References'''
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Specification]]
<nowiki></nowiki>
}}

Datei:ECR Projectathon 2017.pdf

2017-02-01T20:37:30Z

Jcaumanns:

cdaefa:EFA Projectathon 2017

2017-02-01T20:35:58Z

Jcaumanns: /* EFA Projectathon Test Cases */

{{DocumentPart
}}

== 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 [http://www.fallakte.de 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 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. <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) ====
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 [[cdaefa:EFA_Audit_Trail_Binding|EFA Audit Trail Binding]].

==== IHE XUA Get X-User Assertion ====
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.
# 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].

==== 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 [[cdaefa:EFA_Projectathon_2016#EFA_Projectathon_Test_Cases|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 ==

=== EFA Projectathon ===

=== IHE Connectathon ===

IHE Europe set up a [https://groups.google.com/forum/#!forum/eu_connectathon 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 [http://gazelle.ihe.net/training 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 ==

{| class="wikitable"
|-
! 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...
| [https://groups.google.com/forum/#!forum/efa-projectathon done]
|-
| List contact data of FOKUS technical support team on the Projectathon Wiki.
| FOKUS
| asap
| done. See [[#Contact|Contact]] section on this page.
|}

== EFA Projectathon TCons ==

== Contact ==

For questions about EFA in general and the EFA Projectathon organization please contact [mailto:joerg.caumanns@fokus.fraunhofer.de 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 [mailto:ben.kraufmann@fokus.fraunhofer.de ben.kraufmann@fokus.fraunhofer.de] or [mailto:raik.kuhlisch@fokus.fraunhofer.de raik.kuhlisch@fokus.fraunhofer.de].

News, questions and hints that may be relevant to all EFA Projectathon participants should be discussed in the [https://groups.google.com/forum/#!forum/efa-projectathon EFA Projectathon Google Group].
----

{{NoteBox|'''Back References'''
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Specification]]
<nowiki></nowiki>
}}

cdaefa:EFA Projectathon 2017

2017-02-01T20:32:17Z

Jcaumanns: /* EFA Projectathon: General Information */

{{DocumentPart
}}

== 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 [http://www.fallakte.de 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 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. <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) ====
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 [[cdaefa:EFA_Audit_Trail_Binding|EFA Audit Trail Binding]].

==== IHE XUA Get X-User Assertion ====
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.
# 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].

==== 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 [[cdaefa:EFA_Projectathon_2017#EFA_Projectathon_Test_Cases|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 ==

=== EFA Projectathon ===

=== IHE Connectathon ===

IHE Europe set up a [https://groups.google.com/forum/#!forum/eu_connectathon 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 [http://gazelle.ihe.net/training 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 ==

{| class="wikitable"
|-
! 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...
| [https://groups.google.com/forum/#!forum/efa-projectathon done]
|-
| List contact data of FOKUS technical support team on the Projectathon Wiki.
| FOKUS
| asap
| done. See [[#Contact|Contact]] section on this page.
|}

== EFA Projectathon TCons ==

== Contact ==

For questions about EFA in general and the EFA Projectathon organization please contact [mailto:joerg.caumanns@fokus.fraunhofer.de 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 [mailto:ben.kraufmann@fokus.fraunhofer.de ben.kraufmann@fokus.fraunhofer.de] or [mailto:raik.kuhlisch@fokus.fraunhofer.de raik.kuhlisch@fokus.fraunhofer.de].

News, questions and hints that may be relevant to all EFA Projectathon participants should be discussed in the [https://groups.google.com/forum/#!forum/efa-projectathon EFA Projectathon Google Group].
----

{{NoteBox|'''Back References'''
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Specification]]
<nowiki></nowiki>
}}

cdaefa:EFA Projectathon 2017

2017-02-01T20:24:43Z

Jcaumanns: Die Seite wurde neu angelegt: „{{DocumentPart }} == About Elektronische FallAkte (EFA) == The electronic Case Record (Elektronische FallAkte, EFA) is an initiative launched by German hospi…“

{{DocumentPart
}}

== 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 [http://www.fallakte.de 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 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. <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) ====
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 [[cdaefa:EFA_Audit_Trail_Binding|EFA Audit Trail Binding]].

==== IHE XUA Get X-User Assertion ====
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.
# 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].

==== 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 [[cdaefa:EFA_Projectathon_2017#EFA_Projectathon_Test_Cases|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 ==

=== EFA Projectathon ===

=== IHE Connectathon ===

IHE Europe set up a [https://groups.google.com/forum/#!forum/eu_connectathon 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 [http://gazelle.ihe.net/training 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 ==

{| class="wikitable"
|-
! 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...
| [https://groups.google.com/forum/#!forum/efa-projectathon done]
|-
| List contact data of FOKUS technical support team on the Projectathon Wiki.
| FOKUS
| asap
| done. See [[#Contact|Contact]] section on this page.
|}

== EFA Projectathon TCons ==

== Contact ==

For questions about EFA in general and the EFA Projectathon organization please contact [mailto:joerg.caumanns@fokus.fraunhofer.de 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 [mailto:ben.kraufmann@fokus.fraunhofer.de ben.kraufmann@fokus.fraunhofer.de] or [mailto:raik.kuhlisch@fokus.fraunhofer.de raik.kuhlisch@fokus.fraunhofer.de].

News, questions and hints that may be relevant to all EFA Projectathon participants should be discussed in the [https://groups.google.com/forum/#!forum/efa-projectathon EFA Projectathon Google Group].
----

{{NoteBox|'''Back References'''
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Specification]]
<nowiki></nowiki>
}}

cdaefa:EFA Spezifikation v2.0

2017-02-01T20:11:28Z

Jcaumanns:

[[Datei:Information_icon.svg|40px|left]]Gemeinsam mit dem bvitg und IHE Deutschland hat der EFA-Verein einen [http://wiki.hl7.de/index.php?title=Datei:EPPC-G_Draft_for_Comment_v04.pdf Spezifikationsvorschlag für eine elektronische Einwilligung] erstellt, der aktuell innerhalb des Interoperabilitätsforums zur öffentlichen Kommentierung freigegeben wurde. Nach Abschluss der Kommentierung werden die EFA-relevanten Bestandteile dieser Spezifikation als ''Supplement zur EFAv2.0-Spezifikation'' auf dieser Seite verlinkt.

[[Datei:Attention_icon.svg|40px|left]] Im Rahmen des europäischen IHE Connectathon 2017 in Venedig wird der zweite "EFA Projectathon" stattfinden. Alle hierzu relevanten Informationen finden Sie auf der Seite "[[cdaefa:EFA Projectathon 2017|EFA Projectathon 2017]]".

{{DocumentPart}}



= Einleitung =
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.01}</tt>

Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - einer Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.

Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf einem Patienten zugeordnete, medizinische Daten. Ein Fall beginnt mit einer Erstdiagnose und integriert alle weiteren notwendigen Abrechnungs- und Behandlungsdaten. Ein Arzt betreut die Fallakte zusammen mit weiteren behandelnden Ärzten, die für die Inhalte und deren Vollständigkeit verantwortlich sind.

Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt dezentral in bestehenden Systemen verwaltet und können bei Bedarf zu einer integrierten, für alle behandelnden Ärzte einheitlichen Sicht auf den Patienten zusammengeführt werden. Daher kann die Fallakte sehr einfach in bestehende Netze integriert werden und erleichtert somit die Zusammenarbeit auf regionaler Ebene.

== Von EFA 1.2 zu EFA 2.0 ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.02}</tt>

Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der [http://www.fallakte.de/spezifikationen EFA Version 1.2] das erste öffentliche Major-Release der EFA-Spezifikation von den Trägern der EFA-Initiative freigegeben. Bereits Ende 2008 konnten drei namhafte Hersteller (Siemens, ISPro, iSoft) auf dem ersten EFA-Connectathon Produkte präsentieren, die die interoperablen Schnittstellen der EFA implementierten und so miteinander in einem Peer-to-Peer Netzwerk zusammengeschaltet werden konnten. In den folgenden Jahren wurden in verschiedenen Bundesländern EFA-Pilotprojekte gestartet und 2011 konnte am Städtischen Klinikum München das erste regionale EFA-Netzwerk in den Regelbetrieb überführt werden.

Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] und [http://www.p23r.de Prozessdatenbeschleuniger (P23R)] den State-of-the-Art auch mit geprägt hat) haben sich in dieser Zeit im Bereich der Fachschnittstellen von elektronischen Aktensystemen die meisten Hersteller mit ihren Produkten in Richtung des IHE-Profils XDS bewegt, das von der EFA Version 1.2 lediglich logisch aber nicht syntaktisch berücksichtigt wurde - wobei auch die Synchronizität des EFA-1.2-Informationsmodells zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt war.

Im März 2012 haben daher der [http://www.fallakte.de EFA-Verein] als Träger der EFA-Spezifikation und der [http://www.bvitg.de bvitg] als Vertreter der im ambulanten und stationären Sektor tätigen Hersteller von IT-Lösungen beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifikation zu erarbeiten. Diese Version soll
* auf den bewährten und in verschiedenen Gesundheitsnetzen erfolgreich erprobten Kernprinzipien und -konzepten der EFA v1.2 aufbauen,
* in Produkten der Industrie verfügbare Schnittstellenstandards aufgreifen und eine Abbildbarkeit des EFA-Informationsmodells auf das Aktenkonzept von IHE herstellen,
* durch Verzahnung mit dem [[IHE_DE_Cookbook|IHE-D Cookbook]] auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

== EFA 2.0 Spezifikation ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.03}</tt>

Die folgende Tabelle stellt die einzelnen Kapitel der EFA 2.0 Spezifikation im Strukturraster des [[HL7 Enterprise Conformance and Compliance Frameworks]] dar. Die Spezifikation liegt auch als kompiliertes Dokument vor:
* [[cdaefa:EFAv2_Single_Document|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (HTML)]],
* [[Media:EFAv2.0-freeze-131118.pdf|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (PDF)]].

<table border="1" cellspacing="0" cellpadding="5em" width="100%">
<tr bgcolor="lightgray" align="center">
<td width="10%" valign="top">EFA v2.0</td>
<td width="30%" valign="top">'''Enterprise Dimension''' '''''"Why"''''' '''''Policy'''''</td>
<td width="30%" valign="top">'''Information Dimension''' '''''"What"''''' '''''Content'''''</td>
<td width="30%" valign="top">'''Computational Dimension''' '''''"How"''''' '''''Behavior'''''</td>
</tr>

<tr bgcolor="orange" align="center">
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Die EFA als zweckgebundene Akte|Die EFA als zweckgebundene Akte]]

[[cdaefa:EFA Provider|Versorgungsdomänen]]

[[cdaefa:Die EFA als Gesundheitsdatendienst|Die EFA als Gesundheitsdatendienst]]

[[cdaefa:Peer-to-Peer-Vernetzung von EFA-Providern|Peer-to-Peer-Vernetzung von EFA-Providern]]

[[cdaefa:Akteure und Rollen der EFA|Akteure und Rollen]]

[[cdaefa:Prinzipien für Datenschutz und Datensicherheit|Prinzipien für Datenschutz und Datensicherheit]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Kontext, Akte, Ressource|Kontext, Akte, Ressource]]

[[cdaefa:Patienteneinwilligung zur EFA|Patienteneinwilligung zur EFA]]

[[cdaefa:EFA Geschäftsobjekte|EFA Geschäftsobjekte]]

*[[cdaefa:EFA Business Lebenszyklus|Lebenszyklus einer Fallakte]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Interaktionsmuster der EFA|Interaktionsmuster der EFA]]
*[[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
*[[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
*[[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
*[[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
*[[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte oder eine Partition]]
*[[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
*[[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
*[[cdaefa:CIM Invalidieren von Datenobjekten|Invalidieren von Datenobjekten]]
*[[cdaefa:CIM Anpassen des Teilnehmerkreises|Ändern der Einwilligung]]
*[[cdaefa:CIM_Autorisierung_eines_weiteren_Teilnehmers|Autorisierung eines weiteren Teilnehmers]]
*[[cdaefa:CIM_Zusammenführen_von_Fallakten|Zusammenführen von Fallakten]]
</td>
</tr>

<tr bgcolor="yellow" align="center">
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Sicherheitsanforderungen|EFA Sicherheitsanforderungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Business Informationsmodell|Informationsmodelle der EFA Geschäftsobjekte]]

[[cdaefa:EFA Security Informationsmodell|Informationsmodelle der EFA Sicherheitsobjekte]]

[[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Dienste|EFA Dienste]]

[[cdaefa:EFA Kommunikationsmuster|EFA Kommunikationsmuster]]

[[cdaefa:EFA Anwendungsdienste (logische Spezifikation)|EFA Anwendungsdienste (logische Spezifikation)]]

[[cdaefa:EFA Sicherheitsdienste (logische Spezifikation)|EFA Sicherheitsdienste (logische Spezifikation)]]
*[[cdaefa:EFA Context Manager SFM|EFA Context Manager SFM]]
*[[cdaefa:EFA Identity Provider SFM|EFA Identity Provider SFM]]
*[[cdaefa:EFA Policy Provider SFM|EFA Policy Provider SFM]]

[[cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten|Gruppierung von Anwendungs- und Sicherheitsdiensten]]
</td>
</tr>

<tr bgcolor="palegreen" align="center">
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Verwendete Standards|Verwendete Standards]]

[[cdaefa:EFA Used Namespaces|Namespaces]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Metadata Bindings|EFA Metadata Bindings]]
*[[cdaefa:EFA XDS Folder Metadata Binding|EFA XDS Folder Metadata Binding]]
*[[cdaefa:EFA XDS Document Metadata Binding|EFA XDS Document Metadata Binding]]

[[cdaefa:EFA Security Objects Bindings|EFA Security Objects Bindings]]
*[[cdaefa:EFA Identity Assertion SAML2 Binding|EFA Identity Assertion SAML2 Binding]]
*[[cdaefa:EFA Policy Assertion SAML2 Binding|EFA Policy Assertion SAML2 Binding]]

[[cdaefa:EFA Patient Consent Binding|EFA Patient Consent Binding]]

[[cdaefa:EFA Audit Trail Binding|EFA Audit Trail Binding]]

[[cdaefa:EFA Error Codes and Warning Codes|EFA Error Codes and Warning Codes]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA IHE Setup and Flow of Control|EFA IHE Setup and Flow of Control]]

[[cdaefa:EFA XDS/XDR Bindings|EFA XDS Bindings]]
*[[cdaefa:EFA XDS ResourceManager|EFA XDS Binding: ResourceManager]]
*[[cdaefa:EFA XDS DocumentRegistry|EFA XDS Binding: DocumentRegistry]]
*[[cdaefa:EFA XDS DocumentRepository|EFA XDS Binding: DocumentRepository]]

[[cdaefa:EFA Access Control System|EFA Access Control System]]
*[[cdaefa:EFA WS Trust Policy Provider|EFA WS-Trust Binding: PolicyProvider]]

[[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]]
</td>
</tr>
</table>

== Weiterführende Themen ==
In der EFA-Spezifikation wird an verschiedenen Stellen auf weiterführende Informationen oder Grundlagenpapiere verwiesen, die in der ECCF-Matrix nicht verzeichnet sind. Diese "Anhänge" zur EFAv2.0-Spezifikation sind hier verzeichnet.

=== Methodische Grundlagen ===

* [[HL7_Enterprise_Conformance_and_Compliance_Frameworks|HL7 SAIF ECCF]]: Kurze Einführung in das HL7 SAIF ''Enterprise Conformance and Compliance Framework'', das dem Aufbau dieser Spezifikation zugrunde liegt
* [[cdaefa:IHE_Access_Control_Domains | IHE Access Control Domains]]: Zusammenfassung des IHE White Paper "Access Control" mit Fokus auf in der EFAv2.0-Spezifikation genutzte Konzepte und Begrifflichkeiten

=== EFA Konformitätsnachweis ===

In Abstimmung zwischen dem Vorstand des EFA-Vereins und dem Fraunhofer FOKUS wird ein Verfahren zum Nachweis der Konformität von Produkten zu den EFA-Spezifikationen durchgeführt, das im Wesentlichen auf einer Selbsterklärung eines Herstellers beruht. EFAv2.0-konforme Produkte dürfen das EFA-Logo tragen und mit dem EFA-Logo auf Messen sowie in Print- und Online-Materialien beworben werden.
* [[cdaefa:Gegenstand der Konformitätsprüfung|Gegenstand der Konformitätsprüfung]]

Die Ausstellung dieses EFAv2.0-Konformitätsnachweises ist für Hersteller kostenlos und wird wie bisher durch das Fraunhofer FOKUS durchgeführt. Das Fraunhofer FOKUS ist zur Durchführung des Verfahrens und zur Vergabe des EFA-Logos vom EFA-Verein akkreditiert.
* [[cdaefa:Durchführung der Konformitätsprüfung|Durchführung der Konformitätsprüfung]]

Hersteller können alle zur Durchführung des Verfahrens erforderlichen Unterlagen per Mail beim Fraunhofer FOKUS ([mailto:joerg.caumanns@fokus.fraunhofer.de joerg.caumanns@fokus.fraunhofer.de]) anfordern.

'''Hinweis''': Das hier beschriebene Verfahren und die ausgestellten Konformitätsnachweise sind bis Ende 2014 gültig. Ab 2015 soll ein erweitertes Verfahren zum Tragen kommen, dass auf der erfolgreichen Teilnahme von Produkten an einem IHE Connectathon aufsetzt.

== Change Requests ==
Mit der Finalisierung der EFA-Spezifikation im Herbst 2013 haben verschiedene Hersteller (und auch FuE-Projekte) begonnen, die EFAv2.0 zu implementieren. Trotz aller Sorgfalt bei der Erstellung der Spezifikationen fallen hierbei zuweilen kleinere Fehler auf und an manchen Stellen sind fachliche oder technische Festlegungen nur schwer nachvollziehbar, da die entsprechenden Beweggründe der Autorengruppe von Fraunhofer FOKUS, EFA-Verein und bvitg nicht ausreichend dokumentiert wurden.

Um die Spezifikationen kontinuierlich zu verbessern und insbesondere auch Hersteller und Projekte bestmöglich bei der Implementierung zu unterstützen, nehmen wir Fragen und Anregungen weiterhin gerne entgegen. Hierzu wurde für die EFAv2.0 ein regulärer [[EFA Change- und Releasemanagement|Change- und Releasemanagement-Prozess]] definiert, der ab Juli 2015 schrittweise operationalisiert wird.

Alle nach den vorgaben des definierten Prozesses eingereichten Änderungsanforderungen an die EFAv2.0-Spezifikation werden auf dieser Seite aufgelistet und durch Fraunhofer FOKUS, EFA-Verein und bvitg bearbeitet. Der Status der Bearbeitung sowie Entscheidungen zur Annahme bzw. Ablehnung eines Changes Requests werden auf der zu jedem Change Request angelegten Wiki-Seite dokumentiert.

'''Hinweis''': Alle Änderungsbedarfe an der EFAv2.0-Spezifikation, die sich aus angenommenen IHE ITI Change Proposals ergeben können, sind in der nachfolgenden Liste offener Change Requests bis einschließlich Ballot-35 (Juli 2016, finaler Ballot für IHE ITI-TF Revision 13) berücksichtigt.

=== Offene Change Requests ===
* 31.10.16: [[cdaefa:CP-046-00|CP-046-00: IHE ITI TF Revision 13: Änderungen am SOAP Header]]
* 30.10.16: [[cdaefa:CP-045-00|CP-045-00: Differenzierung von Fehlermeldungen beim Ersetzen von Dokumenten]]
* 30.10.16: [[cdaefa:CP-044-00|CP-044-00: Integration administrativer Fallnummern]]
* 30.10.16: [[cdaefa:CP-043-00|CP-043-00: Mehrsprachige Display-Names für Dokumentenmetadaten]]
* 30.10.16: [[cdaefa:CP-042-00|CP-042-00: Klarstellungen zu partiellen Fehlern bei ''ProvideAndRegisterDocument'']]
* 07.07.16: [[cdaefa:CP-041-00|CP-041-00: Zu strikte Vorgaben beim Aktualisieren einer Einwilligung]]
* 07.07.16: [[cdaefa:CP-040-00|CP-040-00: Fehlermeldungen bei Nutzung verbotener Attribute in den XDS Metadaten]]
* 07.07.16: [[cdaefa:CP-039-00|CP-039-00: Umgang mit XDS-''GetAll'' und -''FindDocuments Query Flavor'' klären]]
* 07.07.16: [[cdaefa:CP-038-00|CP-038-00: Überarbeitetes Konzept zur Zweck-Kodierung in die Spezifikation aufnehmen]]
* 07.07.16: [[cdaefa:CP-037-00|CP-037-00: Probleme mit dem Audit Trail bei ''provideAndRegister'']]
* 07.07.16: [[cdaefa:CP-036-00|CP-036-00: Unklar, wieso ''retrieveDocuments'' nur Dokumente in einem Ordner referenzieren darf]]
* 07.07.16: [[cdaefa:CP-035-00|CP-035-00: Nutzung von WS Security ''mustUnderstand'' unklar]]
* 07.07.16: [[cdaefa:CP-034-00|CP-034-00: Fallakten-Manager muss Dokumente im Status ''deprecated'' lesen können]]
* 07.07.16: [[cdaefa:CP-033-00|CP-033-00: EFAv2.0 verletzt die IHE PCC Vorgaben zur ''sourcePatientID'']]
* 07.07.16: [[cdaefa:CP-032-00|CP-032-00: Fehlendes XSPA ''subjectID'' Attribut im EFAv2.0 Policy Binding]]
* 07.07.16: [[cdaefa:CP-031-00|CP-031-00: Vorgabe zur ''nameID'' stellt keine ausreichende Eindeutigkeit von Personen sicher]]
* 07.07.16: [[cdaefa:CP-030-00|CP-030-00: Mehrdeutige Definition im Policy Assertion Binding]]
* 07.07.16: [[cdaefa:CP-029-00|CP-029-00: ''Rule'' Element fehlt im Policy Assertion Beispiel]]
* 07.07.16: [[cdaefa:CP-028-00|CP-028-00: Falsches Beispiel im Binding ''ListPartitions'']]
* 07.07.16: [[cdaefa:CP-027-00|CP-027-00: Nutzung von APPC]]
* 07.07.16: [[cdaefa:CP-026-00|CP-026-00: Im PolicyAssertion Binding fehlt eine Vorgabe für die Kodierung der Rechte des Fallaktenmanagers]]
* 07.07.16: [[cdaefa:CP-025-00|CP-025-00: ''subjectID'' in der EFA Identity Assertion eventuell nicht IHE-konform kodiert]]
* 07.07.16: [[cdaefa:CP-024-00|CP-024-00: EFA-Notation für ''subjectRole'' nicht IHE-konform]]
* 07.07.16: [[cdaefa:CP-023-00|CP-023-00: Beispiel für EFA Identity Assertion fehlerhaft]]
* 07.07.16: [[cdaefa:CP-022-00|CP-022-00: Binding für SFM ''redeemAccessToken'' fehlt]]
* 07.07.16: [[cdaefa:CP-021-00|CP-021-00: Fehlende Stored Query bei ListRecordLocations Binding]]
* 07.04.16: [[cdaefa:CP-020-00|CP-020-00: Systemverhalten bei Berechtigungsfehlern]]
* 07.04.16: [[cdaefa:CP-019-00|CP-019-00: Klassifizierung von Mount-Points]]
* 09.04.15: [[cdaefa:CP-005-00|CP-005-00: Falsche Zuordnung der Signatur (Metadaten statt Dokument)]]
* 09.04.15: [[cdaefa:CP-007-00|CP-007-00: Inkonsistenz in der Darstellung der Dokumenten-Metadaten]]
* 09.04.15: [[cdaefa:CP-008-00|CP-008-00: Fehlende Profilierung der Dokumentensignatur]]
* 09.04.15: [[cdaefa:CP-010-00|CP-010-00: Audit Trail Einträge für EFAv2.0-Sicherheitsdienste]]
* 09.04.15: [[cdaefa:CP-011-00|CP-011-00: SecureRetrieve für EFAv2.0]]

=== In die Revision 2 (EFA-Projectathon 2016) aufgenommene Änderungen ===
* 07.04.16: [[cdaefa:CP-018-00|CP-018-00: Übernahme von Codes der deutschen Value-Set-Gruppe]]
* 02.11.15: [[cdaefa:CP-012-00|CP-012-00: Fehlerhafte Kodierung von IDs in einem Beispiel]]
* 02.11.15: [[cdaefa:CP-013-00|CP-013-00: Groß-/Kleinschreibung bei Query-Parametern]]
* 12.02.16: [[cdaefa:CP-001-00|CP-001-00: Missverständliche Spezifikation der Klasse subjectIdentity]]
* 12.02.16: [[cdaefa:CP-003-00|CP-003-00: Zulässigkeit weiterer Zweckcodes]]
* 12.02.16: [[cdaefa:CP-006-00|CP-006-00: Unvollständiges Binding der Dokumenten-Metadaten]]
* 12.02.16: [[cdaefa:CP-014-00|CP-014-00: Fehler in der OID-Nutzung für SMC-B]]
* 14.02.16: [[cdaefa:CP-015-00|CP-015-00: Fehlende Vorgabe für „HP Speciality“]]
* 14.02.16: [[cdaefa:CP-017-00|CP-017-00: EFA Identity Assertion SAML2 Binding]]
* 14.02.16: [[cdaefa:CP-016-00|CP-016-00: Nutzung von XDS-Optionen explizieren]]
* 16.02.16: [[cdaefa:CP-004-00|CP-004-00: Invalidieren von Dokumenten (Inkonsistenz zum IHE-Cookbook)]]
* 16.02.16: [[cdaefa:CP-002-00|CP-002-00: Unvollständige Spezifikation der Klasse consentInfo]]

=== In die Revision 1 (Januar 2015) aufgenommene Änderungen ===
* 01.10.14: [[cdaefa_Diskussion:EFA_Dienste|Deployment-Optionen für das XDS DocumentRegistry]]
* 27.04.14: [[cdaefa_Diskussion:EFA_Identity_Assertion_SAML2_Binding#Change_Requests|Kodierung von Rollen (HCP Identity Assertion)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests |Zulässigkeit weiterer Verwendungszwecke (logisch)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests|Grundlage einer consentInfo]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Change_Requests|Vorzeitiges Schließen einer Fallakte]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Einbau_eines_technischen_.22Verfallsdatums.22_f.C3.BCr_FallAkten |Einbau eines technischen "Verfallsdatums" für FallAkten]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Geschäftsobjekte#Unterscheidung_von_.22Muss.22-_und_.22Kann.22-Informationen|Unterscheidung von "Muss"- und "Kann"-Informationen ]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Konkretere_Empfehlungen_zur_Archivierung_von_Fallakten|Konkretere Empfehlungen zur Archivierung von Fallakten]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Konkretere_Darstellung_der_Kodierung_der_G.C3.BCltigkeitsdauer_einer_Akte|Konkretere Darstellung der Kodierung der Gültigkeitsdauer einer Akte]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Kommunikationsmuster#Konkreter_beschreiben.2C_wie_ein_Dokument_invalidiert_wird|Konkreter beschreiben, wie ein Dokument invalidiert wird]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Zustands.C3.BCbergang_.22verfallen.22_-.3E_.22archiviert.22_beschreiben|Zustandsübergang "verfallen" -> "archiviert" beschreiben]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Hinweis_auf_laufende_Arbeiten_zur_Einwilligungserkl.C3.A4rung_einf.C3.BCgen|Hinweis auf laufende Arbeiten zur Einwilligungserklärung einfügen]]
* 07.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Ausformulieren_des_Informationsmodells_einer_Einwilligung|Ausformulieren des Informationsmodells einer Einwilligung]]

=== Abgewiesene Change Requests ===
* 09.04.15: [[cdaefa:CP-009-00|CP-009-00: Profilierung von DocumentEntry.confidentialityCode]]

== Offene Punkte und ToDos ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.04}</tt>

=== ToDos aus der Kommentierung (Fraunhofer) ===

* [[cdaefa:EFA_Business_Informationsmodell|Informationsmodell]]: Übersichtsgrafik als UML-Klassenmodell
* [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|EFA Anwendungsdienste]]: Fehlercodes konsolidieren und auf einer Seite zusammenfassen
* [[cdaefa:Akteure_und_Rollen_der_EFA|Akteure und Rollen]]: Akteursdiagramm einfügen
* Darstellung des Zusammenhangs Interaktionsmuster-Kommunikationsmuster-SFM-Binding (zusätzliche Seite)

=== Diskussionsbedarfe - operativ (7er-Gruppe) ===

* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#issueAccessToken|issueAccessToken]]
* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#redeemAccessToken|redeemAccessToken]]
*Informationsmodell für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]
* Binding für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]

=== Diskussionbedarfe - strategisch (Lenkungsgruppe) ===

=== Abschnitte, die ggf. in das Cookbook verschoben werden können ===

* [[cdaefa:EFA_Business_Informationsmodell#Patient]]: Regel "Sender does it right"
* [[cdaefa:EFA_Business_Informationsmodell#purpose]]
* [[cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_createECR]]: "The application of security measures and the contents of the SOAP security header are specified normatively"
* [[cdaefa:EFA_XDS_ResourceManager#Security_Considerations]]
* [[cdaefa:EFA_Verwendete_Standards#Verwendete_Standards:_Sicherheit]]
* [[cdaefa:EFA_IHE_Setup_and_Flow_of_Control#EFA_Setup]]
* [[cdaefa:Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten#Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten]]
* [[cdaefa:Patienteneinwilligung_zur_EFA#Patienteneinwilligung_zur_EFA]]
* [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#HCP_Identity_Attributes]]: Values for attribute "Structural Role"

=== Externe Abhängigkeiten ===

* Aktuell existiert keine OID für die Nutzung der Telematik-ID als Identifizierungsmechansimus für Organisationen und Leistungserbringer. Eine solche OID wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Institution|Element ''AuthorInstitution'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Person|Element ''AuthorPerson'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_Profile|Subject-Identifizierung im EFA SAML Profil]]

* Ein Codesystem für die Klassifizierung von Fachbereichszugehörigkeiten eines Leistungserbringers muss festgelegt werden. Hier gibt es diverse KBV Schlüsseltabellen, die auf ihre Eignung zu prüfen sind. Diese Klassifizierung wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_National_Profile_and_Extensions|Subject-Attribut im EFA SAML Profil]]

cdaefa:CP-041-00

2016-11-02T11:41:13Z

Jcaumanns: /* Zu strikte Vorgaben beim Aktualisieren einer EInwilligung */

= Zu strikte Vorgaben beim Aktualisieren einer Einwilligung=
{|class="wikitable"
|-
| Titel des Change Request || Zu strikte Vorgaben beim Aktualisieren einer Einwilligung
|-
| Einreicher des Change Proposal || Sandra Schmidtlehner
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Computational
|-
| Akteur / Klasse / Transaktion || registerConsent
|-
| Change Proposal ID || CP-041-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Jörg Caumanns''
|}

== Motivation für den Change Request==
EFAv2.0 schreibt vor, dass bei Aktualisieren eines Consent die XDS Nachricht Assoziationen zu dem Ordner enthalten muss, in dem der alte Consent lag. Das ist unnötig, da XDS beim Aktualisieren eined Dokuments automatisch die Assoziationen des alten Dokuments auf das neue Dokument überträgt.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_registerConsent http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_registerConsent]''

ggf. Anpassen des Textes.

cdaefa:CP-041-00

2016-11-02T11:40:42Z

Jcaumanns: Die Seite wurde neu angelegt: „= Zu strikte Vorgaben beim Aktualisieren einer EInwilligung= {|class="wikitable" |- | Titel des Change Request || Zu strikte Vorgaben beim Aktualisieren einer…“

= Zu strikte Vorgaben beim Aktualisieren einer EInwilligung=
{|class="wikitable"
|-
| Titel des Change Request || Zu strikte Vorgaben beim Aktualisieren einer Einwilligung
|-
| Einreicher des Change Proposal || Sandra Schmidtlehner
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Computational
|-
| Akteur / Klasse / Transaktion || registerConsent
|-
| Change Proposal ID || CP-041-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Jörg Caumanns''
|}

== Motivation für den Change Request==
EFAv2.0 schreibt vor, dass bei Aktualisieren eines Consent die XDS Nachricht Assoziationen zu dem Ordner enthalten muss, in dem der alte Consent lag. Das ist unnötig, da XDS beim Aktualisieren eined Dokuments automatisch die Assoziationen des alten Dokuments auf das neue Dokument überträgt.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_registerConsent http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_registerConsent]''

ggf. Anpassen des Textes.

cdaefa:CP-040-00

2016-11-02T11:37:46Z

Jcaumanns: Die Seite wurde neu angelegt: „= Fehlermeldungen bei Nutzung verbotener Attribute in den XDS Metadaten= {|class="wikitable" |- | Titel des Change Request || Fehlermeldungen bei Nutzung verbo…“

= Fehlermeldungen bei Nutzung verbotener Attribute in den XDS Metadaten=
{|class="wikitable"
|-
| Titel des Change Request || Fehlermeldungen bei Nutzung verbotener Attribute in den XDS Metadaten
|-
| Einreicher des Change Proposal || Jörg Caumanns
joerg.caumanns@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Fehlermeldungen
|-
| Change Proposal ID || CP-040-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Jörg Caumanns''
|}
== Motivation für den Change Request==
Es fehlt die Definiton von Felermeldungen, wenn ein Client XDS-Metadaten registriert, in denen „verbotene“ Elemente enthalten sind (d.h. Felder, die aus Datenschutzgründen nicht belegt werden dürfen).

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRegistry#Expected_Actions http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRegistry#Expected_Actions]

Hinweis aufnehmen, dass Metadaten gegen das EFA Binding geprüft werden müssen und auflisten, welche Fehlermeldungen bei welchen Verletzung des Bindings zurückzugeben sind.

''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Fehlermeldungen_und_Warnungen http://wiki.hl7.de/index.php?title=cdaefa:EFA_Fehlermeldungen_und_Warnungen]''

Aufnehmen ggf. neu definierter Fehler in die Liste.

cdaefa:CP-039-00

2016-11-02T11:32:14Z

Jcaumanns: Die Seite wurde neu angelegt: „= Umgang mit „GetAll“ und „FindDocuments“ klären= {|class="wikitable" |- | Titel des Change Request || Umgang mit „GetAll“ und „FindDocuments“…“

= Umgang mit „GetAll“ und „FindDocuments“ klären=
{|class="wikitable"
|-
| Titel des Change Request || Umgang mit „GetAll“ und „FindDocuments“ klären
|-
| Einreicher des Change Proposal || Jörg Caumanns
joerg.caumanns@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Computational
|-
| Akteur / Klasse / Transaktion || Document Registy: listPartitionContent
|-
| Change Proposal ID || CP-039-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Jörg Caumanns''
|}
== Motivation für den Change Request==
'''Es muss diskutiert werden, ob die bestehenden Einschränkungen, dass nur GetFolderAndContents und Get Associations query flavors zulässig sind, bestehen bleiben soll oder weitere/alle IHE XDS Query Flavors unterstützt bzw. zugelassen werden sollen.'''

Die bisher zu dieser Frage von den Herstellern eingegangenen Aussagen sind uneinheitlich und spiegeln die Vor- und Nachteile der getroffenen Einschränkung wider:

* Wenn der EFA eine XDS-konforme Plattform zugrunde liegt, sind alle Query Flavors verfügbar und sollten auch genutzt werden können. Hiermit sind insbesondere bestehende Client-Umsetzungen einfacher für die EFA nutzbar.

* Die beiden zugeassenen Query Flavors erlauben ein einfaches und effizientes Durchsetzen der EFA-Policies, da die Bindung zu einem Ornder explizit gegeben ist. Für alle anderen Queries ist dies komplexer und erfordert zusätzliche Maßnahmen, die nicht zwingend Bestandteil jeder XDS-Umsetzung sind (insbesondere, wenn Ordner vorrangig für die EFA genutzt werden).

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
=== listPartitionContent (Document Registry XDS Binding)===
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRegistry#EFA_XDS_Binding:_listPartitionContent http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRegistry#EFA_XDS_Binding:_listPartitionContent]''

'''Constraints on the Request Message'''

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.

cdaefa:CP-038-00

2016-11-02T11:23:53Z

Jcaumanns: /* Vorschlag für die Änderung der EFAv2.0-Spezifikation */

= Abgestimmtes Konzept zur Zweck-Kodierung in die Spezifikation aufnehmen=
{|class="wikitable"
|-
| Titel des Change Request || „Neue“ Zweckcodes in die Spezifikation aufnehmen
|-
| Einreicher des Change Proposal || Jörg Caumanns
joerg.caumanns@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Folder Metadata Binding
|-
| Change Proposal ID || CP-038-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Jörg Caumanns''
|}
== Motivation für den Change Request==
Die EFAv2.0-Spezifikation muss an das abgestimmte Konzept zu den EFAv2.0 Zweckcodes angepasst werden. Dies betrifft sowohl die logischen als auch vor allem die technischen Teile der Spezifikation.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:Die_EFA_als_zweckgebundene_Akte http://wiki.hl7.de/index.php?title=cdaefa:Die_EFA_als_zweckgebundene_Akte]''

Verweis auf Konzeptpapier zur Zweck-Kodierung einfügen.

[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Business_Informationsmodell#purpose http://wiki.hl7.de/index.php?title=cdaefa:EFA_Business_Informationsmodell#purpose]

Konzept der Zweck-Kodierung skizzieren.

[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_Folder_Metadata_Binding http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_Folder_Metadata_Binding]

Verweis auf die zugelassenen Codesysteme einfügen.

cdaefa:CP-038-00

2016-11-02T11:23:35Z

Jcaumanns: Die Seite wurde neu angelegt: „= Abgestimmtes Konzept zur Zweck-Kodierung in die Spezifikation aufnehmen= {|class="wikitable" |- | Titel des Change Request || „Neue“ Zweckcodes in die Sp…“

= Abgestimmtes Konzept zur Zweck-Kodierung in die Spezifikation aufnehmen=
{|class="wikitable"
|-
| Titel des Change Request || „Neue“ Zweckcodes in die Spezifikation aufnehmen
|-
| Einreicher des Change Proposal || Jörg Caumanns
joerg.caumanns@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Folder Metadata Binding
|-
| Change Proposal ID || CP-038-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Jörg Caumanns''
|}
== Motivation für den Change Request==
Die EFAv2.0-Spezifikation muss an das abgestimmte Konzept zu den EFAv2.0 Zweckcodes angepasst werden. Dies betrifft sowohl die logischen als auch vor allem die technischen Teile der Spezifikation.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:Die_EFA_als_zweckgebundene_Akte http://wiki.hl7.de/index.php?title=cdaefa:Die_EFA_als_zweckgebundene_Akte]''

Verweis auf Konzeptpapier zur Zweck-Kodierungeinfügen.

[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Business_Informationsmodell#purpose http://wiki.hl7.de/index.php?title=cdaefa:EFA_Business_Informationsmodell#purpose]

Konzept der Zweck-Kodierungskizzieren.

[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_Folder_Metadata_Binding http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_Folder_Metadata_Binding]

Verweis auf die zugelassenen Codesysteme einfügen.

cdaefa:CP-037-00

2016-11-02T11:14:21Z

Jcaumanns: Die Seite wurde neu angelegt: „= Probleme mit dem AuditTrail bei provideAndRegister= {|class="wikitable" |- | Titel des Change Request || Probleme mit dem AuditTrail bei provideAndRegister |…“

= Probleme mit dem AuditTrail bei provideAndRegister=
{|class="wikitable"
|-
| Titel des Change Request || Probleme mit dem AuditTrail bei provideAndRegister
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Identity Assertion
|-
| Change Proposal ID || CP-037-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Jörg Caumanns''
|}
== Motivation für den Change Request==
EFAv2.0 erweitert den Audit Trail um Angaben zur logischen EFA-Transaktion (Akte anlegen, etc.). Damit das Repository bei einem ProvideAndRegister diesen erweiterten AuditTrail schrieben kann, braucht es Informationen aus dem Registry. Es sollte aber an dieser Stelle kein Registry-Zugriff durch das Repository erfolgen.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRepository#EFA_XDS_Binding:_provideData http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRepository#EFA_XDS_Binding:_provideData]''

cdaefa:CP-036-00

2016-11-02T11:11:06Z

Jcaumanns: Die Seite wurde neu angelegt: „= Einschränkung unklar, dass retrieveDocuments nur Dokumente in einem Ordner referenzieren darf= {|class="wikitable" |- | Titel des Change Request || Einschr…“

= Einschränkung unklar, dass retrieveDocuments nur Dokumente in einem Ordner referenzieren darf=
{|class="wikitable"
|-
| Titel des Change Request || Einschränkung, dass retrieveDocuments nur Dokumente in einem Ordner referenzieren darf, ist unklar
|-
| Einreicher des Change Proposal || [mailto:ben.kraufmann@fokus.fraunhofer.de Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de]
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Identity Assertion
|-
| Change Proposal ID || CP-036-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Jörg Caumanns''
|}
== Motivation für den Change Request==
Es fehlt eine nachvollziehbare Begründung für diese Einschränkung. Falls es diese nicht gibt, sollte die Einschränkung fallen gelassen werden.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
Die Einschränkung wurde ursprünglich eingeführt, um zu verhindern, dass bei einer P2P-Umsetzung über eine Transaktion auf mehrere Peers zugegriffen wird. Durch die Auswertung der Repository-ID in der Ergebnismenge der XDS-Query kann der Client jedoch gezielt auf einzelne Peers zugreifen. Damit ist das Standard-Verhalten von XDS herstellbar und die Einschränkung überflüssig. Es wird daher empfohlen, die Beschränkung des retriveDocument-Zugriffs auf einen einzelnen Ordner zu streichen.

=== retrieveData Binding (Document Repository)===
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRepository#EFA_XDS_Binding:_retrieveData http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRepository#EFA_XDS_Binding:_retrieveData]''

'''Constraints on the Request Message'''

The retrieveData request message implements the IHE Retrieve Document Set transaction (ITI-43) request message.

…

In addition the following constrains must be considered:

* The data to be retrieved SHALL all be associated with <del>the same</del><ins>an</ins> XDS Folder<del>. It</del><ins>, which</ins> SHALL be classified as an ECR partition.

cdaefa:CP-035-00

2016-11-02T10:54:28Z

Jcaumanns: Die Seite wurde neu angelegt: „= Nutzung von WS Security „mustUnderstand“ unklar= {|class="wikitable" |- | Titel des Change Request || Nutzung von WS Security „mustUnderstand“ unklar…“

= Nutzung von WS Security „mustUnderstand“ unklar=
{|class="wikitable"
|-
| Titel des Change Request || Nutzung von WS Security „mustUnderstand“ unklar
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Computational
|-
| Akteur / Klasse / Transaktion || Alle Bindings
|-
| Change Proposal ID || CP-035-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Raik Kuhlisch''
|}
== Motivation für den Change Request==
EFAv2.0 macht keine Vorgabe zur Nutzung von WS Security „mustUnderstand“. Hier muss eine Festlegung getroffen werden.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
Umsetzung der getroffenen Festlegung in den betroffenen Teilen der Spezifikation (inkl. Beispiele)

cdaefa:CP-034-00

2016-11-02T10:52:32Z

Jcaumanns: Die Seite wurde neu angelegt: „= Fallakten-Manager darf Dokumente im Status „deprecated“ lesen= {|class="wikitable" |- | Titel des Change Request || Fallakten-Manager darf Dokumente im S…“

= Fallakten-Manager darf Dokumente im Status „deprecated“ lesen=
{|class="wikitable"
|-
| Titel des Change Request || Fallakten-Manager darf Dokumente im Status „deprecated“ lesen
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Policy Assertion
|-
| Change Proposal ID || CP-034-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Raik Kuhlisch''
|}
== Motivation für den Change Request==
In den Vorgaben für das Policy-Binding fehlt die Berechtigung für den Fallaktenamanger, auf Dokumente zuzugreifen, die im Status „deprecated“ sind (siehe auch EFA CP 026).

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Assertion_SAML2_Binding http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Assertion_SAML2_Binding]''

Konkretisierung der Aussagen zu den Berechtigungen des Fallaktenmanagers und Abbildung entsprechender Plicies auf IHE APPC.

cdaefa:CP-033-00

2016-11-02T10:48:34Z

Jcaumanns: Die Seite wurde neu angelegt: „= IHE PCC Vorgabe zur sourcePatientID verletzt= {|class="wikitable" |- | Titel des Change Request || IHE PCC Vorgabe zur sourcePatientID verletzt |- | Einreich…“

= IHE PCC Vorgabe zur sourcePatientID verletzt=
{|class="wikitable"
|-
| Titel des Change Request || IHE PCC Vorgabe zur sourcePatientID verletzt
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Computational
|-
| Akteur / Klasse / Transaktion || XDS Bindings
|-
| Change Proposal ID || CP-033-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Raik Kuhlisch''
|}
== Motivation für den Change Request==
IHE PCC macht Vorgaben zur Übername von CDA-Elementen in die XDS-Metadaten. Für die Elemente patientID und sourcePatientID scheint das in der EFAv2.0 nicht richtig umgesetzt zu sein.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_Folder_Metadata_Binding http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_Folder_Metadata_Binding]''

[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_Document_Metadata_Binding http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_Document_Metadata_Binding]

Spezifikationen und Beispiele korrigieren.

cdaefa:CP-032-00

2016-11-02T10:45:02Z

Jcaumanns: Die Seite wurde neu angelegt: „= Fehlendes XSPA subjectID Attribut im Policy Binding= {|class="wikitable" |- | Titel des Change Request || Fehlendes XSPA subjectID Attribut im Policy Binding…“

= Fehlendes XSPA subjectID Attribut im Policy Binding=
{|class="wikitable"
|-
| Titel des Change Request || Fehlendes XSPA subjectID Attribut im Policy Binding
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Policy Assertion
|-
| Change Proposal ID || CP-032-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Raik Kuhlisch''
|}
== Motivation für den Change Request==
Im EFA POlicy Binding fehlt das von XSPA vorgeschriebene subjectID Attribut.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Assertion_SAML2_Binding http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Assertion_SAML2_Binding]''

Attribut in der Spezifikation und in den Beispielen ergänzen.

cdaefa:CP-031-00

2016-11-02T10:06:37Z

Jcaumanns: Die Seite wurde neu angelegt: „= nameID stellt keine Eindeutigkeit von Personen sicher= {|class="wikitable" |- | Titel des Change Request || nameID stellt keine Eindeutigkeit von Personen si…“

= nameID stellt keine Eindeutigkeit von Personen sicher=
{|class="wikitable"
|-
| Titel des Change Request || nameID stellt keine Eindeutigkeit von Personen sicher
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Identity Assertion
|-
| Change Proposal ID || CP-031-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Raik Kuhlisch''
|}
== Motivation für den Change Request==
In der SAML nameID steht nur der Name des Nutzers. Nutzer mit gleichem Namen sind damit nicht unterscheidbar, d.h. einer kann die Rechte des anderen in Anspruch nehmen.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Identity_Assertion_SAML2_Binding http://wiki.hl7.de/index.php?title=cdaefa:EFA_Identity_Assertion_SAML2_Binding]''

Abgestimmte Änderungen in die Spezifikation und die Beispiele übernehmen.

cdaefa:CP-030-00

2016-11-02T10:03:57Z

Jcaumanns: Die Seite wurde neu angelegt: „= Mehrdeutige Definition von ID-Attributen im Policy Assertion Binding= {|class="wikitable" |- | Titel des Change Request || Mehrdeutige Definition im Policy A…“

= Mehrdeutige Definition von ID-Attributen im Policy Assertion Binding=
{|class="wikitable"
|-
| Titel des Change Request || Mehrdeutige Definition im Policy Assertion Binding
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Policy Assertion
|-
| Change Proposal ID || CP-030-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Raik Kuhlisch''
|}
== Motivation für den Change Request==
Im Policy Assertion Binding sind die AttributeIDs für SAML NameId und HealthProfessional ID identisch definiert und damit nicht unterscheidbar.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Assertion_SAML2_Binding http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Assertion_SAML2_Binding]''

Abgestimmte Festlegugen zu den Kodierungen der IDs in die Spezifikation und die Beispiele einpflegen.

cdaefa:CP-029-00

2016-11-02T09:37:56Z

Jcaumanns: Die Seite wurde neu angelegt: „= Rule Element fehlt im Policy Assertion Beispiel= {|class="wikitable" |- | Titel des Change Request || Rule Element fehlt im Policy Assertion Beispiel |- | Ei…“

= Rule Element fehlt im Policy Assertion Beispiel=
{|class="wikitable"
|-
| Titel des Change Request || Rule Element fehlt im Policy Assertion Beispiel
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Policy Assertion
|-
| Change Proposal ID || CP-029-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Raik Kuhlisch''
|}
== Motivation für den Change Request==
Rule Element fehlt im Policy Assertion Beispiel

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Assertion_SAML2_Binding#Example_Assertion http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Assertion_SAML2_Binding#Example_Assertion]''

fehlendes Element nachtragen

cdaefa:CP-028-00

2016-11-02T09:36:06Z

Jcaumanns: Die Seite wurde neu angelegt: „= Falsches Beispiel im Binding ListPartitions= {|class="wikitable" |- | Titel des Change Request || Falsches Beispiel im Binding ListPartitions |- | Einreicher…“

= Falsches Beispiel im Binding ListPartitions=
{|class="wikitable"
|-
| Titel des Change Request || Falsches Beispiel im Binding ListPartitions
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Computational
|-
| Akteur / Klasse / Transaktion || ListPartitions
|-
| Change Proposal ID || CP-028-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Raik Kuhlisch''
|}
== Motivation für den Change Request==
Im Beispiel fehlen die Klammern um den Parameterwert XDS folderCodeList

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_ResourceManager#EFA_XDS_Binding:_listPartitions http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_ResourceManager#EFA_XDS_Binding:_listPartitions]''

Beispiel korrigieren

cdaefa:CP-027-00

2016-11-02T09:32:29Z

Jcaumanns: /* Nutzung von APPC */

= Nutzung von APPC=

{|class="wikitable"
|-
| Titel des Change Request || Nutzung von APPC
|-
| Einreicher des Change Proposal || Jörg Caumanns
Joerg.caumanns@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Policy Assertion
|-
| Change Proposal ID || CP-027-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Raik Kuhlisch''
|}
== Motivation für den Change Request==
Umstellung von EPPC-D auf APPC. In diesen Zusammenhang müssen dann auch die fehlerhaften Policy-Beispiele auf der Projectathon Webseite korrigiert werden (fehlende rules, etc.)

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Assertion_SAML2_Binding http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Assertion_SAML2_Binding]''

Anpassen der Bindings und Beispiele an APPC

[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Projectathon_2016 http://wiki.hl7.de/index.php?title=cdaefa:EFA_Projectathon_2016]

Ersetzen von Referenzen auf EPPC-D durch Verweise auf APPC

[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Projectathon_2016#Examples_of_request_messages http://wiki.hl7.de/index.php?title=cdaefa:EFA_Projectathon_2016#Examples_of_request_messages]

Anpassen der Beispiele

cdaefa:CP-027-00

2016-11-02T09:32:00Z

Jcaumanns: Die Seite wurde neu angelegt: „= Nutzung von APPC= ''[mailto:joerg.caumanns@fokus.fraunhofer.de Bitte senden Sie das ausgefüllte Formular zur weiteren Bearbeitung und zur Einleitung des EFA…“

= Nutzung von APPC=
''[mailto:joerg.caumanns@fokus.fraunhofer.de Bitte senden Sie das ausgefüllte Formular zur weiteren Bearbeitung und zur Einleitung des EFAv2.0 Change Management Prozesses an joerg.caumanns@fokus.fraunhofer.de]''

{|class="wikitable"
|-
| Titel des Change Request || Nutzung von APPC
|-
| Einreicher des Change Proposal || Jörg Caumanns
Joerg.caumanns@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Policy Assertion
|-
| Change Proposal ID || CP-027-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Raik Kuhlisch''
|}
== Motivation für den Change Request==
Umstellung von EPPC-D auf APPC. In diesen Zusammenhang müssen dann auch die fehlerhaften Policy-Beispiele auf der Projectathon Webseite korrigiert werden (fehlende rules, etc.)

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Assertion_SAML2_Binding http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Assertion_SAML2_Binding]''

Anpassen der Bindings und Beispiele an APPC

[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Projectathon_2016 http://wiki.hl7.de/index.php?title=cdaefa:EFA_Projectathon_2016]

Ersetzen von Referenzen auf EPPC-D durch Verweise auf APPC

[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Projectathon_2016#Examples_of_request_messages http://wiki.hl7.de/index.php?title=cdaefa:EFA_Projectathon_2016#Examples_of_request_messages]

Anpassen der Beispiele

cdaefa:CP-026-00

2016-11-02T09:27:00Z

Jcaumanns: Die Seite wurde neu angelegt: „= Im PolicyAssertion Binding fehlt eine Vorgabe für die Kodierung der Rechte des Fallaktenmanagers= {|class="wikitable" |- | Titel des Change Request || Im Po…“

= Im PolicyAssertion Binding fehlt eine Vorgabe für die Kodierung der Rechte des Fallaktenmanagers=
{|class="wikitable"
|-
| Titel des Change Request || Im PolicyAssertion Binding fehlt eine Vorgabe für die Kodierung der Rechte des Fallaktenmanagers
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Policy Assertion
|-
| Change Proposal ID || CP-026-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Raik Kuhlisch''
|}
== Motivation für den Change Request==
Im PolicyAssertion Binding fehlt eine Vorgabe für die Kodierung der Rechte des Fallaktenmanagers.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Security_Informationsmodell#subjectAccessPolicy http://wiki.hl7.de/index.php?title=cdaefa:EFA_Security_Informationsmodell#subjectAccessPolicy]''

Ergänzen eines Abschnitts zu den Berechtigungen der verschiedenen Nutzergruppen

[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Assertion_SAML2_Binding http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Assertion_SAML2_Binding]

Ergänzen eines Bindings zur Abbildung der Rechte des Fallaktenmanagers auf eine APPC-konforme XACML-Poliy

cdaefa:CP-025-00

2016-11-02T09:21:41Z

Jcaumanns: Die Seite wurde neu angelegt: „= subjectID in der Identity Assertion eventuell nicht IHE-konform kodiert= {|class="wikitable" |- | Titel des Change Request || Notation für subjectRole nicht…“

= subjectID in der Identity Assertion eventuell nicht IHE-konform kodiert=
{|class="wikitable"
|-
| Titel des Change Request || Notation für subjectRole nicht IHE-konform
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Identity Assertion
|-
| Change Proposal ID || CP-025-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Raik Kuhlisch''
|}
== Motivation für den Change Request==
Es ist unklar, wie die subjectID zu kodieren ist. Hier gehen die Meinungen auseinander…

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Identity_Assertion_SAML2_Binding http://wiki.hl7.de/index.php?title=cdaefa:EFA_Identity_Assertion_SAML2_Binding]''

TEXT TEXT

cdaefa:CP-023-00

2016-11-02T09:19:54Z

Jcaumanns: /* Beispiel für Identity Assertion fehlerhaft */

= Beispiel für Identity Assertion fehlerhaft=
{|class="wikitable"
|-
| Titel des Change Request || Beispiel für Identity Assertion fehlerhaft
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Identity Assertion
|-
| Change Proposal ID || CP-023-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Raik Kuhlisch''
|}
== Motivation für den Change Request==
In dem Beispiel für eine EFA Identity Assertion sind folgende Fehler:

* Verpflichtend anzugebende Organisations-ID fehlt

* Audience Restriction fehlt (in XUA mandatory)

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Identity_Assertion_SAML2_Binding#Example_Assertion http://wiki.hl7.de/index.php?title=cdaefa:EFA_Identity_Assertion_SAML2_Binding#Example_Assertion]''

Nachtragen der fehlenden Elemente in dem Beispiel

cdaefa:CP-024-00

2016-11-02T09:19:13Z

Jcaumanns: Die Seite wurde neu angelegt: „= Notation für subjectRole nicht IHE-konform= {|class="wikitable" |- | Titel des Change Request || Notation für subjectRole nicht IHE-konform |- | Einreicher…“

= Notation für subjectRole nicht IHE-konform=
{|class="wikitable"
|-
| Titel des Change Request || Notation für subjectRole nicht IHE-konform
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || Identity Assertion
|-
| Change Proposal ID || CP-024-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Raik Kuhlisch''
|}
== Motivation für den Change Request==
IHE nutzt HL7v3 CV zur Kodierung der subject:role. Das muss für die EFA nachgezogen werden.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Identity_Assertion_SAML2_Binding#HCP_Identity_Attributes http://wiki.hl7.de/index.php?title=cdaefa:EFA_Identity_Assertion_SAML2_Binding#HCP_Identity_Attributes]''

Angaben zum Typ des Attributs in der Spezifikation korrigieren. Beipiele anpassen.

cdaefa:CP-023-00

2016-11-02T09:10:28Z

Jcaumanns: Die Seite wurde neu angelegt: „= Beispiel für Identity Assertion fehlerhaft= {|class="wikitable" |- | Titel des Change Request || Beispiel für Identity Assertion fehlerhaft |- | Einreicher…“

= Beispiel für Identity Assertion fehlerhaft=
{|class="wikitable"
|-
| Titel des Change Request || Beispiel für Identity Assertion fehlerhaft
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Computational
|-
| Akteur / Klasse / Transaktion || redeemAccessToken
|-
| Change Proposal ID || CP-023-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Raik Kuhlisch''
|}
== Motivation für den Change Request==
In dem Beispiel für eine EFA Identity Assertion sind folgende Fehler:

* Verpflichtend anzugebende Organisations-ID fehlt

* Audience Restriction fehlt (in XUA mandatory)

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Identity_Assertion_SAML2_Binding#Example_Assertion http://wiki.hl7.de/index.php?title=cdaefa:EFA_Identity_Assertion_SAML2_Binding#Example_Assertion]''

Nachtragen der fehlenden Elemente in dem Beispiel

cdaefa:CP-022-00

2016-11-02T09:08:19Z

Jcaumanns: /* Binding für redeemAccessToen fehlt */

= Binding für SFM ''redeemAccessToken'' fehlt=
{|class="wikitable"
|-
| Titel des Change Request || Binding für redeemAccessToen fehlt
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Computational
|-
| Akteur / Klasse / Transaktion || redeemAccessToken
|-
| Change Proposal ID || CP-022-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Ben Kraufmann''
|}
== Motivation für den Change Request==
Das Binding für die logische Operation [http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Provider_SFM#redeemAccessToken redeemAccessToken] fehlt in der Spezifikation und muss nachgetragen werden.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_WS_Trust_Policy_Provider http://wiki.hl7.de/index.php?title=cdaefa:EFA_WS_Trust_Policy_Provider]''

Anlegen eines neuen Unterkapitels für das fehlende Binding, sofern das SFM an WS Trust gebunden wird. Ansonsten muss auch die Kaptelstruktur angepasst werden.

cdaefa:CP-022-00

2016-11-02T09:07:49Z

Jcaumanns: /* Binding für redeemAccessToen fehlt */

= Binding für redeemAccessToen fehlt=
{|class="wikitable"
|-
| Titel des Change Request || Binding für redeemAccessToen fehlt
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Computational
|-
| Akteur / Klasse / Transaktion || redeemAccessToken
|-
| Change Proposal ID || CP-022-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Ben Kraufmann''
|}
== Motivation für den Change Request==
Das Binding für die logische Operation [http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Provider_SFM#redeemAccessToken redeemAccessToken] fehlt in der Spezifikation und muss nachgetragen werden.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_WS_Trust_Policy_Provider http://wiki.hl7.de/index.php?title=cdaefa:EFA_WS_Trust_Policy_Provider]''

Anlegen eines neuen Unterkapitels für das fehlende Binding, sofern das SFM an WS Trust gebunden wird. Ansonsten muss auch die Kaptelstruktur angepasst werden.

cdaefa:CP-022-00

2016-11-02T09:07:32Z

Jcaumanns: Die Seite wurde neu angelegt: „= Binding für redeemAccessToen fehlt= {|class="wikitable" |- | Titel des Change Request || Binding für redeemAccessToen fehlt |- | Einreicher des Change Prop…“

= Binding für redeemAccessToen fehlt=
{|class="wikitable"
|-
| Titel des Change Request || Binding für redeemAccessToen fehlt
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Computational
|-
| Akteur / Klasse / Transaktion || redeemAccessToken
|-
| Change Proposal ID || CP-021-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Ben Kraufmann''
|}
== Motivation für den Change Request==
Das Binding für die logische Operation [http://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Provider_SFM#redeemAccessToken redeemAccessToken] fehlt in der Spezifikation und muss nachgetragen werden.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_WS_Trust_Policy_Provider http://wiki.hl7.de/index.php?title=cdaefa:EFA_WS_Trust_Policy_Provider]''

Anlegen eines neuen Unterkapitels für das fehlende Binding, sofern das SFM an WS Trust gebunden wird. Ansonsten muss auch die Kaptelstruktur angepasst werden.

cdaefa:EFA Spezifikation v2.0

2016-11-02T08:13:35Z

Jcaumanns: /* Offene Change Requests */

[[Datei:Information_icon.svg|40px|left]]Gemeinsam mit dem bvitg und IHE Deutschland hat der EFA-Verein einen [http://wiki.hl7.de/index.php?title=Datei:EPPC-G_Draft_for_Comment_v04.pdf Spezifikationsvorschlag für eine elektronische Einwilligung] erstellt, der aktuell innerhalb des Interoperabilitätsforums zur öffentlichen Kommentierung freigegeben wurde. Nach Abschluss der Kommentierung werden die EFA-relevanten Bestandteile dieser Spezifikation als ''Supplement zur EFAv2.0-Spezifikation'' auf dieser Seite verlinkt.

[[Datei:Attention_icon.svg|40px|left]] Im Rahmen des europäischen IHE Connectathon 2016 in Bochum wird erstmalig auch ein "EFA Projectathon" stattfinden. Alle hierzu relevanten Informationen finden Sie auf der Seite "[[cdaefa:EFA Projectathon 2016|EFA Projectathon 2016]]".

{{DocumentPart}}



= Einleitung =
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.01}</tt>

Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - einer Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.

Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf einem Patienten zugeordnete, medizinische Daten. Ein Fall beginnt mit einer Erstdiagnose und integriert alle weiteren notwendigen Abrechnungs- und Behandlungsdaten. Ein Arzt betreut die Fallakte zusammen mit weiteren behandelnden Ärzten, die für die Inhalte und deren Vollständigkeit verantwortlich sind.

Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt dezentral in bestehenden Systemen verwaltet und können bei Bedarf zu einer integrierten, für alle behandelnden Ärzte einheitlichen Sicht auf den Patienten zusammengeführt werden. Daher kann die Fallakte sehr einfach in bestehende Netze integriert werden und erleichtert somit die Zusammenarbeit auf regionaler Ebene.

== Von EFA 1.2 zu EFA 2.0 ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.02}</tt>

Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der [http://www.fallakte.de/spezifikationen EFA Version 1.2] das erste öffentliche Major-Release der EFA-Spezifikation von den Trägern der EFA-Initiative freigegeben. Bereits Ende 2008 konnten drei namhafte Hersteller (Siemens, ISPro, iSoft) auf dem ersten EFA-Connectathon Produkte präsentieren, die die interoperablen Schnittstellen der EFA implementierten und so miteinander in einem Peer-to-Peer Netzwerk zusammengeschaltet werden konnten. In den folgenden Jahren wurden in verschiedenen Bundesländern EFA-Pilotprojekte gestartet und 2011 konnte am Städtischen Klinikum München das erste regionale EFA-Netzwerk in den Regelbetrieb überführt werden.

Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] und [http://www.p23r.de Prozessdatenbeschleuniger (P23R)] den State-of-the-Art auch mit geprägt hat) haben sich in dieser Zeit im Bereich der Fachschnittstellen von elektronischen Aktensystemen die meisten Hersteller mit ihren Produkten in Richtung des IHE-Profils XDS bewegt, das von der EFA Version 1.2 lediglich logisch aber nicht syntaktisch berücksichtigt wurde - wobei auch die Synchronizität des EFA-1.2-Informationsmodells zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt war.

Im März 2012 haben daher der [http://www.fallakte.de EFA-Verein] als Träger der EFA-Spezifikation und der [http://www.bvitg.de bvitg] als Vertreter der im ambulanten und stationären Sektor tätigen Hersteller von IT-Lösungen beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifikation zu erarbeiten. Diese Version soll
* auf den bewährten und in verschiedenen Gesundheitsnetzen erfolgreich erprobten Kernprinzipien und -konzepten der EFA v1.2 aufbauen,
* in Produkten der Industrie verfügbare Schnittstellenstandards aufgreifen und eine Abbildbarkeit des EFA-Informationsmodells auf das Aktenkonzept von IHE herstellen,
* durch Verzahnung mit dem [[IHE_DE_Cookbook|IHE-D Cookbook]] auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

== EFA 2.0 Spezifikation ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.03}</tt>

Die folgende Tabelle stellt die einzelnen Kapitel der EFA 2.0 Spezifikation im Strukturraster des [[HL7 Enterprise Conformance and Compliance Frameworks]] dar. Die Spezifikation liegt auch als kompiliertes Dokument vor:
* [[cdaefa:EFAv2_Single_Document|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (HTML)]],
* [[Media:EFAv2.0-freeze-131118.pdf|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (PDF)]].

<table border="1" cellspacing="0" cellpadding="5em" width="100%">
<tr bgcolor="lightgray" align="center">
<td width="10%" valign="top">EFA v2.0</td>
<td width="30%" valign="top">'''Enterprise Dimension''' '''''"Why"''''' '''''Policy'''''</td>
<td width="30%" valign="top">'''Information Dimension''' '''''"What"''''' '''''Content'''''</td>
<td width="30%" valign="top">'''Computational Dimension''' '''''"How"''''' '''''Behavior'''''</td>
</tr>

<tr bgcolor="orange" align="center">
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Die EFA als zweckgebundene Akte|Die EFA als zweckgebundene Akte]]

[[cdaefa:EFA Provider|Versorgungsdomänen]]

[[cdaefa:Die EFA als Gesundheitsdatendienst|Die EFA als Gesundheitsdatendienst]]

[[cdaefa:Peer-to-Peer-Vernetzung von EFA-Providern|Peer-to-Peer-Vernetzung von EFA-Providern]]

[[cdaefa:Akteure und Rollen der EFA|Akteure und Rollen]]

[[cdaefa:Prinzipien für Datenschutz und Datensicherheit|Prinzipien für Datenschutz und Datensicherheit]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Kontext, Akte, Ressource|Kontext, Akte, Ressource]]

[[cdaefa:Patienteneinwilligung zur EFA|Patienteneinwilligung zur EFA]]

[[cdaefa:EFA Geschäftsobjekte|EFA Geschäftsobjekte]]

*[[cdaefa:EFA Business Lebenszyklus|Lebenszyklus einer Fallakte]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Interaktionsmuster der EFA|Interaktionsmuster der EFA]]
*[[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
*[[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
*[[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
*[[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
*[[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte oder eine Partition]]
*[[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
*[[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
*[[cdaefa:CIM Invalidieren von Datenobjekten|Invalidieren von Datenobjekten]]
*[[cdaefa:CIM Anpassen des Teilnehmerkreises|Ändern der Einwilligung]]
*[[cdaefa:CIM_Autorisierung_eines_weiteren_Teilnehmers|Autorisierung eines weiteren Teilnehmers]]
*[[cdaefa:CIM_Zusammenführen_von_Fallakten|Zusammenführen von Fallakten]]
</td>
</tr>

<tr bgcolor="yellow" align="center">
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Sicherheitsanforderungen|EFA Sicherheitsanforderungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Business Informationsmodell|Informationsmodelle der EFA Geschäftsobjekte]]

[[cdaefa:EFA Security Informationsmodell|Informationsmodelle der EFA Sicherheitsobjekte]]

[[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Dienste|EFA Dienste]]

[[cdaefa:EFA Kommunikationsmuster|EFA Kommunikationsmuster]]

[[cdaefa:EFA Anwendungsdienste (logische Spezifikation)|EFA Anwendungsdienste (logische Spezifikation)]]

[[cdaefa:EFA Sicherheitsdienste (logische Spezifikation)|EFA Sicherheitsdienste (logische Spezifikation)]]
*[[cdaefa:EFA Context Manager SFM|EFA Context Manager SFM]]
*[[cdaefa:EFA Identity Provider SFM|EFA Identity Provider SFM]]
*[[cdaefa:EFA Policy Provider SFM|EFA Policy Provider SFM]]

[[cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten|Gruppierung von Anwendungs- und Sicherheitsdiensten]]
</td>
</tr>

<tr bgcolor="palegreen" align="center">
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Verwendete Standards|Verwendete Standards]]

[[cdaefa:EFA Used Namespaces|Namespaces]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Metadata Bindings|EFA Metadata Bindings]]
*[[cdaefa:EFA XDS Folder Metadata Binding|EFA XDS Folder Metadata Binding]]
*[[cdaefa:EFA XDS Document Metadata Binding|EFA XDS Document Metadata Binding]]

[[cdaefa:EFA Security Objects Bindings|EFA Security Objects Bindings]]
*[[cdaefa:EFA Identity Assertion SAML2 Binding|EFA Identity Assertion SAML2 Binding]]
*[[cdaefa:EFA Policy Assertion SAML2 Binding|EFA Policy Assertion SAML2 Binding]]

[[cdaefa:EFA Patient Consent Binding|EFA Patient Consent Binding]]

[[cdaefa:EFA Audit Trail Binding|EFA Audit Trail Binding]]

[[cdaefa:EFA Error Codes and Warning Codes|EFA Error Codes and Warning Codes]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA IHE Setup and Flow of Control|EFA IHE Setup and Flow of Control]]

[[cdaefa:EFA XDS/XDR Bindings|EFA XDS Bindings]]
*[[cdaefa:EFA XDS ResourceManager|EFA XDS Binding: ResourceManager]]
*[[cdaefa:EFA XDS DocumentRegistry|EFA XDS Binding: DocumentRegistry]]
*[[cdaefa:EFA XDS DocumentRepository|EFA XDS Binding: DocumentRepository]]

[[cdaefa:EFA Access Control System|EFA Access Control System]]
*[[cdaefa:EFA WS Trust Policy Provider|EFA WS-Trust Binding: PolicyProvider]]

[[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]]
</td>
</tr>
</table>

== Weiterführende Themen ==
In der EFA-Spezifikation wird an verschiedenen Stellen auf weiterführende Informationen oder Grundlagenpapiere verwiesen, die in der ECCF-Matrix nicht verzeichnet sind. Diese "Anhänge" zur EFAv2.0-Spezifikation sind hier verzeichnet.

=== Methodische Grundlagen ===

* [[HL7_Enterprise_Conformance_and_Compliance_Frameworks|HL7 SAIF ECCF]]: Kurze Einführung in das HL7 SAIF ''Enterprise Conformance and Compliance Framework'', das dem Aufbau dieser Spezifikation zugrunde liegt
* [[cdaefa:IHE_Access_Control_Domains | IHE Access Control Domains]]: Zusammenfassung des IHE White Paper "Access Control" mit Fokus auf in der EFAv2.0-Spezifikation genutzte Konzepte und Begrifflichkeiten

=== EFA Konformitätsnachweis ===

In Abstimmung zwischen dem Vorstand des EFA-Vereins und dem Fraunhofer FOKUS wird ein Verfahren zum Nachweis der Konformität von Produkten zu den EFA-Spezifikationen durchgeführt, das im Wesentlichen auf einer Selbsterklärung eines Herstellers beruht. EFAv2.0-konforme Produkte dürfen das EFA-Logo tragen und mit dem EFA-Logo auf Messen sowie in Print- und Online-Materialien beworben werden.
* [[cdaefa:Gegenstand der Konformitätsprüfung|Gegenstand der Konformitätsprüfung]]

Die Ausstellung dieses EFAv2.0-Konformitätsnachweises ist für Hersteller kostenlos und wird wie bisher durch das Fraunhofer FOKUS durchgeführt. Das Fraunhofer FOKUS ist zur Durchführung des Verfahrens und zur Vergabe des EFA-Logos vom EFA-Verein akkreditiert.
* [[cdaefa:Durchführung der Konformitätsprüfung|Durchführung der Konformitätsprüfung]]

Hersteller können alle zur Durchführung des Verfahrens erforderlichen Unterlagen per Mail beim Fraunhofer FOKUS ([mailto:joerg.caumanns@fokus.fraunhofer.de joerg.caumanns@fokus.fraunhofer.de]) anfordern.

'''Hinweis''': Das hier beschriebene Verfahren und die ausgestellten Konformitätsnachweise sind bis Ende 2014 gültig. Ab 2015 soll ein erweitertes Verfahren zum Tragen kommen, dass auf der erfolgreichen Teilnahme von Produkten an einem IHE Connectathon aufsetzt.

== Change Requests ==
Mit der Finalisierung der EFA-Spezifikation im Herbst 2013 haben verschiedene Hersteller (und auch FuE-Projekte) begonnen, die EFAv2.0 zu implementieren. Trotz aller Sorgfalt bei der Erstellung der Spezifikationen fallen hierbei zuweilen kleinere Fehler auf und an manchen Stellen sind fachliche oder technische Festlegungen nur schwer nachvollziehbar, da die entsprechenden Beweggründe der Autorengruppe von Fraunhofer FOKUS, EFA-Verein und bvitg nicht ausreichend dokumentiert wurden.

Um die Spezifikationen kontinuierlich zu verbessern und insbesondere auch Hersteller und Projekte bestmöglich bei der Implementierung zu unterstützen, nehmen wir Fragen und Anregungen weiterhin gerne entgegen. Hierzu wurde für die EFAv2.0 ein regulärer [[EFA Change- und Releasemanagement|Change- und Releasemanagement-Prozess]] definiert, der ab Juli 2015 schrittweise operationalisiert wird.

Alle nach den vorgaben des definierten Prozesses eingereichten Änderungsanforderungen an die EFAv2.0-Spezifikation werden auf dieser Seite aufgelistet und durch Fraunhofer FOKUS, EFA-Verein und bvitg bearbeitet. Der Status der Bearbeitung sowie Entscheidungen zur Annahme bzw. Ablehnung eines Changes Requests werden auf der zu jedem Change Request angelegten Wiki-Seite dokumentiert.

'''Hinweis''': Alle Änderungsbedarfe an der EFAv2.0-Spezifikation, die sich aus angenommenen IHE ITI Change Proposals ergeben können, sind in der nachfolgenden Liste offener Change Requests bis einschließlich Ballot-35 (Juli 2016, finaler Ballot für IHE ITI-TF Revision 13) berücksichtigt.

=== Offene Change Requests ===
* 31.10.16: [[cdaefa:CP-046-00|CP-046-00: IHE ITI TF Revision 13: Änderungen am SOAP Header]]
* 30.10.16: [[cdaefa:CP-045-00|CP-045-00: Differenzierung von Fehlermeldungen beim Ersetzen von Dokumenten]]
* 30.10.16: [[cdaefa:CP-044-00|CP-044-00: Integration administrativer Fallnummern]]
* 30.10.16: [[cdaefa:CP-043-00|CP-043-00: Mehrsprachige Display-Names für Dokumentenmetadaten]]
* 30.10.16: [[cdaefa:CP-042-00|CP-042-00: Klarstellungen zu partiellen Fehlern bei ''ProvideAndRegisterDocument'']]
* 07.07.16: [[cdaefa:CP-041-00|CP-041-00: Zu strikte Vorgaben beim Aktualisieren einer Einwilligung]]
* 07.07.16: [[cdaefa:CP-040-00|CP-040-00: Fehlermeldungen bei Nutzung verbotener Attribute in den XDS Metadaten]]
* 07.07.16: [[cdaefa:CP-039-00|CP-039-00: Umgang mit XDS-''GetAll'' und -''FindDocuments Query Flavor'' klären]]
* 07.07.16: [[cdaefa:CP-038-00|CP-038-00: Überarbeitetes Konzept zur Zweck-Kodierung in die Spezifikation aufnehmen]]
* 07.07.16: [[cdaefa:CP-037-00|CP-037-00: Probleme mit dem Audit Trail bei ''provideAndRegister'']]
* 07.07.16: [[cdaefa:CP-036-00|CP-036-00: Unklar, wieso ''retrieveDocuments'' nur Dokumente in einem Ordner referenzieren darf]]
* 07.07.16: [[cdaefa:CP-035-00|CP-035-00: Nutzung von WS Security ''mustUnderstand'' unklar]]
* 07.07.16: [[cdaefa:CP-034-00|CP-034-00: Fallakten-Manager muss Dokumente im Status ''deprecated'' lesen können]]
* 07.07.16: [[cdaefa:CP-033-00|CP-033-00: EFAv2.0 verletzt die IHE PCC Vorgaben zur ''sourcePatientID'']]
* 07.07.16: [[cdaefa:CP-032-00|CP-032-00: Fehlendes XSPA ''subjectID'' Attribut im EFAv2.0 Policy Binding]]
* 07.07.16: [[cdaefa:CP-031-00|CP-031-00: Vorgabe zur ''nameID'' stellt keine ausreichende Eindeutigkeit von Personen sicher]]
* 07.07.16: [[cdaefa:CP-030-00|CP-030-00: Mehrdeutige Definition im Policy Assertion Binding]]
* 07.07.16: [[cdaefa:CP-029-00|CP-029-00: ''Rule'' Element fehlt im Policy Assertion Beispiel]]
* 07.07.16: [[cdaefa:CP-028-00|CP-028-00: Falsches Beispiel im Binding ''ListPartitions'']]
* 07.07.16: [[cdaefa:CP-027-00|CP-027-00: Nutzung von APPC]]
* 07.07.16: [[cdaefa:CP-026-00|CP-026-00: Im PolicyAssertion Binding fehlt eine Vorgabe für die Kodierung der Rechte des Fallaktenmanagers]]
* 07.07.16: [[cdaefa:CP-025-00|CP-025-00: ''subjectID'' in der EFA Identity Assertion eventuell nicht IHE-konform kodiert]]
* 07.07.16: [[cdaefa:CP-024-00|CP-024-00: EFA-Notation für ''subjectRole'' nicht IHE-konform]]
* 07.07.16: [[cdaefa:CP-023-00|CP-023-00: Beispiel für EFA Identity Assertion fehlerhaft]]
* 07.07.16: [[cdaefa:CP-022-00|CP-022-00: Binding für SFM ''redeemAccessToken'' fehlt]]
* 07.07.16: [[cdaefa:CP-021-00|CP-021-00: Fehlende Stored Query bei ListRecordLocations Binding]]
* 07.04.16: [[cdaefa:CP-020-00|CP-020-00: Systemverhalten bei Berechtigungsfehlern]]
* 07.04.16: [[cdaefa:CP-019-00|CP-019-00: Klassifizierung von Mount-Points]]
* 09.04.15: [[cdaefa:CP-005-00|CP-005-00: Falsche Zuordnung der Signatur (Metadaten statt Dokument)]]
* 09.04.15: [[cdaefa:CP-007-00|CP-007-00: Inkonsistenz in der Darstellung der Dokumenten-Metadaten]]
* 09.04.15: [[cdaefa:CP-008-00|CP-008-00: Fehlende Profilierung der Dokumentensignatur]]
* 09.04.15: [[cdaefa:CP-010-00|CP-010-00: Audit Trail Einträge für EFAv2.0-Sicherheitsdienste]]
* 09.04.15: [[cdaefa:CP-011-00|CP-011-00: SecureRetrieve für EFAv2.0]]

=== In die Revision 2 (EFA-Projectathon 2016) aufgenommene Änderungen ===
* 07.04.16: [[cdaefa:CP-018-00|CP-018-00: Übernahme von Codes der deutschen Value-Set-Gruppe]]
* 02.11.15: [[cdaefa:CP-012-00|CP-012-00: Fehlerhafte Kodierung von IDs in einem Beispiel]]
* 02.11.15: [[cdaefa:CP-013-00|CP-013-00: Groß-/Kleinschreibung bei Query-Parametern]]
* 12.02.16: [[cdaefa:CP-001-00|CP-001-00: Missverständliche Spezifikation der Klasse subjectIdentity]]
* 12.02.16: [[cdaefa:CP-003-00|CP-003-00: Zulässigkeit weiterer Zweckcodes]]
* 12.02.16: [[cdaefa:CP-006-00|CP-006-00: Unvollständiges Binding der Dokumenten-Metadaten]]
* 12.02.16: [[cdaefa:CP-014-00|CP-014-00: Fehler in der OID-Nutzung für SMC-B]]
* 14.02.16: [[cdaefa:CP-015-00|CP-015-00: Fehlende Vorgabe für „HP Speciality“]]
* 14.02.16: [[cdaefa:CP-017-00|CP-017-00: EFA Identity Assertion SAML2 Binding]]
* 14.02.16: [[cdaefa:CP-016-00|CP-016-00: Nutzung von XDS-Optionen explizieren]]
* 16.02.16: [[cdaefa:CP-004-00|CP-004-00: Invalidieren von Dokumenten (Inkonsistenz zum IHE-Cookbook)]]
* 16.02.16: [[cdaefa:CP-002-00|CP-002-00: Unvollständige Spezifikation der Klasse consentInfo]]

=== In die Revision 1 (Januar 2015) aufgenommene Änderungen ===
* 01.10.14: [[cdaefa_Diskussion:EFA_Dienste|Deployment-Optionen für das XDS DocumentRegistry]]
* 27.04.14: [[cdaefa_Diskussion:EFA_Identity_Assertion_SAML2_Binding#Change_Requests|Kodierung von Rollen (HCP Identity Assertion)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests |Zulässigkeit weiterer Verwendungszwecke (logisch)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests|Grundlage einer consentInfo]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Change_Requests|Vorzeitiges Schließen einer Fallakte]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Einbau_eines_technischen_.22Verfallsdatums.22_f.C3.BCr_FallAkten |Einbau eines technischen "Verfallsdatums" für FallAkten]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Geschäftsobjekte#Unterscheidung_von_.22Muss.22-_und_.22Kann.22-Informationen|Unterscheidung von "Muss"- und "Kann"-Informationen ]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Konkretere_Empfehlungen_zur_Archivierung_von_Fallakten|Konkretere Empfehlungen zur Archivierung von Fallakten]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Konkretere_Darstellung_der_Kodierung_der_G.C3.BCltigkeitsdauer_einer_Akte|Konkretere Darstellung der Kodierung der Gültigkeitsdauer einer Akte]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Kommunikationsmuster#Konkreter_beschreiben.2C_wie_ein_Dokument_invalidiert_wird|Konkreter beschreiben, wie ein Dokument invalidiert wird]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Zustands.C3.BCbergang_.22verfallen.22_-.3E_.22archiviert.22_beschreiben|Zustandsübergang "verfallen" -> "archiviert" beschreiben]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Hinweis_auf_laufende_Arbeiten_zur_Einwilligungserkl.C3.A4rung_einf.C3.BCgen|Hinweis auf laufende Arbeiten zur Einwilligungserklärung einfügen]]
* 07.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Ausformulieren_des_Informationsmodells_einer_Einwilligung|Ausformulieren des Informationsmodells einer Einwilligung]]

=== Abgewiesene Change Requests ===
* 09.04.15: [[cdaefa:CP-009-00|CP-009-00: Profilierung von DocumentEntry.confidentialityCode]]

== Offene Punkte und ToDos ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.04}</tt>

=== ToDos aus der Kommentierung (Fraunhofer) ===

* [[cdaefa:EFA_Business_Informationsmodell|Informationsmodell]]: Übersichtsgrafik als UML-Klassenmodell
* [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|EFA Anwendungsdienste]]: Fehlercodes konsolidieren und auf einer Seite zusammenfassen
* [[cdaefa:Akteure_und_Rollen_der_EFA|Akteure und Rollen]]: Akteursdiagramm einfügen
* Darstellung des Zusammenhangs Interaktionsmuster-Kommunikationsmuster-SFM-Binding (zusätzliche Seite)

=== Diskussionsbedarfe - operativ (7er-Gruppe) ===

* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#issueAccessToken|issueAccessToken]]
* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#redeemAccessToken|redeemAccessToken]]
*Informationsmodell für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]
* Binding für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]

=== Diskussionbedarfe - strategisch (Lenkungsgruppe) ===

=== Abschnitte, die ggf. in das Cookbook verschoben werden können ===

* [[cdaefa:EFA_Business_Informationsmodell#Patient]]: Regel "Sender does it right"
* [[cdaefa:EFA_Business_Informationsmodell#purpose]]
* [[cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_createECR]]: "The application of security measures and the contents of the SOAP security header are specified normatively"
* [[cdaefa:EFA_XDS_ResourceManager#Security_Considerations]]
* [[cdaefa:EFA_Verwendete_Standards#Verwendete_Standards:_Sicherheit]]
* [[cdaefa:EFA_IHE_Setup_and_Flow_of_Control#EFA_Setup]]
* [[cdaefa:Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten#Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten]]
* [[cdaefa:Patienteneinwilligung_zur_EFA#Patienteneinwilligung_zur_EFA]]
* [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#HCP_Identity_Attributes]]: Values for attribute "Structural Role"

=== Externe Abhängigkeiten ===

* Aktuell existiert keine OID für die Nutzung der Telematik-ID als Identifizierungsmechansimus für Organisationen und Leistungserbringer. Eine solche OID wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Institution|Element ''AuthorInstitution'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Person|Element ''AuthorPerson'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_Profile|Subject-Identifizierung im EFA SAML Profil]]

* Ein Codesystem für die Klassifizierung von Fachbereichszugehörigkeiten eines Leistungserbringers muss festgelegt werden. Hier gibt es diverse KBV Schlüsseltabellen, die auf ihre Eignung zu prüfen sind. Diese Klassifizierung wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_National_Profile_and_Extensions|Subject-Attribut im EFA SAML Profil]]

cdaefa:CP-021-00

2016-11-02T08:00:49Z

Jcaumanns: Die Seite wurde neu angelegt: „= Fehlende Stored Query bei ListRecordLocations Binding= {|class="wikitable" |- | Titel des Change Request || Fehlende Stored Query bei ListRecordLocations Bin…“

= Fehlende Stored Query bei ListRecordLocations Binding=
{|class="wikitable"
|-
| Titel des Change Request || Fehlende Stored Query bei ListRecordLocations Binding
|-
| Einreicher des Change Proposal || Ben Kraufmann
ben.kraufmann@fokus.fraunhofer.de
|-
| Datum der Einreichung des Change Proposal || 07.04.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Computational
|-
| Akteur / Klasse / Transaktion || listRecordLocations
|-
| Change Proposal ID || CP-021-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 07.07.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Nein
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 07.07.16
|-
| Zugewiesener Bearbeiter || ''Zuweisung erfolgt in der 7er-Gruppe''
|}
== Motivation für den Change Request==
In der Spezifikation wird die logische EFA-Funktion ListRecordLocations an eine IHE XCA Cross-Gateway Query gebunden. Die gewünschte Funktionalität erfordert eine FindFolders-Abfrage, was in der Spezifikation jedoch nicht deutlich wird.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_ResourceManager#EFA_IHE-ITI-Binding:_listRecordLocations http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_ResourceManager#EFA_IHE-ITI-Binding:_listRecordLocations]''

Für die stored query muss findFolders explizit als Query Flavor vorgegeben werden.

cdaefa:EFA Spezifikation v2.0

2016-11-02T08:00:20Z

Jcaumanns: /* Offene Change Requests */

[[Datei:Information_icon.svg|40px|left]]Gemeinsam mit dem bvitg und IHE Deutschland hat der EFA-Verein einen [http://wiki.hl7.de/index.php?title=Datei:EPPC-G_Draft_for_Comment_v04.pdf Spezifikationsvorschlag für eine elektronische Einwilligung] erstellt, der aktuell innerhalb des Interoperabilitätsforums zur öffentlichen Kommentierung freigegeben wurde. Nach Abschluss der Kommentierung werden die EFA-relevanten Bestandteile dieser Spezifikation als ''Supplement zur EFAv2.0-Spezifikation'' auf dieser Seite verlinkt.

[[Datei:Attention_icon.svg|40px|left]] Im Rahmen des europäischen IHE Connectathon 2016 in Bochum wird erstmalig auch ein "EFA Projectathon" stattfinden. Alle hierzu relevanten Informationen finden Sie auf der Seite "[[cdaefa:EFA Projectathon 2016|EFA Projectathon 2016]]".

{{DocumentPart}}



= Einleitung =
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.01}</tt>

Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - einer Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.

Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf einem Patienten zugeordnete, medizinische Daten. Ein Fall beginnt mit einer Erstdiagnose und integriert alle weiteren notwendigen Abrechnungs- und Behandlungsdaten. Ein Arzt betreut die Fallakte zusammen mit weiteren behandelnden Ärzten, die für die Inhalte und deren Vollständigkeit verantwortlich sind.

Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt dezentral in bestehenden Systemen verwaltet und können bei Bedarf zu einer integrierten, für alle behandelnden Ärzte einheitlichen Sicht auf den Patienten zusammengeführt werden. Daher kann die Fallakte sehr einfach in bestehende Netze integriert werden und erleichtert somit die Zusammenarbeit auf regionaler Ebene.

== Von EFA 1.2 zu EFA 2.0 ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.02}</tt>

Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der [http://www.fallakte.de/spezifikationen EFA Version 1.2] das erste öffentliche Major-Release der EFA-Spezifikation von den Trägern der EFA-Initiative freigegeben. Bereits Ende 2008 konnten drei namhafte Hersteller (Siemens, ISPro, iSoft) auf dem ersten EFA-Connectathon Produkte präsentieren, die die interoperablen Schnittstellen der EFA implementierten und so miteinander in einem Peer-to-Peer Netzwerk zusammengeschaltet werden konnten. In den folgenden Jahren wurden in verschiedenen Bundesländern EFA-Pilotprojekte gestartet und 2011 konnte am Städtischen Klinikum München das erste regionale EFA-Netzwerk in den Regelbetrieb überführt werden.

Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] und [http://www.p23r.de Prozessdatenbeschleuniger (P23R)] den State-of-the-Art auch mit geprägt hat) haben sich in dieser Zeit im Bereich der Fachschnittstellen von elektronischen Aktensystemen die meisten Hersteller mit ihren Produkten in Richtung des IHE-Profils XDS bewegt, das von der EFA Version 1.2 lediglich logisch aber nicht syntaktisch berücksichtigt wurde - wobei auch die Synchronizität des EFA-1.2-Informationsmodells zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt war.

Im März 2012 haben daher der [http://www.fallakte.de EFA-Verein] als Träger der EFA-Spezifikation und der [http://www.bvitg.de bvitg] als Vertreter der im ambulanten und stationären Sektor tätigen Hersteller von IT-Lösungen beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifikation zu erarbeiten. Diese Version soll
* auf den bewährten und in verschiedenen Gesundheitsnetzen erfolgreich erprobten Kernprinzipien und -konzepten der EFA v1.2 aufbauen,
* in Produkten der Industrie verfügbare Schnittstellenstandards aufgreifen und eine Abbildbarkeit des EFA-Informationsmodells auf das Aktenkonzept von IHE herstellen,
* durch Verzahnung mit dem [[IHE_DE_Cookbook|IHE-D Cookbook]] auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

== EFA 2.0 Spezifikation ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.03}</tt>

Die folgende Tabelle stellt die einzelnen Kapitel der EFA 2.0 Spezifikation im Strukturraster des [[HL7 Enterprise Conformance and Compliance Frameworks]] dar. Die Spezifikation liegt auch als kompiliertes Dokument vor:
* [[cdaefa:EFAv2_Single_Document|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (HTML)]],
* [[Media:EFAv2.0-freeze-131118.pdf|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (PDF)]].

<table border="1" cellspacing="0" cellpadding="5em" width="100%">
<tr bgcolor="lightgray" align="center">
<td width="10%" valign="top">EFA v2.0</td>
<td width="30%" valign="top">'''Enterprise Dimension''' '''''"Why"''''' '''''Policy'''''</td>
<td width="30%" valign="top">'''Information Dimension''' '''''"What"''''' '''''Content'''''</td>
<td width="30%" valign="top">'''Computational Dimension''' '''''"How"''''' '''''Behavior'''''</td>
</tr>

<tr bgcolor="orange" align="center">
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Die EFA als zweckgebundene Akte|Die EFA als zweckgebundene Akte]]

[[cdaefa:EFA Provider|Versorgungsdomänen]]

[[cdaefa:Die EFA als Gesundheitsdatendienst|Die EFA als Gesundheitsdatendienst]]

[[cdaefa:Peer-to-Peer-Vernetzung von EFA-Providern|Peer-to-Peer-Vernetzung von EFA-Providern]]

[[cdaefa:Akteure und Rollen der EFA|Akteure und Rollen]]

[[cdaefa:Prinzipien für Datenschutz und Datensicherheit|Prinzipien für Datenschutz und Datensicherheit]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Kontext, Akte, Ressource|Kontext, Akte, Ressource]]

[[cdaefa:Patienteneinwilligung zur EFA|Patienteneinwilligung zur EFA]]

[[cdaefa:EFA Geschäftsobjekte|EFA Geschäftsobjekte]]

*[[cdaefa:EFA Business Lebenszyklus|Lebenszyklus einer Fallakte]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Interaktionsmuster der EFA|Interaktionsmuster der EFA]]
*[[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
*[[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
*[[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
*[[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
*[[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte oder eine Partition]]
*[[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
*[[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
*[[cdaefa:CIM Invalidieren von Datenobjekten|Invalidieren von Datenobjekten]]
*[[cdaefa:CIM Anpassen des Teilnehmerkreises|Ändern der Einwilligung]]
*[[cdaefa:CIM_Autorisierung_eines_weiteren_Teilnehmers|Autorisierung eines weiteren Teilnehmers]]
*[[cdaefa:CIM_Zusammenführen_von_Fallakten|Zusammenführen von Fallakten]]
</td>
</tr>

<tr bgcolor="yellow" align="center">
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Sicherheitsanforderungen|EFA Sicherheitsanforderungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Business Informationsmodell|Informationsmodelle der EFA Geschäftsobjekte]]

[[cdaefa:EFA Security Informationsmodell|Informationsmodelle der EFA Sicherheitsobjekte]]

[[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Dienste|EFA Dienste]]

[[cdaefa:EFA Kommunikationsmuster|EFA Kommunikationsmuster]]

[[cdaefa:EFA Anwendungsdienste (logische Spezifikation)|EFA Anwendungsdienste (logische Spezifikation)]]

[[cdaefa:EFA Sicherheitsdienste (logische Spezifikation)|EFA Sicherheitsdienste (logische Spezifikation)]]
*[[cdaefa:EFA Context Manager SFM|EFA Context Manager SFM]]
*[[cdaefa:EFA Identity Provider SFM|EFA Identity Provider SFM]]
*[[cdaefa:EFA Policy Provider SFM|EFA Policy Provider SFM]]

[[cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten|Gruppierung von Anwendungs- und Sicherheitsdiensten]]
</td>
</tr>

<tr bgcolor="palegreen" align="center">
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Verwendete Standards|Verwendete Standards]]

[[cdaefa:EFA Used Namespaces|Namespaces]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Metadata Bindings|EFA Metadata Bindings]]
*[[cdaefa:EFA XDS Folder Metadata Binding|EFA XDS Folder Metadata Binding]]
*[[cdaefa:EFA XDS Document Metadata Binding|EFA XDS Document Metadata Binding]]

[[cdaefa:EFA Security Objects Bindings|EFA Security Objects Bindings]]
*[[cdaefa:EFA Identity Assertion SAML2 Binding|EFA Identity Assertion SAML2 Binding]]
*[[cdaefa:EFA Policy Assertion SAML2 Binding|EFA Policy Assertion SAML2 Binding]]

[[cdaefa:EFA Patient Consent Binding|EFA Patient Consent Binding]]

[[cdaefa:EFA Audit Trail Binding|EFA Audit Trail Binding]]

[[cdaefa:EFA Error Codes and Warning Codes|EFA Error Codes and Warning Codes]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA IHE Setup and Flow of Control|EFA IHE Setup and Flow of Control]]

[[cdaefa:EFA XDS/XDR Bindings|EFA XDS Bindings]]
*[[cdaefa:EFA XDS ResourceManager|EFA XDS Binding: ResourceManager]]
*[[cdaefa:EFA XDS DocumentRegistry|EFA XDS Binding: DocumentRegistry]]
*[[cdaefa:EFA XDS DocumentRepository|EFA XDS Binding: DocumentRepository]]

[[cdaefa:EFA Access Control System|EFA Access Control System]]
*[[cdaefa:EFA WS Trust Policy Provider|EFA WS-Trust Binding: PolicyProvider]]

[[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]]
</td>
</tr>
</table>

== Weiterführende Themen ==
In der EFA-Spezifikation wird an verschiedenen Stellen auf weiterführende Informationen oder Grundlagenpapiere verwiesen, die in der ECCF-Matrix nicht verzeichnet sind. Diese "Anhänge" zur EFAv2.0-Spezifikation sind hier verzeichnet.

=== Methodische Grundlagen ===

* [[HL7_Enterprise_Conformance_and_Compliance_Frameworks|HL7 SAIF ECCF]]: Kurze Einführung in das HL7 SAIF ''Enterprise Conformance and Compliance Framework'', das dem Aufbau dieser Spezifikation zugrunde liegt
* [[cdaefa:IHE_Access_Control_Domains | IHE Access Control Domains]]: Zusammenfassung des IHE White Paper "Access Control" mit Fokus auf in der EFAv2.0-Spezifikation genutzte Konzepte und Begrifflichkeiten

=== EFA Konformitätsnachweis ===

In Abstimmung zwischen dem Vorstand des EFA-Vereins und dem Fraunhofer FOKUS wird ein Verfahren zum Nachweis der Konformität von Produkten zu den EFA-Spezifikationen durchgeführt, das im Wesentlichen auf einer Selbsterklärung eines Herstellers beruht. EFAv2.0-konforme Produkte dürfen das EFA-Logo tragen und mit dem EFA-Logo auf Messen sowie in Print- und Online-Materialien beworben werden.
* [[cdaefa:Gegenstand der Konformitätsprüfung|Gegenstand der Konformitätsprüfung]]

Die Ausstellung dieses EFAv2.0-Konformitätsnachweises ist für Hersteller kostenlos und wird wie bisher durch das Fraunhofer FOKUS durchgeführt. Das Fraunhofer FOKUS ist zur Durchführung des Verfahrens und zur Vergabe des EFA-Logos vom EFA-Verein akkreditiert.
* [[cdaefa:Durchführung der Konformitätsprüfung|Durchführung der Konformitätsprüfung]]

Hersteller können alle zur Durchführung des Verfahrens erforderlichen Unterlagen per Mail beim Fraunhofer FOKUS ([mailto:joerg.caumanns@fokus.fraunhofer.de joerg.caumanns@fokus.fraunhofer.de]) anfordern.

'''Hinweis''': Das hier beschriebene Verfahren und die ausgestellten Konformitätsnachweise sind bis Ende 2014 gültig. Ab 2015 soll ein erweitertes Verfahren zum Tragen kommen, dass auf der erfolgreichen Teilnahme von Produkten an einem IHE Connectathon aufsetzt.

== Change Requests ==
Mit der Finalisierung der EFA-Spezifikation im Herbst 2013 haben verschiedene Hersteller (und auch FuE-Projekte) begonnen, die EFAv2.0 zu implementieren. Trotz aller Sorgfalt bei der Erstellung der Spezifikationen fallen hierbei zuweilen kleinere Fehler auf und an manchen Stellen sind fachliche oder technische Festlegungen nur schwer nachvollziehbar, da die entsprechenden Beweggründe der Autorengruppe von Fraunhofer FOKUS, EFA-Verein und bvitg nicht ausreichend dokumentiert wurden.

Um die Spezifikationen kontinuierlich zu verbessern und insbesondere auch Hersteller und Projekte bestmöglich bei der Implementierung zu unterstützen, nehmen wir Fragen und Anregungen weiterhin gerne entgegen. Hierzu wurde für die EFAv2.0 ein regulärer [[EFA Change- und Releasemanagement|Change- und Releasemanagement-Prozess]] definiert, der ab Juli 2015 schrittweise operationalisiert wird.

Alle nach den vorgaben des definierten Prozesses eingereichten Änderungsanforderungen an die EFAv2.0-Spezifikation werden auf dieser Seite aufgelistet und durch Fraunhofer FOKUS, EFA-Verein und bvitg bearbeitet. Der Status der Bearbeitung sowie Entscheidungen zur Annahme bzw. Ablehnung eines Changes Requests werden auf der zu jedem Change Request angelegten Wiki-Seite dokumentiert.

'''Hinweis''': Alle Änderungsbedarfe an der EFAv2.0-Spezifikation, die sich aus angenommenen IHE ITI Change Proposals ergeben können, sind in der nachfolgenden Liste offener Change Requests bis einschließlich Ballot-35 (Juli 2016, finaler Ballot für IHE ITI-TF Revision 13) berücksichtigt.

=== Offene Change Requests ===
* 31.10.16: [[cdaefa:CP-046-00|CP-046-00: IHE ITI TF Revision 13: Änderungen am SOAP Header]]
* 30.10.16: [[cdaefa:CP-045-00|CP-045-00: Differenzierung von Fehlermeldungen beim Ersetzen von Dokumenten]]
* 30.10.16: [[cdaefa:CP-044-00|CP-044-00: Integration administrativer Fallnummern]]
* 30.10.16: [[cdaefa:CP-043-00|CP-043-00: Mehrsprachige Display-Names für Dokumentenmetadaten]]
* 30.10.16: [[cdaefa:CP-042-00|CP-042-00: Klarstellungen zu partiellen Fehlern bei ProvideAndRegisterDocument]]
* 07.07.16: [[cdaefa:CP-021-00|CP-021-00: Fehlende Stored Query bei ListRecordLocations Binding]]
* 07.04.16: [[cdaefa:CP-020-00|CP-020-00: Systemverhalten bei Berechtigungsfehlern]]
* 07.04.16: [[cdaefa:CP-019-00|CP-019-00: Klassifizierung von Mount-Points]]
* 09.04.15: [[cdaefa:CP-005-00|CP-005-00: Falsche Zuordnung der Signatur (Metadaten statt Dokument)]]
* 09.04.15: [[cdaefa:CP-007-00|CP-007-00: Inkonsistenz in der Darstellung der Dokumenten-Metadaten]]
* 09.04.15: [[cdaefa:CP-008-00|CP-008-00: Fehlende Profilierung der Dokumentensignatur]]
* 09.04.15: [[cdaefa:CP-010-00|CP-010-00: Audit Trail Einträge für EFAv2.0-Sicherheitsdienste]]
* 09.04.15: [[cdaefa:CP-011-00|CP-011-00: SecureRetrieve für EFAv2.0]]

=== In die Revision 2 (EFA-Projectathon 2016) aufgenommene Änderungen ===
* 07.04.16: [[cdaefa:CP-018-00|CP-018-00: Übernahme von Codes der deutschen Value-Set-Gruppe]]
* 02.11.15: [[cdaefa:CP-012-00|CP-012-00: Fehlerhafte Kodierung von IDs in einem Beispiel]]
* 02.11.15: [[cdaefa:CP-013-00|CP-013-00: Groß-/Kleinschreibung bei Query-Parametern]]
* 12.02.16: [[cdaefa:CP-001-00|CP-001-00: Missverständliche Spezifikation der Klasse subjectIdentity]]
* 12.02.16: [[cdaefa:CP-003-00|CP-003-00: Zulässigkeit weiterer Zweckcodes]]
* 12.02.16: [[cdaefa:CP-006-00|CP-006-00: Unvollständiges Binding der Dokumenten-Metadaten]]
* 12.02.16: [[cdaefa:CP-014-00|CP-014-00: Fehler in der OID-Nutzung für SMC-B]]
* 14.02.16: [[cdaefa:CP-015-00|CP-015-00: Fehlende Vorgabe für „HP Speciality“]]
* 14.02.16: [[cdaefa:CP-017-00|CP-017-00: EFA Identity Assertion SAML2 Binding]]
* 14.02.16: [[cdaefa:CP-016-00|CP-016-00: Nutzung von XDS-Optionen explizieren]]
* 16.02.16: [[cdaefa:CP-004-00|CP-004-00: Invalidieren von Dokumenten (Inkonsistenz zum IHE-Cookbook)]]
* 16.02.16: [[cdaefa:CP-002-00|CP-002-00: Unvollständige Spezifikation der Klasse consentInfo]]

=== In die Revision 1 (Januar 2015) aufgenommene Änderungen ===
* 01.10.14: [[cdaefa_Diskussion:EFA_Dienste|Deployment-Optionen für das XDS DocumentRegistry]]
* 27.04.14: [[cdaefa_Diskussion:EFA_Identity_Assertion_SAML2_Binding#Change_Requests|Kodierung von Rollen (HCP Identity Assertion)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests |Zulässigkeit weiterer Verwendungszwecke (logisch)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests|Grundlage einer consentInfo]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Change_Requests|Vorzeitiges Schließen einer Fallakte]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Einbau_eines_technischen_.22Verfallsdatums.22_f.C3.BCr_FallAkten |Einbau eines technischen "Verfallsdatums" für FallAkten]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Geschäftsobjekte#Unterscheidung_von_.22Muss.22-_und_.22Kann.22-Informationen|Unterscheidung von "Muss"- und "Kann"-Informationen ]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Konkretere_Empfehlungen_zur_Archivierung_von_Fallakten|Konkretere Empfehlungen zur Archivierung von Fallakten]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Konkretere_Darstellung_der_Kodierung_der_G.C3.BCltigkeitsdauer_einer_Akte|Konkretere Darstellung der Kodierung der Gültigkeitsdauer einer Akte]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Kommunikationsmuster#Konkreter_beschreiben.2C_wie_ein_Dokument_invalidiert_wird|Konkreter beschreiben, wie ein Dokument invalidiert wird]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Zustands.C3.BCbergang_.22verfallen.22_-.3E_.22archiviert.22_beschreiben|Zustandsübergang "verfallen" -> "archiviert" beschreiben]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Hinweis_auf_laufende_Arbeiten_zur_Einwilligungserkl.C3.A4rung_einf.C3.BCgen|Hinweis auf laufende Arbeiten zur Einwilligungserklärung einfügen]]
* 07.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Ausformulieren_des_Informationsmodells_einer_Einwilligung|Ausformulieren des Informationsmodells einer Einwilligung]]

=== Abgewiesene Change Requests ===
* 09.04.15: [[cdaefa:CP-009-00|CP-009-00: Profilierung von DocumentEntry.confidentialityCode]]

== Offene Punkte und ToDos ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.04}</tt>

=== ToDos aus der Kommentierung (Fraunhofer) ===

* [[cdaefa:EFA_Business_Informationsmodell|Informationsmodell]]: Übersichtsgrafik als UML-Klassenmodell
* [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|EFA Anwendungsdienste]]: Fehlercodes konsolidieren und auf einer Seite zusammenfassen
* [[cdaefa:Akteure_und_Rollen_der_EFA|Akteure und Rollen]]: Akteursdiagramm einfügen
* Darstellung des Zusammenhangs Interaktionsmuster-Kommunikationsmuster-SFM-Binding (zusätzliche Seite)

=== Diskussionsbedarfe - operativ (7er-Gruppe) ===

* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#issueAccessToken|issueAccessToken]]
* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#redeemAccessToken|redeemAccessToken]]
*Informationsmodell für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]
* Binding für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]

=== Diskussionbedarfe - strategisch (Lenkungsgruppe) ===

=== Abschnitte, die ggf. in das Cookbook verschoben werden können ===

* [[cdaefa:EFA_Business_Informationsmodell#Patient]]: Regel "Sender does it right"
* [[cdaefa:EFA_Business_Informationsmodell#purpose]]
* [[cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_createECR]]: "The application of security measures and the contents of the SOAP security header are specified normatively"
* [[cdaefa:EFA_XDS_ResourceManager#Security_Considerations]]
* [[cdaefa:EFA_Verwendete_Standards#Verwendete_Standards:_Sicherheit]]
* [[cdaefa:EFA_IHE_Setup_and_Flow_of_Control#EFA_Setup]]
* [[cdaefa:Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten#Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten]]
* [[cdaefa:Patienteneinwilligung_zur_EFA#Patienteneinwilligung_zur_EFA]]
* [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#HCP_Identity_Attributes]]: Values for attribute "Structural Role"

=== Externe Abhängigkeiten ===

* Aktuell existiert keine OID für die Nutzung der Telematik-ID als Identifizierungsmechansimus für Organisationen und Leistungserbringer. Eine solche OID wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Institution|Element ''AuthorInstitution'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Person|Element ''AuthorPerson'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_Profile|Subject-Identifizierung im EFA SAML Profil]]

* Ein Codesystem für die Klassifizierung von Fachbereichszugehörigkeiten eines Leistungserbringers muss festgelegt werden. Hier gibt es diverse KBV Schlüsseltabellen, die auf ihre Eignung zu prüfen sind. Diese Klassifizierung wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_National_Profile_and_Extensions|Subject-Attribut im EFA SAML Profil]]

cdaefa:CP-046-00

2016-11-02T07:49:35Z

Jcaumanns: Die Seite wurde neu angelegt: „= IHE ITI TF Revision 13: Änderungen am SOAP Header= {|class="wikitable" |- | Titel des Change Request || IHE ITI TF Revision 13: Änderungen am SOAP Header |…“

= IHE ITI TF Revision 13: Änderungen am SOAP Header=
{|class="wikitable"
|-
| Titel des Change Request || IHE ITI TF Revision 13: Änderungen am SOAP Header
|-
| Einreicher des Change Proposal || Jörg Caumanns
|-
| Datum der Einreichung des Change Proposal || 31.10.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Computational
|-
| Akteur / Klasse / Transaktion || Beispiele
|-
| Change Proposal ID || CP-046-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 31.10.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Ja; IHE ITI CP-914 als Trigger
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 31.10.16
|-
| Zugewiesener Bearbeiter || ''Ben Kraufmann''
|}
== Motivation für den Change Request==
IHE [ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2016/CPs/3_FinalText/from_Ballot_34/CP-ITI-914-04.doc ITI CP-914] motiviert eine Änderung des SoapAction Parameters im SOAP Header. Der CP ist Bestandteil der aktuellen Revision 13 des IHE ITI TF.

Es ist abzustimmen, ob und wann dieser CP in die EFA übernommen wird und insbesondere ob und wann dieser auch für Projectathons relevant ist.

== Vorschlag für den Umgang mit dem Change Request ==
Die EFAv2.0 Spezifikation sollte zumindest für 2016/17 auf IHE ITI TF Rev. 12 eingefroren bleiben. Der Änderungsantrag sollte daher zunächst zurückgestellt werden.

cdaefa:EFA Spezifikation v2.0

2016-11-02T07:46:31Z

Jcaumanns: /* Offene Change Requests */

[[Datei:Information_icon.svg|40px|left]]Gemeinsam mit dem bvitg und IHE Deutschland hat der EFA-Verein einen [http://wiki.hl7.de/index.php?title=Datei:EPPC-G_Draft_for_Comment_v04.pdf Spezifikationsvorschlag für eine elektronische Einwilligung] erstellt, der aktuell innerhalb des Interoperabilitätsforums zur öffentlichen Kommentierung freigegeben wurde. Nach Abschluss der Kommentierung werden die EFA-relevanten Bestandteile dieser Spezifikation als ''Supplement zur EFAv2.0-Spezifikation'' auf dieser Seite verlinkt.

[[Datei:Attention_icon.svg|40px|left]] Im Rahmen des europäischen IHE Connectathon 2016 in Bochum wird erstmalig auch ein "EFA Projectathon" stattfinden. Alle hierzu relevanten Informationen finden Sie auf der Seite "[[cdaefa:EFA Projectathon 2016|EFA Projectathon 2016]]".

{{DocumentPart}}



= Einleitung =
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.01}</tt>

Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - einer Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.

Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf einem Patienten zugeordnete, medizinische Daten. Ein Fall beginnt mit einer Erstdiagnose und integriert alle weiteren notwendigen Abrechnungs- und Behandlungsdaten. Ein Arzt betreut die Fallakte zusammen mit weiteren behandelnden Ärzten, die für die Inhalte und deren Vollständigkeit verantwortlich sind.

Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt dezentral in bestehenden Systemen verwaltet und können bei Bedarf zu einer integrierten, für alle behandelnden Ärzte einheitlichen Sicht auf den Patienten zusammengeführt werden. Daher kann die Fallakte sehr einfach in bestehende Netze integriert werden und erleichtert somit die Zusammenarbeit auf regionaler Ebene.

== Von EFA 1.2 zu EFA 2.0 ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.02}</tt>

Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der [http://www.fallakte.de/spezifikationen EFA Version 1.2] das erste öffentliche Major-Release der EFA-Spezifikation von den Trägern der EFA-Initiative freigegeben. Bereits Ende 2008 konnten drei namhafte Hersteller (Siemens, ISPro, iSoft) auf dem ersten EFA-Connectathon Produkte präsentieren, die die interoperablen Schnittstellen der EFA implementierten und so miteinander in einem Peer-to-Peer Netzwerk zusammengeschaltet werden konnten. In den folgenden Jahren wurden in verschiedenen Bundesländern EFA-Pilotprojekte gestartet und 2011 konnte am Städtischen Klinikum München das erste regionale EFA-Netzwerk in den Regelbetrieb überführt werden.

Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] und [http://www.p23r.de Prozessdatenbeschleuniger (P23R)] den State-of-the-Art auch mit geprägt hat) haben sich in dieser Zeit im Bereich der Fachschnittstellen von elektronischen Aktensystemen die meisten Hersteller mit ihren Produkten in Richtung des IHE-Profils XDS bewegt, das von der EFA Version 1.2 lediglich logisch aber nicht syntaktisch berücksichtigt wurde - wobei auch die Synchronizität des EFA-1.2-Informationsmodells zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt war.

Im März 2012 haben daher der [http://www.fallakte.de EFA-Verein] als Träger der EFA-Spezifikation und der [http://www.bvitg.de bvitg] als Vertreter der im ambulanten und stationären Sektor tätigen Hersteller von IT-Lösungen beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifikation zu erarbeiten. Diese Version soll
* auf den bewährten und in verschiedenen Gesundheitsnetzen erfolgreich erprobten Kernprinzipien und -konzepten der EFA v1.2 aufbauen,
* in Produkten der Industrie verfügbare Schnittstellenstandards aufgreifen und eine Abbildbarkeit des EFA-Informationsmodells auf das Aktenkonzept von IHE herstellen,
* durch Verzahnung mit dem [[IHE_DE_Cookbook|IHE-D Cookbook]] auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

== EFA 2.0 Spezifikation ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.03}</tt>

Die folgende Tabelle stellt die einzelnen Kapitel der EFA 2.0 Spezifikation im Strukturraster des [[HL7 Enterprise Conformance and Compliance Frameworks]] dar. Die Spezifikation liegt auch als kompiliertes Dokument vor:
* [[cdaefa:EFAv2_Single_Document|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (HTML)]],
* [[Media:EFAv2.0-freeze-131118.pdf|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (PDF)]].

<table border="1" cellspacing="0" cellpadding="5em" width="100%">
<tr bgcolor="lightgray" align="center">
<td width="10%" valign="top">EFA v2.0</td>
<td width="30%" valign="top">'''Enterprise Dimension''' '''''"Why"''''' '''''Policy'''''</td>
<td width="30%" valign="top">'''Information Dimension''' '''''"What"''''' '''''Content'''''</td>
<td width="30%" valign="top">'''Computational Dimension''' '''''"How"''''' '''''Behavior'''''</td>
</tr>

<tr bgcolor="orange" align="center">
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Die EFA als zweckgebundene Akte|Die EFA als zweckgebundene Akte]]

[[cdaefa:EFA Provider|Versorgungsdomänen]]

[[cdaefa:Die EFA als Gesundheitsdatendienst|Die EFA als Gesundheitsdatendienst]]

[[cdaefa:Peer-to-Peer-Vernetzung von EFA-Providern|Peer-to-Peer-Vernetzung von EFA-Providern]]

[[cdaefa:Akteure und Rollen der EFA|Akteure und Rollen]]

[[cdaefa:Prinzipien für Datenschutz und Datensicherheit|Prinzipien für Datenschutz und Datensicherheit]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Kontext, Akte, Ressource|Kontext, Akte, Ressource]]

[[cdaefa:Patienteneinwilligung zur EFA|Patienteneinwilligung zur EFA]]

[[cdaefa:EFA Geschäftsobjekte|EFA Geschäftsobjekte]]

*[[cdaefa:EFA Business Lebenszyklus|Lebenszyklus einer Fallakte]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Interaktionsmuster der EFA|Interaktionsmuster der EFA]]
*[[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
*[[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
*[[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
*[[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
*[[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte oder eine Partition]]
*[[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
*[[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
*[[cdaefa:CIM Invalidieren von Datenobjekten|Invalidieren von Datenobjekten]]
*[[cdaefa:CIM Anpassen des Teilnehmerkreises|Ändern der Einwilligung]]
*[[cdaefa:CIM_Autorisierung_eines_weiteren_Teilnehmers|Autorisierung eines weiteren Teilnehmers]]
*[[cdaefa:CIM_Zusammenführen_von_Fallakten|Zusammenführen von Fallakten]]
</td>
</tr>

<tr bgcolor="yellow" align="center">
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Sicherheitsanforderungen|EFA Sicherheitsanforderungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Business Informationsmodell|Informationsmodelle der EFA Geschäftsobjekte]]

[[cdaefa:EFA Security Informationsmodell|Informationsmodelle der EFA Sicherheitsobjekte]]

[[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Dienste|EFA Dienste]]

[[cdaefa:EFA Kommunikationsmuster|EFA Kommunikationsmuster]]

[[cdaefa:EFA Anwendungsdienste (logische Spezifikation)|EFA Anwendungsdienste (logische Spezifikation)]]

[[cdaefa:EFA Sicherheitsdienste (logische Spezifikation)|EFA Sicherheitsdienste (logische Spezifikation)]]
*[[cdaefa:EFA Context Manager SFM|EFA Context Manager SFM]]
*[[cdaefa:EFA Identity Provider SFM|EFA Identity Provider SFM]]
*[[cdaefa:EFA Policy Provider SFM|EFA Policy Provider SFM]]

[[cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten|Gruppierung von Anwendungs- und Sicherheitsdiensten]]
</td>
</tr>

<tr bgcolor="palegreen" align="center">
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Verwendete Standards|Verwendete Standards]]

[[cdaefa:EFA Used Namespaces|Namespaces]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Metadata Bindings|EFA Metadata Bindings]]
*[[cdaefa:EFA XDS Folder Metadata Binding|EFA XDS Folder Metadata Binding]]
*[[cdaefa:EFA XDS Document Metadata Binding|EFA XDS Document Metadata Binding]]

[[cdaefa:EFA Security Objects Bindings|EFA Security Objects Bindings]]
*[[cdaefa:EFA Identity Assertion SAML2 Binding|EFA Identity Assertion SAML2 Binding]]
*[[cdaefa:EFA Policy Assertion SAML2 Binding|EFA Policy Assertion SAML2 Binding]]

[[cdaefa:EFA Patient Consent Binding|EFA Patient Consent Binding]]

[[cdaefa:EFA Audit Trail Binding|EFA Audit Trail Binding]]

[[cdaefa:EFA Error Codes and Warning Codes|EFA Error Codes and Warning Codes]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA IHE Setup and Flow of Control|EFA IHE Setup and Flow of Control]]

[[cdaefa:EFA XDS/XDR Bindings|EFA XDS Bindings]]
*[[cdaefa:EFA XDS ResourceManager|EFA XDS Binding: ResourceManager]]
*[[cdaefa:EFA XDS DocumentRegistry|EFA XDS Binding: DocumentRegistry]]
*[[cdaefa:EFA XDS DocumentRepository|EFA XDS Binding: DocumentRepository]]

[[cdaefa:EFA Access Control System|EFA Access Control System]]
*[[cdaefa:EFA WS Trust Policy Provider|EFA WS-Trust Binding: PolicyProvider]]

[[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]]
</td>
</tr>
</table>

== Weiterführende Themen ==
In der EFA-Spezifikation wird an verschiedenen Stellen auf weiterführende Informationen oder Grundlagenpapiere verwiesen, die in der ECCF-Matrix nicht verzeichnet sind. Diese "Anhänge" zur EFAv2.0-Spezifikation sind hier verzeichnet.

=== Methodische Grundlagen ===

* [[HL7_Enterprise_Conformance_and_Compliance_Frameworks|HL7 SAIF ECCF]]: Kurze Einführung in das HL7 SAIF ''Enterprise Conformance and Compliance Framework'', das dem Aufbau dieser Spezifikation zugrunde liegt
* [[cdaefa:IHE_Access_Control_Domains | IHE Access Control Domains]]: Zusammenfassung des IHE White Paper "Access Control" mit Fokus auf in der EFAv2.0-Spezifikation genutzte Konzepte und Begrifflichkeiten

=== EFA Konformitätsnachweis ===

In Abstimmung zwischen dem Vorstand des EFA-Vereins und dem Fraunhofer FOKUS wird ein Verfahren zum Nachweis der Konformität von Produkten zu den EFA-Spezifikationen durchgeführt, das im Wesentlichen auf einer Selbsterklärung eines Herstellers beruht. EFAv2.0-konforme Produkte dürfen das EFA-Logo tragen und mit dem EFA-Logo auf Messen sowie in Print- und Online-Materialien beworben werden.
* [[cdaefa:Gegenstand der Konformitätsprüfung|Gegenstand der Konformitätsprüfung]]

Die Ausstellung dieses EFAv2.0-Konformitätsnachweises ist für Hersteller kostenlos und wird wie bisher durch das Fraunhofer FOKUS durchgeführt. Das Fraunhofer FOKUS ist zur Durchführung des Verfahrens und zur Vergabe des EFA-Logos vom EFA-Verein akkreditiert.
* [[cdaefa:Durchführung der Konformitätsprüfung|Durchführung der Konformitätsprüfung]]

Hersteller können alle zur Durchführung des Verfahrens erforderlichen Unterlagen per Mail beim Fraunhofer FOKUS ([mailto:joerg.caumanns@fokus.fraunhofer.de joerg.caumanns@fokus.fraunhofer.de]) anfordern.

'''Hinweis''': Das hier beschriebene Verfahren und die ausgestellten Konformitätsnachweise sind bis Ende 2014 gültig. Ab 2015 soll ein erweitertes Verfahren zum Tragen kommen, dass auf der erfolgreichen Teilnahme von Produkten an einem IHE Connectathon aufsetzt.

== Change Requests ==
Mit der Finalisierung der EFA-Spezifikation im Herbst 2013 haben verschiedene Hersteller (und auch FuE-Projekte) begonnen, die EFAv2.0 zu implementieren. Trotz aller Sorgfalt bei der Erstellung der Spezifikationen fallen hierbei zuweilen kleinere Fehler auf und an manchen Stellen sind fachliche oder technische Festlegungen nur schwer nachvollziehbar, da die entsprechenden Beweggründe der Autorengruppe von Fraunhofer FOKUS, EFA-Verein und bvitg nicht ausreichend dokumentiert wurden.

Um die Spezifikationen kontinuierlich zu verbessern und insbesondere auch Hersteller und Projekte bestmöglich bei der Implementierung zu unterstützen, nehmen wir Fragen und Anregungen weiterhin gerne entgegen. Hierzu wurde für die EFAv2.0 ein regulärer [[EFA Change- und Releasemanagement|Change- und Releasemanagement-Prozess]] definiert, der ab Juli 2015 schrittweise operationalisiert wird.

Alle nach den vorgaben des definierten Prozesses eingereichten Änderungsanforderungen an die EFAv2.0-Spezifikation werden auf dieser Seite aufgelistet und durch Fraunhofer FOKUS, EFA-Verein und bvitg bearbeitet. Der Status der Bearbeitung sowie Entscheidungen zur Annahme bzw. Ablehnung eines Changes Requests werden auf der zu jedem Change Request angelegten Wiki-Seite dokumentiert.

'''Hinweis''': Alle Änderungsbedarfe an der EFAv2.0-Spezifikation, die sich aus angenommenen IHE ITI Change Proposals ergeben können, sind in der nachfolgenden Liste offener Change Requests bis einschließlich Ballot-35 (Juli 2016, finaler Ballot für IHE ITI-TF Revision 13) berücksichtigt.

=== Offene Change Requests ===
* 31.10.16: [[cdaefa:CP-046-00|CP-046-00: IHE ITI TF Revision 13: Änderungen am SOAP Header]]
* 30.10.16: [[cdaefa:CP-045-00|CP-045-00: Differenzierung von Fehlermeldungen beim Ersetzen von Dokumenten]]
* 30.10.16: [[cdaefa:CP-044-00|CP-044-00: Integration administrativer Fallnummern]]
* 30.10.16: [[cdaefa:CP-043-00|CP-043-00: Mehrsprachige Display-Names für Dokumentenmetadaten]]
* 30.10.16: [[cdaefa:CP-042-00|CP-042-00: Klarstellungen zu partiellen Fehlern bei ProvideAndRegisterDocument]]
* 07.04.16: [[cdaefa:CP-020-00|CP-020-00: Systemverhalten bei Berechtigungsfehlern]]
* 07.04.16: [[cdaefa:CP-019-00|CP-019-00: Klassifizierung von Mount-Points]]
* 09.04.15: [[cdaefa:CP-005-00|CP-005-00: Falsche Zuordnung der Signatur (Metadaten statt Dokument)]]
* 09.04.15: [[cdaefa:CP-007-00|CP-007-00: Inkonsistenz in der Darstellung der Dokumenten-Metadaten]]
* 09.04.15: [[cdaefa:CP-008-00|CP-008-00: Fehlende Profilierung der Dokumentensignatur]]
* 09.04.15: [[cdaefa:CP-010-00|CP-010-00: Audit Trail Einträge für EFAv2.0-Sicherheitsdienste]]
* 09.04.15: [[cdaefa:CP-011-00|CP-011-00: SecureRetrieve für EFAv2.0]]

=== In die Revision 2 (EFA-Projectathon 2016) aufgenommene Änderungen ===
* 07.04.16: [[cdaefa:CP-018-00|CP-018-00: Übernahme von Codes der deutschen Value-Set-Gruppe]]
* 02.11.15: [[cdaefa:CP-012-00|CP-012-00: Fehlerhafte Kodierung von IDs in einem Beispiel]]
* 02.11.15: [[cdaefa:CP-013-00|CP-013-00: Groß-/Kleinschreibung bei Query-Parametern]]
* 12.02.16: [[cdaefa:CP-001-00|CP-001-00: Missverständliche Spezifikation der Klasse subjectIdentity]]
* 12.02.16: [[cdaefa:CP-003-00|CP-003-00: Zulässigkeit weiterer Zweckcodes]]
* 12.02.16: [[cdaefa:CP-006-00|CP-006-00: Unvollständiges Binding der Dokumenten-Metadaten]]
* 12.02.16: [[cdaefa:CP-014-00|CP-014-00: Fehler in der OID-Nutzung für SMC-B]]
* 14.02.16: [[cdaefa:CP-015-00|CP-015-00: Fehlende Vorgabe für „HP Speciality“]]
* 14.02.16: [[cdaefa:CP-017-00|CP-017-00: EFA Identity Assertion SAML2 Binding]]
* 14.02.16: [[cdaefa:CP-016-00|CP-016-00: Nutzung von XDS-Optionen explizieren]]
* 16.02.16: [[cdaefa:CP-004-00|CP-004-00: Invalidieren von Dokumenten (Inkonsistenz zum IHE-Cookbook)]]
* 16.02.16: [[cdaefa:CP-002-00|CP-002-00: Unvollständige Spezifikation der Klasse consentInfo]]

=== In die Revision 1 (Januar 2015) aufgenommene Änderungen ===
* 01.10.14: [[cdaefa_Diskussion:EFA_Dienste|Deployment-Optionen für das XDS DocumentRegistry]]
* 27.04.14: [[cdaefa_Diskussion:EFA_Identity_Assertion_SAML2_Binding#Change_Requests|Kodierung von Rollen (HCP Identity Assertion)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests |Zulässigkeit weiterer Verwendungszwecke (logisch)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests|Grundlage einer consentInfo]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Change_Requests|Vorzeitiges Schließen einer Fallakte]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Einbau_eines_technischen_.22Verfallsdatums.22_f.C3.BCr_FallAkten |Einbau eines technischen "Verfallsdatums" für FallAkten]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Geschäftsobjekte#Unterscheidung_von_.22Muss.22-_und_.22Kann.22-Informationen|Unterscheidung von "Muss"- und "Kann"-Informationen ]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Konkretere_Empfehlungen_zur_Archivierung_von_Fallakten|Konkretere Empfehlungen zur Archivierung von Fallakten]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Konkretere_Darstellung_der_Kodierung_der_G.C3.BCltigkeitsdauer_einer_Akte|Konkretere Darstellung der Kodierung der Gültigkeitsdauer einer Akte]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Kommunikationsmuster#Konkreter_beschreiben.2C_wie_ein_Dokument_invalidiert_wird|Konkreter beschreiben, wie ein Dokument invalidiert wird]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Zustands.C3.BCbergang_.22verfallen.22_-.3E_.22archiviert.22_beschreiben|Zustandsübergang "verfallen" -> "archiviert" beschreiben]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Hinweis_auf_laufende_Arbeiten_zur_Einwilligungserkl.C3.A4rung_einf.C3.BCgen|Hinweis auf laufende Arbeiten zur Einwilligungserklärung einfügen]]
* 07.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Ausformulieren_des_Informationsmodells_einer_Einwilligung|Ausformulieren des Informationsmodells einer Einwilligung]]

=== Abgewiesene Change Requests ===
* 09.04.15: [[cdaefa:CP-009-00|CP-009-00: Profilierung von DocumentEntry.confidentialityCode]]

== Offene Punkte und ToDos ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.04}</tt>

=== ToDos aus der Kommentierung (Fraunhofer) ===

* [[cdaefa:EFA_Business_Informationsmodell|Informationsmodell]]: Übersichtsgrafik als UML-Klassenmodell
* [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|EFA Anwendungsdienste]]: Fehlercodes konsolidieren und auf einer Seite zusammenfassen
* [[cdaefa:Akteure_und_Rollen_der_EFA|Akteure und Rollen]]: Akteursdiagramm einfügen
* Darstellung des Zusammenhangs Interaktionsmuster-Kommunikationsmuster-SFM-Binding (zusätzliche Seite)

=== Diskussionsbedarfe - operativ (7er-Gruppe) ===

* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#issueAccessToken|issueAccessToken]]
* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#redeemAccessToken|redeemAccessToken]]
*Informationsmodell für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]
* Binding für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]

=== Diskussionbedarfe - strategisch (Lenkungsgruppe) ===

=== Abschnitte, die ggf. in das Cookbook verschoben werden können ===

* [[cdaefa:EFA_Business_Informationsmodell#Patient]]: Regel "Sender does it right"
* [[cdaefa:EFA_Business_Informationsmodell#purpose]]
* [[cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_createECR]]: "The application of security measures and the contents of the SOAP security header are specified normatively"
* [[cdaefa:EFA_XDS_ResourceManager#Security_Considerations]]
* [[cdaefa:EFA_Verwendete_Standards#Verwendete_Standards:_Sicherheit]]
* [[cdaefa:EFA_IHE_Setup_and_Flow_of_Control#EFA_Setup]]
* [[cdaefa:Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten#Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten]]
* [[cdaefa:Patienteneinwilligung_zur_EFA#Patienteneinwilligung_zur_EFA]]
* [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#HCP_Identity_Attributes]]: Values for attribute "Structural Role"

=== Externe Abhängigkeiten ===

* Aktuell existiert keine OID für die Nutzung der Telematik-ID als Identifizierungsmechansimus für Organisationen und Leistungserbringer. Eine solche OID wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Institution|Element ''AuthorInstitution'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Person|Element ''AuthorPerson'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_Profile|Subject-Identifizierung im EFA SAML Profil]]

* Ein Codesystem für die Klassifizierung von Fachbereichszugehörigkeiten eines Leistungserbringers muss festgelegt werden. Hier gibt es diverse KBV Schlüsseltabellen, die auf ihre Eignung zu prüfen sind. Diese Klassifizierung wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_National_Profile_and_Extensions|Subject-Attribut im EFA SAML Profil]]

cdaefa:CP-045-00

2016-10-30T20:25:29Z

Jcaumanns: Die Seite wurde neu angelegt: „= Differenzierung von Fehlermeldungen beim Ersetzen von Dokumenten= {|class="wikitable" |- | Titel des Change Request || Differenzierung von Fehlermeldungen be…“

= Differenzierung von Fehlermeldungen beim Ersetzen von Dokumenten=
{|class="wikitable"
|-
| Titel des Change Request || Differenzierung von Fehlermeldungen beim Ersetzen von Dokumenten
|-
| Einreicher des Change Proposal || Jörg Caumanns
|-
| Datum der Einreichung des Change Proposal || 30.10.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Computational
|-
| Akteur / Klasse / Transaktion || ProvideDocument Binding
|-
| Change Proposal ID || CP-045-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 30.10.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Ja; IHE ITI CP-889 als Trigger
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 30.10.16
|-
| Zugewiesener Bearbeiter || ''-''
|}
== Motivation für den Change Request==
IHE ITI CP-889 differenziert die Fehlermeldungen, die bei einem gescheiterten Ersetzen eines Dokuments zurückzugeben sind.

Es wird vorgeschlagen, diese Differenzierungen auch für die EFAv2 zu übernehmen und EFA-spezifische Fehlermeldungen analog auszudifferenzieren.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRepository#EFA_XDS_Binding:_provideData http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRepository#EFA_XDS_Binding:_provideData]''

TEXT TEXT

cdaefa:CP-044-00

2016-10-30T20:24:04Z

Jcaumanns: Die Seite wurde neu angelegt: „= Integration administrativer Fallnummern= {|class="wikitable" |- | Titel des Change Request || Integration administrativer Fallnummern |- | Einreicher des Cha…“

= Integration administrativer Fallnummern=
{|class="wikitable"
|-
| Titel des Change Request || Integration administrativer Fallnummern
|-
| Einreicher des Change Proposal || Jörg Caumanns
|-
| Datum der Einreichung des Change Proposal || 30.10.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || EFA XDS Metadata Binding
|-
| Change Proposal ID || CP-044-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 30.10.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Ja; IHE ITI CP-903 als Trigger
|-
| Abhängigkeit zum IHE-D Cookbook || Ja
|-
| Auswirkungen auf bestehende Implementierungen || Ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 30.10.16
|-
| Zugewiesener Bearbeiter || ''-''
|}
== Motivation für den Change Request==
IHE ITI CP-903 führt aus:

''The use case behind adding the encounter ID as an referenceIdList CXi.5 Identifier Type Code is to enable a simpler transformation of HL7v2 MDM messages to XDS P&R. The previous alternative we proposed in implementation projects was to use XdsFolders with the XdsFolder.uniqueId set to the encounter ID. We didn't find any clients willing to implement this, because of the overhead associated with XdsFolders. A XdsFolder needs to be created on the first document registration that references the encounter and needs to be updated using the entryUUID for every subsequent document.''

''In practice, this means an adapter taking HL7v2 MDM input needs to''
# ''receive the MDM and parse the encounter ID''
# ''query the registry using FindFolders with the encounter ID as the XdsFolder.uniqueId''
# ''(if there is more than one) pick the right folder and register the document with an association to the folder's entryUUID''
# ''(if there are none) create a new folder and register the document with an association to a new folder''

''In comparison, using the referenceIdList is as simple as''
# ''receive the MDM and parse the encounter ID''
# ''register the document with a referenceIdList value referencing the encounter ID''

''This greatly helps establishing an XDS exchange in a HL7v2 MDM legacy environment.''

Dies gilt auch für EFA-Umsetzungen, in denen ein Krankenhaus (auch) die Rolle des EFA-Clients einnimmt. Es ist zu diskutieren, ob die Vorgabe aus dem Change Proposal für die EFA übernommen wird und welche Auswirkungen dies potenziell auf die Nutzung von Ordnern als alleiniges Merkmal der Zuordnung von Dokumenten zu einer FallAkte hat.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_Document_Metadata_Binding http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_Document_Metadata_Binding]''

TEXT TEXT

cdaefa:CP-043-00

2016-10-30T20:20:25Z

Jcaumanns: Die Seite wurde neu angelegt: „= Mehrsprachige Display-Names für Dokumentenmetadaten= {|class="wikitable" |- | Titel des Change Request || Mehrsprachige Display-Names für Dokumentenmetadat…“

= Mehrsprachige Display-Names für Dokumentenmetadaten=
{|class="wikitable"
|-
| Titel des Change Request || Mehrsprachige Display-Names für Dokumentenmetadaten
|-
| Einreicher des Change Proposal || Jörg Caumanns
|-
| Datum der Einreichung des Change Proposal || 30.10.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Information
|-
| Akteur / Klasse / Transaktion || EFA XDS Metadata Binding
|-
| Change Proposal ID || CP-043-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 30.10.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Ja; IHE ITI CP-814 als Trigger
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Ja
|-
| Datum der letzten Aktualisierung des Change Proposal || 30.10.16
|-
| Zugewiesener Bearbeiter || ''-''
|}
== Motivation für den Change Request==
Der in der aktuellen Version des IHE ITI TF umgestezte IHE ITI CP-814 weicht die bestehenden Regeln zur Nutzung und Validierung der Display-Names von Dokumentenmetadaten auf:

# Es ist zulässig, mehrere Display Names (z. B. in verschiedenen Sprachen) als Teil des Metadatensatzes anzugeben.
# Der Ersteller der Metadaten legt fest, welchen Display Name er für einen kodierten Wert verwedet. . Eine Implementierung kann alle oder eine Untermenge der in der Affinity Domain definierten Display Names nutzen oder auch eigene Display Names verwenden. Der Empfänger der Metadaten interpretiert nur den Code des kodierten Werts. Er kann den angegebenen Display Name übernehmen oder zur Anzeige der Metadaten auch eigene Display Names nutzen.
# Eine Validierung von in Dokumentenmetadaten enthaltenen Display Names gegen die in der Affinity Domain definierten Display Names findet nicht statt.

Diese Regelungen betreffen die folgenden Dokumentenmetadaten:

* classCode
* confidentialityCode
* eventCodeList
* formatCode
* healthcareFacilityTypeCode
* practiceSettingCode
* typeCode

Auf Basis dieser Änderung des IHE ITI-TF werden die folgenden Änderungen an der EFAv2 Spezifikation vorgeschlagen:

* in Bezug auf die Kodierung der benannten Metadaten wird weiterhin auf die Definitionen von IHE Deutschland verwiesen. Es wird jedoch klargestellt, dass die dort definierten Display Names lediglich für EFA-Umsetzungen im deutschen Sprachraum verbindloch sind. Internationale EFA-Lösungen können/sollten eigene (z. B. englischsprachige) Display Names verwenden.

* Für die von der EFA genutzten Codes aus den Vorgaben von IHE-D werden Empfehlungen für englischprachige Display Names definiert. Dies erfolgt in Abstimmung mit der Arbeitsgruppe, die die IHE XD* Value Sets definiert hat.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_Document_Metadata_Binding http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_Document_Metadata_Binding]''

TEXT TEXT

cdaefa:CP-042-00

2016-10-30T20:17:33Z

Jcaumanns: Die Seite wurde neu angelegt: „= Klarstellungen zu partiellen Fehlern bei ProvideAndRegisterDocument= {|class="wikitable" |- | Titel des Change Request || Klarstellungen zu partiellen Fehler…“

= Klarstellungen zu partiellen Fehlern bei ProvideAndRegisterDocument=
{|class="wikitable"
|-
| Titel des Change Request || Klarstellungen zu partiellen Fehlern bei ProvideAndRegisterDocument
|-
| Einreicher des Change Proposal || Jörg Caumanns
|-
| Datum der Einreichung des Change Proposal || 28.10.16
|-
| Betroffene Revision der EFA-Spezifikation || 2 (Release Januar 2016)
|-
| EFAv2.0 Wiki Perspective || Implementable
|-
| EFAv2.0 Wiki Dimension || Computational
|-
| Akteur / Klasse / Transaktion || EFA XDS Binding: provideData
|-
| Change Proposal ID || CP-042-00
|-
| Datum der Veröffentlichung im EFAv2.0 Wiki || 28.10.16
|-
| Change Proposal Status || Eingereicht
|-
| Abhängigkeit zum IHE Technical Framework || Ja; IHE ITI CP-870 als Trigger
|-
| Abhängigkeit zum IHE-D Cookbook || Nein
|-
| Auswirkungen auf bestehende Implementierungen || Nein
|-
| Datum der letzten Aktualisierung des Change Proposal || 28.10.16
|-
| Zugewiesener Bearbeiter || ''-''
|}
== Motivation für den Change Request==
Die EFAv2 Spezifikation ist sehr vage, wie sich ein Provider verhalten soll, wenn von einem Paket einzustellender Dokumente einzelne Dokumente einen Fehler (entweder am Repository oder Registry) auslösen. Grundsätzlich ist es aber zulässig, nur die fehlerhaften Dokumente zurückzuweisen und die anderen Dokumente des Pakets zu registrieren. IHE ITI CP-870 lässt dieses Verhalten auch für die zugrunde liegende IHE Transaktion ProvideAndRegisterDocument zu und definiert konkrete Vorgaben zum Systemverhalten.

Für die EFA-Spezifikation sollte das in CP-870 definierte Verhalten mitsamt der dort vorgegebenen Fehlermeldungen übernommen werden. Um ggf. bestehende Unklarheiten zu beseitigen, sollten in der Spezifikation die gewählten Formulierungen an CP-870 angeglichen werden.

== Vorschlag für die Änderung der EFAv2.0-Spezifikation==
''[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRepository#EFA_XDS_Binding:_provideData http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRepository#EFA_XDS_Binding:_provideData]''

TEXT TEXT

cdaefa:EFA Spezifikation v2.0

2016-10-30T14:46:33Z

Jcaumanns: /* Change Requests */

[[Datei:Information_icon.svg|40px|left]]Gemeinsam mit dem bvitg und IHE Deutschland hat der EFA-Verein einen [http://wiki.hl7.de/index.php?title=Datei:EPPC-G_Draft_for_Comment_v04.pdf Spezifikationsvorschlag für eine elektronische Einwilligung] erstellt, der aktuell innerhalb des Interoperabilitätsforums zur öffentlichen Kommentierung freigegeben wurde. Nach Abschluss der Kommentierung werden die EFA-relevanten Bestandteile dieser Spezifikation als ''Supplement zur EFAv2.0-Spezifikation'' auf dieser Seite verlinkt.

[[Datei:Attention_icon.svg|40px|left]] Im Rahmen des europäischen IHE Connectathon 2016 in Bochum wird erstmalig auch ein "EFA Projectathon" stattfinden. Alle hierzu relevanten Informationen finden Sie auf der Seite "[[cdaefa:EFA Projectathon 2016|EFA Projectathon 2016]]".

{{DocumentPart}}



= Einleitung =
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.01}</tt>

Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - einer Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.

Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf einem Patienten zugeordnete, medizinische Daten. Ein Fall beginnt mit einer Erstdiagnose und integriert alle weiteren notwendigen Abrechnungs- und Behandlungsdaten. Ein Arzt betreut die Fallakte zusammen mit weiteren behandelnden Ärzten, die für die Inhalte und deren Vollständigkeit verantwortlich sind.

Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt dezentral in bestehenden Systemen verwaltet und können bei Bedarf zu einer integrierten, für alle behandelnden Ärzte einheitlichen Sicht auf den Patienten zusammengeführt werden. Daher kann die Fallakte sehr einfach in bestehende Netze integriert werden und erleichtert somit die Zusammenarbeit auf regionaler Ebene.

== Von EFA 1.2 zu EFA 2.0 ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.02}</tt>

Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der [http://www.fallakte.de/spezifikationen EFA Version 1.2] das erste öffentliche Major-Release der EFA-Spezifikation von den Trägern der EFA-Initiative freigegeben. Bereits Ende 2008 konnten drei namhafte Hersteller (Siemens, ISPro, iSoft) auf dem ersten EFA-Connectathon Produkte präsentieren, die die interoperablen Schnittstellen der EFA implementierten und so miteinander in einem Peer-to-Peer Netzwerk zusammengeschaltet werden konnten. In den folgenden Jahren wurden in verschiedenen Bundesländern EFA-Pilotprojekte gestartet und 2011 konnte am Städtischen Klinikum München das erste regionale EFA-Netzwerk in den Regelbetrieb überführt werden.

Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] und [http://www.p23r.de Prozessdatenbeschleuniger (P23R)] den State-of-the-Art auch mit geprägt hat) haben sich in dieser Zeit im Bereich der Fachschnittstellen von elektronischen Aktensystemen die meisten Hersteller mit ihren Produkten in Richtung des IHE-Profils XDS bewegt, das von der EFA Version 1.2 lediglich logisch aber nicht syntaktisch berücksichtigt wurde - wobei auch die Synchronizität des EFA-1.2-Informationsmodells zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt war.

Im März 2012 haben daher der [http://www.fallakte.de EFA-Verein] als Träger der EFA-Spezifikation und der [http://www.bvitg.de bvitg] als Vertreter der im ambulanten und stationären Sektor tätigen Hersteller von IT-Lösungen beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifikation zu erarbeiten. Diese Version soll
* auf den bewährten und in verschiedenen Gesundheitsnetzen erfolgreich erprobten Kernprinzipien und -konzepten der EFA v1.2 aufbauen,
* in Produkten der Industrie verfügbare Schnittstellenstandards aufgreifen und eine Abbildbarkeit des EFA-Informationsmodells auf das Aktenkonzept von IHE herstellen,
* durch Verzahnung mit dem [[IHE_DE_Cookbook|IHE-D Cookbook]] auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

== EFA 2.0 Spezifikation ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.03}</tt>

Die folgende Tabelle stellt die einzelnen Kapitel der EFA 2.0 Spezifikation im Strukturraster des [[HL7 Enterprise Conformance and Compliance Frameworks]] dar. Die Spezifikation liegt auch als kompiliertes Dokument vor:
* [[cdaefa:EFAv2_Single_Document|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (HTML)]],
* [[Media:EFAv2.0-freeze-131118.pdf|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (PDF)]].

<table border="1" cellspacing="0" cellpadding="5em" width="100%">
<tr bgcolor="lightgray" align="center">
<td width="10%" valign="top">EFA v2.0</td>
<td width="30%" valign="top">'''Enterprise Dimension''' '''''"Why"''''' '''''Policy'''''</td>
<td width="30%" valign="top">'''Information Dimension''' '''''"What"''''' '''''Content'''''</td>
<td width="30%" valign="top">'''Computational Dimension''' '''''"How"''''' '''''Behavior'''''</td>
</tr>

<tr bgcolor="orange" align="center">
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Die EFA als zweckgebundene Akte|Die EFA als zweckgebundene Akte]]

[[cdaefa:EFA Provider|Versorgungsdomänen]]

[[cdaefa:Die EFA als Gesundheitsdatendienst|Die EFA als Gesundheitsdatendienst]]

[[cdaefa:Peer-to-Peer-Vernetzung von EFA-Providern|Peer-to-Peer-Vernetzung von EFA-Providern]]

[[cdaefa:Akteure und Rollen der EFA|Akteure und Rollen]]

[[cdaefa:Prinzipien für Datenschutz und Datensicherheit|Prinzipien für Datenschutz und Datensicherheit]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Kontext, Akte, Ressource|Kontext, Akte, Ressource]]

[[cdaefa:Patienteneinwilligung zur EFA|Patienteneinwilligung zur EFA]]

[[cdaefa:EFA Geschäftsobjekte|EFA Geschäftsobjekte]]

*[[cdaefa:EFA Business Lebenszyklus|Lebenszyklus einer Fallakte]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Interaktionsmuster der EFA|Interaktionsmuster der EFA]]
*[[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
*[[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
*[[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
*[[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
*[[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte oder eine Partition]]
*[[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
*[[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
*[[cdaefa:CIM Invalidieren von Datenobjekten|Invalidieren von Datenobjekten]]
*[[cdaefa:CIM Anpassen des Teilnehmerkreises|Ändern der Einwilligung]]
*[[cdaefa:CIM_Autorisierung_eines_weiteren_Teilnehmers|Autorisierung eines weiteren Teilnehmers]]
*[[cdaefa:CIM_Zusammenführen_von_Fallakten|Zusammenführen von Fallakten]]
</td>
</tr>

<tr bgcolor="yellow" align="center">
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Sicherheitsanforderungen|EFA Sicherheitsanforderungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Business Informationsmodell|Informationsmodelle der EFA Geschäftsobjekte]]

[[cdaefa:EFA Security Informationsmodell|Informationsmodelle der EFA Sicherheitsobjekte]]

[[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Dienste|EFA Dienste]]

[[cdaefa:EFA Kommunikationsmuster|EFA Kommunikationsmuster]]

[[cdaefa:EFA Anwendungsdienste (logische Spezifikation)|EFA Anwendungsdienste (logische Spezifikation)]]

[[cdaefa:EFA Sicherheitsdienste (logische Spezifikation)|EFA Sicherheitsdienste (logische Spezifikation)]]
*[[cdaefa:EFA Context Manager SFM|EFA Context Manager SFM]]
*[[cdaefa:EFA Identity Provider SFM|EFA Identity Provider SFM]]
*[[cdaefa:EFA Policy Provider SFM|EFA Policy Provider SFM]]

[[cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten|Gruppierung von Anwendungs- und Sicherheitsdiensten]]
</td>
</tr>

<tr bgcolor="palegreen" align="center">
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Verwendete Standards|Verwendete Standards]]

[[cdaefa:EFA Used Namespaces|Namespaces]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Metadata Bindings|EFA Metadata Bindings]]
*[[cdaefa:EFA XDS Folder Metadata Binding|EFA XDS Folder Metadata Binding]]
*[[cdaefa:EFA XDS Document Metadata Binding|EFA XDS Document Metadata Binding]]

[[cdaefa:EFA Security Objects Bindings|EFA Security Objects Bindings]]
*[[cdaefa:EFA Identity Assertion SAML2 Binding|EFA Identity Assertion SAML2 Binding]]
*[[cdaefa:EFA Policy Assertion SAML2 Binding|EFA Policy Assertion SAML2 Binding]]

[[cdaefa:EFA Patient Consent Binding|EFA Patient Consent Binding]]

[[cdaefa:EFA Audit Trail Binding|EFA Audit Trail Binding]]

[[cdaefa:EFA Error Codes and Warning Codes|EFA Error Codes and Warning Codes]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA IHE Setup and Flow of Control|EFA IHE Setup and Flow of Control]]

[[cdaefa:EFA XDS/XDR Bindings|EFA XDS Bindings]]
*[[cdaefa:EFA XDS ResourceManager|EFA XDS Binding: ResourceManager]]
*[[cdaefa:EFA XDS DocumentRegistry|EFA XDS Binding: DocumentRegistry]]
*[[cdaefa:EFA XDS DocumentRepository|EFA XDS Binding: DocumentRepository]]

[[cdaefa:EFA Access Control System|EFA Access Control System]]
*[[cdaefa:EFA WS Trust Policy Provider|EFA WS-Trust Binding: PolicyProvider]]

[[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]]
</td>
</tr>
</table>

== Weiterführende Themen ==
In der EFA-Spezifikation wird an verschiedenen Stellen auf weiterführende Informationen oder Grundlagenpapiere verwiesen, die in der ECCF-Matrix nicht verzeichnet sind. Diese "Anhänge" zur EFAv2.0-Spezifikation sind hier verzeichnet.

=== Methodische Grundlagen ===

* [[HL7_Enterprise_Conformance_and_Compliance_Frameworks|HL7 SAIF ECCF]]: Kurze Einführung in das HL7 SAIF ''Enterprise Conformance and Compliance Framework'', das dem Aufbau dieser Spezifikation zugrunde liegt
* [[cdaefa:IHE_Access_Control_Domains | IHE Access Control Domains]]: Zusammenfassung des IHE White Paper "Access Control" mit Fokus auf in der EFAv2.0-Spezifikation genutzte Konzepte und Begrifflichkeiten

=== EFA Konformitätsnachweis ===

In Abstimmung zwischen dem Vorstand des EFA-Vereins und dem Fraunhofer FOKUS wird ein Verfahren zum Nachweis der Konformität von Produkten zu den EFA-Spezifikationen durchgeführt, das im Wesentlichen auf einer Selbsterklärung eines Herstellers beruht. EFAv2.0-konforme Produkte dürfen das EFA-Logo tragen und mit dem EFA-Logo auf Messen sowie in Print- und Online-Materialien beworben werden.
* [[cdaefa:Gegenstand der Konformitätsprüfung|Gegenstand der Konformitätsprüfung]]

Die Ausstellung dieses EFAv2.0-Konformitätsnachweises ist für Hersteller kostenlos und wird wie bisher durch das Fraunhofer FOKUS durchgeführt. Das Fraunhofer FOKUS ist zur Durchführung des Verfahrens und zur Vergabe des EFA-Logos vom EFA-Verein akkreditiert.
* [[cdaefa:Durchführung der Konformitätsprüfung|Durchführung der Konformitätsprüfung]]

Hersteller können alle zur Durchführung des Verfahrens erforderlichen Unterlagen per Mail beim Fraunhofer FOKUS ([mailto:joerg.caumanns@fokus.fraunhofer.de joerg.caumanns@fokus.fraunhofer.de]) anfordern.

'''Hinweis''': Das hier beschriebene Verfahren und die ausgestellten Konformitätsnachweise sind bis Ende 2014 gültig. Ab 2015 soll ein erweitertes Verfahren zum Tragen kommen, dass auf der erfolgreichen Teilnahme von Produkten an einem IHE Connectathon aufsetzt.

== Change Requests ==
Mit der Finalisierung der EFA-Spezifikation im Herbst 2013 haben verschiedene Hersteller (und auch FuE-Projekte) begonnen, die EFAv2.0 zu implementieren. Trotz aller Sorgfalt bei der Erstellung der Spezifikationen fallen hierbei zuweilen kleinere Fehler auf und an manchen Stellen sind fachliche oder technische Festlegungen nur schwer nachvollziehbar, da die entsprechenden Beweggründe der Autorengruppe von Fraunhofer FOKUS, EFA-Verein und bvitg nicht ausreichend dokumentiert wurden.

Um die Spezifikationen kontinuierlich zu verbessern und insbesondere auch Hersteller und Projekte bestmöglich bei der Implementierung zu unterstützen, nehmen wir Fragen und Anregungen weiterhin gerne entgegen. Hierzu wurde für die EFAv2.0 ein regulärer [[EFA Change- und Releasemanagement|Change- und Releasemanagement-Prozess]] definiert, der ab Juli 2015 schrittweise operationalisiert wird.

Alle nach den vorgaben des definierten Prozesses eingereichten Änderungsanforderungen an die EFAv2.0-Spezifikation werden auf dieser Seite aufgelistet und durch Fraunhofer FOKUS, EFA-Verein und bvitg bearbeitet. Der Status der Bearbeitung sowie Entscheidungen zur Annahme bzw. Ablehnung eines Changes Requests werden auf der zu jedem Change Request angelegten Wiki-Seite dokumentiert.

'''Hinweis''': Alle Änderungsbedarfe an der EFAv2.0-Spezifikation, die sich aus angenommenen IHE ITI Change Proposals ergeben können, sind in der nachfolgenden Liste offener Change Requests bis einschließlich Ballot-35 (Juli 2016, finaler Ballot für IHE ITI-TF Revision 13) berücksichtigt.

=== Offene Change Requests ===
* 30.10.16: [[cdaefa:CP-045-00|CP-045-00: Differenzierung von Fehlermeldungen beim Ersetzen von Dokumenten]]
* 30.10.16: [[cdaefa:CP-044-00|CP-044-00: Integration administrativer Fallnummern]]
* 30.10.16: [[cdaefa:CP-043-00|CP-043-00: Mehrsprachige Display-Names für Dokumentenmetadaten]]
* 30.10.16: [[cdaefa:CP-042-00|CP-042-00: Klarstellungen zu partiellen Fehlern bei ProvideAndRegisterDocument]]
* 07.04.16: [[cdaefa:CP-020-00|CP-020-00: Systemverhalten bei Berechtigungsfehlern]]
* 07.04.16: [[cdaefa:CP-019-00|CP-019-00: Klassifizierung von Mount-Points]]
* 09.04.15: [[cdaefa:CP-005-00|CP-005-00: Falsche Zuordnung der Signatur (Metadaten statt Dokument)]]
* 09.04.15: [[cdaefa:CP-007-00|CP-007-00: Inkonsistenz in der Darstellung der Dokumenten-Metadaten]]
* 09.04.15: [[cdaefa:CP-008-00|CP-008-00: Fehlende Profilierung der Dokumentensignatur]]
* 09.04.15: [[cdaefa:CP-010-00|CP-010-00: Audit Trail Einträge für EFAv2.0-Sicherheitsdienste]]
* 09.04.15: [[cdaefa:CP-011-00|CP-011-00: SecureRetrieve für EFAv2.0]]

=== In die Revision 2 (EFA-Projectathon 2016) aufgenommene Änderungen ===
* 07.04.16: [[cdaefa:CP-018-00|CP-018-00: Übernahme von Codes der deutschen Value-Set-Gruppe]]
* 02.11.15: [[cdaefa:CP-012-00|CP-012-00: Fehlerhafte Kodierung von IDs in einem Beispiel]]
* 02.11.15: [[cdaefa:CP-013-00|CP-013-00: Groß-/Kleinschreibung bei Query-Parametern]]
* 12.02.16: [[cdaefa:CP-001-00|CP-001-00: Missverständliche Spezifikation der Klasse subjectIdentity]]
* 12.02.16: [[cdaefa:CP-003-00|CP-003-00: Zulässigkeit weiterer Zweckcodes]]
* 12.02.16: [[cdaefa:CP-006-00|CP-006-00: Unvollständiges Binding der Dokumenten-Metadaten]]
* 12.02.16: [[cdaefa:CP-014-00|CP-014-00: Fehler in der OID-Nutzung für SMC-B]]
* 14.02.16: [[cdaefa:CP-015-00|CP-015-00: Fehlende Vorgabe für „HP Speciality“]]
* 14.02.16: [[cdaefa:CP-017-00|CP-017-00: EFA Identity Assertion SAML2 Binding]]
* 14.02.16: [[cdaefa:CP-016-00|CP-016-00: Nutzung von XDS-Optionen explizieren]]
* 16.02.16: [[cdaefa:CP-004-00|CP-004-00: Invalidieren von Dokumenten (Inkonsistenz zum IHE-Cookbook)]]
* 16.02.16: [[cdaefa:CP-002-00|CP-002-00: Unvollständige Spezifikation der Klasse consentInfo]]

=== In die Revision 1 (Januar 2015) aufgenommene Änderungen ===
* 01.10.14: [[cdaefa_Diskussion:EFA_Dienste|Deployment-Optionen für das XDS DocumentRegistry]]
* 27.04.14: [[cdaefa_Diskussion:EFA_Identity_Assertion_SAML2_Binding#Change_Requests|Kodierung von Rollen (HCP Identity Assertion)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests |Zulässigkeit weiterer Verwendungszwecke (logisch)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests|Grundlage einer consentInfo]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Change_Requests|Vorzeitiges Schließen einer Fallakte]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Einbau_eines_technischen_.22Verfallsdatums.22_f.C3.BCr_FallAkten |Einbau eines technischen "Verfallsdatums" für FallAkten]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Geschäftsobjekte#Unterscheidung_von_.22Muss.22-_und_.22Kann.22-Informationen|Unterscheidung von "Muss"- und "Kann"-Informationen ]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Konkretere_Empfehlungen_zur_Archivierung_von_Fallakten|Konkretere Empfehlungen zur Archivierung von Fallakten]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Konkretere_Darstellung_der_Kodierung_der_G.C3.BCltigkeitsdauer_einer_Akte|Konkretere Darstellung der Kodierung der Gültigkeitsdauer einer Akte]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Kommunikationsmuster#Konkreter_beschreiben.2C_wie_ein_Dokument_invalidiert_wird|Konkreter beschreiben, wie ein Dokument invalidiert wird]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Zustands.C3.BCbergang_.22verfallen.22_-.3E_.22archiviert.22_beschreiben|Zustandsübergang "verfallen" -> "archiviert" beschreiben]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Hinweis_auf_laufende_Arbeiten_zur_Einwilligungserkl.C3.A4rung_einf.C3.BCgen|Hinweis auf laufende Arbeiten zur Einwilligungserklärung einfügen]]
* 07.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Ausformulieren_des_Informationsmodells_einer_Einwilligung|Ausformulieren des Informationsmodells einer Einwilligung]]

=== Abgewiesene Change Requests ===
* 09.04.15: [[cdaefa:CP-009-00|CP-009-00: Profilierung von DocumentEntry.confidentialityCode]]

== Offene Punkte und ToDos ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.04}</tt>

=== ToDos aus der Kommentierung (Fraunhofer) ===

* [[cdaefa:EFA_Business_Informationsmodell|Informationsmodell]]: Übersichtsgrafik als UML-Klassenmodell
* [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|EFA Anwendungsdienste]]: Fehlercodes konsolidieren und auf einer Seite zusammenfassen
* [[cdaefa:Akteure_und_Rollen_der_EFA|Akteure und Rollen]]: Akteursdiagramm einfügen
* Darstellung des Zusammenhangs Interaktionsmuster-Kommunikationsmuster-SFM-Binding (zusätzliche Seite)

=== Diskussionsbedarfe - operativ (7er-Gruppe) ===

* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#issueAccessToken|issueAccessToken]]
* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#redeemAccessToken|redeemAccessToken]]
*Informationsmodell für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]
* Binding für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]

=== Diskussionbedarfe - strategisch (Lenkungsgruppe) ===

=== Abschnitte, die ggf. in das Cookbook verschoben werden können ===

* [[cdaefa:EFA_Business_Informationsmodell#Patient]]: Regel "Sender does it right"
* [[cdaefa:EFA_Business_Informationsmodell#purpose]]
* [[cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_createECR]]: "The application of security measures and the contents of the SOAP security header are specified normatively"
* [[cdaefa:EFA_XDS_ResourceManager#Security_Considerations]]
* [[cdaefa:EFA_Verwendete_Standards#Verwendete_Standards:_Sicherheit]]
* [[cdaefa:EFA_IHE_Setup_and_Flow_of_Control#EFA_Setup]]
* [[cdaefa:Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten#Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten]]
* [[cdaefa:Patienteneinwilligung_zur_EFA#Patienteneinwilligung_zur_EFA]]
* [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#HCP_Identity_Attributes]]: Values for attribute "Structural Role"

=== Externe Abhängigkeiten ===

* Aktuell existiert keine OID für die Nutzung der Telematik-ID als Identifizierungsmechansimus für Organisationen und Leistungserbringer. Eine solche OID wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Institution|Element ''AuthorInstitution'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Person|Element ''AuthorPerson'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_Profile|Subject-Identifizierung im EFA SAML Profil]]

* Ein Codesystem für die Klassifizierung von Fachbereichszugehörigkeiten eines Leistungserbringers muss festgelegt werden. Hier gibt es diverse KBV Schlüsseltabellen, die auf ihre Eignung zu prüfen sind. Diese Klassifizierung wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_National_Profile_and_Extensions|Subject-Attribut im EFA SAML Profil]]

cdaefa:EFA Spezifikation v2.0

2016-10-30T14:44:52Z

Jcaumanns: /* Offene Change Requests */

[[Datei:Information_icon.svg|40px|left]]Gemeinsam mit dem bvitg und IHE Deutschland hat der EFA-Verein einen [http://wiki.hl7.de/index.php?title=Datei:EPPC-G_Draft_for_Comment_v04.pdf Spezifikationsvorschlag für eine elektronische Einwilligung] erstellt, der aktuell innerhalb des Interoperabilitätsforums zur öffentlichen Kommentierung freigegeben wurde. Nach Abschluss der Kommentierung werden die EFA-relevanten Bestandteile dieser Spezifikation als ''Supplement zur EFAv2.0-Spezifikation'' auf dieser Seite verlinkt.

[[Datei:Attention_icon.svg|40px|left]] Im Rahmen des europäischen IHE Connectathon 2016 in Bochum wird erstmalig auch ein "EFA Projectathon" stattfinden. Alle hierzu relevanten Informationen finden Sie auf der Seite "[[cdaefa:EFA Projectathon 2016|EFA Projectathon 2016]]".

{{DocumentPart}}



= Einleitung =
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.01}</tt>

Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - einer Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.

Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf einem Patienten zugeordnete, medizinische Daten. Ein Fall beginnt mit einer Erstdiagnose und integriert alle weiteren notwendigen Abrechnungs- und Behandlungsdaten. Ein Arzt betreut die Fallakte zusammen mit weiteren behandelnden Ärzten, die für die Inhalte und deren Vollständigkeit verantwortlich sind.

Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt dezentral in bestehenden Systemen verwaltet und können bei Bedarf zu einer integrierten, für alle behandelnden Ärzte einheitlichen Sicht auf den Patienten zusammengeführt werden. Daher kann die Fallakte sehr einfach in bestehende Netze integriert werden und erleichtert somit die Zusammenarbeit auf regionaler Ebene.

== Von EFA 1.2 zu EFA 2.0 ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.02}</tt>

Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der [http://www.fallakte.de/spezifikationen EFA Version 1.2] das erste öffentliche Major-Release der EFA-Spezifikation von den Trägern der EFA-Initiative freigegeben. Bereits Ende 2008 konnten drei namhafte Hersteller (Siemens, ISPro, iSoft) auf dem ersten EFA-Connectathon Produkte präsentieren, die die interoperablen Schnittstellen der EFA implementierten und so miteinander in einem Peer-to-Peer Netzwerk zusammengeschaltet werden konnten. In den folgenden Jahren wurden in verschiedenen Bundesländern EFA-Pilotprojekte gestartet und 2011 konnte am Städtischen Klinikum München das erste regionale EFA-Netzwerk in den Regelbetrieb überführt werden.

Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] und [http://www.p23r.de Prozessdatenbeschleuniger (P23R)] den State-of-the-Art auch mit geprägt hat) haben sich in dieser Zeit im Bereich der Fachschnittstellen von elektronischen Aktensystemen die meisten Hersteller mit ihren Produkten in Richtung des IHE-Profils XDS bewegt, das von der EFA Version 1.2 lediglich logisch aber nicht syntaktisch berücksichtigt wurde - wobei auch die Synchronizität des EFA-1.2-Informationsmodells zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt war.

Im März 2012 haben daher der [http://www.fallakte.de EFA-Verein] als Träger der EFA-Spezifikation und der [http://www.bvitg.de bvitg] als Vertreter der im ambulanten und stationären Sektor tätigen Hersteller von IT-Lösungen beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifikation zu erarbeiten. Diese Version soll
* auf den bewährten und in verschiedenen Gesundheitsnetzen erfolgreich erprobten Kernprinzipien und -konzepten der EFA v1.2 aufbauen,
* in Produkten der Industrie verfügbare Schnittstellenstandards aufgreifen und eine Abbildbarkeit des EFA-Informationsmodells auf das Aktenkonzept von IHE herstellen,
* durch Verzahnung mit dem [[IHE_DE_Cookbook|IHE-D Cookbook]] auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

== EFA 2.0 Spezifikation ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.03}</tt>

Die folgende Tabelle stellt die einzelnen Kapitel der EFA 2.0 Spezifikation im Strukturraster des [[HL7 Enterprise Conformance and Compliance Frameworks]] dar. Die Spezifikation liegt auch als kompiliertes Dokument vor:
* [[cdaefa:EFAv2_Single_Document|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (HTML)]],
* [[Media:EFAv2.0-freeze-131118.pdf|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (PDF)]].

<table border="1" cellspacing="0" cellpadding="5em" width="100%">
<tr bgcolor="lightgray" align="center">
<td width="10%" valign="top">EFA v2.0</td>
<td width="30%" valign="top">'''Enterprise Dimension''' '''''"Why"''''' '''''Policy'''''</td>
<td width="30%" valign="top">'''Information Dimension''' '''''"What"''''' '''''Content'''''</td>
<td width="30%" valign="top">'''Computational Dimension''' '''''"How"''''' '''''Behavior'''''</td>
</tr>

<tr bgcolor="orange" align="center">
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Die EFA als zweckgebundene Akte|Die EFA als zweckgebundene Akte]]

[[cdaefa:EFA Provider|Versorgungsdomänen]]

[[cdaefa:Die EFA als Gesundheitsdatendienst|Die EFA als Gesundheitsdatendienst]]

[[cdaefa:Peer-to-Peer-Vernetzung von EFA-Providern|Peer-to-Peer-Vernetzung von EFA-Providern]]

[[cdaefa:Akteure und Rollen der EFA|Akteure und Rollen]]

[[cdaefa:Prinzipien für Datenschutz und Datensicherheit|Prinzipien für Datenschutz und Datensicherheit]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Kontext, Akte, Ressource|Kontext, Akte, Ressource]]

[[cdaefa:Patienteneinwilligung zur EFA|Patienteneinwilligung zur EFA]]

[[cdaefa:EFA Geschäftsobjekte|EFA Geschäftsobjekte]]

*[[cdaefa:EFA Business Lebenszyklus|Lebenszyklus einer Fallakte]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Interaktionsmuster der EFA|Interaktionsmuster der EFA]]
*[[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
*[[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
*[[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
*[[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
*[[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte oder eine Partition]]
*[[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
*[[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
*[[cdaefa:CIM Invalidieren von Datenobjekten|Invalidieren von Datenobjekten]]
*[[cdaefa:CIM Anpassen des Teilnehmerkreises|Ändern der Einwilligung]]
*[[cdaefa:CIM_Autorisierung_eines_weiteren_Teilnehmers|Autorisierung eines weiteren Teilnehmers]]
*[[cdaefa:CIM_Zusammenführen_von_Fallakten|Zusammenführen von Fallakten]]
</td>
</tr>

<tr bgcolor="yellow" align="center">
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Sicherheitsanforderungen|EFA Sicherheitsanforderungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Business Informationsmodell|Informationsmodelle der EFA Geschäftsobjekte]]

[[cdaefa:EFA Security Informationsmodell|Informationsmodelle der EFA Sicherheitsobjekte]]

[[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Dienste|EFA Dienste]]

[[cdaefa:EFA Kommunikationsmuster|EFA Kommunikationsmuster]]

[[cdaefa:EFA Anwendungsdienste (logische Spezifikation)|EFA Anwendungsdienste (logische Spezifikation)]]

[[cdaefa:EFA Sicherheitsdienste (logische Spezifikation)|EFA Sicherheitsdienste (logische Spezifikation)]]
*[[cdaefa:EFA Context Manager SFM|EFA Context Manager SFM]]
*[[cdaefa:EFA Identity Provider SFM|EFA Identity Provider SFM]]
*[[cdaefa:EFA Policy Provider SFM|EFA Policy Provider SFM]]

[[cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten|Gruppierung von Anwendungs- und Sicherheitsdiensten]]
</td>
</tr>

<tr bgcolor="palegreen" align="center">
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Verwendete Standards|Verwendete Standards]]

[[cdaefa:EFA Used Namespaces|Namespaces]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Metadata Bindings|EFA Metadata Bindings]]
*[[cdaefa:EFA XDS Folder Metadata Binding|EFA XDS Folder Metadata Binding]]
*[[cdaefa:EFA XDS Document Metadata Binding|EFA XDS Document Metadata Binding]]

[[cdaefa:EFA Security Objects Bindings|EFA Security Objects Bindings]]
*[[cdaefa:EFA Identity Assertion SAML2 Binding|EFA Identity Assertion SAML2 Binding]]
*[[cdaefa:EFA Policy Assertion SAML2 Binding|EFA Policy Assertion SAML2 Binding]]

[[cdaefa:EFA Patient Consent Binding|EFA Patient Consent Binding]]

[[cdaefa:EFA Audit Trail Binding|EFA Audit Trail Binding]]

[[cdaefa:EFA Error Codes and Warning Codes|EFA Error Codes and Warning Codes]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA IHE Setup and Flow of Control|EFA IHE Setup and Flow of Control]]

[[cdaefa:EFA XDS/XDR Bindings|EFA XDS Bindings]]
*[[cdaefa:EFA XDS ResourceManager|EFA XDS Binding: ResourceManager]]
*[[cdaefa:EFA XDS DocumentRegistry|EFA XDS Binding: DocumentRegistry]]
*[[cdaefa:EFA XDS DocumentRepository|EFA XDS Binding: DocumentRepository]]

[[cdaefa:EFA Access Control System|EFA Access Control System]]
*[[cdaefa:EFA WS Trust Policy Provider|EFA WS-Trust Binding: PolicyProvider]]

[[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]]
</td>
</tr>
</table>

== Weiterführende Themen ==
In der EFA-Spezifikation wird an verschiedenen Stellen auf weiterführende Informationen oder Grundlagenpapiere verwiesen, die in der ECCF-Matrix nicht verzeichnet sind. Diese "Anhänge" zur EFAv2.0-Spezifikation sind hier verzeichnet.

=== Methodische Grundlagen ===

* [[HL7_Enterprise_Conformance_and_Compliance_Frameworks|HL7 SAIF ECCF]]: Kurze Einführung in das HL7 SAIF ''Enterprise Conformance and Compliance Framework'', das dem Aufbau dieser Spezifikation zugrunde liegt
* [[cdaefa:IHE_Access_Control_Domains | IHE Access Control Domains]]: Zusammenfassung des IHE White Paper "Access Control" mit Fokus auf in der EFAv2.0-Spezifikation genutzte Konzepte und Begrifflichkeiten

=== EFA Konformitätsnachweis ===

In Abstimmung zwischen dem Vorstand des EFA-Vereins und dem Fraunhofer FOKUS wird ein Verfahren zum Nachweis der Konformität von Produkten zu den EFA-Spezifikationen durchgeführt, das im Wesentlichen auf einer Selbsterklärung eines Herstellers beruht. EFAv2.0-konforme Produkte dürfen das EFA-Logo tragen und mit dem EFA-Logo auf Messen sowie in Print- und Online-Materialien beworben werden.
* [[cdaefa:Gegenstand der Konformitätsprüfung|Gegenstand der Konformitätsprüfung]]

Die Ausstellung dieses EFAv2.0-Konformitätsnachweises ist für Hersteller kostenlos und wird wie bisher durch das Fraunhofer FOKUS durchgeführt. Das Fraunhofer FOKUS ist zur Durchführung des Verfahrens und zur Vergabe des EFA-Logos vom EFA-Verein akkreditiert.
* [[cdaefa:Durchführung der Konformitätsprüfung|Durchführung der Konformitätsprüfung]]

Hersteller können alle zur Durchführung des Verfahrens erforderlichen Unterlagen per Mail beim Fraunhofer FOKUS ([mailto:joerg.caumanns@fokus.fraunhofer.de joerg.caumanns@fokus.fraunhofer.de]) anfordern.

'''Hinweis''': Das hier beschriebene Verfahren und die ausgestellten Konformitätsnachweise sind bis Ende 2014 gültig. Ab 2015 soll ein erweitertes Verfahren zum Tragen kommen, dass auf der erfolgreichen Teilnahme von Produkten an einem IHE Connectathon aufsetzt.

== Change Requests ==
Mit der Finalisierung der EFA-Spezifikation im Herbst 2013 haben verschiedene Hersteller (und auch FuE-Projekte) begonnen, die EFAv2.0 zu implementieren. Trotz aller Sorgfalt bei der Erstellung der Spezifikationen fallen hierbei zuweilen kleinere Fehler auf und an manchen Stellen sind fachliche oder technische Festlegungen nur schwer nachvollziehbar, da die entsprechenden Beweggründe der Autorengruppe von Fraunhofer FOKUS, EFA-Verein und bvitg nicht ausreichend dokumentiert wurden.

Um die Spezifikationen kontinuierlich zu verbessern und insbesondere auch Hersteller und Projekte bestmöglich bei der Implementierung zu unterstützen, nehmen wir Fragen und Anregungen weiterhin gerne entgegen. Hierzu wurde für die EFAv2.0 ein regulärer [[EFA Change- und Releasemanagement|Change- und Releasemanagement-Prozess]] definiert, der ab Juli 2015 schrittweise operationalisiert wird.

Alle nach den vorgaben des definierten Prozesses eingereichten Änderungsanforderungen an die EFAv2.0-Spezifikation werden auf dieser Seite aufgelistet und durch Fraunhofer FOKUS, EFA-Verein und bvitg bearbeitet. Der Status der Bearbeitung sowie Entscheidungen zur Annahme bzw. Ablehnung eines Changes Requests werden auf der zu jedem Change Request angelegten Wiki-Seite dokumentiert.

'''Hinweis''': Alle Änderungsbedarfe an der EFAv2.0-Spezifikation, die sich aus angenommenen IHE ITI Change Proposals ergeben können, sind in der nachfolgenden Liste offener Change Requests bis einschließlich Ballot-29 (Ende September 2015) berücksichtigt.

=== Offene Change Requests ===
* 30.10.16: [[cdaefa:CP-045-00|CP-045-00: Differenzierung von Fehlermeldungen beim Ersetzen von Dokumenten]]
* 30.10.16: [[cdaefa:CP-044-00|CP-044-00: Integration administrativer Fallnummern]]
* 30.10.16: [[cdaefa:CP-043-00|CP-043-00: Mehrsprachige Display-Names für Dokumentenmetadaten]]
* 30.10.16: [[cdaefa:CP-042-00|CP-042-00: Klarstellungen zu partiellen Fehlern bei ProvideAndRegisterDocument]]
* 07.04.16: [[cdaefa:CP-020-00|CP-020-00: Systemverhalten bei Berechtigungsfehlern]]
* 07.04.16: [[cdaefa:CP-019-00|CP-019-00: Klassifizierung von Mount-Points]]
* 09.04.15: [[cdaefa:CP-005-00|CP-005-00: Falsche Zuordnung der Signatur (Metadaten statt Dokument)]]
* 09.04.15: [[cdaefa:CP-007-00|CP-007-00: Inkonsistenz in der Darstellung der Dokumenten-Metadaten]]
* 09.04.15: [[cdaefa:CP-008-00|CP-008-00: Fehlende Profilierung der Dokumentensignatur]]
* 09.04.15: [[cdaefa:CP-010-00|CP-010-00: Audit Trail Einträge für EFAv2.0-Sicherheitsdienste]]
* 09.04.15: [[cdaefa:CP-011-00|CP-011-00: SecureRetrieve für EFAv2.0]]

=== In die Revision 2 (EFA-Projectathon 2016) aufgenommene Änderungen ===
* 07.04.16: [[cdaefa:CP-018-00|CP-018-00: Übernahme von Codes der deutschen Value-Set-Gruppe]]
* 02.11.15: [[cdaefa:CP-012-00|CP-012-00: Fehlerhafte Kodierung von IDs in einem Beispiel]]
* 02.11.15: [[cdaefa:CP-013-00|CP-013-00: Groß-/Kleinschreibung bei Query-Parametern]]
* 12.02.16: [[cdaefa:CP-001-00|CP-001-00: Missverständliche Spezifikation der Klasse subjectIdentity]]
* 12.02.16: [[cdaefa:CP-003-00|CP-003-00: Zulässigkeit weiterer Zweckcodes]]
* 12.02.16: [[cdaefa:CP-006-00|CP-006-00: Unvollständiges Binding der Dokumenten-Metadaten]]
* 12.02.16: [[cdaefa:CP-014-00|CP-014-00: Fehler in der OID-Nutzung für SMC-B]]
* 14.02.16: [[cdaefa:CP-015-00|CP-015-00: Fehlende Vorgabe für „HP Speciality“]]
* 14.02.16: [[cdaefa:CP-017-00|CP-017-00: EFA Identity Assertion SAML2 Binding]]
* 14.02.16: [[cdaefa:CP-016-00|CP-016-00: Nutzung von XDS-Optionen explizieren]]
* 16.02.16: [[cdaefa:CP-004-00|CP-004-00: Invalidieren von Dokumenten (Inkonsistenz zum IHE-Cookbook)]]
* 16.02.16: [[cdaefa:CP-002-00|CP-002-00: Unvollständige Spezifikation der Klasse consentInfo]]

=== In die Revision 1 (Januar 2015) aufgenommene Änderungen ===
* 01.10.14: [[cdaefa_Diskussion:EFA_Dienste|Deployment-Optionen für das XDS DocumentRegistry]]
* 27.04.14: [[cdaefa_Diskussion:EFA_Identity_Assertion_SAML2_Binding#Change_Requests|Kodierung von Rollen (HCP Identity Assertion)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests |Zulässigkeit weiterer Verwendungszwecke (logisch)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests|Grundlage einer consentInfo]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Change_Requests|Vorzeitiges Schließen einer Fallakte]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Einbau_eines_technischen_.22Verfallsdatums.22_f.C3.BCr_FallAkten |Einbau eines technischen "Verfallsdatums" für FallAkten]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Geschäftsobjekte#Unterscheidung_von_.22Muss.22-_und_.22Kann.22-Informationen|Unterscheidung von "Muss"- und "Kann"-Informationen ]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Konkretere_Empfehlungen_zur_Archivierung_von_Fallakten|Konkretere Empfehlungen zur Archivierung von Fallakten]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Konkretere_Darstellung_der_Kodierung_der_G.C3.BCltigkeitsdauer_einer_Akte|Konkretere Darstellung der Kodierung der Gültigkeitsdauer einer Akte]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Kommunikationsmuster#Konkreter_beschreiben.2C_wie_ein_Dokument_invalidiert_wird|Konkreter beschreiben, wie ein Dokument invalidiert wird]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Zustands.C3.BCbergang_.22verfallen.22_-.3E_.22archiviert.22_beschreiben|Zustandsübergang "verfallen" -> "archiviert" beschreiben]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Hinweis_auf_laufende_Arbeiten_zur_Einwilligungserkl.C3.A4rung_einf.C3.BCgen|Hinweis auf laufende Arbeiten zur Einwilligungserklärung einfügen]]
* 07.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Ausformulieren_des_Informationsmodells_einer_Einwilligung|Ausformulieren des Informationsmodells einer Einwilligung]]

=== Abgewiesene Change Requests ===
* 09.04.15: [[cdaefa:CP-009-00|CP-009-00: Profilierung von DocumentEntry.confidentialityCode]]

== Offene Punkte und ToDos ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.04}</tt>

=== ToDos aus der Kommentierung (Fraunhofer) ===

* [[cdaefa:EFA_Business_Informationsmodell|Informationsmodell]]: Übersichtsgrafik als UML-Klassenmodell
* [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|EFA Anwendungsdienste]]: Fehlercodes konsolidieren und auf einer Seite zusammenfassen
* [[cdaefa:Akteure_und_Rollen_der_EFA|Akteure und Rollen]]: Akteursdiagramm einfügen
* Darstellung des Zusammenhangs Interaktionsmuster-Kommunikationsmuster-SFM-Binding (zusätzliche Seite)

=== Diskussionsbedarfe - operativ (7er-Gruppe) ===

* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#issueAccessToken|issueAccessToken]]
* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#redeemAccessToken|redeemAccessToken]]
*Informationsmodell für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]
* Binding für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]

=== Diskussionbedarfe - strategisch (Lenkungsgruppe) ===

=== Abschnitte, die ggf. in das Cookbook verschoben werden können ===

* [[cdaefa:EFA_Business_Informationsmodell#Patient]]: Regel "Sender does it right"
* [[cdaefa:EFA_Business_Informationsmodell#purpose]]
* [[cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_createECR]]: "The application of security measures and the contents of the SOAP security header are specified normatively"
* [[cdaefa:EFA_XDS_ResourceManager#Security_Considerations]]
* [[cdaefa:EFA_Verwendete_Standards#Verwendete_Standards:_Sicherheit]]
* [[cdaefa:EFA_IHE_Setup_and_Flow_of_Control#EFA_Setup]]
* [[cdaefa:Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten#Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten]]
* [[cdaefa:Patienteneinwilligung_zur_EFA#Patienteneinwilligung_zur_EFA]]
* [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#HCP_Identity_Attributes]]: Values for attribute "Structural Role"

=== Externe Abhängigkeiten ===

* Aktuell existiert keine OID für die Nutzung der Telematik-ID als Identifizierungsmechansimus für Organisationen und Leistungserbringer. Eine solche OID wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Institution|Element ''AuthorInstitution'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Person|Element ''AuthorPerson'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_Profile|Subject-Identifizierung im EFA SAML Profil]]

* Ein Codesystem für die Klassifizierung von Fachbereichszugehörigkeiten eines Leistungserbringers muss festgelegt werden. Hier gibt es diverse KBV Schlüsseltabellen, die auf ihre Eignung zu prüfen sind. Diese Klassifizierung wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_National_Profile_and_Extensions|Subject-Attribut im EFA SAML Profil]]

cdaefa:EFA XDS Document Metadata Binding

2016-08-16T13:06:20Z

Jcaumanns: /* HealthcareFacilityTypeCode */

{{DocumentPart
}}
''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 "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".''
----

== Document Metadata ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDoct.01}</tt>

The table below shows how eCR folder attributes map onto IHE XDS Folder metadata and vice versa:

{|class="wikitable" style="text-align: left; cellpadding: 10;"
![[cdaefa:EFA_Business_Informationsmodell#docMetadata|EFA Metadata]]
![http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE documentEntry Attribute]
!Remarks and Usage Constraints
|-
|Verantwortliche Organisation
|author
|EFA demands for registering the organization that takes responsibility for providing a document while IHE only allows to register the person/device (and organisation) that created the document. As it is assumed that provider of a document either ist the author of the document or acts on behalf the author of the document, the EFA "responsible organization" object is mapped onto an IHE "documentEntry.author" element. In cases these semantics conflict, the IHE semantics of "documentEntry.author" according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.1 shall be followed.
|-
|Status
|availabilityStatus
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.2.
|-
|Dokumentklasse
|classCode
|see below
|-
|
|comments
|see below
|-
|
|confidentialityCode
|shall always be "N" for EFA
|-
|Zeitpunkt der Bereitstellung
|
|EFA demands for registering the timestamp when a document was provided to an EFA. IHE XDS does not assign this information to single document entry but to the submissions set which was used for registering a set of documents with an XDS Document Registry. EFA implementations SHALL therefore map this logical attribute onto the XDS submission set's ''submissionTime'' attribute.
|-
|
|creationTime
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.6.
|-
|
|entryUUID
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.7.
|-
|
|eventCodeList
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.8.
|-
|
|formatCode
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.9.
|-
|Fehlererkennender Code
|hash
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.10.
|-
|
|healthcareFacilityTypeCode
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.11.
|-
|
|homeCommunityId
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.12.
|-
|
|languageCode
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.13.
|-
|
|legalAuthenticator
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.14. For consent documents this element shall record the person/organization that validated the patient's consent and registered it with EFA.
|-
|Dokumentformat
|mimeType
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.15.
|-
|patientID
|patientId
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.16. EFA Document Registry actors shall verify that the patient matches the person who gave consent to the respective EFA.
|-
|
|practiceSettingCode
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.17.
|-
|
|repositoryUniqueId
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.18.
|-
|rowspan="2"|Zeitliche Einordnung
|serviceStartTime
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.19.
|-
|serviceStopTime
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.20.
|-
|Dateigröße
|size
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.21.
|-
|
|sourcePatientId
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.22.
|-
|
|sourcePatientInfo
|This element shall not be used for EFA.
|-
|Titel
|title
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.24.
|-
|Dokumenttyp
|typeCode
|see below
|-
|documentID
|uniqueId
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.25.
|-
|
|URI
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.26.
|-
|
|referenceIdList
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.27.
|-
|
|limitedMetadata
|Limited metadata are not allowed for IHE XDS document sources and therefore the respective option SHALL NOT be used by EFA implementations.
|-
|
|objectType
|shall be used according to [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI TF-3]#4.2.3.2.29.
|-
|Signatur
|
|Documents provided to an EFA may be digitally signed. In this case, the constraints and means defined by the IHE ITI DSG integration profile shall be considered.
|}

=== classCode ===
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDoct.01.01}</tt>

The document class shall be taken from a national catalogue. The national catalogue should be a value set on top of LOINC as a reference terminology.

=== typeCode ===
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDoct.01.02}</tt>

The document type shall be provided as a LOINC code. Document types shall be more specific than document classes. They may be defined per [[cdaefa:EFA_Provider|Care Domain]].

'''Example:'''
<syntaxhighlight lang="xml">
<rim:Classification
id="urn:uuid:c33ca26a-29b4-45be-a9b9-de60adca4c64"
lid="urn:uuid:c33ca26a-29b4-45be-a9b9-de60adca4c64"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
classifiedObject="urn:uuid:fbf2ea29-3aa3-4bc5-9187-01d7b6b0f481"
nodeRepresentation="11520-4">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>2.16.840.1.113883.6.1</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString xml:lang="de" charset="UTF-8" value="EKG Befund"/>
</rim:Name>
</rim:Classification>

</syntaxhighlight>

=== Comments ===
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDoct.01.03}</tt>

This slot is optional. If given, it SHALL hold a summary of the document content.

'''Example:'''
<syntaxhighlight lang="xml">
<rim:Description>
<rim:LocalizedString xml:lang="de" charset="UTF-8" value = "Befund zur Magenspiegelung vom 3.3.13"/>
</rim:Description>
</syntaxhighlight>

=== German Profile ===
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDoct.02}</tt>

For using EFA within the German national healthcare IT infrastructure (''Telematikinfrastruktur'') the constraints listed below MUST be considered.

==== Author Institution ====
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDoct.02.01}</tt>

For the German healthcare system the following identification schemes MUST be used. If multiple schemes are available for an organization, the order in the table denotes the order of preference.

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Organization
!Scheme
!Code System OID
|-
|Practice
|Telematik ID This ID scheme MUST be preferred only if the Telematik ID is recorded within the SMC-B AUT certificate of the practice.
|1.2.276.0.76.4.188
|-
|Practice
|»Institutskennzeichen (IK)« acc. to § 293 SGB V
|1.2.276.0.76.4.5
|-
|Practice
|KBV »Arztnummer Praxis«
|1.2.276.0.76.4.10
|-
|Practice
|Any internal identification scheme that guarantees a unique identification within the scope of the affinity domain. Identifiers SHALL be resolvable to all EFA participants through public directory services (e.g. HPD, see IHE-Cookbook).
|''local code system''
|-
|Hospital department or faculty
|Telematik ID This ID scheme MUST be preferred only if the Telematik ID is recorded within the SMC-B AUT certificate of the department/faculty.
|1.2.276.0.76.4.188
|-
|Hospital department or faculty
|Any internal identification scheme that guarantees a unique identification within the scope of the affinity domain. Identifiers SHALL be resolvable to all EFA participants through public directory services (e.g. HPD, see IHE-Cookbook).
|''local code system''
|-
|Hospital
|Telematik ID This ID scheme MUST be preferred only if the Telematik ID is recorded within the SMC-B AUT certificate of the hospital.
|1.2.276.0.76.4.188
|-
|Hospital
|»Institutskennzeichen (IK)« acc. to § 293 SGB V
|1.2.276.0.76.4.5
|-
|Hospital
|Any internal identification scheme that guarantees a unique identification within the scope of the affinity domain. Identifiers SHALL be resolvable to all EFA participants through public directory services (e.g. HPD, see IHE-Cookbook).
|''local code system''
|}

{{AlertBox|Telematik ID and SMC-B certificates will only be available with the Telematik-Infrastruktur. Before the final roll-out of the Telematik-Infrastruktur identifiers based on Telematik ID and SMC-B SHOULD NOT be used.}}

'''Example:'''

A resident practice with the ''Institutskennzeichen'' 260326822 would be encoded as:
<syntaxhighlight lang="xml">
<rim:Slot name="authorInstitution">
<rim:ValueList>
<rim:Value>Name der Praxis^^^^^&1.2.276.0.76.4.5&ISO^^^^260326822</rim:Value>
</rim:ValueList>
</rim:Slot>
</syntaxhighlight>

==== Author Person ====
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDoct.02.02}</tt>

For the German healthcare system the following identification schemes MUST be used. If multiple schemes are available for an author's ID, the order in the table denotes the order of preference. If multiple IDs are known, at least two SHOULD be provided (considering the order of preference). An author identifier SHALL NOT be used without additionally providing the full name of the author.

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Person Role
!Scheme
!Code System OID
|-
|Physician
|Telematik ID This ID scheme MUST be preferred only if the Telematik ID is recorded within the HBA AUT certificate of the physician.
|1.2.276.0.76.4.188
|-
|Physician
|Lebenslange Arztnummer KV
|1.2.276.0.76.4.16
|-
|Physician Hospital Staff Practice Staff
|Any internal identification scheme that guarantees a unique identification within the scope of the identified organization. The <authorInstitution> and an <id> for this organization MUST be recorded.
|''local code system''
|}

{{AlertBox|Telematik ID and HBA certificates will only be available with the Telematik-Infrastruktur. Before the final roll-out of the Telematik-Infrastruktur identifiers based on Telematik ID and HBA SHOULD NOT be used.}}

'''Example:'''

A physician with the ''Arztnummer'' 12345678 would be encoded as:

<syntaxhighlight lang="xml">
<rim:Slot name="authorPerson">
<rim:ValueList>
<rim:Value>Name des Arztes^^^^^&1.2.276.0.76.4.16&ISO^^^^12345678</rim:Value>
</rim:ValueList>
</rim:Slot>
</syntaxhighlight>

==== HealthcareFacilityTypeCode ====
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDoct.02.03}</tt>

The healthcare facility type code SHALL be encoded as a coded value acc to the ''KBV Schlüsseltabelle S_VDX_PRAXISTYP'' ([http://applications.kbv.de/keytabs/ita/schluesseltabellen.asp?page=S_VDX_PRAXISTYP_V1.07.htm]). The root OID 1.2.276.0.76.3.1.1.5.1.4 SHALL be used.

'''Example:'''

A hospital facility type would be encoded as:

<syntaxhighlight lang="xml">
<rim:Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
classifiedObject="theDocument" id=”ID_050"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="50">
<rim:Name>
<rim:LocalizedString xml:lang="de" value="Krankenhaus"/>
</rim:Name>
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>1.2.276.0.76.3.1.1.5.1.4</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Classification>

</syntaxhighlight>

==== sourcePatientInfo ====
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EDoct.02.04}</tt>

For reasons of protecting the confidentiality of personal medical information this slot SHALL NOT be used. For the identifing the patient the sourcePatientId element SHALL be provided for all documents metadata.

----

{{NoteBox|'''Referenzen und Querverweise'''
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
<nowiki></nowiki>
}}

cdaefa:CP-020-00

2016-04-07T11:41:37Z

Jcaumanns: Die Seite wurde neu angelegt: „ =Systemverhalten bei Berechtigungsfehlern= <!-- Bitte senden Sie das ausgefüllte Formular zur weiteren Bearbeitung und zur Einleitung des EFAv2.0 Change Man…“

=Systemverhalten bei Berechtigungsfehlern=



{|class="wikitable"
|Titel des Change Request ||Systemverhalten bei Berechtigungsfehlern
|-
|Einreicher des Change Proposal||Jörg Caumanns
[mailto:joerg.caumanns@fokus.fraunhofer.de joerg.caumanns@fokus.fraunhofer.de]
|-
|Datum der Einreichung des Change Proposal||07.04.16
|-
|Betroffene Revision der EFA-Spezifikation||2 (Release Januar 2016)
|-
|EFAv2.0 Wiki Perspective ||Logical / Implementable
|-
|EFAv2.0 Wiki Dimension||Information / Computational
|-
|Akteur / Klasse / Transaktion||Fehlermeldungen
|-
|Change Proposal ID||CP-020-00
|-
|Datum der Veröffentlichung im EFAv2.0 Wiki||07.04.16
|-
|Change Proposal Status||Eingereicht
|-
|Abhängigkeit zum IHE Technical Framework ||Nein
|-
|Abhängigkeit zum IHE-D Cookbook ||Ja
|-
|Auswirkungen auf bestehende Implementierungen ||Ja
|-
|Datum der letzten Aktualisierung des Change Proposal||07.04.16
|-
|Zugewiesener Bearbeiter||''Zuweisung erfolgt in der 7er-Gruppe''
|-
|}

==Motivation für den Change Request==
Aussagen der Spezifikation zum Verhalten bei Berechtigungsfehlern sind auf der logischen und technischen Ebene nicht konsistent. Darüber hinaus dürfen durch Fehlermeldungen Unberechtigten gegenüber keine Informationen über die Existenz einer bestimmten EFA ableitbar sein.

==Vorschlag für die Änderung der EFAv2.0-Spezifikation ==
{|class="wikitable" style="background-color:#FFE4C4;"
|[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Fehlermeldungen_und_Warnungen http://wiki.hl7.de/index.php?title=cdaefa:EFA_Fehlermeldungen_und_Warnungen]
|}
Die Tabelle zu den Berechtigungsfehlern ist fehlerhaft und es fehlt ein Hinweis, dass einige der Fehlermeldungen nur intern in den Log geschrieben werden müssen aber nicht an den Nutzer zurückgegeben werden dürfen.

{|class="wikitable" style="background-color:#FFE4C4;"
|[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Error_Codes_and_Warning_Codes http://wiki.hl7.de/index.php?title=cdaefa:EFA_Error_Codes_and_Warning_Codes]
|}
In der Tabelle sind nicht alle logischen Fehlermeldungen durch Fehlercodes abgedeckt.

{|class="wikitable" style="background-color:#FFE4C4;"
|[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRegistry\#Response_Message_.28Failure_or_Partial_Failure_Scenario.29_2 http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRegistry]
|}
Die Fehlermeldung 4701 darf nicht an den Nutzer zurückgegeben werden, da hieraus ersichtlich wäre, dass die identifizierte EFA existiert. Stattdessen muss eine leere Ergebnismenge mit Status OK zurückgeliefert werden.

Darüber hinaus fehlen in der Auflistung einige der definierten logischen Fehler.

cdaefa:EFA Spezifikation v2.0

2016-04-07T11:40:34Z

Jcaumanns: /* Offene Change Requests */

[[Datei:Information_icon.svg|40px|left]]Gemeinsam mit dem bvitg und IHE Deutschland hat der EFA-Verein einen [http://wiki.hl7.de/index.php?title=Datei:EPPC-G_Draft_for_Comment_v04.pdf Spezifikationsvorschlag für eine elektronische Einwilligung] erstellt, der aktuell innerhalb des Interoperabilitätsforums zur öffentlichen Kommentierung freigegeben wurde. Nach Abschluss der Kommentierung werden die EFA-relevanten Bestandteile dieser Spezifikation als ''Supplement zur EFAv2.0-Spezifikation'' auf dieser Seite verlinkt.

[[Datei:Attention_icon.svg|40px|left]] Im Rahmen des europäischen IHE Connectathon 2016 in Bochum wird erstmalig auch ein "EFA Projectathon" stattfinden. Alle hierzu relevanten Informationen finden Sie auf der Seite "[[cdaefa:EFA Projectathon 2016|EFA Projectathon 2016]]".

{{DocumentPart}}



= Einleitung =
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.01}</tt>

Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - einer Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.

Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf einem Patienten zugeordnete, medizinische Daten. Ein Fall beginnt mit einer Erstdiagnose und integriert alle weiteren notwendigen Abrechnungs- und Behandlungsdaten. Ein Arzt betreut die Fallakte zusammen mit weiteren behandelnden Ärzten, die für die Inhalte und deren Vollständigkeit verantwortlich sind.

Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt dezentral in bestehenden Systemen verwaltet und können bei Bedarf zu einer integrierten, für alle behandelnden Ärzte einheitlichen Sicht auf den Patienten zusammengeführt werden. Daher kann die Fallakte sehr einfach in bestehende Netze integriert werden und erleichtert somit die Zusammenarbeit auf regionaler Ebene.

== Von EFA 1.2 zu EFA 2.0 ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.02}</tt>

Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der [http://www.fallakte.de/spezifikationen EFA Version 1.2] das erste öffentliche Major-Release der EFA-Spezifikation von den Trägern der EFA-Initiative freigegeben. Bereits Ende 2008 konnten drei namhafte Hersteller (Siemens, ISPro, iSoft) auf dem ersten EFA-Connectathon Produkte präsentieren, die die interoperablen Schnittstellen der EFA implementierten und so miteinander in einem Peer-to-Peer Netzwerk zusammengeschaltet werden konnten. In den folgenden Jahren wurden in verschiedenen Bundesländern EFA-Pilotprojekte gestartet und 2011 konnte am Städtischen Klinikum München das erste regionale EFA-Netzwerk in den Regelbetrieb überführt werden.

Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] und [http://www.p23r.de Prozessdatenbeschleuniger (P23R)] den State-of-the-Art auch mit geprägt hat) haben sich in dieser Zeit im Bereich der Fachschnittstellen von elektronischen Aktensystemen die meisten Hersteller mit ihren Produkten in Richtung des IHE-Profils XDS bewegt, das von der EFA Version 1.2 lediglich logisch aber nicht syntaktisch berücksichtigt wurde - wobei auch die Synchronizität des EFA-1.2-Informationsmodells zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt war.

Im März 2012 haben daher der [http://www.fallakte.de EFA-Verein] als Träger der EFA-Spezifikation und der [http://www.bvitg.de bvitg] als Vertreter der im ambulanten und stationären Sektor tätigen Hersteller von IT-Lösungen beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifikation zu erarbeiten. Diese Version soll
* auf den bewährten und in verschiedenen Gesundheitsnetzen erfolgreich erprobten Kernprinzipien und -konzepten der EFA v1.2 aufbauen,
* in Produkten der Industrie verfügbare Schnittstellenstandards aufgreifen und eine Abbildbarkeit des EFA-Informationsmodells auf das Aktenkonzept von IHE herstellen,
* durch Verzahnung mit dem [[IHE_DE_Cookbook|IHE-D Cookbook]] auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

== EFA 2.0 Spezifikation ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.03}</tt>

Die folgende Tabelle stellt die einzelnen Kapitel der EFA 2.0 Spezifikation im Strukturraster des [[HL7 Enterprise Conformance and Compliance Frameworks]] dar. Die Spezifikation liegt auch als kompiliertes Dokument vor:
* [[cdaefa:EFAv2_Single_Document|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (HTML)]],
* [[Media:EFAv2.0-freeze-131118.pdf|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (PDF)]].

<table border="1" cellspacing="0" cellpadding="5em" width="100%">
<tr bgcolor="lightgray" align="center">
<td width="10%" valign="top">EFA v2.0</td>
<td width="30%" valign="top">'''Enterprise Dimension''' '''''"Why"''''' '''''Policy'''''</td>
<td width="30%" valign="top">'''Information Dimension''' '''''"What"''''' '''''Content'''''</td>
<td width="30%" valign="top">'''Computational Dimension''' '''''"How"''''' '''''Behavior'''''</td>
</tr>

<tr bgcolor="orange" align="center">
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Die EFA als zweckgebundene Akte|Die EFA als zweckgebundene Akte]]

[[cdaefa:EFA Provider|Versorgungsdomänen]]

[[cdaefa:Die EFA als Gesundheitsdatendienst|Die EFA als Gesundheitsdatendienst]]

[[cdaefa:Peer-to-Peer-Vernetzung von EFA-Providern|Peer-to-Peer-Vernetzung von EFA-Providern]]

[[cdaefa:Akteure und Rollen der EFA|Akteure und Rollen]]

[[cdaefa:Prinzipien für Datenschutz und Datensicherheit|Prinzipien für Datenschutz und Datensicherheit]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Kontext, Akte, Ressource|Kontext, Akte, Ressource]]

[[cdaefa:Patienteneinwilligung zur EFA|Patienteneinwilligung zur EFA]]

[[cdaefa:EFA Geschäftsobjekte|EFA Geschäftsobjekte]]

*[[cdaefa:EFA Business Lebenszyklus|Lebenszyklus einer Fallakte]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Interaktionsmuster der EFA|Interaktionsmuster der EFA]]
*[[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
*[[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
*[[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
*[[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
*[[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte oder eine Partition]]
*[[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
*[[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
*[[cdaefa:CIM Invalidieren von Datenobjekten|Invalidieren von Datenobjekten]]
*[[cdaefa:CIM Anpassen des Teilnehmerkreises|Ändern der Einwilligung]]
*[[cdaefa:CIM_Autorisierung_eines_weiteren_Teilnehmers|Autorisierung eines weiteren Teilnehmers]]
*[[cdaefa:CIM_Zusammenführen_von_Fallakten|Zusammenführen von Fallakten]]
</td>
</tr>

<tr bgcolor="yellow" align="center">
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Sicherheitsanforderungen|EFA Sicherheitsanforderungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Business Informationsmodell|Informationsmodelle der EFA Geschäftsobjekte]]

[[cdaefa:EFA Security Informationsmodell|Informationsmodelle der EFA Sicherheitsobjekte]]

[[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Dienste|EFA Dienste]]

[[cdaefa:EFA Kommunikationsmuster|EFA Kommunikationsmuster]]

[[cdaefa:EFA Anwendungsdienste (logische Spezifikation)|EFA Anwendungsdienste (logische Spezifikation)]]

[[cdaefa:EFA Sicherheitsdienste (logische Spezifikation)|EFA Sicherheitsdienste (logische Spezifikation)]]
*[[cdaefa:EFA Context Manager SFM|EFA Context Manager SFM]]
*[[cdaefa:EFA Identity Provider SFM|EFA Identity Provider SFM]]
*[[cdaefa:EFA Policy Provider SFM|EFA Policy Provider SFM]]

[[cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten|Gruppierung von Anwendungs- und Sicherheitsdiensten]]
</td>
</tr>

<tr bgcolor="palegreen" align="center">
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Verwendete Standards|Verwendete Standards]]

[[cdaefa:EFA Used Namespaces|Namespaces]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Metadata Bindings|EFA Metadata Bindings]]
*[[cdaefa:EFA XDS Folder Metadata Binding|EFA XDS Folder Metadata Binding]]
*[[cdaefa:EFA XDS Document Metadata Binding|EFA XDS Document Metadata Binding]]

[[cdaefa:EFA Security Objects Bindings|EFA Security Objects Bindings]]
*[[cdaefa:EFA Identity Assertion SAML2 Binding|EFA Identity Assertion SAML2 Binding]]
*[[cdaefa:EFA Policy Assertion SAML2 Binding|EFA Policy Assertion SAML2 Binding]]

[[cdaefa:EFA Patient Consent Binding|EFA Patient Consent Binding]]

[[cdaefa:EFA Audit Trail Binding|EFA Audit Trail Binding]]

[[cdaefa:EFA Error Codes and Warning Codes|EFA Error Codes and Warning Codes]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA IHE Setup and Flow of Control|EFA IHE Setup and Flow of Control]]

[[cdaefa:EFA XDS/XDR Bindings|EFA XDS Bindings]]
*[[cdaefa:EFA XDS ResourceManager|EFA XDS Binding: ResourceManager]]
*[[cdaefa:EFA XDS DocumentRegistry|EFA XDS Binding: DocumentRegistry]]
*[[cdaefa:EFA XDS DocumentRepository|EFA XDS Binding: DocumentRepository]]

[[cdaefa:EFA Access Control System|EFA Access Control System]]
*[[cdaefa:EFA WS Trust Policy Provider|EFA WS-Trust Binding: PolicyProvider]]

[[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]]
</td>
</tr>
</table>

== Weiterführende Themen ==
In der EFA-Spezifikation wird an verschiedenen Stellen auf weiterführende Informationen oder Grundlagenpapiere verwiesen, die in der ECCF-Matrix nicht verzeichnet sind. Diese "Anhänge" zur EFAv2.0-Spezifikation sind hier verzeichnet.

=== Methodische Grundlagen ===

* [[HL7_Enterprise_Conformance_and_Compliance_Frameworks|HL7 SAIF ECCF]]: Kurze Einführung in das HL7 SAIF ''Enterprise Conformance and Compliance Framework'', das dem Aufbau dieser Spezifikation zugrunde liegt
* [[cdaefa:IHE_Access_Control_Domains | IHE Access Control Domains]]: Zusammenfassung des IHE White Paper "Access Control" mit Fokus auf in der EFAv2.0-Spezifikation genutzte Konzepte und Begrifflichkeiten

=== EFA Konformitätsnachweis ===

In Abstimmung zwischen dem Vorstand des EFA-Vereins und dem Fraunhofer FOKUS wird ein Verfahren zum Nachweis der Konformität von Produkten zu den EFA-Spezifikationen durchgeführt, das im Wesentlichen auf einer Selbsterklärung eines Herstellers beruht. EFAv2.0-konforme Produkte dürfen das EFA-Logo tragen und mit dem EFA-Logo auf Messen sowie in Print- und Online-Materialien beworben werden.
* [[cdaefa:Gegenstand der Konformitätsprüfung|Gegenstand der Konformitätsprüfung]]

Die Ausstellung dieses EFAv2.0-Konformitätsnachweises ist für Hersteller kostenlos und wird wie bisher durch das Fraunhofer FOKUS durchgeführt. Das Fraunhofer FOKUS ist zur Durchführung des Verfahrens und zur Vergabe des EFA-Logos vom EFA-Verein akkreditiert.
* [[cdaefa:Durchführung der Konformitätsprüfung|Durchführung der Konformitätsprüfung]]

Hersteller können alle zur Durchführung des Verfahrens erforderlichen Unterlagen per Mail beim Fraunhofer FOKUS ([mailto:joerg.caumanns@fokus.fraunhofer.de joerg.caumanns@fokus.fraunhofer.de]) anfordern.

'''Hinweis''': Das hier beschriebene Verfahren und die ausgestellten Konformitätsnachweise sind bis Ende 2014 gültig. Ab 2015 soll ein erweitertes Verfahren zum Tragen kommen, dass auf der erfolgreichen Teilnahme von Produkten an einem IHE Connectathon aufsetzt.

== Change Requests ==
Mit der Finalisierung der EFA-Spezifikation im Herbst 2013 haben verschiedene Hersteller (und auch FuE-Projekte) begonnen, die EFAv2.0 zu implementieren. Trotz aller Sorgfalt bei der Erstellung der Spezifikationen fallen hierbei zuweilen kleinere Fehler auf und an manchen Stellen sind fachliche oder technische Festlegungen nur schwer nachvollziehbar, da die entsprechenden Beweggründe der Autorengruppe von Fraunhofer FOKUS, EFA-Verein und bvitg nicht ausreichend dokumentiert wurden.

Um die Spezifikationen kontinuierlich zu verbessern und insbesondere auch Hersteller und Projekte bestmöglich bei der Implementierung zu unterstützen, nehmen wir Fragen und Anregungen weiterhin gerne entgegen. Hierzu wurde für die EFAv2.0 ein regulärer [[EFA Change- und Releasemanagement|Change- und Releasemanagement-Prozess]] definiert, der ab Juli 2015 schrittweise operationalisiert wird.

Alle nach den vorgaben des definierten Prozesses eingereichten Änderungsanforderungen an die EFAv2.0-Spezifikation werden auf dieser Seite aufgelistet und durch Fraunhofer FOKUS, EFA-Verein und bvitg bearbeitet. Der Status der Bearbeitung sowie Entscheidungen zur Annahme bzw. Ablehnung eines Changes Requests werden auf der zu jedem Change Request angelegten Wiki-Seite dokumentiert.

'''Hinweis''': Alle Änderungsbedarfe an der EFAv2.0-Spezifikation, die sich aus angenommenen IHE ITI Change Proposals ergeben können, sind in der nachfolgenden Liste offener Change Requests bis einschließlich Ballot-29 (Ende September 2015) berücksichtigt.

=== Offene Change Requests ===
* 07.04.16: [[cdaefa:CP-020-00|CP-020-00: Systemverhalten bei Berechtigungsfehlern]]
* 07.04.16: [[cdaefa:CP-019-00|CP-019-00: Klassifizierung von Mount-Points]]
* 09.04.15: [[cdaefa:CP-005-00|CP-005-00: Falsche Zuordnung der Signatur (Metadaten statt Dokument)]]
* 09.04.15: [[cdaefa:CP-007-00|CP-007-00: Inkonsistenz in der Darstellung der Dokumenten-Metadaten]]
* 09.04.15: [[cdaefa:CP-008-00|CP-008-00: Fehlende Profilierung der Dokumentensignatur]]
* 09.04.15: [[cdaefa:CP-010-00|CP-010-00: Audit Trail Einträge für EFAv2.0-Sicherheitsdienste]]
* 09.04.15: [[cdaefa:CP-011-00|CP-011-00: SecureRetrieve für EFAv2.0]]

=== In die Revision 2 (EFA-Projectathon 2016) aufgenommene Änderungen ===
* 07.04.16: [[cdaefa:CP-018-00|CP-018-00: Übernahme von Codes der deutschen Value-Set-Gruppe]]
* 02.11.15: [[cdaefa:CP-012-00|CP-012-00: Fehlerhafte Kodierung von IDs in einem Beispiel]]
* 02.11.15: [[cdaefa:CP-013-00|CP-013-00: Groß-/Kleinschreibung bei Query-Parametern]]
* 12.02.16: [[cdaefa:CP-001-00|CP-001-00: Missverständliche Spezifikation der Klasse subjectIdentity]]
* 12.02.16: [[cdaefa:CP-003-00|CP-003-00: Zulässigkeit weiterer Zweckcodes]]
* 12.02.16: [[cdaefa:CP-006-00|CP-006-00: Unvollständiges Binding der Dokumenten-Metadaten]]
* 12.02.16: [[cdaefa:CP-014-00|CP-014-00: Fehler in der OID-Nutzung für SMC-B]]
* 14.02.16: [[cdaefa:CP-015-00|CP-015-00: Fehlende Vorgabe für „HP Speciality“]]
* 14.02.16: [[cdaefa:CP-017-00|CP-017-00: EFA Identity Assertion SAML2 Binding]]
* 14.02.16: [[cdaefa:CP-016-00|CP-016-00: Nutzung von XDS-Optionen explizieren]]
* 16.02.16: [[cdaefa:CP-004-00|CP-004-00: Invalidieren von Dokumenten (Inkonsistenz zum IHE-Cookbook)]]
* 16.02.16: [[cdaefa:CP-002-00|CP-002-00: Unvollständige Spezifikation der Klasse consentInfo]]

=== In die Revision 1 (Januar 2015) aufgenommene Änderungen ===
* 01.10.14: [[cdaefa_Diskussion:EFA_Dienste|Deployment-Optionen für das XDS DocumentRegistry]]
* 27.04.14: [[cdaefa_Diskussion:EFA_Identity_Assertion_SAML2_Binding#Change_Requests|Kodierung von Rollen (HCP Identity Assertion)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests |Zulässigkeit weiterer Verwendungszwecke (logisch)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests|Grundlage einer consentInfo]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Change_Requests|Vorzeitiges Schließen einer Fallakte]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Einbau_eines_technischen_.22Verfallsdatums.22_f.C3.BCr_FallAkten |Einbau eines technischen "Verfallsdatums" für FallAkten]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Geschäftsobjekte#Unterscheidung_von_.22Muss.22-_und_.22Kann.22-Informationen|Unterscheidung von "Muss"- und "Kann"-Informationen ]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Konkretere_Empfehlungen_zur_Archivierung_von_Fallakten|Konkretere Empfehlungen zur Archivierung von Fallakten]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Konkretere_Darstellung_der_Kodierung_der_G.C3.BCltigkeitsdauer_einer_Akte|Konkretere Darstellung der Kodierung der Gültigkeitsdauer einer Akte]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Kommunikationsmuster#Konkreter_beschreiben.2C_wie_ein_Dokument_invalidiert_wird|Konkreter beschreiben, wie ein Dokument invalidiert wird]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Zustands.C3.BCbergang_.22verfallen.22_-.3E_.22archiviert.22_beschreiben|Zustandsübergang "verfallen" -> "archiviert" beschreiben]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Hinweis_auf_laufende_Arbeiten_zur_Einwilligungserkl.C3.A4rung_einf.C3.BCgen|Hinweis auf laufende Arbeiten zur Einwilligungserklärung einfügen]]
* 07.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Ausformulieren_des_Informationsmodells_einer_Einwilligung|Ausformulieren des Informationsmodells einer Einwilligung]]

=== Abgewiesene Change Requests ===
* 09.04.15: [[cdaefa:CP-009-00|CP-009-00: Profilierung von DocumentEntry.confidentialityCode]]

== Offene Punkte und ToDos ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.04}</tt>

=== ToDos aus der Kommentierung (Fraunhofer) ===

* [[cdaefa:EFA_Business_Informationsmodell|Informationsmodell]]: Übersichtsgrafik als UML-Klassenmodell
* [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|EFA Anwendungsdienste]]: Fehlercodes konsolidieren und auf einer Seite zusammenfassen
* [[cdaefa:Akteure_und_Rollen_der_EFA|Akteure und Rollen]]: Akteursdiagramm einfügen
* Darstellung des Zusammenhangs Interaktionsmuster-Kommunikationsmuster-SFM-Binding (zusätzliche Seite)

=== Diskussionsbedarfe - operativ (7er-Gruppe) ===

* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#issueAccessToken|issueAccessToken]]
* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#redeemAccessToken|redeemAccessToken]]
*Informationsmodell für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]
* Binding für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]

=== Diskussionbedarfe - strategisch (Lenkungsgruppe) ===

=== Abschnitte, die ggf. in das Cookbook verschoben werden können ===

* [[cdaefa:EFA_Business_Informationsmodell#Patient]]: Regel "Sender does it right"
* [[cdaefa:EFA_Business_Informationsmodell#purpose]]
* [[cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_createECR]]: "The application of security measures and the contents of the SOAP security header are specified normatively"
* [[cdaefa:EFA_XDS_ResourceManager#Security_Considerations]]
* [[cdaefa:EFA_Verwendete_Standards#Verwendete_Standards:_Sicherheit]]
* [[cdaefa:EFA_IHE_Setup_and_Flow_of_Control#EFA_Setup]]
* [[cdaefa:Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten#Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten]]
* [[cdaefa:Patienteneinwilligung_zur_EFA#Patienteneinwilligung_zur_EFA]]
* [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#HCP_Identity_Attributes]]: Values for attribute "Structural Role"

=== Externe Abhängigkeiten ===

* Aktuell existiert keine OID für die Nutzung der Telematik-ID als Identifizierungsmechansimus für Organisationen und Leistungserbringer. Eine solche OID wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Institution|Element ''AuthorInstitution'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Person|Element ''AuthorPerson'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_Profile|Subject-Identifizierung im EFA SAML Profil]]

* Ein Codesystem für die Klassifizierung von Fachbereichszugehörigkeiten eines Leistungserbringers muss festgelegt werden. Hier gibt es diverse KBV Schlüsseltabellen, die auf ihre Eignung zu prüfen sind. Diese Klassifizierung wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_National_Profile_and_Extensions|Subject-Attribut im EFA SAML Profil]]

cdaefa:EFA Spezifikation v2.0

2016-04-07T11:40:03Z

Jcaumanns: /* Offene Change Requests */

[[Datei:Information_icon.svg|40px|left]]Gemeinsam mit dem bvitg und IHE Deutschland hat der EFA-Verein einen [http://wiki.hl7.de/index.php?title=Datei:EPPC-G_Draft_for_Comment_v04.pdf Spezifikationsvorschlag für eine elektronische Einwilligung] erstellt, der aktuell innerhalb des Interoperabilitätsforums zur öffentlichen Kommentierung freigegeben wurde. Nach Abschluss der Kommentierung werden die EFA-relevanten Bestandteile dieser Spezifikation als ''Supplement zur EFAv2.0-Spezifikation'' auf dieser Seite verlinkt.

[[Datei:Attention_icon.svg|40px|left]] Im Rahmen des europäischen IHE Connectathon 2016 in Bochum wird erstmalig auch ein "EFA Projectathon" stattfinden. Alle hierzu relevanten Informationen finden Sie auf der Seite "[[cdaefa:EFA Projectathon 2016|EFA Projectathon 2016]]".

{{DocumentPart}}



= Einleitung =
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.01}</tt>

Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - einer Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.

Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf einem Patienten zugeordnete, medizinische Daten. Ein Fall beginnt mit einer Erstdiagnose und integriert alle weiteren notwendigen Abrechnungs- und Behandlungsdaten. Ein Arzt betreut die Fallakte zusammen mit weiteren behandelnden Ärzten, die für die Inhalte und deren Vollständigkeit verantwortlich sind.

Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt dezentral in bestehenden Systemen verwaltet und können bei Bedarf zu einer integrierten, für alle behandelnden Ärzte einheitlichen Sicht auf den Patienten zusammengeführt werden. Daher kann die Fallakte sehr einfach in bestehende Netze integriert werden und erleichtert somit die Zusammenarbeit auf regionaler Ebene.

== Von EFA 1.2 zu EFA 2.0 ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.02}</tt>

Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der [http://www.fallakte.de/spezifikationen EFA Version 1.2] das erste öffentliche Major-Release der EFA-Spezifikation von den Trägern der EFA-Initiative freigegeben. Bereits Ende 2008 konnten drei namhafte Hersteller (Siemens, ISPro, iSoft) auf dem ersten EFA-Connectathon Produkte präsentieren, die die interoperablen Schnittstellen der EFA implementierten und so miteinander in einem Peer-to-Peer Netzwerk zusammengeschaltet werden konnten. In den folgenden Jahren wurden in verschiedenen Bundesländern EFA-Pilotprojekte gestartet und 2011 konnte am Städtischen Klinikum München das erste regionale EFA-Netzwerk in den Regelbetrieb überführt werden.

Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] und [http://www.p23r.de Prozessdatenbeschleuniger (P23R)] den State-of-the-Art auch mit geprägt hat) haben sich in dieser Zeit im Bereich der Fachschnittstellen von elektronischen Aktensystemen die meisten Hersteller mit ihren Produkten in Richtung des IHE-Profils XDS bewegt, das von der EFA Version 1.2 lediglich logisch aber nicht syntaktisch berücksichtigt wurde - wobei auch die Synchronizität des EFA-1.2-Informationsmodells zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt war.

Im März 2012 haben daher der [http://www.fallakte.de EFA-Verein] als Träger der EFA-Spezifikation und der [http://www.bvitg.de bvitg] als Vertreter der im ambulanten und stationären Sektor tätigen Hersteller von IT-Lösungen beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifikation zu erarbeiten. Diese Version soll
* auf den bewährten und in verschiedenen Gesundheitsnetzen erfolgreich erprobten Kernprinzipien und -konzepten der EFA v1.2 aufbauen,
* in Produkten der Industrie verfügbare Schnittstellenstandards aufgreifen und eine Abbildbarkeit des EFA-Informationsmodells auf das Aktenkonzept von IHE herstellen,
* durch Verzahnung mit dem [[IHE_DE_Cookbook|IHE-D Cookbook]] auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

== EFA 2.0 Spezifikation ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.03}</tt>

Die folgende Tabelle stellt die einzelnen Kapitel der EFA 2.0 Spezifikation im Strukturraster des [[HL7 Enterprise Conformance and Compliance Frameworks]] dar. Die Spezifikation liegt auch als kompiliertes Dokument vor:
* [[cdaefa:EFAv2_Single_Document|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (HTML)]],
* [[Media:EFAv2.0-freeze-131118.pdf|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (PDF)]].

<table border="1" cellspacing="0" cellpadding="5em" width="100%">
<tr bgcolor="lightgray" align="center">
<td width="10%" valign="top">EFA v2.0</td>
<td width="30%" valign="top">'''Enterprise Dimension''' '''''"Why"''''' '''''Policy'''''</td>
<td width="30%" valign="top">'''Information Dimension''' '''''"What"''''' '''''Content'''''</td>
<td width="30%" valign="top">'''Computational Dimension''' '''''"How"''''' '''''Behavior'''''</td>
</tr>

<tr bgcolor="orange" align="center">
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Die EFA als zweckgebundene Akte|Die EFA als zweckgebundene Akte]]

[[cdaefa:EFA Provider|Versorgungsdomänen]]

[[cdaefa:Die EFA als Gesundheitsdatendienst|Die EFA als Gesundheitsdatendienst]]

[[cdaefa:Peer-to-Peer-Vernetzung von EFA-Providern|Peer-to-Peer-Vernetzung von EFA-Providern]]

[[cdaefa:Akteure und Rollen der EFA|Akteure und Rollen]]

[[cdaefa:Prinzipien für Datenschutz und Datensicherheit|Prinzipien für Datenschutz und Datensicherheit]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Kontext, Akte, Ressource|Kontext, Akte, Ressource]]

[[cdaefa:Patienteneinwilligung zur EFA|Patienteneinwilligung zur EFA]]

[[cdaefa:EFA Geschäftsobjekte|EFA Geschäftsobjekte]]

*[[cdaefa:EFA Business Lebenszyklus|Lebenszyklus einer Fallakte]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:Interaktionsmuster der EFA|Interaktionsmuster der EFA]]
*[[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
*[[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
*[[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
*[[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
*[[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte oder eine Partition]]
*[[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
*[[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
*[[cdaefa:CIM Invalidieren von Datenobjekten|Invalidieren von Datenobjekten]]
*[[cdaefa:CIM Anpassen des Teilnehmerkreises|Ändern der Einwilligung]]
*[[cdaefa:CIM_Autorisierung_eines_weiteren_Teilnehmers|Autorisierung eines weiteren Teilnehmers]]
*[[cdaefa:CIM_Zusammenführen_von_Fallakten|Zusammenführen von Fallakten]]
</td>
</tr>

<tr bgcolor="yellow" align="center">
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Sicherheitsanforderungen|EFA Sicherheitsanforderungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Business Informationsmodell|Informationsmodelle der EFA Geschäftsobjekte]]

[[cdaefa:EFA Security Informationsmodell|Informationsmodelle der EFA Sicherheitsobjekte]]

[[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Dienste|EFA Dienste]]

[[cdaefa:EFA Kommunikationsmuster|EFA Kommunikationsmuster]]

[[cdaefa:EFA Anwendungsdienste (logische Spezifikation)|EFA Anwendungsdienste (logische Spezifikation)]]

[[cdaefa:EFA Sicherheitsdienste (logische Spezifikation)|EFA Sicherheitsdienste (logische Spezifikation)]]
*[[cdaefa:EFA Context Manager SFM|EFA Context Manager SFM]]
*[[cdaefa:EFA Identity Provider SFM|EFA Identity Provider SFM]]
*[[cdaefa:EFA Policy Provider SFM|EFA Policy Provider SFM]]

[[cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten|Gruppierung von Anwendungs- und Sicherheitsdiensten]]
</td>
</tr>

<tr bgcolor="palegreen" align="center">
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Verwendete Standards|Verwendete Standards]]

[[cdaefa:EFA Used Namespaces|Namespaces]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA Metadata Bindings|EFA Metadata Bindings]]
*[[cdaefa:EFA XDS Folder Metadata Binding|EFA XDS Folder Metadata Binding]]
*[[cdaefa:EFA XDS Document Metadata Binding|EFA XDS Document Metadata Binding]]

[[cdaefa:EFA Security Objects Bindings|EFA Security Objects Bindings]]
*[[cdaefa:EFA Identity Assertion SAML2 Binding|EFA Identity Assertion SAML2 Binding]]
*[[cdaefa:EFA Policy Assertion SAML2 Binding|EFA Policy Assertion SAML2 Binding]]

[[cdaefa:EFA Patient Consent Binding|EFA Patient Consent Binding]]

[[cdaefa:EFA Audit Trail Binding|EFA Audit Trail Binding]]

[[cdaefa:EFA Error Codes and Warning Codes|EFA Error Codes and Warning Codes]]
</td>
<td width="30%" valign="top" align="left">
[[cdaefa:EFA IHE Setup and Flow of Control|EFA IHE Setup and Flow of Control]]

[[cdaefa:EFA XDS/XDR Bindings|EFA XDS Bindings]]
*[[cdaefa:EFA XDS ResourceManager|EFA XDS Binding: ResourceManager]]
*[[cdaefa:EFA XDS DocumentRegistry|EFA XDS Binding: DocumentRegistry]]
*[[cdaefa:EFA XDS DocumentRepository|EFA XDS Binding: DocumentRepository]]

[[cdaefa:EFA Access Control System|EFA Access Control System]]
*[[cdaefa:EFA WS Trust Policy Provider|EFA WS-Trust Binding: PolicyProvider]]

[[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]]
</td>
</tr>
</table>

== Weiterführende Themen ==
In der EFA-Spezifikation wird an verschiedenen Stellen auf weiterführende Informationen oder Grundlagenpapiere verwiesen, die in der ECCF-Matrix nicht verzeichnet sind. Diese "Anhänge" zur EFAv2.0-Spezifikation sind hier verzeichnet.

=== Methodische Grundlagen ===

* [[HL7_Enterprise_Conformance_and_Compliance_Frameworks|HL7 SAIF ECCF]]: Kurze Einführung in das HL7 SAIF ''Enterprise Conformance and Compliance Framework'', das dem Aufbau dieser Spezifikation zugrunde liegt
* [[cdaefa:IHE_Access_Control_Domains | IHE Access Control Domains]]: Zusammenfassung des IHE White Paper "Access Control" mit Fokus auf in der EFAv2.0-Spezifikation genutzte Konzepte und Begrifflichkeiten

=== EFA Konformitätsnachweis ===

In Abstimmung zwischen dem Vorstand des EFA-Vereins und dem Fraunhofer FOKUS wird ein Verfahren zum Nachweis der Konformität von Produkten zu den EFA-Spezifikationen durchgeführt, das im Wesentlichen auf einer Selbsterklärung eines Herstellers beruht. EFAv2.0-konforme Produkte dürfen das EFA-Logo tragen und mit dem EFA-Logo auf Messen sowie in Print- und Online-Materialien beworben werden.
* [[cdaefa:Gegenstand der Konformitätsprüfung|Gegenstand der Konformitätsprüfung]]

Die Ausstellung dieses EFAv2.0-Konformitätsnachweises ist für Hersteller kostenlos und wird wie bisher durch das Fraunhofer FOKUS durchgeführt. Das Fraunhofer FOKUS ist zur Durchführung des Verfahrens und zur Vergabe des EFA-Logos vom EFA-Verein akkreditiert.
* [[cdaefa:Durchführung der Konformitätsprüfung|Durchführung der Konformitätsprüfung]]

Hersteller können alle zur Durchführung des Verfahrens erforderlichen Unterlagen per Mail beim Fraunhofer FOKUS ([mailto:joerg.caumanns@fokus.fraunhofer.de joerg.caumanns@fokus.fraunhofer.de]) anfordern.

'''Hinweis''': Das hier beschriebene Verfahren und die ausgestellten Konformitätsnachweise sind bis Ende 2014 gültig. Ab 2015 soll ein erweitertes Verfahren zum Tragen kommen, dass auf der erfolgreichen Teilnahme von Produkten an einem IHE Connectathon aufsetzt.

== Change Requests ==
Mit der Finalisierung der EFA-Spezifikation im Herbst 2013 haben verschiedene Hersteller (und auch FuE-Projekte) begonnen, die EFAv2.0 zu implementieren. Trotz aller Sorgfalt bei der Erstellung der Spezifikationen fallen hierbei zuweilen kleinere Fehler auf und an manchen Stellen sind fachliche oder technische Festlegungen nur schwer nachvollziehbar, da die entsprechenden Beweggründe der Autorengruppe von Fraunhofer FOKUS, EFA-Verein und bvitg nicht ausreichend dokumentiert wurden.

Um die Spezifikationen kontinuierlich zu verbessern und insbesondere auch Hersteller und Projekte bestmöglich bei der Implementierung zu unterstützen, nehmen wir Fragen und Anregungen weiterhin gerne entgegen. Hierzu wurde für die EFAv2.0 ein regulärer [[EFA Change- und Releasemanagement|Change- und Releasemanagement-Prozess]] definiert, der ab Juli 2015 schrittweise operationalisiert wird.

Alle nach den vorgaben des definierten Prozesses eingereichten Änderungsanforderungen an die EFAv2.0-Spezifikation werden auf dieser Seite aufgelistet und durch Fraunhofer FOKUS, EFA-Verein und bvitg bearbeitet. Der Status der Bearbeitung sowie Entscheidungen zur Annahme bzw. Ablehnung eines Changes Requests werden auf der zu jedem Change Request angelegten Wiki-Seite dokumentiert.

'''Hinweis''': Alle Änderungsbedarfe an der EFAv2.0-Spezifikation, die sich aus angenommenen IHE ITI Change Proposals ergeben können, sind in der nachfolgenden Liste offener Change Requests bis einschließlich Ballot-29 (Ende September 2015) berücksichtigt.

=== Offene Change Requests ===
* 07.04.16: [[cdaefa:CP-019-00|CP-020-00: Systemverhalten bei Berechtigungsfehlern]]
* 07.04.16: [[cdaefa:CP-019-00|CP-019-00: Klassifizierung von Mount-Points]]
* 09.04.15: [[cdaefa:CP-005-00|CP-005-00: Falsche Zuordnung der Signatur (Metadaten statt Dokument)]]
* 09.04.15: [[cdaefa:CP-007-00|CP-007-00: Inkonsistenz in der Darstellung der Dokumenten-Metadaten]]
* 09.04.15: [[cdaefa:CP-008-00|CP-008-00: Fehlende Profilierung der Dokumentensignatur]]
* 09.04.15: [[cdaefa:CP-010-00|CP-010-00: Audit Trail Einträge für EFAv2.0-Sicherheitsdienste]]
* 09.04.15: [[cdaefa:CP-011-00|CP-011-00: SecureRetrieve für EFAv2.0]]

=== In die Revision 2 (EFA-Projectathon 2016) aufgenommene Änderungen ===
* 07.04.16: [[cdaefa:CP-018-00|CP-018-00: Übernahme von Codes der deutschen Value-Set-Gruppe]]
* 02.11.15: [[cdaefa:CP-012-00|CP-012-00: Fehlerhafte Kodierung von IDs in einem Beispiel]]
* 02.11.15: [[cdaefa:CP-013-00|CP-013-00: Groß-/Kleinschreibung bei Query-Parametern]]
* 12.02.16: [[cdaefa:CP-001-00|CP-001-00: Missverständliche Spezifikation der Klasse subjectIdentity]]
* 12.02.16: [[cdaefa:CP-003-00|CP-003-00: Zulässigkeit weiterer Zweckcodes]]
* 12.02.16: [[cdaefa:CP-006-00|CP-006-00: Unvollständiges Binding der Dokumenten-Metadaten]]
* 12.02.16: [[cdaefa:CP-014-00|CP-014-00: Fehler in der OID-Nutzung für SMC-B]]
* 14.02.16: [[cdaefa:CP-015-00|CP-015-00: Fehlende Vorgabe für „HP Speciality“]]
* 14.02.16: [[cdaefa:CP-017-00|CP-017-00: EFA Identity Assertion SAML2 Binding]]
* 14.02.16: [[cdaefa:CP-016-00|CP-016-00: Nutzung von XDS-Optionen explizieren]]
* 16.02.16: [[cdaefa:CP-004-00|CP-004-00: Invalidieren von Dokumenten (Inkonsistenz zum IHE-Cookbook)]]
* 16.02.16: [[cdaefa:CP-002-00|CP-002-00: Unvollständige Spezifikation der Klasse consentInfo]]

=== In die Revision 1 (Januar 2015) aufgenommene Änderungen ===
* 01.10.14: [[cdaefa_Diskussion:EFA_Dienste|Deployment-Optionen für das XDS DocumentRegistry]]
* 27.04.14: [[cdaefa_Diskussion:EFA_Identity_Assertion_SAML2_Binding#Change_Requests|Kodierung von Rollen (HCP Identity Assertion)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests |Zulässigkeit weiterer Verwendungszwecke (logisch)]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests|Grundlage einer consentInfo]]
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Change_Requests|Vorzeitiges Schließen einer Fallakte]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Einbau_eines_technischen_.22Verfallsdatums.22_f.C3.BCr_FallAkten |Einbau eines technischen "Verfallsdatums" für FallAkten]]
* 11.12.13: [[cdaefa_Diskussion:EFA_Geschäftsobjekte#Unterscheidung_von_.22Muss.22-_und_.22Kann.22-Informationen|Unterscheidung von "Muss"- und "Kann"-Informationen ]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Konkretere_Empfehlungen_zur_Archivierung_von_Fallakten|Konkretere Empfehlungen zur Archivierung von Fallakten]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Konkretere_Darstellung_der_Kodierung_der_G.C3.BCltigkeitsdauer_einer_Akte|Konkretere Darstellung der Kodierung der Gültigkeitsdauer einer Akte]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Kommunikationsmuster#Konkreter_beschreiben.2C_wie_ein_Dokument_invalidiert_wird|Konkreter beschreiben, wie ein Dokument invalidiert wird]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Zustands.C3.BCbergang_.22verfallen.22_-.3E_.22archiviert.22_beschreiben|Zustandsübergang "verfallen" -> "archiviert" beschreiben]]
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Hinweis_auf_laufende_Arbeiten_zur_Einwilligungserkl.C3.A4rung_einf.C3.BCgen|Hinweis auf laufende Arbeiten zur Einwilligungserklärung einfügen]]
* 07.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Ausformulieren_des_Informationsmodells_einer_Einwilligung|Ausformulieren des Informationsmodells einer Einwilligung]]

=== Abgewiesene Change Requests ===
* 09.04.15: [[cdaefa:CP-009-00|CP-009-00: Profilierung von DocumentEntry.confidentialityCode]]

== Offene Punkte und ToDos ==
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.04}</tt>

=== ToDos aus der Kommentierung (Fraunhofer) ===

* [[cdaefa:EFA_Business_Informationsmodell|Informationsmodell]]: Übersichtsgrafik als UML-Klassenmodell
* [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|EFA Anwendungsdienste]]: Fehlercodes konsolidieren und auf einer Seite zusammenfassen
* [[cdaefa:Akteure_und_Rollen_der_EFA|Akteure und Rollen]]: Akteursdiagramm einfügen
* Darstellung des Zusammenhangs Interaktionsmuster-Kommunikationsmuster-SFM-Binding (zusätzliche Seite)

=== Diskussionsbedarfe - operativ (7er-Gruppe) ===

* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#issueAccessToken|issueAccessToken]]
* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#redeemAccessToken|redeemAccessToken]]
*Informationsmodell für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]
* Binding für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]

=== Diskussionbedarfe - strategisch (Lenkungsgruppe) ===

=== Abschnitte, die ggf. in das Cookbook verschoben werden können ===

* [[cdaefa:EFA_Business_Informationsmodell#Patient]]: Regel "Sender does it right"
* [[cdaefa:EFA_Business_Informationsmodell#purpose]]
* [[cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_createECR]]: "The application of security measures and the contents of the SOAP security header are specified normatively"
* [[cdaefa:EFA_XDS_ResourceManager#Security_Considerations]]
* [[cdaefa:EFA_Verwendete_Standards#Verwendete_Standards:_Sicherheit]]
* [[cdaefa:EFA_IHE_Setup_and_Flow_of_Control#EFA_Setup]]
* [[cdaefa:Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten#Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten]]
* [[cdaefa:Patienteneinwilligung_zur_EFA#Patienteneinwilligung_zur_EFA]]
* [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#HCP_Identity_Attributes]]: Values for attribute "Structural Role"

=== Externe Abhängigkeiten ===

* Aktuell existiert keine OID für die Nutzung der Telematik-ID als Identifizierungsmechansimus für Organisationen und Leistungserbringer. Eine solche OID wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Institution|Element ''AuthorInstitution'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Person|Element ''AuthorPerson'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_Profile|Subject-Identifizierung im EFA SAML Profil]]

* Ein Codesystem für die Klassifizierung von Fachbereichszugehörigkeiten eines Leistungserbringers muss festgelegt werden. Hier gibt es diverse KBV Schlüsseltabellen, die auf ihre Eignung zu prüfen sind. Diese Klassifizierung wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_National_Profile_and_Extensions|Subject-Attribut im EFA SAML Profil]]

cdaefa:CP-019-00

2016-04-07T07:22:25Z

Jcaumanns: Die Seite wurde neu angelegt: „ =Klassifizierung von Mount-Points= <!-- Bitte senden Sie das ausgefüllte Formular zur weiteren Bearbeitung und zur Einleitung des EFAv2.0 Change Management …“

=Klassifizierung von Mount-Points=



{|class="wikitable"
|Titel des Change Request ||Klassifizierung von Mount-Points
|-
|Einreicher des Change Proposal||Jörg Caumanns
[mailto:joerg.caumanns@fokus.fraunhofer.de joerg.caumanns@fokus.fraunhofer.de]
|-
|Datum der Einreichung des Change Proposal||07.04.16
|-
|Betroffene Revision der EFA-Spezifikation||2 (Release Januar 2016)
|-
|EFAv2.0 Wiki Perspective ||Implementable
|-
|EFAv2.0 Wiki Dimension||Information
|-
|Akteur / Klasse / Transaktion||XDS Folder
|-
|Change Proposal ID||CP-019-00
|-
|Datum der Veröffentlichung im EFAv2.0 Wiki||07.04.16
|-
|Change Proposal Status||Eingereicht
|-
|Abhängigkeit zum IHE Technical Framework ||Nein
|-
|Abhängigkeit zum IHE-D Cookbook ||Ja
|-
|Auswirkungen auf bestehende Implementierungen ||Nein
|-
|Datum der letzten Aktualisierung des Change Proposal||07.04.16
|-
|Zugewiesener Bearbeiter||''Zuweisung erfolgt in der 7er-Gruppe''
|-
|}

==Motivation für den Change Request==
Für die Klassifizierung von XDS Ordnern wurden in den EFA Revisionen 1 und 2 die (temporären) Festlegungen des IHE Cookbook übernommen. Hier hat es nun Festlegungen der deutschen Value-Set-Gruppe gegeben, die auch für die EFA übernommen wurden. Bei der Übernahme der Codes ist übersehen worden, dass in dem nun referenzierten Value Set kein Code für die Auszeichnung eines Orndern als Mount Point enthalten ist.

==Vorschlag für die Änderung der EFAv2.0-Spezifikation ==
{|class="wikitable" style="background-color:#FFE4C4;"
|[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_Folder_Metadata_Binding http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_Folder_Metadata_Binding]
|}
Through a coded value in the XDS filder codeList attribute, an XDS Folder SHALL be marked as part of an eCR. The respective coded value SHALL contain either the EFA-Folder classification code (code="ECR", codeSystem="1.3.6.1.4.1.19376.3.276.1.5.7") '''or the EFA-Mount-Point classification code (code="ECR-mountpoint", codeSystem="1.3.6.1.4.1.19376.3.276.1.5.7").'''

Der hervorgehobene Code ist nicht Bestandteil des referenzierten Codesystems und sollte dort eingefügt werden. Ansonsten muss ein entsprechender Code für die EFA definiert und per Value Set mit den anderen zulässigen Codes zusammengefasst werden.