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. (ti, 28.05.2013)

{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. (ti, 29.05.2013)

- "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)

{Eouns.01.02.02}

Wenn die alte und die neu anzulegende Fallakte den gleichen Patienten und den gleichen Zweck haben, können sie sich ja nur im Teilnehmerkreis und der Gültigkeit unterscheiden (da ja in der neuen Fallakte noch keine Inhalte sind). Somit unterscheidet sich der Fall nicht vom Interaktionsmuster zum Anpassen einer EFA (ti, 31.05.2013)

{Eouns.01.06}

- Es wird hier von dem Document Repository des EFA Providers gesprochen. Aufgrund der konzeptionellen Darstellung geht der Leser aber eher von einer dezentralen Dokumentenspeicherung mit Ausnahmen für Praxissysteme aus. Daher sollte die Formulierung hier hinsichtlich des Repositories neutraler sein. Ich würde hier vom "Document Repository für den Teilnehmer" sprechen, wobei natürlich noch erläutert werden soll was das heisst. Prinzipiell hat jeder Teilnehmer aber genau ein dediziertes Repository wo er Daten ablegt. - Unter 4.4 sollte auch noch die Verpflichtung der Registry zum Markieren von veralteten verlinkten Dokumenten (d.h. bei availability auf deprecated setzen bei Replace Assoziationen) erwähnt werden. (ti, 31.05.2013)

{Eouns.01.08}

Wie im vorherigen Abschnitt sollte auch hier auf den Umgang mit mehreren Repositories hingewiesen werden. Dies ist ja auch ein Teil der Konzeption und logischen Sicht auf das System, daher ist eine Erwähnung in diesem Kapitel sinnvoll. Der Abruf muss natürlich nicht aus dem Repository des abfragenden Teilnehmers geschehen, sondern aus dem für den einstellenden Teilnehmer zuständigem Repository. (ti, 31.05.2013)

{Eouns.01.09}

Die unter 3.2 beschriebene Prüfung der Einwilligung durch den EFA Provider sollte genauer erläutert werden: Handelt es sich um eine manuelle Prüfung oder eine automatische? Wenn automatisch, was muss dort geprüft werden, da die EFA Spezifikation ja sehr konkrete Vorgaben mit wenig Freiheitsgraden macht? (ti, 31.05.2013)

{Enndn.01.01.01}

"Sofern bereits eine Fallakte zu dem benannten Zweck existiert, wird keine neue Akte angelegt, sondern stattdessen die bestehende Akte um eine Partition und die neu hinzu kommenden Behandlungsteilnehmer erweitert." Dies scheint im Widerspruch zu {Eouns.01.02.02} zu stehen, wo beschrieben wird, dass die neue Einwilligung die alte ersetzt, d.h. es handelt sich um einen neuen "Snapshot" der Teilnehmer, nicht wie hier beschrieben ein Hinzufügen der bisher nicht geführten Teilnehmer. Um die Ad-Hoc Autorisierung durch eine zusätzliche Einwilligung (bei Fallaktenidentifikation über ein identifizierendes Offline Token) zu unterstützen, ist der hier beschriebene Mechanismus der additiven Einwilligung vorzuziehen. Dafür müsste die Einschränkung aus der referenzierten (logischen) Transaktion, dass der anlegende Teilnehmer auf die schon vorhandene Akte autorisiert ist, ausser Kraft gesetzt werden. (ti, 31.05.2013)

{Enndn.01.03.01}

Die auf diesen Abschnitt folgenden Abschnitte wiederholen nur die schon gelisteten Operationen und haben keinen Kommentierungscode. Die folgenden Abschnitte bis zu {Eierz.01} sollten wahrscheinlich gelöscht werden. (ti, 31.05.2013)

{Eierz.01}

Hier gibt es noch die bekannten Differenzen zum IHE Cookbook, z.B. Proof-of-Possession. Dies sollten wir noch harmonisieren. (ti, 31.05.2013)

{Eoexr.02.01}

In der Grafik gibt es bei der Guarantor Assertion 2 initiale Authentifizierungspunkte. Hier wäre eine weitere Erläuterung hilfreich. (ti, 31.05.2013)

{Eocye.01}

Das Vorgehen beim Verweis mit Semantik ist für mich nicht ganz nachvollziehbar. Wer fragt beim Policy Push von wem die Policy an? Wird diese im Client System gespeichert? (ti, 31.05.2013)

{Eocye.01}

Die Notwendigkeit und Auswirkungen der activatePolicy Operation sind mir nicht klar. Die Policy sollte doch gültig sein wenn der Patient ihr zugestimmt hat, unabhängig davon ob sie angefragt wurde oder nicht. (ti.03.06.2013)

Es gibt ausserdem noch eine Differenz zum Cookbook bei der Semantik der requestPolicy Operation. Im Cookbook wird beim policy pull des Authorization Provider immer der gesamte Policy Kontext für den Patienten vom Policy Repository abgerufen. Bei der EFA wird der Policy Kontext wiederum für den Benutzer abgerufen. Da die requestPolicy Operation explizit an das policy push gebunden ist, hat das unterschiedliche Vorgehen wahrscheinlich keine Auswirkungen. Dies sollte aber bei der weiteren Evaluierung genau betrachtet werden. (ti, 03.06.2013)

{MdaBs.01}

Wie schon im Kommentar zu {BnsIi.02.11} erwähnt, ist über die XDSDocumentEntry.uniqueId (und über die XDSFolder.uniqueId) keine Verlinkung über Assoziationen und kein Metadata Update möglich. (ti, 03.06.2013)

{EDold.01.01}

Mir fehlt hier noch ein expliziterer Hinweis auf das logische Konzept purpose das über die codeList abgebildet wird. (ti, 03.06.2013)

Ist ein Hausarztvertrag nicht viel zu breit und unspezifisch um dies mit einer Fallakte abzubilden? Hier geht es ja um ein getrenntes Abrechnungssystem, das nicht-indikationsspezifisch ist. (ti, 03.06.2013)

Für IV Vertrag und Hausarztzentrierte Versorgung sollte in der Value(s) Spalte nicht von "event code", sondern einfach nur von "code" gesprochen werden.

Das für IV Vertrag und Hausarztzentrierte Versorgung gewählte Konstrukt, indem der displayName die für die Differenzierung entscheidende Information enthält, sehe ich kritisch. Es ist nun nicht mehr möglich anhand des codes eine Unterscheidung zwischen zwei verschiedenen IV Verträgen durchzuführen. Wenn für 2 IV Verträge jeweils eine Fallakte geführt wird, heisst dies, dass die Registry nicht anhand der codeList (d.h. codingScheme+code) alleine Filtern kann, sondern auch noch den ursprünglich verwendeten displayName heranziehen muss. Dies widerspricht ausserdem der Definition der codeListDisplayName in volume 3: "The list of human readable descriptions of the meaning of each of the codes present in the codeList." Es handelt sich hier nicht um eine menschenlesbare Erläuterung, sondern um ein kritisches Unterscheidungsmerkmal um unterschiedliche IV Verträge auseinanderzuhalten. Hier sollte auch bedacht werden, dass viele Systeme bei der Rückgabe von displayNames die eingesendete Variante ggf. durch eine normalisierte/kanonische und ggf. übersetzte Variante aus der eigenen Katalogverwaltung ersetzen. Sinnvoller wäre hier eine explizitere Kennzeichnung von Fallakten die auf IV (oder HA) Verträgen basieren. Anstelle von (oder zusätzlich zu) einem immer gleichen Kennzeichen (code="ECR", codeSystem="IHE-D-Cookbook-FolderClassCode"), könnte man die vier Fälle unterscheiden (DMP, IV, HA, DIAG für diagnose-basiert). Ähnlich haben wir das im Cookbook dargestellt: [1]. Die besondere Problematik, wie man unterschiedliche IV und HA Verträge einheitlich benennt, ist aber auch dort nicht adressiert. Wenn man durch einen expliziten code diese Fälle unterscheiden kann und somit nicht das codingScheme zur Unterscheidung zwischen den 4 Fällen benutzen muss, kann man auch auf eine Projekt-spezifische Kennzeichnung von IV und HA Verträgen setzen. Solche Verträge die mittels Fallakte abgebildet werden sollen, würden dann bei allen betroffenen EFA Providern (entsprechend der in der 7er Gruppe diskutierten "Fachlichen Netzwerke") eine eindeutige Kennzeichnung (d.h. eine Kombination aus codingScheme und code) festlegen. (ti, 03.06.2013)

{EDoct.01.01}

Für den classCode würde ich keine LOINC codes empfehlen. Mir ist es noch nicht gelungen dort wirklich passende codes zu identifizieren. Inhaltlich haben wir für das Cookbook die Festlegung auf ein noch zu definierendes value set geplant: Quote: "XDSDocumentEntry.classCode: Festlegung auf ein value set geplant (ca. 5-10 Werte, z.B. Untersuchungsbefund, Diagnostische Rohdaten, Arztbrief, Bilddaten, Pflegedokumentation, Administratives Dokument, Patientendokument)" (ti, 03.06.2013)

{EDoct.02}

Es sollten für die folgenden Attribute auch Festlegungen unabhängig von der Telematikinfrastruktur getroffen werden. Viele der aufgeführten Optionen sind ja auch ohne diese Infrastruktur sinnvoll und nutzbar (z.B. KBV Arztnummer Praxis oder Institutskennzeichen). (ti, 07.06.2013)

{EDoct.02.01}

Ich würde hier eine Affinity Domain spezifische Identifikation nicht ausschliessen wollen. Für die Verwendung als Author Institution bietet sich natürlich die vom EFA Provider geführte Liste der autorisierbaren Organisationen (Einrichtungen, Fachkliniken, Abteilungen, ...) an. Es sollte ausserdem klar definiert werden ob die AuthorInstitution ID verpflichtend ist und auch die Beziehung zum Klarnamen, d.h. muss der Klarname der ID entsprechen oder kann er zusätzliche Eingrenzungen enthalten. Z.B. wenn die ID der UniKlinik A entspricht, darf der Name "Abteilung 1 der Fachklinik X der Uniklinik A" sein? (ti, 07.06.2013)

{EDoct.02.02}

Das Beispiel verwendet den Slot name authorInstitution, nicht authorPerson. Ausserdem wird im Text von "mul-tiple schemes are available for a role" gesprochen. Das sollte doch wahrscheinlich "multiple schemes are available for an author's ID" heissen. (ti, 07.06.2013)

Auch hier sollte klarer definiert werden wann/ob die ID verpflichtend ist, oder ob die ID nur wenn vorhanden wie unten definiert abgebildet werden muss. (ti, 07.06.2013)

Wie ist der Satz "If multiple IDs are known, at least two SHOULD be provided" zu verstehen? Wenn ich drei IDs für einen Arzt nutzen könnte, welche 2 sollten dann verwendet werden? (ti, 07.06.2013)

Für den Arzt in der Privatpraxis erscheinen mir alle gegebenen Optionen wenig hilfreich. Hier sollte auch für Niedergelassene die Option einer nicht globalen ID existieren. (ti, 07.06.2013)

Ist mit "<representedOrganization>" die authorInstitution gemeint? Dieser Begriff ist im HL7v3 Umfeld gebräuchlich, aber bei einem Binding von EFA Konzepten auf ebxml unter Einsatz von HL7v2 Datentypen nicht eindeutig genug. (ti, 07.06.2013)

Generell würde ich die Notwendigkeit eines verpflichtenden Einsatzes von nationalen IDs bei AuthorPerson und AuthorInstitution hinterfragen. Im Berechtigungssystem der EFA sind diese Felder nicht Interoperabilitäts-relevant. Es werden keine Berechtigungen anhand des Authors gesteuert (wie es z.B. in anderen Systemen gemacht wird um dem Autor weitergehende Rechte einzuräumen). Auch fürs Audit sind diese Daten nur begrenzt wichtig, da es keinerlei Überprüfung der gemachten Angaben gibt. Die einzigen Gründe die mir für eine Pflicht zu nationalen IDs hier einfallen würde wäre eine ordentliche Darstellung bei Cross-Community (die man aber eher über den Klartextnamen und ein paar nicht-verpflichtende Formatierungshinweise für den Namen erreicht) und für Auswertungen bei Cross-Community Nutzung. Wobei die Auswertung durch die min. 4 Optionen dadurch immer noch nicht eindeutig wird. Kurz: Ein SHOULD für die Nutzung der hier beschriebenen identification schemes sollte ausreichen. (ti, 07.06.2013)

Ich würde ausserdem einen Vorschlag hinzufügen, wie die Author Role und Author Speciality gefüllt werden sollten. (ti, 07.06.2013)

{EDoct.02.04}

Die Formulierung ist irreführend. Z.Zt. würde ich es wie folgt übersetzen: "Mit diesem Feld darf man nicht die Vertraulichkeit von persönlichen medizinischen Daten schützen." Gemeint ist doch wahrscheinlich eher: "For reasons of protecting the confidentiality of personal medical information this slot SHALL NOT be used." (ti, 07.06.2013)

Hier sollte ausserdem klar zwischen der sourcePatientInfo und der sourcePatientId unterschieden werden. Die sourcePatientId sollte immer gesetzt sein um Fehlzuordnungen (z.B. durch einen MPI) rückgängig machen zu können. Dies ist auch der Ansatz des X-PID [2] (ti, 07.06.2013)

{ItyAn.01}

Um unnötige Mapping-Schritte zu vermeiden, sollte die NameID soweit eingeschränkt werden, dass sie ohne weiteres in die XACML engine gegeben und mit der policy verglichen werden kann. Selbst die Deutschland-spezifischen Einschränkungen in {ItyAn.01.05} sind hier noch zu flexibel. Ich würde hier jeweils eine einzige Definition für Niedergelassene und Ärzte in Einrichtungen vorschlagen. Zumindest sollte dem Leser klar gemacht werden dass die NameID mit den Policies abgeglichen wird und somit der Ersteller der Policies den gleichen Identifikator verwendet. Wenn dies nicht der Fall ist, könnte es passieren dass der IdP die ID des HBA AUT Zertifikats verwendet, die Policy aber auf eine bestimmte Lebenslange Arztnummer der KV des gleichen Arztes abgleicht. (ti, 07.06.2013)

Die Subject Confirmation Method sollten wir noch wie besprochen diskutieren. (ti, 07.06.2013)

Wenn als AuthnContextClassRef nur urn:oasis:names:tc:SAML:2.0:ac:classes:X509 verwendet werden darf, heisst dass dann das kein Benutzer über Benutzername+Passwort identifiziert werden darf? In {Eecim.02.02} unter "Art der Authentifizierung" deutet die Formulierung ja eher auf eine Entscheidung des EFA Providers hin, welche Authentifizierungsmethoden er bei IdPs erwartet. (ti, 07.06.2013)

{ItyAn.01.02}

HP Identifier: XSPA definiert hier "urn:oasis:names:tc:xacml:1.0:subject:subject-id" als Attributsnamen, während XUA "urn:oasis:names:tc:xspa:1.0:subject:subject-id" verwendet, was doppelt falsch ist: weder ist es wirklich eine ID, noch ist es von XSPA mit dieser URN versehen worden. Beide Alternativen haben den Nachteil, dass sie die Referenzierung auf die primäre ID des Benutzers in einer XACML policy unnötig erwschweren. Da die primäre ID des Benutzers in SAML nicht als AttributeStatement mit name und type sondern als NameID Element übertragen wird, gibt es keinen "natürlichen" Attributsnamen um in einer Policy einen bestimmten Benutzer zu authorisieren. Die logischste URN dafür wäre eigentlich "urn:oasis:names:tc:xacml:2.0:subject:subject-id" (ob 1.0 oder 2.0 ist dabei nicht entscheidend). Daher würde ich mich gegen die von XSPA (und z.T. von XUA) gewählte Umdefinition des Klarnamens zur "subject-id" aussprechen. Der Klarname kann auch viel besser mit Rückgriff auf den LDAP Standard definiert werden. Im XACML Core wird dies auf Seite 129 (ab Zeile 5027) als Pflicht (zumindest für den XACML Request Context) für in LDAP schon existierende Attribute definiert: "Where a suitable attribute is already defined in LDAP [LDAP-1, LDAP-2], the XACML identifier SHALL be formed by adding the attribute name to the URI of the LDAP specification. For example, the attribute name for the userPassword defined in the RFC 2256 SHALL be: http://www.ietf.org/rfc/rfc2256.txt#userPassword"

Daher mein Vorschlag: "urn:oasis:names:tc:xacml:2.0:subject:subject-id" in XACML policies bezeichnet den primären Identifier des Benutzers, "http://www.ietf.org/rfc/rfc2256.txt#cn" im SAML AttributeStatement und im XACML Request Context bezeichnet den Klarnamen des Benutzers. (ti, 07.06.2013)

Structural Role of the HCP: 1. XUA erweitert erlaubt ausser ASTM E1986 auch SNOMED CT und ISO 21298 - hatten wir uns nicht in der 7er Gruppe vorläufig eher für SNOMED ausgesprochen? 2. Wenn die Rolle auf die hier beschriebenen eingeschränkt wird, wie wird dann z.B. der Fallaktenmanager abgebildet? 3. Ich würde für die Rolle einen strukturierteren Datentyp wählen. XUA sieht "urn:hl7-org:v3#CE" vor, ich hätte eher CV gewählt. Aus Sicht des Cookbooks ist es durchaus wichtig unterschiedliche Codesysteme unterstützen zu können, gerade auch um die unterschiedlichen Aktentypen abbilden zu können. (ti, 07.06.2013)

Healthcare Professional Organisation und Healthcare Professional Organisation ID: Ich würde zumindest die Organisation ID immer zwingend übertragen. Aus Sicht der Authorisierung von Einrichtungen erscheint mir die organisatorische Zugehörigkeit als das kritischere Unterscheidungsmerkmal. Ich vermute mal Point of Care ist mandatory und als Grundlage für die Policies gedacht, um den Fall des Belegarzt abzudecken, dessen Daten nicht im KH System landen sollen, mit dem er manchmal auf Fallakten zugreift. Dieser Fall sollte adressiert werden, aber locality scheint mir nicht die optimale Lösung zu sein. Erstens ist es ein Environment Aspekt und nicht Teil des Subjects. Zweitens ist es im Gegensatz zur Organisation ID nicht in IHE XUA definiert. Wenn locality eingesetzt wird, würde ich ausserdem die Definition von XSPA vorziehen: "Unique identifier of the servicing organization". Zusätzlich würde ich auch den Type einschränken: "URN encoded OID of the Healthcare Professional Organisation" (wie bei Org-ID). (ti, 07.06.2013)

Purpose of Use: 1. Für PoU würde ich auch auf einen strukturierten Typ setzen, wie auch in XUA definiert. Also "urn:hl7-org:v3#CE" oder "urn:hl7-org:v3#CV". 2. Im Cookbook haben wir das Attribut nicht mandatory gesetzt, sondern stattdessen Treatment bzw. den ungefähr equivalenten Wert 1 aus ISO 14265 als Default Wert annehmen muss. Dies erlaubt eine explizite Nennung bei Ausnahmen (v.a. Notfallzugriff) ohne dem Client zuviel abzuverlangen. (ti, 07.06.2013)

{ItyAn.01.03}

Für Clinical Speciality bietet sich der epsos Name an: "urn:epsos:names:wp3.4:subject:clinical-speciality". (ti, 07.06.2013)

{Eocyo.01.01}

Ich kann dieser Unterscheidung im Kontext eines EFA authorization statement nicht ganz folgen. Eine solche Dreiteilung leuchtet mir für die Patientenzustimmung ein, in dem Fall ist mir aber der Nutzen als Assertion nicht klar. (ti, 07.06.2013)

{Eocyo.01.02}

@PolicySetId: BPPC sieht OIDs als Policy Identifier vor. XACML schreibt nur vor das es eine URI sein muss. Ich würde als Kompromiss auch die Verwendung von URN prefixed OIDs erlauben. (ti, 07.06.2013)

@PolicyCombiningAlgId: Ich halte es für riskant sich auf die Reihenfolge der Policies zu verlassen, v.a. da diese ggf. on-the-fly vom Policy Provider zusammengebaut werden. Hier wäre deny-override (in Kombination mit einem deny-biased PEP) sinnvoller. (ti, 07.06.2013)

SubjectAttributeDesignator@AttributeId: In der SAML Assertion wurde "urn:oasis:names:tc:xacml:1.0:subject:subject-id" als Klarname definiert. D.h. hier müsste beim Aufbau des Kontext das vorhandene Attribut ...:subject-id rausgeschmissen werden und eine Umwandlung von NameID auf ...:subject-id stattfinden (siehe auch {ItyAn.01.02}). (ti, 07.06.2013)

SubjectAttributeDesignator@DataType: Ich würde hier wie auch schon bei der SAML NameID eine klare Festlegung befürworten. Ansonsten werden v.a. cross-community Szenarien sehr schwierig. (ti, 07.06.2013)

ResourceAttributeDesignator@AttributeId: Woher weiss der Policy Provider auf welche Ressourcen ID der Benutzer zugreifen darf? Was ist die Ressourcen ID in diesem Kontext? (ti, 07.06.2013)

{Eocyo.01.03}

Die zu verwendenden Basis-PolicySets sind eigentlich durch die Rollenbeschreibungen und das Rechtemodell der EFA voll definiert. Wäre es somit hier nicht sinnvoller diese Regeln (ggf. nicht normativ) mitzuliefern? (ti, 07.06.2013)

{EHetw.01}

Gehört das wirklich an diese Stelle? Es scheint mir inhaltlich nicht in den Implementierungsteil zu passen.

{EDXDg.01}

Um Hybridsysteme zu unterstützen, sollte es für EFA systeme keine Pflicht sein Dokumente ohne Folder abzulehnen, bzw. Folder ohne EFA Code abzulehnen. (ti, 07.06.2013)

{EDesa.01}

Der einleitende Satz kündigt ein Mapping auf XDR an. XDR kennt nur Document Source und Document Recipient. Die anderen Akteure (Repository, Consumer, Registry) sind Teil von XDS. Dies deutet darauf hin, dass hier der Einsatz von XDS ggf. angebrachter wäre. (ti, 09.06.2013)

{EDesa.02}

Wie ist die Aussage "Documents cannot be copied by reference" zu verstehen? Geht es um das hinzufügen eines Dokuments per Assoziation mit Typ "Reference" (siehe Vol.3 4.1.4.1) in einem Submission Set? Oder geht es um das Hinzufügen eines existierenden Dokuments per Assoziation mit dem neu anzulegenden Folder (Vol.3 4.1.5)? Oder geht es um die Verknüpfung eines bestehenden Dokuments aus einem anderen Folder mit einem neuem Dokument per Assoziation (siehe Vol.3 4.1.6.1)? (ti, 07.06.2013)

{EDesa.02.01}

Ist mit embrace "The requestor (EFA Client) SHOULD embrace the provided documents as a single IHE XDS submission set acc. to [IHE ITI TF-2a]." gemeint, dass alle Dokumente in einem einzigen SubmissionSet gesammelt werden sollen? (ti, 07.06.2013)

"The EFA provider MUST NOT process any metadata assigned to the submission set, it MUST solely rely on the document metadata and contents." Auch hierdurch wird die Umsetzung von Hybridsystemen unnötig erschwert. Auch wenn reine EFA Systeme das Submission Set nicht persistieren müssen, sollte es nicht verboten sein dies zu tun. Aus Interoperabilitätssicht spricht nichts dagegen wenn ein EFA Provider System das SubmissionSet speichert, solange sich dadurch das externe Verhalten nicht ändert. Aus Sicherheitssicht sollte einfach die Abfrage dieser Objekte nicht über EFA Schnittstellen möglich sein. (ti, 07.06.2013)

"The EFA provider MUST NOT register documents that are only provided through associations." Geht es hier um Dokumente die nur per Referenz Assoziation (siehe Vol.3 4.1.4.1) in das SubmissionSet inkludiert wurden? (ti, 07.06.2013)

{EDesa.02.02}

Die unterschiedlichen Akteure und ihre Aufgaben erschliessen sich mir beim Lesen nicht. Es fängt an mit "The XDS Document Repository provider SHALL ...", dann kommt "The provider of the XDS Document Repository provider MUST ..." was ja auf ein versehentlich gedoppeltes Wort deutet. Aber dann geht es weiter mit "The ECR provider SHALL ..." während die Response dann vom "EFA Document Registry Service provider" (in {EDesa.02.03}) kommt. Hier wären 1. eine einheitliche Benennung und 2. ein Übersichtsbild hilfreich. (ti, 09.06.2013)

Ist das Document Repository nicht (im Sinne einer dezentralen Datenspeicherung) Teil des EFA Clients? In dem Fall würde die Kommunikation zwischen Document Source und Document Repository interessanterweise eine interne Kommunikation des EFA Clients sein. (ti, 09.06.2013)

Der Akteur XDR Document Repository existiert so nicht in IHE XDR. Es gibt nur einen XDR Document Recipient. Dies ist relevant, wenn es um die Möglichkeit des Abrufs eines Dokuments geht. Hierfür hat das XDS Document Repository eine Schnittstelle, der XDR Document Recipient aber nicht. (ti, 09.06.2013)

Wenn schon eine Fallakte mit gleichem Zweck existiert, soll auf das "modify consent" Recht geprüft werden. Wann dieses Recht festgelegt wird, wer das darf und wie es geändert werden kann erschliesst sich mir (noch) nicht. Ich vermute, das Ziel hier ist es eine einfache Ad-Hoc Berechtigung optional zu ermöglichen, in dem man einfach die gleiche Akte nochmal anlegt. Dies halte ich für sinnvoll, auch wenn dies noch viel klarer spezifiziert werden müsste. V.a. das Verhalten hinsichtlich des consent info Dokuments ist sehr unklar. Es wird initial davon gesprochen, dass es die consent info nur einmal geben darf. Am Ende des hier beschriebenen Prozesses gibt es aber (mindestens) zwei consent info Dokumente. Was vereinheitlich wird ist nur die access control policy, was mir fraglich erscheint, da es sich auf der XACML Ebene wahrscheinlich sowieso um mehr als ein Objekt (mehrere Policies mit vielen Rules) handelt. (ti, 09.06.2013)

{EDesa.02.03}

Ich würde als Reponse Status Type nicht Success erwarten, wenn die Anfrage nicht verarbeitet wurde (und somit die Fallakte auch noch nicht existiert, bzw. die Dokumente noch nicht registriert sind). "Processing deferred" ist ja auch keine Garantie, dass die Anlage zu einem späteren Zeitpunkt (d.h. nach der manuellen Intervention) nicht noch fehlschlägt. (ti, 09.06.2013)

{EDesa.02.04}

4702: In {ItyAn.01} wurde X509 als einziger erlaubter AuthContext festgelegt, daher sehe ich nicht ganz, wie diese Fehlermeldung auftreten sollte (ausser es handelt sich um eine Protokollverletzung, worauf der Benutzer ja kaum wie beschrieben reagieren kann. (ti, 09.06.2013)

{EDesa.02.05.02}

Hier wäre es sicherlich hilfreich die EFA 1.2 Audit Trail Spezifikation zu verlinken. Wäre es nicht simpler diese Spezifikation, wenn sie keine Änderungen benötigt, einfach hochzuzählen (d.h. als EFA Audit Trail 2.0 neu herauszugeben)? (ti, 09.06.2013)

Wie verhält sich die EFA Audit Anforderung zu den ebenso verpflichtenden Audit Anforderungen des IHE XDS Profils (bzw. XDR). Müssen clients und registry/repositor jeweils zweimal auditieren? (ti, 09.06.2013)

{EDesa.03.04}

Ich würde empfehlen, dass Fehler die durch den Benutzer durch unterscheidliche Aktionen korrigiert werden können auch unterschiedliche Error Codes erhalten. So kann der EFA Client den Benutzer ideal in der Korrektur des Fehlers unterstützen, ohne die Fehlerbeschreibung parsen zu müssen (wie es bei den 3 Fehlern mit code 4109 der Fall ist). (ti, 09.06.2013)

{EDesa.04.01}

Warum können hier ausser den consentInfo und consentDoc Dokumenten auch noch andere Dokumente eingestellt werden. Wäre es hier nicht sinnvoller darauf zu bestehen, dass diese Transaktion nur die dargestellten Dokumente beinhält. Wenn weitere Dokumente zum Abschluss notwendig sind, können diese ja durchaus vorher hochgeladen werden. (ti, 09.06.2013)

{EDesa.05}

"The initial query is restricted to folder metadata and does not return any data contained within that folders." Heisst initial, das immer zuerst diese Query gemacht werden muss? Muss die Registry prüfen was die "initiale" Query war (und somit pro Client den Zustand halten)? (ti, 09.06.2013)

{EDesa.05.01}

In der Tabelle klingt die purpose Einschränkung so, daß man nur nach einem spezifischen Grund fragen darf. In der Auflistung darunter wird es so dargestellt, dass man nur nach Fallakten fragen darf, aber nicht einen spezifischen Grund angeben muss. Welches ist korrekt? (ti, 09.06.2013)

{EDesa.05.04}

Die Action to be taken bei "No Data" macht wenig Sinn, wenn der Client die drei Fälle nicht unterscheiden kann. Soll er Sie unterscheiden können oder ist dies aus Datenschutzgründen abzulehnen (v.a. da man sonst abfragen könnte ob ein Patient mit ID X eine Fallakte mit Code Y hat). (ti, 09.06.2013)

{EDesa.06.02}

"if the purpose is aligned by the new consent: change the eventList codes of all containers that are assigned to the eCR to the new purpose" heisst das man kann damit den Purpose ändern? "Aligned" ist da sehr zweideutig. Was passiert mit den alten consentInfo Dokumenten? Werden diese nicht invalidiert? Muss die register Nachricht eingentlich noch den alten Code in der Folder.codeList haben? Wenn ja, wie wird der neue code transportiert? Wenn nein, woher weiss der EFA Provider, dass es sich hier um eine Änderung des Zwecks handelt, da ja auch ein neu anzulegender Folder hierfür werden werden kann. Dabei darf man auch nicht ausser lassen, dass sich die Folder codeList ohne XDS Metadata Update nicht anpassen lässt. (ti, 09.06.2013)

{EDcui.02.02}

RegisterDocumentSet nicht ProvideAndRegister (ti, 09.06.2013)

Wenn die Registry zentral und die Document Repositories dezentral stehen und ggf. als EFA Clients auftreten, sollte die Registry sich nicht auf die Autorisierungsprüfung der Repositories verlassen. (ti, 09.06.2013)

{EDcui.03.01}

Werden reine ID Abfragen (d.h. returnType = ObjectRef) unterstützt? Im Moment wird dies nicht ausgeschlossen. Das kann auch ein sinnvoller Mechanismus sein, um zu prüfen ob seit Beginn der Session neue Dokumente hinzugefügt wurden. (ti, 09.06.2013)

{EXoce.02.01}

Wie sollen eigentlich Dokumentenersetzungen realisiert werden? Die folgenden Einschränkungen scheinen Assoziationen zu einem bestehendem Dokument praktisch auszuschliessen: "The EFA provider SHOULD ignore this grouping and MUST ignore all associations between documents and submission sets." (also auch Assoziationen zwischen 2 Dokumenten, oder ist dies nur eine sprachliche Ungenauigkeit?) sowie "Documents to be stored and registered SHALL be included with the request. The EFA provider MUST NOT register documents that are only provided through metadata and/or associations." (man kann somit kein existierendes Dokument per RPLC Assoziation ersetzen, da es dann nicht "provided" wäre). (ti, 09.06.2013)

{EXoce.02.04}

Decode ist nicht der richtige Begriff für das erfolgreiche Verarbeiten. Auch die Kombination aus processing und forwarding ist sehr ungenau. Es geht eigentlich um das Processing der Registry und das Forwarding vom Repository. (ti, 09.06.2013)

Namenskürzel

ti

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