Kommentare und Auflösungen zum Abstimmungsverfahren Spezifikation Offline Token - Draft 03-05-2018
Version vom 31. August 2018, 12:11 Uhr von Wikiadmin (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „{{#CustomTitle:Kommentare und Auflösungen zum Abstimmungsverfahren ''Spezifikation Offline Token - Draft 03-05-2018''}} Stand: [Calendar: AD]31. August 2018…“)
Stand: [Calendar: AD]31. August 2018
| Auszählung (Tally) | |
|---|---|
| Anzahl Kommentare | 124 |
| Angenommen | 83 |
| Angenommen mit Modifikationen | 7 |
| Nicht angenommen | 7 |
| Nicht relevant | 22 |
| Zur zukünftigen Verwendung | 0 |
| Weitergeleitet | 0 |
| Warten auf Information vom Antragsteller | 0 |
| Warten auf Information von anderer Arbeitsgruppe | 0 |
| Unbearbeitet | 5 |
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
|---|---|---|---|---|---|
| 1 | 1. |  Tippfehler | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
Kommentar  | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Außerdem ist es in beispielsweise in… | Außerdem ist es beispielsweise in… | ||||
Reconcile  | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 2 | 1. | Tippfehler | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| …für eine Fallakte zu berechtigten. | …für eine Fallakte zu berechtigen. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 3 | 2.2. |  Vorschlag | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Zusammen mit der Benutzeridentität hat der einlösende EFA-Teilnehmer vollen Zugriff auf die Fallakte. | Zusammen mit der Benutzeridentität hat der einlösende EFA-Teilnehmer temporär vollen Zugriff auf die Fallakte. | Es sollte hier schon klargestellt werden, dass die Zugriffsberechtigung nur temporär gilt. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 4 | 2.2. |  Kommentar allgemeiner Art | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| - Das EFA-Teilnehmersystem öffnet die Berechtigungskonfiguration… | Sollen immer wie beschrieben die Berechtigungen angepaßt werden? Wenn ja, muss dies wie beschrieben manuell geschehen? Evtl. macht das im jeweiligen Use-Case ja keinen Sinn, sich für eine Akte dauerhaft zu berechtigen (z.B. Notfall). Vielleicht kann aber auch durch die Übergabe des Offline-Token an den entsprechenden Arzt davon ausgegangen werden, dass dieser auf jeden Fall zu berechtigen ist. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Das Einlösen des Offline Tokens ermöglicht die manuelle Anpassung der Berechtigung. Diese kann abhängig vom Anwendungsfall in Abstimmung mit dem Patienten angepasst werden. Im Client kann eine Vorauswahl des einlösenden Arztes umgesetzt werden, um den Prozess für Anwender zu vereinfachen. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 5 | 2.2. | Tippfehler | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| …übergibt dem zu berechtigendem… | …übergibt dem zu berechtigenden… | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 6 | 3. | Tippfehler | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| werden in Kapitel… | Hier sollte der richtige Verweis eingebaut werden | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 7 | 3.1.2 | Kommentar allgemeiner Art | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| …darf die aktuelle Gültigkeitsdauer der Fallakte überschreiten. | Ist das wirklich so gewollt? Dann dürfte ein Offline-Token länger benutzt werden als normale Nutzer Zugriff hätten. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 8 | 3.1.2 | Tippfehler | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das Endes es Gültigkeitszeitraums… | Das Ende des Gültigkeitszeitraums… | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 9 | 3.1.2 | Kommentar allgemeiner Art | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| … die Gültigkeitsdauer der Fallakte. | Was genau ist die Gültigkeit? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Gültigkeit der EFA | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 10 | 3.1.4 | Tippfehler | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| …eine Kennung an die… | eine Kennung, an die | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 11 | 3.1.4 | Tippfehler | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Kennung setzt sich aus einer kryptografisch sicher erzeugtem Zufallswert… | Die Kennung setzt sich aus einem kryptografisch sicher erzeugten Zufallswert… | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 12 | 3.2.1.X | Kommentar allgemeiner Art | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Aufrufer: EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne | Wie würde die Funktionen bei Peer-To-Peer aussehen? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Peer2Peer Funktionen analog zur EFA 2.1 Spezifikation. Jeder Peer muss OfflineToken unterstützen. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 13 | 3.2.1.1. | Kommentar allgemeiner Art | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| docRelationship: offlineTokenInfo MUSS über docRelationship (Wert "ersetzt") mit dem gültigen offlineTokenInfo-Dokument assoziiert werden, wenn ein solches bereits existiert. | Was, wenn es das erste ist? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Im neuen Konzeptentwurf nicht relevant. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 14 | 3.2.1.1. | Tippfehler | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Ablauf:…lösche vorhanden offlineTokePolicy… | Ablauf:…lösche vorhandene offlineTokenPolicy… | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 15 | 3.2.2.1. | Kommentar allgemeiner Art | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Rückgabe: Ein Berechtigungstoken, das den Leistungserbringer, der es einreicht, zum Zugriff auf die Fallakte berechtigt | Wie lange? Gibt es hier Vorgaben oder zumindest Zeitrahmen? 5 Minuten, 1 Stunde, 1 Tag,…? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Empfehlung wird ergänzt. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 16 | 4.1.2. | Kommentar allgemeiner Art | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Actions: R: May contain… | Sind Actions hier wirklich required? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Actions sind nicht relevant. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 17 | 4.1.2.1 | Kommentar allgemeiner Art | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Resources | Kann man die Resources nicht komplett im Policy Set abbilden? Es soll doch nur eine Policy fürt eine Person geben. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Im neuen Konzeptentwurf nicht relevant. Das Consent Dokument der EFA wird um die Offline Token Policy erweitert. Die Ressource ist gemäß EFA 2.0 definiert. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 18 | 4.2.1. | Kommentar allgemeiner Art | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| docRelationship | Warum RPLC und nicht zumindest initial HasMember? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Im neuen Konzeptentwurf nicht relevant. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 19 | 4.2.3. | Kommentar allgemeiner Art | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Beispiel: | Evtl. wäre es sinnvoll, den SOAP-Envelope und den Header im Beispiel anzudeuten | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Wird ergänzt. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 20 | 5.1. | Kommentar allgemeiner Art | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| …erzeugt ein Offline Token Dokument… | Es wäre schön, ein durchgehendes Vokabular zu verwenden. Offline Token Dokument = Offline Token Info? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Im Konzept werden zunächst logische Begriffe genutzt, die dann später durch technische Begriffe ersetzt werden (analog zur bestehenden EFA-Spezifikation). | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 21 | Allg. | Vorschlag | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Aufbau des Dokuments | Kapitel 5 in Kapitel 2 | Lieber einmal Einleitung, Use-Case, Abläufe und das technische Konzept. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 22 | 2.1. | Vorschlag | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| keine | Beschr. Bei P2P | Unklar, wie das bei P2P funktioniert | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Peer2Peer Funktionen analog zur EFA 2.1 Spezifikation. Jeder Peer muss OfflineToken unterstützen. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 23 | 2.2. | Vorschlag | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Darstellung als Ablaufdiagramm? | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Use Case Diagramme werden ergänzt. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 24 | 4 | Vorschlag | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Text eher in die Einleitung übernommen werden | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 25 | 3.2.2.2. | Vorschlag | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Wenigstens ein Vorschlag machen? | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Formal ist es im Konzept vergleichbar wie das Einstellen einer Policy | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 26 | 4.1.4. | Vorschlag | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| ist das bereits erfolgt? | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Neuer Konzeptentwurf. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 27 | Allg. | Vorschlag | Lars Rüsing, Mathias Aschhoff | RZV Rechenzentrum Volmarstein | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Generell, kann das Offline-Token mehrfach verwendet werden. Dies sollte ausgeschlossen werden. | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Aus Praktikabilitätsgründen ist ein Offline Token mehrfach nutzbar. Die Sicherheit wird über Protokollierung und Netzwerkauthentifizierung geregelt. Allerdings ist es möglich ein Token zu deaktivieren / neu anzulegen. Der Client kann theoretisch das Token nach Einlösen deaktivieren, wenn dies projektspezifisch definiert wird. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 28 | Kapitel 1 - Abs. 1 | Tippfehler | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Außerdem ist es in beispielsweise in Notfallszenarien relevant… | "in" entfernen | Rechtschreibung | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 29 | Kapitel 1 - Abs. 1 | Tippfehler | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Spezifikation setzt auf bestehende Mechanismen der Fallakte auf, um den Entwicklungsaufwand möglichst gering zu halten und auf bereits etablierte Verfahren aufzusetzen. | Satzzeichen fehlt am Ende des Satzes. | Rechtschreibung | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 30 | Kapitel 3 - Abs. 1 | Tippfehler | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Fehler! Verweisquelle konnte nicht gefunden werden. | Verweisquelle korrigieren. | Verweiskorrektur | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 31 | Kapitel 3.1.2. - Abs. 1 | Tippfehler | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Sie ist an einer zufällig erzeugten Kennung gebunden und nicht an einen konkreten EFA-Teilnehmer. | Sie ist an eine zufällig erzeugte Kennung gebunden… | Rechtschreibung - Kennung (fem.) Die erzeugte Kennung. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 32 | Kapitel 3.1.2. - Abs. 1 | Tippfehler | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das Endes es Gültigkeitszeitraums … | Das Ende des Gültigkeitszeitraums … | Rechtschreibung | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 33 | Kapitel 3.1.2. - Abs. 1 | Tippfehler | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das Endes es Gültigkeitszeitraums eine Offline Token (expireDate) ist optional und darf die aktuelle Gültigkeitsdauer der Fallakte überschreiten. | Das Ende des Gültigkeitszeitraum eines Offline Tokens (expireDate) ist optional … | Rechtschreibung - Grammtik Genitivfall verwenden. | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 34 | Kapitel 3.1.4 - Abs. 1 | Tippfehler | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Kennung setzt sich aus einer kryptografisch sicher erzeugtem Zufallswert… | Die Kennung setzt sich aus einem kryptografisch sicher erzeugtem Zufallswert… | Rechtschreibung - Grammtik Dativfall verwenden. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 35 | Kapitel 3.2.2.1 - Abs. 1 |  Negativ, kleineres Problem | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Eingabe - docRelationship offlineTokenInfo MUSS über docRelationship (Wert "ersetzt") | "replaced" | Warum wird hier nicht englisch verwendet, wir wollen doch auch für internaltionale Projekte bzw. Softwarehersteller offen bleiben. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 36 | Kapitel 3.2.1.1 - Abs. 1 | Tippfehler | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Ablauf 1. Trage im offlineTokenInfo enthaltene offlineTokenPolicy beim Policy Provider ein… | 1. Trage die, im offlineTokenInfo enthaltene offlineTokenPolicy, beim Policy Provider ein… | Rechtschreibung, Satzzeichen | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 37 | Kapitel 3.2.1.1 - Abs. 1 | Tippfehler | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Ablauf 1. ... und lösche vorhanden offlineTokePolicy wenn ein bestehndes offlineTokenInfo ersetzt wird. | 1. … und lösche vorhandene offlineTokenPolicy wenn ein bestehendes offlineTokenInfo ersetzt wird. | Rechtschreibung | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 38 | Kapitel 3.2.2.1 - Abs. 1 | Tippfehler | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Ablauf 2. Erzeuge offlineTokenPolicyAssertion. (Wenn die offlineTokenPolicyRef auf eine andere Affinity-Domain verweist, muss die Anfrage an alle in Frage kommenden Policy Provider weitergeitet werden.) | … weitergeleitet… | Rechtschreibung | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 39 | Kapitel 3.2.2.1 - Abs. 1 | Tippfehler | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| sd issuetOfflineTokenPolicyAssertion | issueOfflineTokenPolicyAssertion | Rechtschreibung | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 40 | Kapitel 4.1.4 - Abs. 1 | Tippfehler | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die technische Umsetzung von offlineTokenInfo durch Advanced Patient Privacy Consents Content Module (IHE ITI Supplement APPC2, Section 5.6). | z.B.: Die technische Umsetzung von offlineTokenInfo wird durch das Advanced Patient Privacy Consent Content Module (IHE ITI Supplement APPC2, Section 5.6) umgesetzt. | Rechtschreibung - Dieser Satz ergibt so keinen Sinn, ich denke hier fehlt ein Wort. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 41 | Kapitel 4.2.1 - Abs. 1 | Tippfehler | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Technisch wird die Transaktion registerOfflineToken IHE-XDS Provide and Register Document Set3 (ITI-41) umgesetzt. | z.B.: Technisch wird die Transaktion registerOfflineToken durch die Transaktion IHE-XDS Provide and Register Document Set3 (ITI-41) umgesetzt. | Rechtschreibung | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 42 | Kapitel 4.2.2 - Abs. 1 | Tippfehler | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die technische Umsetzung von invalidateOfflineTokenInfo entspricht den EFA XDS Binding von invalidateData | Die technische Umsetzung von invalidateOfflineTokenInfo entspricht dem EFA XDS Binding von invalidateData | Rechtschreibung - Grammtik Dativfall verwenden. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 43 | Kapitel 7 - Tabelle |  Negativ, schwerwiegend | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Fault: Invalid Lifespan (nur relevant, wenn Gültigkeitsdauer gesetzt) Die angegebene Gültigkeitdauer des Offline Tokens (und damit der daran hängenden Akte) ist nicht gültig, da sie sie die aktuelle Lebenszeit der EFA überschreitet. | Korrigieren | In dieser Fehlermeldung wird beschrieben, dass die Gültigkeitsdauer des Offline Tokens nicht länger sein darf als die Lebenszeit der EFA. Dies ist ein Widerspruch zur Spezifikation in Kapitel 3.1.2. offlineTokenPolicy ("Das Endes es Gültigkeitszeitraums eine Offline Token (expireDate) ist optional und darf die aktuelle Gültigkeitsdauer der Fallakte überschreiten.") | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | "nicht" vergessen. Wurde jetzt ergänzt. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 44 | Kapitel 4.1.3 | Negativ, schwerwiegend | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die offlineTokenPolicyAssertion wird technisch als signierte Form eines XACML 2.0 PolicySet abgebildet. | Handelt es sich hierbei nicht um ein SAML 2.0 Assertion Element? Hier wäre eine Beispielassrtion hilfreich. Siehe auch Zeile 19. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Konzept des Offline Tokens wurde angepasst. Beispiele für Assertions wurden eingefügt. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 45 | Allgemein | Vorschlag | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Im Allgemeinen wird durch die Spezifikation nicht ausreichend genug ersichtlich, welche technischen Transaktionen der IHE aus dem XDS-Profil oder anderen Profilen verwendet werden und wie diese mit einander interagieren. | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 46 | Allgemein | Vorschlag | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Es wäre hilfreich, zu den technischen Artefakten /Datenmodellen Beispiele anzugeben. Hier wäre es möglich, an den entsprechenden Stellen, Beispiele in Form der technischen Nachrichten inkl. Beispielinhalt anzugeben (siehe hierzu Kapitel 4.2.3 issueOfflineTokenPolicy-Assertion). | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 47 | Allgemein | Vorschlag | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Es werden viele unterschiedliche Begrifflichkeiten benutzt (z.B.: EFA-Client, EFA-Teilnehmersystem, TNS, EFA-Portal oder auch EFA-Providersystem, EFA-Resource Manager). Hier wäre es gut, sich auf einen oder maximal zwei Begriffe zu beschränken | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 48 | Allgemein | Vorschlag | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Auf allen Seiten fehlen entsprechende Seitenzahlen, was ein Referenzieren der Spezifikation erschwert! | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 49 | Allgemein | Vorschlag | Lüttmann, Sven | VISUS Health IT GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| 3.2 Transaktionen
3.2.1 EFA Ressource Manager 3.2.2 EFA Policy Provider | 3.2 Transaktionen
3.2.1 registerOfflineToken 3.2.3 invalidateOfflineToken 3.2.3 issueOfflineTokenPolicy-Assertion … | Im Kapitel 3.2 sollen Transaktionen gelistet werden. Jedoch findet man hier zunächst die Akteure und dann die Transkationen, die jedoch nicht im Inhaltsverzeichnis zu finden sind. Da die tatsächliche technische Implementierung letztendlich in der Transaktion beschrieben wird, fände ich es sinnvoll hier zunächst die Transaktionen zu listen und innerhalb der Kapitel dann zu beschreiben welche Akteure hiervon betroffen sind (siehe auch IHE Spezifikationen z.B. im IHE ITI-TF 2a). | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Gruppierung nach Akteuren wurde bewusst ausgewählt, damit Hersteller von EFA Akteuren sehen welche Transaktionen ergänzt werden müssen. Erweiterung des Inhaltsverzeichnisses um die Transaktionen. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 50 | S.6. | Tippfehler | Thomas Liebscher, Dominic Swarat | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Fehler! Verweisquelle konnte nicht gefunden werden. | gebrochener Link | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 51 | S.7. | Tippfehler | Thomas Liebscher, Dominic Swarat | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das Endes es Gültigkeitszeitraums eine Offline Token (expireDate) ist optional und darf die aktuelle Gültigkeitsdauer der Fallakte überschreiten. Ist dieses nicht gesetzt, greift immer die Gültigkeit der Fallakte. | Das Ende des Gültigkeitszeitraums eines Offline Tokens (expireDate) ist optional und darf die aktuelle Gültigkeitsdauer der Fallakte überschreiten. Ist dieses nicht gesetzt, greift immer die Gültigkeit der Fallakte. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 52 | S.7. | Kommentar allgemeiner Art | Thomas Liebscher, Dominic Swarat | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das Endes es Gültigkeitszeitraums eine Offline Token (expireDate) ist optional und darf die aktuelle Gültigkeitsdauer der Fallakte überschreiten. Ist dieses nicht gesetzt, greift immer die Gültigkeit der Fallakte. | Was soll damit erreicht werden? Wenn die Fallakte nicht mehr gültig ist, dann hat das Offline Token keine Bedeutung mehr. Fehlertoleranz? Vielleicht einfach noch etwas erklären. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Offline Token darf nicht länger gültig sein als die Gültigkeitsdauer der Akte. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 53 | S.12, Tabelle, Zeile Ablauf | Tippfehler | Thomas Liebscher, Dominic Swarat | Philips GmbH | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| (Wenn die offlineTokenPolicyRef auf eine andere Affinity-Domain verweist, muss die Anfrage an alle in Frage kommenden Policy Provider weitergeitet werden.) | (Wenn die offlineTokenPolicyRef auf eine andere Affinity-Domain verweist, muss die Anfrage an alle in Frage kommenden Policy Provider weitergeleitet werden.) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 54 | 1. (Absatz 1) | Tippfehler | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Außerdem ist es in beispielsweise in Notfallszenarien relevant, | Außerdem ist es in beispielsweise in Notfallszenarien relevant, | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 55 | 2.1 (Absatz 2) | Tippfehler | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| wird der Prozess inkl. der Ausnahmen detailliert beschreiben. | wird der Prozess inkl. der Ausnahmen detailliert beschrieben. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 56 | 3. (Absatz nach Abbildung 1) | Tippfehler | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Interaktionen zwischen den
Komponenten werden in Kapitel Fehler! Verweisquelle konnte nicht gefunden werden. detailliert beschrieben. | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 57 | 3.1.2 | Tippfehler | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das Endes es Gültigkeitszeitraums eine Offline Token | Das Ende des Gültigkeitszeitraums eines Offline Tokens | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 58 | 3.1.3 | Vorschlag | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Es gibt keine Abbildung der Beziehung einer offlineTokenPolicyAssertion zu den anderen hier beschriebenen Objekten. Auch die Beziehung der ecrRef zur OfflineTokenPolicy Bedarf weiterer Erklärung. | Abbildung hinzufügen | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Beziehungen ergeben sich aus EFA 2.0 Spezifikation (z. B. Relationen der consentinfo) | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 59 | 3.2.1.1 (Ablauf) | Tippfehler | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| und lösche vorhanden offlineTokePolicy wenn ein bestehndes offlineTokenInfo ersetzt wird. | und lösche die vorhandene offlineTokenPolicy wenn ein bestehendes offlineTokenInfo ersetzt wird. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 60 | Abbildung 4 | Tippfehler | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| regsiterOfflineTokenPolicy() | registerOfflineTokenPolicy() | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 61 | 4.1.2 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| @PolicySetId - Shall be of type UUID or OID. Shall not be URN encoded. | PolicySetId in XACML ist vom Typ anyURI. UUID und OID wären beide nur URN-encoded sinnvoll. Da dies per APPC umgesetzt werden soll, muss ein URN-encoding eingesetzt werden. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Verweis auf APPC und Darstellung der Constraints. Die APPC Spezifikation beschreibt das so wie im Änderungsvorschlag. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 62 | 4.1.2.1 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| @PolicyId - Shall be of type UUID or OID. Shall not be URN encoded. | PolicyId in XACML ist vom Typ anyURI. UUID und OID wären beide nur URN-encoded sinnvoll | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Verweis auf APPC und Darstellung der Constraints. Die APPC Spezifikation beschreibt das so wie im Änderungsvorschlag. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 63 | 4.1.2 | Vorschlag | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Actions - May contain Action elements that qualify the use of specific operations in the context of an EFA. | Hier sollten die konkret zu verwendenden Werte angegeben sein. Es kann natürlich zusätzlich Hinweise für Erweiterungen geben. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Actions sind nicht relevant beim Offline Token. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 64 | 4.1.2.1 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| SubjectMatch - Shall contain at leat one of the following SubjectMatch element SubjectMatch for EFA Identity Assertion NameID. The offlineTokenPolicyRef MUST be used. | Diese kritische Anforderung ist nicht verständlich. "One of the following" impliziert mehrere Auswahlmöglichkeiten. Jedoch wird nur eine Option gegeben (NameID). Es wird auch nicht festgelegt, wie offlineTokenPolicyRef verwendet werden soll. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Ersetzt durch Verweise auf APPC und EPPCG | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 65 | 4.1.2.1 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Environments - O - If relevant for the use case, the expiration time can be defined. Otherwise the access is restricted by the ECR expiration time. | a) Wenn Environments optional ist, sollten die Elemente darunter maximal "conditional" sein, nicht required. B) unklar wie die ECR expiration time aus einer anderen Policy einfluss auf diese Policy haben kann (XACML Policies sind im Enforcement vollkommen unabhängig voneinander) | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Ersetzt durch Verweise auf APPC und EPPCG. Gültigkeit der EFA wird über Environment berücksichtigt. Wenn die Lebensdauer einer EFA geändert wird, dann muss die Lebensdauer der OfflineTokenPolicy auch angepasst werden. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 66 | 4.1.2.1 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| EnvironmentMatch - R - Verifies, that the current date is before the date of expiry, i. e. the grace period has not started. | Es ist keine Grace Period fürs Offline Token definiert. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Keine Grace Periode für das Offline Token | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 67 | 4.1.2.1 | Vorschlag | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| AttributeValue - R - Shall be the point in time when offline token should expire. | Shall be the point in time after which the offline token is no longer valid. | SHOULD ist ein keyword und verwirrt hier | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Ersetzt durch Verweise auf APPC und EPPCG. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 68 | 4.1.3 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| @ID - R - URN encoded unique identifier (UUID) of the assertion | SAML assertion IDs sind vom Typ xs:ID. Der Typ erlaubt keine Doppelpunkte. URNs haben immer mindestens 2 davon. Unencoded UUIDs können übrigens auch nur verwendet werden, wenn ein underscore vorne angefügt wird (xs:ID darf nicht mit einer Zahl beginnen) | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Ersetzt durch Verweise auf APPC und EPPCG. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 69 | 4.1.3 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| The OID must be provided as a string encoded in ISO format. | Unklar ob dot notation, ASN-1 notation oder IRI notation gemeint ist | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Ersetzt durch Verweise auf APPC und EPPCG. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 70 | 4.2.1 | Kommentar allgemeiner Art | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| The codeList shall contain all purpose codes as assigned to the ECR that is to be aligned | Was bedeutet aligned hier? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Consent welches schon Zweck beinhaltet wird um Offline Token Policy ergänzt. Vorgaben der EFA gelten. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 71 | 4.2.3 | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Es sollte SOAP Version 1.2 verwendet werden. | Es muss SOAP Version 1.2 verwendet werden. | Eine freie Wahl der SOAP Version führt zu Interoperabilitätsproblemen | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 72 | 4.2.3 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| /auth:ClaimType/@Uri Claim URI muss in Form von URI festgelegt werden, z.B. "urn:ihe:efa:offlinetoken:id". | 1) Der EFA Verein darf keine URNs für IHE International vergeben. Neue URNs in dieser Spezifikation dürfen somit nicht mit urn:ihe: starten. 2) Von wem genau muss die URI festgelegt werden? Darf der Client die festlegen? Oder der EFA Provider? Warum ist die URI nicht fest vorgegeben? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | lautet jetzt: Uri="urn:efa:2.0:offlinetoken:id" | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 73 | 5.1 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das EFA-Teilnehmersystem erzeugt einen kryptografisch starken Zufallswert und kombiniert diesen mit der eigenen homeComunityId zu einer Kennung | Entweder besteht die offlineTokenPolicyRef aus einem "kryptografisch starken Zufallswert" ODER aus einer UUID. UUIDs können in einigen Situationen erraten werden und sollten nicht als Schlüssel verwendet werden. UUIDs garantieren nur eine gewisse Eindeutigkeit, nicht das sie schwer zu errechnen sein. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Keine Vorgaben durch die Spezifikation. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 74 | 5.2 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Der Security Token Service sucht die passende Policy für die gesendete Kennung und sendet diese in Form einer signierten Policy Assertion zurück an das EFA-Teilnehmersystem | Wenn die Kennung nur verwendet wird um die Policy zu finden und die Policy unverändert signiert und zurückgegeben wird, dann ist nachher nicht der Benutzer mit ID <userID> berechtigt, sondern ein Benutzer mit ID <offlineTokenPolicyRef> (Der Benutzer war zum Zeitpunkt der Token-Erstellung nicht bekannt). Die Policy Prüfung beim Dokumenten/Consent-Zugriff kann dann nicht erfolgreich sein. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Konzeptanpassungen. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 75 | 7. | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die angegebene Gültigkeitdauer des Offline Tokens (und damit der daran hängenden Akte) ist nicht gültig, da sie sie die aktuelle Lebenszeit der EFA überschreitet | 3.1.2 sagt "Das Endes es Gültigkeitszeitraums eine Offline Token (expireDate) ist optional und darf die aktuelle Gültigkeitsdauer der Fallakte überschreiten". Wie kann es dann zu der Fehlermeldung kommen? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Gültigkeitsdauer ist nicht mehr optional. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 76 | 3.2.2.2 | Kommentar allgemeiner Art | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Transaktionen registerOfflineTokenPolicy ist in Ihrer Umsetzung nicht spezifiziert. Die Implementierung ist dem Hersteller überlassen. | Ich stimme dem Ansatz zu, die Interaktionen zwischen PolicyProvider und ResourceManager dem Hersteller zu überlassen, da beides aus einer Hand kommen sollte. Ggf. sollte das hier aber begründet werden. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Beschreibung reicht ggf. aus Sicht der Spezifikation schon. Herstellerspezifische Umsetzung ist genannt. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 77 | 6. | Negativ, kleineres Problem | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Für das ATNA Audit Trail Binding werden zusätzliche Events spezifiziert | Es wird hieraus nicht klar, welche Audit Events verpflichtend sind. Die nicht spezifizierten Transaktionen sollten nicht zwingend auditiert werden. Je nach Implementierungsstrategie könnte es sich hier um einen Applikationsinternen Aufruf handeln, daher ist eine Audit Nachricht nicht immer angebracht. Die registerOfflineToken Transaktion muss schon als XDS P&R nach IHE Regeln auditiert werden. Zusätzlich muss sie ggf. schon als EFA provideData auditiert werden. Hier müssen die Audit Verpflichtungen klarer definiert werden. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Audit bei dem Erstellen und Ändern von Offline Token passiert wie bereits in der EFA spezifiziert, da Offline Token Teil des Consents ist. Die Protokollierung des Einlösens wird in der Spezifikation ergänzt. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 78 | 1 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Spezifikation setzt auf bestehende Mechanismen der Fallakte auf, um den Entwicklungsaufwand möglichst gering zu halten und auf bereits etablierte Verfahren aufzusetzen. | Der für dieses Offline-Token zwingend notwendige Policy Push Mechanismus ist eine optionale Variante, die im Gegensatz zum Policy Pull von EFA Providern nicht unterstützt werden muss (und daher häufig nicht umgesetzt ist). Der Policies zwischen der Registry (wo das Enforcement passiert) und dem Policy Provider (wo die Regeln liegen) über die Clients zu transportieren wird nur toleriert, um die Registry und den Policy Provider "trennen" zu können. Wenn wie hier geschehen die Transaktionen zwischen Registry und Policy Provider nicht spezifiziert werden, ist die Verwendung von Policy Push nicht konsistent. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 79 | 1 | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Spezifikation setzt auf bestehende Mechanismen der Fallakte auf, um den Entwicklungsaufwand möglichst gering zu halten und auf bereits etablierte Verfahren aufzusetzen. | Die Spezifikation ist unnötig komplex. Das gleiche Ergebnis mit den gleichen Sicherheitseigenschaften könnte über einfachere Mechanismen erreicht werden. Z.B. könnte die OfflineTokenPolicy einen beliebigen Leistungserbringer lesend und schreibend auf die Akte berechtigen, solange dieser als Subject Attribut "OfflineTokenRef" eine UUID mitbringt, die in der Policy steht. (Da ein Token nach der bisherigen Spezifikation beliebig oft einlösbar ist, ist die Assertion Dauer irrelevant.) Der einlösende Client müsste nur die UUID per Barcode einlesen und ins Token bringen (z.B. als Claim fürs Identity Token). | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 80 | 1. | Negativ, schwerwiegend | Tarik Idris | InterComponentWare AG | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Außerdem ist die schriftliche Einwilligung des Patienten oder eines Vormunds wesentlich. | Wenn eine schriftliche Einwilligung bei Verwendung des Online Tokens postuliert wird, kann der Patient doch gleich eine neue Fallakten-Einwilligung unterschreiben. Wenn der EFA Provider Fallakten-Merges unterstützt, müsste der Patient auch nur einmal unterschreiben, ohne dass ein kompliziertes Token notwendig wäre. Ein "Token" wäre dann nur für die Identifikation des Patienten und der Fallakte (und des Enddatums) hilfreich. Diese Informationen sind schon beim Client der das "Token" anlegt vorhanden und könnten einfach über den QR-Code übermittelt werden. Wenn der bisher etwas unterspezifiziert Merge ausführlicher definiert werden würde, könnten auch bestehende Teilnehmerberechtigungen übernommen werden. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Anpassung des Konzeptentwurfs ohne Fallakten-Merge. Das Mergen wird noch nicht unterstützt und in der Spezifikation nicht ausreichend bzw. passend definiert. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 81 | 1. | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Außerdem ist es in beispielsweise in Notfallszenarien relevant | Außerdem ist es beispielsweise in Notfallszenarien relevant | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 82 | 1. | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Dies ist ein Mechanismus, der es dem Patienten ermöglicht unabhängig relevante Leistungserbringer für den Zugriff auf die Fallakte zu berechtigen. | Dies ist ein Mechanismus, der es dem Patienten ermöglicht, unabhängig relevante Leistungserbringer für den Zugriff auf die Fallakte zu berechtigen. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 83 | 1. | Vorschlag | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Außerdem ist es in beispielsweise in Notfallszenarien relevant, schnell neue Leistungserbringer für eine Fallakte zu berechtigten. Ein Kommunikationsaufbau zu berechtigten Leistungserbringern für die Editierung der Zugriffsberechtigungen ist zeitintensiv, organisatorisch komplex und nicht realistisch, da eine Zugriffsrechteerweiterung ohne Patient oder Vormund nicht möglich ist. | Außerdem ist es für verschiedene Überleitungsszenarien relevant, schnell neue Leistungserbringer für eine Fallakte zu berechtigten. Ein Kommunikationsaufbau zu berechtigten Leistungserbringern für die Editierung der Zugriffsberechtigungen ist zeitintensiv, organisatorisch komplex und nicht realistisch, da eine Zugriffsrechteerweiterung ohne Patient oder Vormund nicht möglich ist. | Wie kann mit Offline Token in Notfallszenarien umgegangen werden? Ist der Verzicht auf die Patientenzustimmung beim Offline Token im Rahmen von Notfallszenarien möglich? Ich denke, die Komlpexitätsverringerung ist auch außerhalb von Notfallszenarien relevant. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Fokus auf Überleitungsszenarien | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 84 | 1. | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Spezifikation setzt auf bestehende Mechanismen der Fallakte auf, um den Entwicklungsaufwand möglichst gering zu halten und auf bereits etablierte Verfahren aufzusetzen | Die Spezifikation setzt auf bestehende Mechanismen der Fallakte auf, um den Entwicklungsaufwand möglichst gering zu halten und auf bereits etablierte Verfahren aufzusetzen. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 85 | 2.1 | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Nach Erstellung des Offline Token wird dieses ausgedruckt und dem Patienten ausgehändigt. | Nach Erstellung des Offline Tokens wird dieses ausgedruckt und dem Patienten ausgehändigt. | Vorangehender Satz: "eines Offline Tokens". (Lehnwort vs. Internationalismus?) | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 86 | 2.1 | Vorschlag | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das EFA-Teilnehmersystem erzeugt eine Einlöse-Policy, welches die Kennung und die Fallakte verknüpft | Das EFA-Teilnehmersystem erzeugt eine Einlöse-Policy, welches die Offline Token Kennung und die Fallakte verknüpft | Die konsistente Bezeichnung des Konzepts erleichtert das Verständnis. Weitere Vorkommen des Begriffs sollten ebenfalls optimiert werden. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 87 | 2.1 | Vorschlag | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das EFA-Teilnehmersystem generiert einen QR-Codes aus der Kennung | Das EFA-Teilnehmersystem generiert einen QR-Code aus der Offline Token Kennung und stellt QR-Code und Zeichenkette der Offline Token Kennung für den Ausdruck bereit | Falls ein einlösendes EFA-Teilnehmersystem nicht über die Möglichkeit zum Einscannen / zur maschinellen Verarbeiten des QR-Codes verfügt, sollte die Möglichkeit bestehen, die Offline Token Kennung manuell zu erfassen - idealerweise als verkürzte Zeichenkette. Ist das ein Sicherheitsrisiko? | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 88 | 2.2 | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Durch das Aushändigen des QR-Code | Durch das Aushändigen des QR-Codes | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 89 | 2.2 | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das EFA-Teilnehmersystem sendet eine Anfrage inkl. der Kennung aus dem Offline Token sowie der Benutzeridentität des EFA-Teilnehmers an das EFA-Providersystem das Offline Token einzulösen | Das EFA-Teilnehmersystem sendet eine Anfrage zum Einlösen des Offline Tokens inkl. der Kennung aus dem Offline Token sowie der Benutzeridentität des EFA-Teilnehmers an das EFA-Providersystem | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 90 | 2.2 | Kommentar allgemeiner Art | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das EFA-Providersystem sendet nach Prüfung der Benutzeridentität eine temporäre Einlöse-Policy an das EFA-Teilnehmersystem | Das EFA-Providersystem sendet nach Prüfung der Benutzeridentität eine Einlöse-Policy an das EFA-Teilnehmersystem | Ist das die im Rahmen des Anwendungsfalls "Offline Token erstellen" erzeugte und registrierte Einlöse-Policy, oder wird die gesendete Einlöse-Policy hier mit temporärer Gültigkeit neu erzeugt? Ich würde das Attribut "temporär" auslassen. | |||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 91 | 2.2 | Vorschlag | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Der EFA-Teilnehmer editiert die Berechtigungen und gibt sich oder seiner gesamten Einrichtung Zugriffsrechte auf die Fallakte | Der EFA-Teilnehmer editiert die Berechtigungen gemäß Patientenwunsch | Da die Konfiguration der Zugriffsrechte hier nicht zwingend die eigene Einrichtung betrifft, würde ich den Satzteil einfach weglassen oder als optional kennzeichnen. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 92 | 2.3 | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das EFA-Teilnehmersystem sendet eine Anfrage mit der Benutzeridentität des EFA-Teilnehmers an das EFA-Providersystem das Offline Token zu deaktivieren | Das EFA-Teilnehmersystem sendet eine Anfrage zum Deaktivieren des Offline Tokens mit der Benutzeridentität des EFA-Teilnehmers an das EFA-Providersystem | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 93 | 3. | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Interaktionen zwischen den Komponenten werden in Kapitel Fehler! Verweisquelle konnte nicht gefunden werden. detailliert beschrieben. | Kapitelverweis fehlt | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 94 | 3. | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die nachfolgende Tabelle listet die EFA-Akteur auf | Die nachfolgende Tabelle listet die EFA-Akteure auf | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 95 | 3.1.1 | Vorschlag | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Diese Klasse repräsentiert eine strukturierte Abbildung einer Zugriffsregel für eine konkrete EFA in einem Dokument | Diese Klasse repräsentiert eine strukturierte Abbildung einer Zugriffsregel für eine konkrete EFA in einem Dokument. Sie bildet das Konzept der Einlöse-Policy als strukturiertes Dokument ab. | Ein ergänzender Bezug zu den oben genannten Konzepten ist hilfreich. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 96 | 3.1.2 | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Sie ist an einer zufällig erzeugten Kennung gebunden | Sie ist an eine zufällig erzeugte Kennung gebunden | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 97 | 3.1.2 | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das Endes es Gültigkeitszeitraums eine Offline Token (expireDate) ist optional | Das Ende des Gültigkeitszeitraums eines Offline Tokens (expireDate) ist optional | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 98 | 3.1.4 | Vorschlag | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Klasse beschreibt eine Kennung an die eine offlineTokenPolicy gebunden ist. | Die Klasse beschreibt die Offline Token Kennung, an die eine Einlöse-Policy (offlineTokenPolicy) gebunden ist. | Ein ergänzender Bezug zu den oben genannten Konzepten ist hilfreich. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 99 | 3.1.4 | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Kennung setzt sich aus einer kryptografisch sicher erzeugtem Zufallswert und einer Repräsentation der homeCommunityId zusammen. | Die Kennung setzt sich aus einem kryptografisch sicher erzeugten Zufallswert und einer Repräsentation der homeCommunityId zusammen. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 100 | 3.1.4 | Kommentar allgemeiner Art | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Kennung muss gegenüber dritten geheim gehalten werden, da diese einem EFA-Teilnehmer direkten Zugriff auf eine Fallakte ermöglicht. | Den Satz würde ich entfallen lassen. Ziel ist die Erweiterung der Zugriffsrechte um "dritte" bzw. bislang nicht berechtigte EFA-Teilnehmer. Voraussetzung zur Anwendung ist die gültige Authentifizierung als EFA-Teilnehmer. Die Darstellungsform als QR-Code genügt im Zweifelsfall keiner Geheimhaltungsmaßnahme. Selbst wenn die Kennung gegenüber unerwünschten "Dritten" offenbart wird, müssen diese zunächst alle (technischen und organisatorischen) Voraussetzungen erfüllen, um das Offline Token einlösen zu können. Wer ist "Dritter", andere EFA-Teilnehmer oder Unbeteiligte? Gibt es nicht-vertrauenswürdige EFA-Teilnehmer? Kann ein bislang nicht berechtigter EFA-Teilnehmer auf anderem Weg an die Kennung gelangen? | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Es gibt keine Vorgaben zum Aufbau der Offline Token Referenz. Diese müssen lediglich im Kontext einer Patienten-ID eindeutig sein. Die genaue Spezifikation der Umsetzung erfolgt projektspezifisch. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 101 | 3.2.1.1 | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| offlineTokenInfo MUSS über docRelationship (Wert "ersetzt") mit dem gültigen offlineTokenInfo-Dokument in der Fallakte assoziiert werden wenn ein solches bereits existiert. | offlineTokenInfo MUSS über docRelationship (Wert "ersetzt") mit dem gültigen offlineTokenInfo-Dokument in der Fallakte assoziiert werden, wenn ein solches bereits existiert. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 102 | 3.2.1.2 | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Invalidieren eines Offline Token Documents in einer Fallakte und zurückziehen der offlineTokenPolicy beim EFA Policy Provicer. | Invalidieren eines Offline Token Documents in einer Fallakte und Zurückziehen der offlineTokenPolicy beim EFA Policy Provider. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 103 | 3.2.1.2 | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Bestehenden offlineTokenPolicy wird beim EFA Policy Provider mit removeOfflineTokenPolicy zurückgezogen. | Die bestehende offlineTokenPolicy wird beim EFA Policy Provider mit removeOfflineTokenPolicy zurückgezogen. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 104 | 3.2.2.2 | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Transaktionen registerOfflineTokenPolicy ist in Ihrer Umsetzung nicht spezifiziert. | Die Transaktion registerOfflineTokenPolicy ist in Ihrer Umsetzung nicht spezifiziert. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 105 | 4.1.4 | Tippfehler | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Diese Abstimmung wird mit der ValueSet-Gruppe von IHE-D durchgeführt | Diese Abstimmung wird mit der ValueSet-Gruppe von IHE-D durchgeführt. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 106 | 2.2 | Vorschlag | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Aus meiner Sicht fehlt eine Information zur Verwendungshäufigkeit bzw. zum Verwendungsablauf im Rahmen der Einlösung eines Offline Tokens. Wie häufig kann ein existierendes Offline Token eingelöst werden? Was passiert, wenn das Token nicht erneut eingelöst werden kann? Muss ein eingelöstes Offline Token gelöscht und ggf. erneuert bzw. ein neues Offline Token auf Patientenwunsch erstellt werden? | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 107 | 2.2 | Vorschlag | Marcel Klötgen | Fraunhofer ISST | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Da das Offline Token eine Gültigkeitsfrist besitzt, sollte auch festgelegt werden, wie damit umgegangen werden soll. Was passiert bei Ablauf der Gültigkeitsfrist? (Wie) werden Teilnehmer oder der Patient über Ablauf und Maßnahmen informiert? | |||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 108 | 1. Problemstellung | Negativ, schwerwiegend | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Zugriff auf eine seiner Fallakte erteilen | Die Formulierung erzeugt das Bild, die EFA sei eine Patienten-geführte Akte | Im Gegensatz zu anderen e-Health-Akten wurde die EFA als rein Arzt-geführte Akte für die intersektorale Arzt-zu-Arzt-Kommunikation entworfen, um die integrierte Versorgung optimal unterstützen zu können. Patienten willigen in die Führung einer Fallakte ein, die den Patienten jedoch nicht unmittelbar zugänglich ist. Patienten können der Nutzung der EFA zum zweckgebundenen Austausch ihrer Gesundheitsdaten jederzeit widersprechen. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Umformulierung: Arzt löst im Auftrag des Patienten ein | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 109 | 1. Problemstellung | Negativ, schwerwiegend | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| in Notfallszenarien relevant | streichen | Der Zugriff auf Fallakten im Notfall erscheint nicht praktikabel, da die Informationstruktur und die Informationtiefe nicht an den Anforderungen der Notfallversorgung ausgerichtet sind. Das Addendum Offline-Token sieht außerdem kein Metadatum vor, anhand dessen entschieden werden kann, ob die vom Patienten gegebene Einwilligung in das Offline Token eine Einwilligung in den Zugriff auf die Fallakte im Notfall ist. Das beschlossene Notfalldatenmanagement NFDM bietet hierfür bereits einen akzeptierten Rahmen. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Überleitungsszenarien; Beispiele I/E-Health Projekt | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 110 | allgemein | Negativ, schwerwiegend | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das Dokument sollte beschreiben, z. B. in Form von Anwendungsfällen, warum das Addendum Offline-Token relevant ist. | Es bleibt offen, warum der organisatorische und technische Aufwand zur Implementierung von Offline-Tokens gerechtfertig ist und die angestrebten Anwendungsfälle nicht besser durch andere Verfahren abgebildet werden können. Beispiel: Notfalldatenmanagement, Akte-zu-Akte-Adapter (EFA zu EPA, EFA zu EPF), Zweitmeinungs-EFA | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | wird ergänzt | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 111 | 2.1.Offline Token erstellen | Negativ, kleineres Problem | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| (z. B. EFA Portal) | streichen | Der Spezifikationstext sollte sich nicht auf konkrete Systemlösungsangebote beziehen. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 112 | 2.1.Offline Token erstellen | Negativ, schwerwiegend | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Das EFA-Providersystem speichert die Einlöse-Policy und deaktiviert bereits bestehende Offline Tokens sofern vorhanden | Anhand eines Anwendungsfalls sollte beschrieben werden, warum nur ein Offline-Token oder mehrere Offline-Tokens gleichzeitig verwendet werden können sollen. | Es ist unklar, warum für eine Fallakte höchstens ein Offline-Token aktiv sein darf. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Szenarien + Abstimmung mit Datenschutz | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 113 | 2.2. Einlösen eines Offline Tokens | Negativ, kleineres Problem | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| einem beliebigem EFA-Teilnehmer den Zugriff auf die entsprechende Fallakte ermöglichen | einem beliebigen EFA-Teilnehmer derselben EFA-Domain | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Peer2Peer Funktionen analog zur EFA 2.1 Spezifikation. Jeder Peer muss OfflineToken unterstützen. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 114 | 3.1.4. offlineTokenPolicyRef | Negativ, schwerwiegend | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| kryptografisch sicher erzeugtem Zufallswert | Verweis auf akzeptable kryptographische Verfahren einfügen oder die Anforderung aus der Sichtweise eines Bedrohungsszenarios formulieren, z.B. "Der erste Teil der Kennung ist eine geheime Zeichenkette, welche von dritten nicht hergeleitet oder leicht geraten werden kann, vergleichbar mit einem Passwort.". | Ohne den Hinweis darauf, was im Addendum als kryptographisch sicher erzeugter Zufallswert gilt, kann diese Anforderung nicht technisch realisiert werden. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Es ist nicht mehr vorgeschrieben, wie eine Offline-Token-Referenz aussehen soll. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 115 | 3.1.4. offlineTokenPolicyRef | Negativ, schwerwiegend | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Die Kennung muss gegenüber dritten geheim gehalten werden | Anforderungen an ein Passwortschema für die Zeichenkette vorgeben. Anforderung ergänzen, dass Zugriffe mit ungültigem Offline Token auf den STS mit einer Zeitstrafe belegt werden. | Die Kennung muss geheim gehalten werden, da Unbefugte mit einem automatisierten Angriffsverfahren die Kennung erraten können. Diese Angriffsverfahren müssen durch eine Anforderung an das Schema der Kennung hinreichend teuer gemacht werden. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Es gibt keine Vorgaben zum Aufbau der Offline Token Referenz. Diese müssen lediglich im Kontext einer Patienten-ID eindeutig sein. Die genaue Spezifikation der Umsetzung erfolgt projektspezifisch. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 116 | 4.1.2. offlineTokenPolicy | Negativ, kleineres Problem | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| PolicySet | Policy anstelle von PolicySet Policy. | Das Addendum gibt vor, dass höchstens ein Offline Token je Fallakte genutzt werden muss. Die OfflineTokenPolicy könnte daher statt als PolicySet mit nur einer enthaltenen Policy auch einfach als Policy kodiert werden. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | |||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 117 | 4.1.2.1. Policy Attachment for offline token | Negativ, schwerwiegend | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| SubjectMatch: Shall contain at leat one of the following SubjectMatch element SubjectMatch for EFA Identity Assertion NameID. The offlineTokenPolicyRef MUST be used. | Constraint klar definieren | Es ist unklar, wie die in der Constraints-Spalte definierten Anforderungen umgesetzt werden sollen. Muss für offlineTokenPolicyRef ein eigenes SubjectMatch nebst dem SubjectMatch für EFA Identity Assertion NameID eingefügt werden? | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | Es gibt ein eigenes SAML Attribut offlinetoken-id für die offlineTokenPolicyRef, welches auf ein SubjectMatch in der Policy abgestimmt wird. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 118 | 4.1.2.1. Policy Attachment for offline token | Negativ, schwerwiegend | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| SubjectMatch: Shall contain at leat one of the following SubjectMatch element SubjectMatch for EFA Identity Assertion NameID. | Verbindlichkeit von SubjectMatch for EFA Identity Assertion NameID streichen | Die Policy mit dem Policy Attachment wird vom EFA-Teilnehmersystem mit der Operation registerOfflineToken bereitgestellt. Zu diesem Zeitpunkt ist das Subject, welches das OfflineToken einlösen wird, noch unbekannt. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen | SAML schickt offlinetoken-id mit, welches dann auf die offlineTokenPolicyRef gematcht wird | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 119 | 4.1.2.1. Policy Attachment for offline token | Negativ, schwerwiegend | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| SubjectMatch: The offlineTokenPolicyRef MUST be used. | offlineTokenPolicyRef als Ressource-Target spezifizieren | offlineTokenPolicyRef sollte besser als ResourceMatch in der Policy kodiert werden, da es die Fallakte und nicht ein Subject identifiziert. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | offlineTokenPolicyRef ist Teil vom SAML-Token | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 120 | 4.1.4. offlineTokenInfo | Negativ, schwerwiegend | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| technische Umsetzung von offlineTokenInfo durch Advanced Patient Privacy Consents Content Module | Konformität zu APPC herstellen | Das in 4.1.2.1 definierte Schema für PolicyAttachment ist nicht konform zu APPC, da offlineTokenPolicyRef kein in APPC vorgesehener Resourcentyp ist. Eine mögliche Lösung wäre es, das XDS-Document mit einer referenceId auszustatten und diese referenceId in der Policy zu hinterlegen. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Angenommen mit Modifikationen | Spezifikation für EPPCG und APPC ergänzt | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 121 | 4.1.4. offlineTokenInfo | Negativ, kleineres Problem | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Für das DocumentEntry wird noch ein TypeCode benötigt | Im Addendum sollte ein Wert für DocumentEntry.typeCode vorgeschlagen werden, der sich an den aktuellen Ergebnissen der IHE-D ValueSet-Arbeitsgruppe orientiert. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Offline Token Berechtigungsregel ist jetzt Teil des Consents | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 122 | 4.2.1. registerOfflineToken | Negativ, schwerwiegend | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Peer-to-Peer berücksichtigen | Die Transaktion registerOfflineToken beschreibt nicht, wie ein existierendes OfflineToken, dass in einer anderen EFA-Domain zuvor registriert wurde, durch das neue OfflineToken ersetzt wird. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht angenommen | Peer2Peer Funktionen analog zur EFA 2.1 Spezifikation. Jeder Peer muss OfflineToken unterstützen. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 123 | 4.2.3. issueOfflineTokenPolicyAssertion | Negativ, schwerwiegend | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Peer-to-Peer berücksichtigen | Die Transaktion issueOfflineTokenPolicyAssertion beschreibt nicht die Abläufe für den Fall, dass die in der offlineTokenPolicyRef kodierte homeCommunityId fremd ist bzw. die offlineTokenPolicy in einer anderen EFA-Domain registriert wurde. | ||||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Peer2Peer Funktionen analog zur EFA 2.1 Spezifikation. Jeder Peer muss OfflineToken unterstützen. | ||||
| ID | Referenz | Typ | Antragsteller | Organisation | Im Namen von |
| 124 | 5.2. Token einlösen | Negativ, schwerwiegend | Ben Kraufmann | Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS | |
| Kommentar | Existierende Formulierung | Vorgeschlagene Änderung | Begründung | ||
| Entspricht die mitgesendete homeCommunityId nicht der des Security Token Service wird die Nachricht an den entsprechenden Security Token Service weitergeleitet. | X-Domain-Transaktion für die Weiterleitung ergänzen | Der Aspekt der Weiterleitung wird in der Transaktion 4.2.3 issueOfflineTokenPolicyAssertion nicht erwähnt oder beschrieben. Grundsätzlich sollte die Weiterleitung als eigene Transaktion beschrieben werden, da es sich um einen EFA/XDS-Domain-übergreifenden Nachrichtenaustausch handelt. | |||
| Reconcile | Entscheidung | Kommentar | Abstimmung | ||
| Nicht relevant | Peer2Peer Funktionen analog zur EFA 2.1 Spezifikation. Jeder Peer muss OfflineToken unterstützen. | ||||
