Stream: german (d-a-ch)
Topic: E2E-Enryption
Markus Ritthaler (Jun 22 2021 at 12:40):
Hallo zusammen,
ich bin leider noch Neuling in Sachen FHIR, daher besteht die Möglichkeit und aktuell noch am Einlesen, dass die Frage bzw. Problematik sich einfach aufklären lässt.
Wir führen aktuell ein gefördertes Forschungsprojekt durch, an welchem auch ein Industriepartner beteiligt ist. Kern ist die Schaffung eines intersektaralen Konsil, welches als Standard FHIR nutzt. Unser Partner hat bereits solche Konsile im Portfolio, jedoch erfüllen diese noch keinen Standard. Das Sicherheitskonzept sieht wie folgt aus: medizinische und persönliche Daten werden getrennt voneinander auf unterschiedlichen Servern E2E verschlüsselt gespeichert. Der Partner möchte dieses, da zertifiziertes und etabliertes Konzept, gerne beibehalten. Wir sehen dies jedoch im Rahmen des FHIR-Standards als schwierig an. Zwar wäre die Trennung der Daten machbar (mehrere FHIR-Server als verteiltes System) aus unserer Sicht möglich, jedoch ist eine eine E2E-Verschlüsselung (d.h. die Daten würden ausschließlich im Client ver-/entschlüsselt) aus unserer Sicht nicht FHIR-konform möglich. Dazu hätte dieses Vorgehen für uns den Nachteil, dass ein Versand bzw. das Verarbeiten als Bundle dann (soweit wir das gelesen haben) nicht mehr möglich wäre.
Da wir alle wie gesagt erst Neulinge sind und wir das in der Literatur /dem Standard nicht explizit rausgelesen haben, wollten wir uns hier durch die Community rückversichern.
Danke schon mal und VG
Markus
Ingo Wolf (Jun 22 2021 at 15:46):
Hallo Markus,
deine Einschätzung ist korrekt. Ein Server, der nur verschlüsselte Daten empfängt und verarbeitet kann keine standard-konforme FHIR-API realisieren, die über "store & forward" hinaus geht. Da Du erwähnt hast, dass es um das Versenden und Verarbeiten von Bundles geht, sehe ich nicht, an welcher Stelle ein FHIR-API zum Einsatz kommt, ohne die System-Architektur zu kennen. E2E-Verschlüsselung ist zwar ein Mechanismus, um sicherheitstechnische Anforderungen umzusetzen, jedoch kein Allheilmittel...
my2cent Ingo
Morten Ernebjerg (Jun 22 2021 at 16:12):
Hi @Markus Ritthaler, ich glaube, man muss hier zwischen FHIR-Konformität generell und konforme FHIR REST APIs unterscheiden.
Einerseits, wie Ingo schreibt, kann man nicht direkt auf ein E2E-Backend-System eine (sinnvolle) FHIR REST API packen, weil der Server ja per definition keine entschlüsselte Resources ausgeben kann (so wie der API-Spec vorgibt). Man könnte höchsten die verschlüsselte Daten in Resources vom Typ Binary verpacken und damit CRUD über eine FHIR REST API machen, hätte aber nicht viel gewonnen, da man nicht suchen usw. kann.
Anderseits kann man durchaus Systeme habe, die auf E2E-Verschlüsselte Daten beruhen und konform mit FHIR arbeitet - bei Data4Life machen wir das so, z.B. auch als teil vom Europäischen Smart4Health-Projekt. FHIR schreibt nicht vor, wie man Resources speichern oder übertragen muss - die E2E zu verschlüsseln ist von daher nicht nicht-konform an sich. Wie Du schreibst, muss man aber dann die Funktonalität, die man sonnst im Server hat, auf das Frontend verlagern, wo die Daten entschlüsselt vorliegen. Das ist nicht unmöglich, aber auch nicht ganz einfach: einerseits hat man weniger Speicher und CPU-Kraft zur Verfügung, anderseits ist der Tooling erheblich schwächer - man kann da nicht einfach einen HAPI FHIR Server hochfahren. Ob das möglich & machbar ist, hängt also von den genauen Umständen an.
Markus Ritthaler (Jun 23 2021 at 07:26):
Hallo,
danke schon mal für eure Rückmeldungen. Dann weiß ich aktuell schon mal in welche Richtung wir schauen müssen bzw. in welche Richtung wir uns einlesen müssen. Aktuell steht auch die Architektur noch nicht fest, da hier noch weitere Themen (Anbindung TI etc.) reinspielen. Mir ist es nur wichtig, dass ganze von vornherein in die richtige Richtung zu lenken, auch wenn wir aktuell mehr mit regulatorischem Kram beschäftigt sind als uns mit der eigentlichen Aufgabe zu beschäftigen.
@Ingo Wolf : du hattest erwöhnt, dass Bundle und FHIR-API sich widersprechen? Ich hatte das so verstanden, dass ein Bundle ein Container ist, mit dem man definierte Ressourcen zusammenfassen kann. Dabie geht es uns darum, dass mit dem Konsil definierte und (von den Ärzten) vorgegebene Informationen erfasst und verarbeitet werden müssen. Daher hatte wir es als Bundle geplant.
VG
Markus
Ingo Wolf (Jun 23 2021 at 08:27):
Hallo @Markus Ritthaler,
ich habe nicht gesagt, dass Bundle und FHIR-API sich widersprechen. Mit dem Bundle als Container kann man, wie Du sagst, definierte Ressourcen zusammenfassen und dabei den kontextuellen Zusammenhang der Ressourcen in reduzierter Form an andere (FHIR-)Systeme übertragen. Nur kannst Du dieses Bundle (bzw. dessen strukturierte Ressourcen) nicht weiterverarbeiten, solange es verschlüsselt ist. Welche Funktionen des FHIR-API (CRUD, search, operations etc.) sinnvollerweise zum Einsatz kommen, wird durch das Anwendungsdesign bestimmt, ebenso welche Sicherheitsmechanismen und System-Architektur (Client-Server, P2P) für die Umsetzung der Anforderungen der Anwendung geeignet sind.
Wie Morten richtig sagt: was machbar und möglich ist, hängt von den genauen Umständen ab...
Simone Heckmann (Jun 24 2021 at 14:00):
Das ist ja im Prinzip das "ePA"-Dilemma. Die Daten (MIOs) liegen im FHIR-Format vor, jedoch E2E-verschlüsselt, so dass der Server nicht als FHIR-Endpunkt agieren kann, sondern im Prinzip nur als eine Ablage für verschlüsselte Dokumente (Bundles) agiert.
Da könnte man höchstens noch mit einer unverschlüsselten DocumentReference arbeiten, die ein paar Informationen über die Art des Dokumentes hat und für die REST-basierte Abfrage genutzt werden kann. Das verschlüsslte Bundle ist dann einfach nur das verlinkte Attachment dazu.
Das alles ist natürlich verbunden mit massiven Einbußen seitens der Funktionalität und mitunter auch datenschutz-technisch suboptimalen Konsequenzen. Just heute wurde mir bewusst, dass dies im Szenario einer "Datenspende" zur Konsequenz hat, dass die Verantwortung für die korrekte und vollständige Anonymisierung der Daten damit bei Endpunkt des Patienten (App!?) liegen muss. :flushed:
Morten Ernebjerg (Jun 24 2021 at 14:56):
Ich denke, dass es diese derzeitige Einbußen auch damit zusammenhängen, dass Client-Side FHIR Handling & Tooling etwas vernachlässigt wurde, weil es üblicherweise immer irgendwo einen Server gab, den man die ganze Logik zuschieben konnte. Natürlich hat man auf mobilen Endgeräten auch einfach weniger Power (CPU/Speicherplatz), aber man kann da durchaus vernünftiges Data-Handling machen, wenn man den Qualitätsstandard hoch genug setzt. Insofern hoffe ich, dass die Verbreitung von E2E-Verschlüsselung auch zu einem verstärkten Fokus auf client-side FHIR führen wird.
Simone Heckmann (Jun 24 2021 at 16:11):
Es widerspricht halt ein Stück weit der FHIR-Philosophie, die Komplexität serverseitig zu handeln um die Entwicklung von Client-Applikationen so einfach und kostengünstig wie möglich zu machen…
Christof Gessner (Jun 24 2021 at 19:03):
Ich stelle mal die Hypothese auf, dass es Systeme oder Kontexte geben wird, in denen das "verwalten" verschlüsselter Datenobjekte mithilfe geeigneter Metadaten im Vordergrund steht (natürlich via FHIR API auf Ebene dieser Metadaten). Und andere Kontexte, in denen die E2E-Encryption keine Anforderung ist. Die Verbindung zwischen diesen beiden "Welten" wird dann wohl clientseitig stattfinden müssen.
Markus Ritthaler (Jun 25 2021 at 06:58):
Hallo @Simone Heckmann ,
unser Partner nutzt sogar ein ähnliches Konzept, wie das der ePA (es gab dort nur keinen Aktenschlüssel, da die bisherigen Anwendungen auf eine bidirektionale Arzt-Arzt-Kommunikation ausgelegt sind). Wir sind auch bereits mit der gematik im Austausch, nur FHIR stand noch nicht auf der Agenda, da wir hier noch Grundsatzfragen zu klären haben.
Wir hatten auch schon mehrere mögliche Lösungen diskutiert (die nötigste Logik in den Client auslagern und dann nur verschlüsselte Ressourcen versenden bis hin zu lokal die kritischen Inhalte (=persönliche Daten) zu verschlüsseln und verschlüsselt in die Ressource zu schreiben). Allerdings sehen wir als Team das dahingehend kritisch, dass hier aus unserer Sicht dann die Interoperabilität ein wenig einbüßt (dahingehend, dass dann immer ein proprietärer Client benötigt wird) und das ganze natürlich nicht unerheblichen Wartungsaufwand in den Clients nach sich zieht. Wir (aus wissenschaftlicher Sicher) fänden den Ansatz sympatisch, dass die Anwendung (die in der TI angesiedelt ist) perspektivisch den noch kommenden IdP nutzt und damit (entsprechende Vergütungen etc. vorausgesetzt) "allen offen steht".
Morten Ernebjerg (Jun 25 2021 at 07:25):
@Christof Gessner Ja, dem stimme ich zu, es wird bestimmt weder nur das eine noch nur das andere geben - und so sicherlich auf mehr "Portale" zwischen diese Welten. Wo es passt, ist es ja absolut Sinnvoll, die Last auf den Server zu liegen, da bin ich auch bei Dir @Simone Heckmann - ich meinte nur, dass man sich halt technologisch bisher weniger mit den Use Cases beschäftigt hat, wo es nicht geht. Die Komplexität und Kosten bei der Client-Entwicklung hängt ja auch davon ab, in welchem technologischen Ökosystem man arbeitet. So machen JavaScript-Frameworks with React oder Vue es ja heute möglich, sehr komplexe Webapps in überschaubarer Zeit zu bauen.
@Markus Ritthaler Es ist ein guter Punkt, dass E2E APIs nicht so interoperable sind, weil nicht standardisiert. Theoretisch müsste es aber nicht so bleiben (auch wenn das sicherlich erst für Weile so sein wird...) . Bei E2E ist die unverschlüsselte API ("REST-Äquivalent") ja typischerweise die API von einem SDK, das vom E2E-Platform bereitgestellt wird und die Entschlüsselung übernimmt. So wie man Standards von FHIR REST APIs festgelegt hat, könnte man sich ja auch auf Standard für solche SDK-APIs einigen. Das müssten Clients zwar einen anderen SDK einbinden, wenn Sie eine andere Platform benutzen möchten, müssten aber die Program-Logik nicht ändern, weil die SDK-API identisch ist .
Morten Ernebjerg (Jun 25 2021 at 07:29):
(Wobei man natürlich, im Gegensatz zu REST, ein eigenes SDK für jedes OS braucht - das ist dann aber eher Aufwand für die Plattformen)
Christof Gessner (Jun 25 2021 at 11:54):
Unabhängig von den APIs auf die fachlichen Resourcen (die ggf. in den Bundles vorliegen) könnten wir jedoch eine durchgängig einheitliche FHIR REST-API samt Metadaten-Valuesets vereinbaren für den Umgang mit "Dokumenten" (incl. E2E-verschlüsselten)
Simone Heckmann (Jun 25 2021 at 13:00):
Markus Ritthaler said:
Hallo Simone Heckmann ,
unser Partner nutzt sogar ein ähnliches Konzept, wie das der ePA (es gab dort nur keinen Aktenschlüssel, da die bisherigen Anwendungen auf eine bidirektionale Arzt-Arzt-Kommunikation ausgelegt sind). Wir sind auch bereits mit der gematik im Austausch, nur FHIR stand noch nicht auf der Agenda, da wir hier noch Grundsatzfragen zu klären haben.
Es dürfte sich lohnen, das Thema FHIR bei der Gematik anzusprechen. Die Idee, die ePA mit einer FHIR-API zu versehen ist nicht neu!
Last updated: Apr 12 2022 at 19:14 UTC
