cdaefa Diskussion:EFA Spezifikation v2.0

Aus Hl7wiki
Version vom 16. September 2014, 13:22 Uhr von Jcaumanns (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Change Log

19.01.14 Neue Seite verlinkt
Übersichtsdarstellung zu P2P-Vernetzung von EFA-Providern eingefügt.
19.01.14 Editorische Änderung
Die Reihenfolge der Links im ersten Feld der ECCF-Matrix wurde umgestellt, so dass alle für die Darstellung der P2P Vernetzung von EFA-Providern erforderlichen Konzepte möglichst früh eingeführt sind. Themen wie Sicherheit und Akteure können damit hinter der P2P-Einführungsseite dargestellt werden und beide Umsetzungsoptionen (Single-Peer und P2P) berücksichtigen.

Change Requests

ID Requester Status Section Change Request Recommendation Editor Discussion
13 - rejected common Auflösen der HomeCommunityID:

Können wir davon ausgehen. Dass jeder Peer sämtliche homeCommunityIDs auflösen kann?

Ja. Aquivalent zu XDS innerhalb einer Affinity-Domain. (ti, 2014-01-21)
14 - postponed common Direktzugriff auf Daten:

Wenn ein Peer nach einem weitergeleiteten Query-Request die mitgelieferte Policy cacht, könnte er folgende Retrieve-Anfragen auch direkt beantworten (d.h. ohne Weiterleitung durch den „dedicated peer“ des Anfragenden). Wollen wir dies als Option zulassen? Oder gar als Regelfall?

  • DocumentConsumer spricht eigene DocumentRegistry an, um MountPoints zu finden. DocumentRegistry lädt Policy. Wie funktioniert erster Aufruf? Was bei verteilten Repositories in einem Peer? Muss nicht immer Retrieve ans Initiating-GW gerichtet werden? Registry müsste Non-IHE-Logik für P2P umsetzen. Registry müsste dann lokale Retrieve-Anfrage beantworten. Repository-UID bei fremd-Communities nicht auflösbar Vorschlag: Bekanntgabe des intitating-Gateway an Client (ti, 2014-01-21)
  • postpone (jc, 2014-01-21)


15 bkr captured common XDS-Binding: Einstellen von Dokumenten in eine vorhande Partition:

Assoziierte XDSDocumentEntries und XDSFolder müssen von der gleichen Document Registry gespeichert werden. Der Grund ist, dass die HasMember-Assoziation nur über die UUIDs der beiden Objekte hergestellt wird. Die homeCommunityId ist kein Attribut der HasMember-Association. Es sollte daher ein Hinweis eingefügt werden, dass Dokumente nicht in EFA-Partitionen eines benachten EFA-Providers eingestellt werden können, unter der Annahme, dass EFA-Provider untereinander nur lesenden Zugriff haben.

In dem Binding providerData sollte ein Hinweis auf diese Einschränkung eingefügt werden. (bkr, 17.06.2014)
16 bkr captured common Trennscharfe Definition der EFA-Dienste:

Kommentare

ID Author Status Section Vote Existing Proposed Comment Comment Editor Discussion
208 fo included Epif.02 : Von EFA 1.2 zu EFA 2.0 übergeordneten EFA-Konzepte (Fallakte, Ordner) Es ist genau Aufgabe des IHE-Cookbooks und dieser Spezifikation, die Abdeckbarkeit der EFA-Konzepte zu beschreiben. Wenn dieser Satz stimmt, dann ist EFA "nicht on top of IHE"! Ok, Formulierung korrigiert. (bkr, 13.06.2014)
209 fo included Epif.02 : Von EFA 1.2 zu EFA 2.0 Stateof- the-Art entspricht Das ist eine zweischneidige Aussage: State-of-the-Art ist ein Punkt, Einordnung in den europäischen Kontext und damit kein deutscher Alleingang ein anderer. Ok.
261 fo included common Alle Wikiseiten sollten als Teildokument angelegt werden, so dass man daraus relativ leicht ein Gesamtdokument erstellen kann. So ist das Herunterladen doch recht mühsam.

Für die Wiederverwendbarkeit sind diese einzelnen Seiten aber hervorragend.

Ein Link auf der Einstiegsseite wurde eingefügt.
262 fo included common Der EFA 2.0 Spezifikation fehlt noch eine Profilierungsgrundlage, aus der die benötigten Akteure hervorgehen.

Auch sollte angegeben werden, was eine EFA-Konformität unter der Überschrift "EFA on top of IHE" genau bedeutet: Jemand, der das kann, muss die dazugehörigen IHE-Profile nachweisen!!!!

Dieser Aspekt ist mit der Vorlage einer Konformitätserklärung abgedeckt. (bkr, 13.06.2014)
263 fo postponed common Die EFA 2.0 hat keine Verankerung in dem IHE-Cookbook.
264 iw postponed common Spezifikation sollte in einer Form geschrieben sein, die das Erfassen der Anforderungen erleichtert.
265 mr postponed common Abgleich des Implementierungsleitfadens mit der eFA 2.0 Spezifikation Der Implementierungsleitfaden (http://wiki.hl7.de/index.php/IG:EFA_Spezifikation_v2.0#Anwendungsszenario:_Anlegen_einer_Fallakte) ist nicht konsistent mit der eFA 2.0 Spezifikation gemäß http://wiki.hl7.de/index.php/cdaefa:EFA_Spezifikation_v2.0 Beispiel: im Implementierungsleitfaden werden mehrere parallele eFAs zu einem Zweck bei einem eFA-Provider beschrieben
266 sh postponed common eFA EFA Einheitliche Schreibweise
267 iw rejected common Es wäre sinnvoll, die Schnittstellenbeschreibung (WSDL) in der Implementable Perspective zu ergänzen bzw. zu referenzieren. (15.08.2014) Für die verwendeten ITI-Transaktionen spezifiziert IHE bereits die Fragmente einer WSDL. WSDL-Dokumente veröffentlicht IHE unter ftp://ftp.ihe.net/TF_Implementation_Material/ITI/wsdl/ (bk, 12.09.2014)

Authors

Kürzel Name Organisation E-Mail
fh Frank Oemig Agfa Healthcare
ti Tarik Idris InterComponentWare AG
mr Michael Rübener X-tension
sh Salima Houta Fraunhofer ISST
jc Jörg Caumanns Fraunhofer FOKUS
bk Ben Kraufmann Fraunhofer FOKUS
iw Ingo Wolf gematik
mk Marcel Klötgen CompuGroup Medical