Kommentierung 20180831

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.