IG Diskussion:EFA Spezifikation v2.0

{Auun.01.02}

Unter Fallaktenmanager wird zuerst davon gesprochen, dass der Fallaktenmanager Berechtigungen auf eine Fallakte hat. Im gleichen Abschnitt wird über "verwaiste" Fallakten gesprochen, die keine aktuell gültige Berechtigung mehr ausweisen. Diese verwaisten Fallakten sollen automatisch dem zuständigen Fallaktenmanager "zugeordnet werden". Nach meinem Verständnis ist dies als eine Fallback Regelung für fehlerhaft geführte Fallakten zu verstehen. Es wird aber nur der Fall adressiert, in dem die Berechtigungen der EFA-Teilnehmer fehlen oder abgelaufen sind, ohne dass die Fallakte gelöscht/archiviert wurde, wobei die Berechtigung des Fallaktenmanagers (vor allem wer der zuständige Fallaktenmanager ist) vorhanden ist. Ich würde mir eine Klarstellung wünschen, die es dem Aktenbetreiber ermöglicht einen "Default-Fallaktenmanager" zu definieren, dem über einen ordentlich dokumentierten Prozess die Berechtigung auf eine verwaiste Fallakte erteilt werden kann, wenn der ordentliche Fallaktenmanager nicht zweifelsfrei festgestellt werden kann. (ti, 28.05.2013)

{Pziee.02.01}

Der letzte Satz zur Granularität der Authentisierung verwirrt mich etwas. Ich bin davon ausgegangen dass auch bei Vergabe der Zugriffsrechte auf Organisationsgranularität der individuelle Benutzer in der Assertion mitgeliefert wird (auch wenn er nicht zentral geführt wird und somit nicht weiter verifiziert werden kann). Dies ermöglicht eine weitaus bessere Auditierung, da immer ein individueller Benutzerkontext vorhanden ist. Eine Klarstellung ob Informationen zum Benutzer für Auditzwecke trotzdem benötigt werden, wäre hier sinnvoll (auch wenn dies im späteren Text hoffentlich geklärt wird). (ti, 28.05.2013)

{Pziee.02.02}

Das in 4. als default vorgegebene Policy Push verfahren widerspricht dem im Cookbook verwendetem Verfahren, bei dem der Authorization Decision Provider als PDP die relevanten Policies vom Policy Repository (hier Policy Provider) abfragt. Die Entscheidung basierte auf dem Ziel die Implementierung von Clients zu vereinfachen und einen besseren Schutz der ggf. schützenswerten Policies zu ermöglichen (da beim Cookbook nur der PDP Policies abrufen muss und somit weniger Angriffsfläche besteht). Der Schutz der Policies ist im EFA Kontext wahrscheinlich weniger dringend als im PEPA Kontext (v.a. wegen Blacklisting und krankheitsspezifischen Restriktionen), aber die geringere Implementationslast für Clients sollte auch ein Anliegen des EFA Vereins sein. Die Vorteile des hier gewählten Ansatzes gegenüber dem Cookbook erchliessen sich mir hier noch nicht. (ti, 28.05.2013)

{Pziee.02.04}

Was für Auswirkungen hat die Aussage: "In der Summe bedeutet dies, dass sich ein Provider niemals auf eine Zugriffskontrollentscheidung oder Auswertung einer Einwilligung verlassen darf, die er nicht selbst verantwortet und durchgeführt hat." Ein Provider muss sich ja schon auf die Aussagen von "vertrauenswürdigen" Systemen verlassen: Der Identity Provider kann vom EFA-Teilnehmer betrieben werden. Nicht elektronisch signierte Patientenzustimmungsdokumente die von einem EFA-Teilnehmer kommen werden auch als verlässlich akzeptiert. Ich würde hier einfach berücksichtigen, dass der EFA Provider mit seinen Teilnehmern vertraglich klärt, welches Verhalten von "vertrauenswürdigen" Systemen gefordert ist und wer die Verantwortung bei Abweichungen trägt (bzw. was die Folge von Abweichungen sind). (ti, 28.05.2013)

{Eehä.01.02.01}

Der hier beschriebene Mechanismus für verteilte Fallakten scheint (v.a. von Punkt 4 an) signifikant vom in der 7er Gruppe abgestimmten Vorschlag abzuweichen. (ti, 28.05.2013)

{Eehä.01.04}

Das Aktualisieren eines Dokuments ist in XDS nicht wie hier beschrieben vorgesehen. XDS kennt die Beziehungen "replace", "addendum", "transform" und "transform+replace". Die "replace" Beziehung bewirkt immer ein "deprecated" setzen des alten Dokuments. Es gibt über XDS Metadata Update die Möglichkeit die Metadaten zu aktualisieren, aber nicht die Document uniqueId, d.h. die referenzierten Binärdaten. Ausserdem gilt auch hier: "At any point in time there shall be at most one version of a logical DocumentEntry object with status Approved in the registry/recipient. If this version exists it shall always be the most recent version." (Metadata Update Supplement rev 1.2, line 623-625). Ich würde vorschlagen keine Unterscheidung zwischen Aktualisierung und Ersetzen zu machen. Änderungen am Dokument sollten immer als "replace" aufgefasst werden. Ich halte es nicht für notwendig den Client entscheiden zu lassen ob eine Ersetzung das alte Dokument invalidieren soll. (ti, 28.05.2013) In späteren Teilen des Dokuments (v.a. {CiteD.01.03}) wird die Unterscheidung zwischen Aktualisieren und Ersetzen auch nicht mehr gemacht.

{Eune.01}

1. Ich habe noch keine Abbildung der Stati auf die zugrunde liegende XDS Strukturen gefunden. Ein entsprechender Verweis wäre hier sicherlich ein hilfreicher Hinweis für Implementierer. 2. Ich würde keine so genaue Empfehlung für die Gültigkeitsdauer einer Fallakte machen. Diese sollte eher von fachlicher Seite definiert werden. Da die Fallakte auch nicht notwendigerweise für den gesamten Krankheitsverlauf benötigt wird (sondern z.B. nur für eine Zweitmeinung), ist der ansonsten sinnvolle Ansatz objektive Kriterien für solche Empfehlungen heranzuziehen hier nicht notwendig. (ti, 28.05.2013)

{Peen.01.01}

Die Verwendung eines Offline-Tokens zur Autorisierung eines Teilnehmers über eine Arztrolle (bspw. Kardiologe) widerspricht der Abmachung in der 7er Gruppe, dass Offline-Tokens nur zur Identifikation von Fallakten verwendet werden. Auch der explizite Ausschluss von mehreren Einwilligungserklärungen widerspricht der abgesprochenen Verwendung von Offline-Tokens. Bei Einsatz eines Tokens zur Identifkation einer Fallakte, ist danach ein Anlegen einer weiteren Patientenzustimmung, die den vorher nicht autorisierten Arzt berechtigt, zwingend notwendig. Ansonsten hat der hinzuzufügende Arzt nicht die notwendige Berechtigung um die zu ersetzende Patientenzustimmung zu identifizieren. (ti, 28.05.2013)

{Cngea.01.01}

Bei den Nachbedingungen sollte die elektronische Verfügbarkeit der Einwilligung als Dokument zwingend sein. Bei einer Umsetzung anhand der abgestimmten Konzepte (Einwilligung als CDA Dokument) ist dies immer der Fall und sollte dementsprechend auch von der Spezifikation verlangt werden. Oder geht es hier nur um eine gescannte Version der unterschriebenen Papiereinwilligung? (ti, 28.05.2013)

{Cngea.01.04.01}

Die Anforderung einen rein schreibenden Zugriff für den Aktenersteller auch ohne eine Patientenzustimmung zu ermöglichen ist mir neu. Abgesehen von der rechtlichen Zulässigkeit einer Datenverarbeitung ohne Einwilligungserklärung, entsteht hier die Frage wie das auf der technischen Ebene auf Basis von XDS umzusetzen ist (falls dies weiter unten noch ausgeführt wird mag sich dieser Kommentar erübrigen). Prinzipiell könnte ansteller einer Patientenzustimmung auch ein anderes CDA Document eingesetzt werden, das die gleiche Funktion erfüllt. Dies wäre als eine Art "Policy Activation Document" zu verstehen, dass im Policy Repository die Vergabe eines zeitlichen begrenzten Schreibrechts für den Aktenersteller auslöst (d.h. ein PolicySet das auf eine Policy verweist die dem spezifischen Benutzer Zugriff auf die "Provide and Register" und "Register" Schnittstelle ermöglicht). Der komplette Verzicht auf ein initial hochzuladendes Dokument ist über XDS kaum umzusetzen, da eine P&R Transaktion (die den entsprechenden Folder mit Zweckcode anlegt) nicht ohne einen zu registrierenden DocumentEntry durchgeführt werden kann. (ti, 28.05.2013)

{CiteD.01.03}

Ich würde bei der Aktualisierung noch die Nachbedingung empfehlen, dass veraltete Dokumente entsprechend gekennzeichnet sind. In XDS geschieht dies sowieso (bei Replace wird das alte Doc auf "Obsolete" gesetzt), es macht aber auch konzeptionell Sinn. (ti, 29.05.2013)

{Ccier.01.05}

Der Zusatz zum Weiterleiten des Begründungsdokuments (im zweiten Absatz) überrascht mich etwas. Beim Interaktionsmuster "Daten einstellen" war in der Peer-to-Peer Semantik {CiteD.01.05} keine Rede von einem Weiterleiten von Dokumenten. Wenn ein solches Weiterleiten generell nicht benötigt wird, ist der Hinweis an dieser Stelle sinnlos. (ti, 29.05.2013)

{Cnlio.01.04.01}

Nummerierungsfehler beim Ablauf (Punkt 1 beinhaltet 2 Schritte) (ti, 29.05.2013)

{Cnlio.01.05}

D.h. dass es sich beim Zugriff auf andere Peers nicht um einen rein lesenden Zugriff handelt, sondern dass ein EFA Teilnehmer auch Daten bei einem anderen EFA Provider invalidieren kann. Ist dies ohne eine direkte vertragliche Beziehung zwischen Teilnehmer und dem (fremden) EFA Provider möglich? Oder wird dies über die (von mir vermutete) Vertragsbeziehung zwischen den beiden EFA Providern geregelt? (ti, 29.05.2013)

{Eierf.01}

Ich würde empfehlen das Thema Haftung hier nicht zu erwähnen. Die Haftungsregelung zwischen Identity Provider und EFA Provider sind ein eigenes Thema, das an dieser Stelle nicht ausgiebig behandelt werden kann. Ich würde daher nur vom "ausstellendem Dienst" sprechen, nicht vom "ausstellenden (und haftenden)". (ti, 29.05.2013)

{Eierf.02}

Falls deny-biased im Sinne von XACML (d.h. ein "deny-biased PEP") gemeint ist, ist die Definition nicht korrekt. Jeder PEP führt bei eventuellen Negativindikatoren zu einer Negativentscheidung (nicht zum Abbruch der Entscheidungsfindung!). Nur ein "deny-biased PEP" führt auch ohne Negativindikatoren, sondern einzig durch das Ausbleiben von "Positivindikatoren" zu einer Negativentscheidung. Wenn es hier um die Kombination unterschiedlicher Regeln geht, sprechen wir eher von einem "deny-override". Ggf. wären hier ein paar Beispiele für Negativindikatoren sinnvoll, um den Text verständlicher zu machen. (ti, 29.05.2013)

{Eierf.03}

"außerhalb der Fallakte (wie beispielsweise durch Metadaten)" Dies würde andeuten dass die Dokumentenmetadaten in der Registry nicht als Teil der Fallakte zu verstehen sind. Dies entspricht aber nicht der vorherigen Definition einer Fallakte (z.B. beim Einstellen von Daten werden sowohl das Dokument als auch die Metadaten einer Partition zugeordnet, die Teil der Fallakte ist. Wenn es hier um eine abgestufte Handhabe von Dokumenten und deren Metadaten geht, um z.B. eine Verschlüsselung der Dokumente ohne eine Verschlüsselung der Metadaten zu begründen, verstehe ich den Beweggrund, würde aber eine andere Darstellung bevorzugen (d.h. Metadaten sind - ähnlich wie demografische Daten des Patienten - ein weniger schützenswerter Teil der Fallakte als die Dokumenteninhalte). (ti, 29.05.2013)

{BnsIi.02.04}

Siehe den Kommentar unter {Peen.01.01} zur Notwendigkeit mehrerer Patientenzustimmungen. Die Einschränkung ist auch problematisch für den Umgang mit Peer-to-Peer Fallakten, bei denen es consentInfo Objekte in mehreren Affinity Domains gibt. Selbst wenn diese synchronisiert werden, handelt es sich um unterschiedliche Objekte, da sie auf unterschiedliche XAD-PIDs referenzieren. (ti, 29.05.2013)

{BnsIi.02.07}

Um Peer-to-Peer Fallakten zu unterstützen, wäre hier eine Referenz auf den EFA Provider sinnvoll. (ti, 29.05.2013)

{BnsIi.02.11}

Bei der Document ID sollte bedacht werden, dass auf der XDS Ebene zwei unterschiedliche IDs für die Verknüpfung und das Abrufen zum Einsatz kommen: Die entryUUID für Verknüpfungen und die uniqueId für das Retrieval. (ti, 29.05.2013) 'Beim Element "Zeitliche Einordnung" sollte keine Vermischung mit dem nicht medizinisch relevantem Datum des Einstellens in die Fallakte gefordert werden. Wann das Dokument eingestellt wurde sollte immer mitgeführt werden (es wird im Moment auf der logischen Sicht kein Feld dafür definiert). Wenn der medizinisch relevante Zeitraum (effectiveTime) nicht bekannt ist, sollte er lieber leer bleiben. Ansonsten ist es für Clients nicht möglich zu unterscheiden ob der Zeitraum explizit angegeben wurde (und somit faach relevant ist) oder es sich nur um einen default fallback Wert handelt, dem keine fachliche Bedeutung beizumessen ist. (ti, 29.05.2013)

{BnsIi.02.12}

Ein Ersetzen (Replace Assoziation) in XDS bewirkt immer eine Invalidierung (d.h. "availabilityStatus=Deprecated"). Dies betrifft übrigens nicht nur das Original Dokument, sondern auch seine Addenda! (ti, 29.05.2013)

{BnsIi.02.13}

Die Beziehung zwischen der Klasse documentID und dem Attribut documentID der Klasse documentMetadata ist unklar. Wird die Klasse documentID in der Klasse documentMetadata verwendet oder ist sie als davon unabhängiges logisches Objekt zu sehen? (ti, 29.05.2013)

{Eecim.02.02}

- Zur Assertion der angefragten Patienten ID: Ich kann die Argumente zu epSOS und SSO nachvollziehen. Diese wären durch eine von der Identity Assertion getrennte Assertion der relevanten Patienten ID addressierbar. Zum Thema Effizienzgewinn: Wenn ich bei einer reinkommenden Query durch die Patienten ID alle relevanten Policies abfrage, kann ich einen signifikanten Teil der Anfragen ohne Aufbauen des Request Context beantworten. Der Request Context würde ja im EFA Fall (wo die gesamte Akte auf einmal abgefragt wird) eine signifikante Größe haben. Alle Anfragen bei denen der LE kein Teilnehmer ist, benötigen keine Abfrage der kompletten Metadaten, sondern können alleine anhand der Policies, der Action (z.B. RegistryStoredQuery) und der Subject Informationen negativ beantwortet werden. Bevor Dokumente herausgegeben werden, wird natürlich trotzdem die dort referenzierte Patienten ID mit den Policies verglichen, die aufgrund der Patienten ID in der Assertion herangezogen werden. Wenn die Patienten ID in den Policies (die aus der Assertion stammt) anders ist als die Patienten ID in den Dokumenten Metadaten, matcht die XACML Rule nicht und der Zugriff wird nicht gestattet. Solange es wie bei der EFA keine expliziten Deny Regeln (z.B. pat.-spezifisches Blacklisting von bestimmten Ärzten) gibt, besteht hier auch kein Sicherheitsrisiko. TL;DR: Die Pat ID in der Assertion ist als "Hint" aufzufassen, der eine effizientere Verarbeitung gerade bei nicht authorisierten Benutzern führt. - "Sofern in der EFA-Einwilligung eines Patienten Organisationen bzw. Organisationseinheiten als EFA-Teilnehmer benannt sind, muss der subjectIdentity-Nachweis weiter Informationen enthalten" Ich würde eine explizite Pflicht zur Organisations-ID vorziehen. Die hier zitierte Regel hiesse das der Identity Provider wissen muss wie die EFA Einwilligung strukturiert ist, d.h. ob darin nur Individuen oder auch Organisationen berechtigt werden (Sofern ... muss ...). Es muss ja auch nicht unbedingt eine OID sein. (ti, 29.05.2013)

Namenskürzel

ti

Tarik Idris, InterComponentWare AG
tarik.idris@icw.de