Leitfaden für App-Entwickler: Unterschied zwischen den Versionen

Aus Hl7wiki
Wechseln zu: Navigation, Suche
K (Offline)
(Szenarien)
Zeile 23: Zeile 23:
 
=Szenarien=
 
=Szenarien=
 
''Autoren: Franke, Wolf, Oberkirch, Klauß, Rey''
 
''Autoren: Franke, Wolf, Oberkirch, Klauß, Rey''
 +
Mobile Szenarien sind dadurch gekennzeichnet, dass die Mobilität des Nutzers einer Anwendung durch die Anwendung selbst gewährleistet wird. Als mobile Endgeräte haben heutzutage Smartphones und Tablets Einzug gehalten in den Alltag der Patienten und Ärzte. Die Erwartung dieser Nutzer, mobile Endgeräte im Arbeitsalltag der medizinischen Versorgung nutzen zu können ist hoch, allerdings bietet die Datenverarbeitung im Umfeld der medizinischen Versorgung über Sektorengrenzen hinweg einige Herausforderungen bei der Einhaltung angemessener Datenschutz- und Datensicherheitsniveaus.
 +
Beispielhaft seien im Folgenden einige mobile Szenarien skizziert.
 +
 
==Zweckbestimmungen==
 
==Zweckbestimmungen==
 +
Auch mobile Anwendungen dienen dem Nutzer auf eine zweckgebundene Art und Weise. Die datenschutzgerechte Verarbeitung von persönlichen oder auch medizinischen Daten eines Nutzers muss stets im Kontext eines definierten Zwecks unter Enwilligung des Nutzers erfolgen.
 +
 
==Nutzer von Apps==
 
==Nutzer von Apps==
 
===Patienten / Bürger===
 
===Patienten / Bürger===
 +
====Szenarien zum Einsatz von mobilen Apps beim Online-Zugriff auf geschützte Resourcen====
 +
In Abhängigkeit des Schutzniveaus der zu verarbeitenden Daten sind geeignete Maßnahmen gemäß IT-Grundschutz des BSI [https://www.bsi.bund.de/DE/Themen/ITGrundschutz/itgrundschutz_node.html] umzusetzen, um den Anforderungen bzgl. der Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit der mobilen Anwendung erfüllen zu können.
 +
Viele mobile Anwendungen setzen dazu ein spezifisches Nutzeridentitäts- und Berechtigungsmanagement ein, dass im mobilen Umfeld oftmals als Token basierte Sicherheitsarchitektur umgesetzt ist. Gängige Standards wie z.B: OAUTH2.0[https://tools.ietf.org/html/rfc6749], OpenId Connect 1.0 [http://openid.net/connect/] und User Managed Access[https://kantarainitiative.org/confluence/display/uma/Home] kommen hierbei zum Einsatz und ermöglichen u.A. eine Patienten-zentrierte Sichtweise.
 +
 
====Szenarien zum Einsatz von mobilen Apps bei der Privatliquidation====
 
====Szenarien zum Einsatz von mobilen Apps bei der Privatliquidation====
  

Version vom 30. Mai 2016, 11:18 Uhr

Vorwort

HL 7 Deutschland e.V. und der Qualitätsring Medizinische Software e.V. (QMS) haben im Dezember 2015 eine gemeinsame Arbeitsgruppe ("AG MobileApps") gegründet, die sich mit der Interoperabilität von Apps für mobile Systeme (mobile Apps) auseinandersetzen soll.

Der Patient im Mittelpunkt

Apps auf mobilen Systemen können vor allem Bürger und Patienten zu Mitwirkenden oder Verwaltern bei der Bereitstellung von Daten für die eigene medizinische Betreuung (oder auch die von Angehörigen) machen. Daneben werden auch im Gesundheitssystem tätige Personen zunehmend Apps benutzen, um Daten zu erfassen, zu transferieren oder abzurufen. Wenn alle App-Entwickler ein patientenzentriertes Informationsmodell zugrunde legen, wird der Prozess der Zusammenführung notwendiger Daten erleichtert.

Ziel der Zusammenarbeit zwischen HL7 Deutschland und QMS

HL7 Deutschland beteiligt sich traditionell an der Definition von Standards für den Datenaustausch in der Medizin, wobei der Schwerpunkt der Betrachtung der stationäre Sektor ist. Demgegenüber definiert der QMS traditionell Standards der xDT-Familie, wobei der Schwerpunkt der Betrachtung der ambulante Sektor ist. Während HL7-Standards weltweite Verbreitung gefunden haben, sind die Standards der xDT-Familie wesentlich in Deutschland im Einsatz; einige Standards der xDT-Familie werden von der Kassenärztlichen Bundesvereinigung definiert und verbindlich vorgeschrieben. Der Standard GDT (Gerätedatentransfer), welcher der Anbindung medizinischer Geräte an Praxisverwaltungssysteme dient, hat sich allerdings auch international verbreitet. HL7 Deutschland und QMS arbeiten erstmals mit dem Ziel der Harmonisierung von Standards für den stationären Sektor mit den Standards für den ambulanten Sektor zusammen. Dabei wird zunächst keine syntaktische Vereinheitlichung, sondern eine Angleichung der Bedeutung von Datenelementen und von deren Codierung sowie der zugrunde liegenden Konzepte angestrebt. Konkret sollen die FHIR Ressourcen mit den Informationsobjekten des xDT-Objektkatalogs abgeglichen werden. Dieser Leitfaden zeigt exemplarisch die Verwendung harmonisierter Ressourcen/Informationsobjekte in Kommunikationsprozessen, die sich dabei sowohl der HL7 FHIR Syntax (und Strukturen) als auch der Syntax (und Strukturen) der xDT-Familie bedienen können.

Ziel dieses Leitfadens

Der hier vorliegende Leitfaden soll Entwicklern von Apps eine Hilfestellung geben hinsichtlich der Herstellung von Interoperabilität. Der Fokus der Arbeitsgruppe liegt dabei auf dem Austausch von Daten.

Einleitung

FHIR

Autor: Heckmann

REST

SMART

xDT

Autor: Neubert

HL7 V2

Autor: Heckmann

HL7 CDA

Autor: Heckmann

Szenarien

Autoren: Franke, Wolf, Oberkirch, Klauß, Rey Mobile Szenarien sind dadurch gekennzeichnet, dass die Mobilität des Nutzers einer Anwendung durch die Anwendung selbst gewährleistet wird. Als mobile Endgeräte haben heutzutage Smartphones und Tablets Einzug gehalten in den Alltag der Patienten und Ärzte. Die Erwartung dieser Nutzer, mobile Endgeräte im Arbeitsalltag der medizinischen Versorgung nutzen zu können ist hoch, allerdings bietet die Datenverarbeitung im Umfeld der medizinischen Versorgung über Sektorengrenzen hinweg einige Herausforderungen bei der Einhaltung angemessener Datenschutz- und Datensicherheitsniveaus. Beispielhaft seien im Folgenden einige mobile Szenarien skizziert.

Zweckbestimmungen

Auch mobile Anwendungen dienen dem Nutzer auf eine zweckgebundene Art und Weise. Die datenschutzgerechte Verarbeitung von persönlichen oder auch medizinischen Daten eines Nutzers muss stets im Kontext eines definierten Zwecks unter Enwilligung des Nutzers erfolgen.

Nutzer von Apps

Patienten / Bürger

Szenarien zum Einsatz von mobilen Apps beim Online-Zugriff auf geschützte Resourcen

In Abhängigkeit des Schutzniveaus der zu verarbeitenden Daten sind geeignete Maßnahmen gemäß IT-Grundschutz des BSI [1] umzusetzen, um den Anforderungen bzgl. der Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit der mobilen Anwendung erfüllen zu können. Viele mobile Anwendungen setzen dazu ein spezifisches Nutzeridentitäts- und Berechtigungsmanagement ein, dass im mobilen Umfeld oftmals als Token basierte Sicherheitsarchitektur umgesetzt ist. Gängige Standards wie z.B: OAUTH2.0[2], OpenId Connect 1.0 [3] und User Managed Access[4] kommen hierbei zum Einsatz und ermöglichen u.A. eine Patienten-zentrierte Sichtweise.

Szenarien zum Einsatz von mobilen Apps bei der Privatliquidation

1. Papierlose Rechnung

- Der Patient installiert die App der Abrechnungsstelle - Über die App registriert sich der Patient bei der Abrechnungsstelle und erlaubt dadurch, dass er seine Rechnung in Zukunft nur als Datei erhält, z.B. als PDF - Bei Erstellung der Rechnung durch die Abrechnungsstelle wird der Patient identifiziert und erhält in der App eine Nachricht, dass eine Rechnung zum Abruf bereit steht. - Durch entsprechende Legitimation kann er die Rechnung auf sein mobiles Gerät laden - Vor Erreichen der Zahlungsfrist erhält der Patient Erinnerungen zur Zahlung der Rechnung auf sein mobiles Gerät

2. Papierlose Einreichung

- Versicherung und Abrechnungsstelle vereinbaren ein Verfahren zur Übermittlung von Daten - Die Abrechnungsstellespeichert die Behandlungsdaten des Arztes - Der Patient erhält seine Rechnung in Papierform oder papierlos (siehe 1.) - Durch eine Funktion in der App, erlaubt der Patient seiner Versicherung, dass die Daten aus der Abrechnungsstelle abgerufen und in das System der Versicherung übertragen werden. - Auf der Papierrechnung wird ein QR-Code aufgedruckt, der über die App die zuletzt beschriebene Funktion auslöst

3. Zahlung einer Rechnung

- Ähnlich wie unter 2. enthält die Papierrechnung einen QR-Code der den Rechnungsbetrag und die Bankverbindung der Abrechnungsstelle enthält. - Der Patient scannt den Code mit seinem mobilen Gerät und überweist so den Betrag an die Abrechnungsstelle

4. Anforderung einer Rechnungskopie

- Nach dem Versand von Mahnungen kommt es häufig zu Anfragen von Patienten, die eine Rechnungskopie benötigen - Auf den Mahnungen könnte ein QR-Code aufgedruckt sein, der die Rechnung identifiziert (z.B. die Rechnungsnummer) - Durch Einscannen des QR-Codes werden die Daten an die Abrechnungsstelle übermittelt und der Patient erhält eine Kopie seiner Rechnung

Ärzte / Apotheker

Hilfspersonal

Pflegepersonal

Studien

Zu lösende Probleme

Benötigte Informationsobjekte/Ressourcen

Implementierungsbeispiele

FHIR-Profile / REST

GDT / XDT

Geschäftsmodelle

Mehrwertdienste

Zielgruppen

Patienten

Leistungserbringer

Kostenträger

Herstellung von Interoperabilität

Mapping von Standards

FHIR <---> XDT

Datenquellen

Kataloge

Schichtenmodell

Metadaten

App zu App Kommunikation

App zu KIS Kommunikation

App zu PVS Kommunikation

App für Studien

Infrastrukturvoraussetzungen

Online

Autor: Wolf

Offline

Was haben uns Offline-Lösungen in Zeiten eines nahezu omnipräsenten und äußerst komfortablen Online-Zustandes überhaupt zu bieten?

- Geschwindigkeit - Lokale Verbindungen sind üblicherweise im Vorteil bei Antwortzeit und Bandbreite

- Datenschutz - Minimale Übertragungsstrecken minimieren auch das Risiko

- Zuverlässigkeit - Die Funktionalität ist auch in Ausnahmesituationen gewährleistet (Tunnel, Flugzeug, Gelände, Strom- oder Netz-Ausfall)

Was sind denkbare Technologien für Offline-Lösungen?

- Bluetooth

- privates WLAN

- privates Ethernet

- proprietäre Kabelverbindungen

- proprietäre Funkverbindungen

- Barcodes

- QR-Codes

- manuelle Dateneingabe und -Haltung

- Flicker (wie beim Chip-/TAN-Verfahren)

Sicherheit und Datensicherung

Berechtigungsverwaltung

Identifizierungsdienste

Authentisierung und Autorisierung

Elektonische Signatur

Ort der Datenspeicherung / Synchronisierung

Verschlüsselung

Rechtliche Aspekte

Datenschutz

Um der oft praxisfernen Natur dieses überwiegend als "Bla-Bla" und Innovationshemmnis eingeordneten Themas eine hoffentlich lesenswerte neue und konstruktive Richtung zu geben wird hier auf Worthülsen und Zitate aus Texten sowieso nicht durchgesetzter Gesetze etc. verzichtet. Beide eint, dass sie a) niemanden weiterbringen und deswegen b) im Zweifelsfall ignoriert werden. Diese lesen Sie also bitte woanders nach.

Hier soll es stattdessen darum gehen, Datenschutz als eine wesentliche Qualitätsdimension von Software und damit letztlich ein mögliches Alleinstellungsmerkmal Ihrer Produkte zu erklären.

Inwiefern ist Datenschutz ein relevantes Qualitätsmerkmal?

Wenn man den vielzitierten "Mensch im Mittelpunkt" wirklich ernst nimmt dann trifft das auch auf seine Ängste zu. Wie sehr eine grundsätzliche Angst vor Digitalisierung nun gerechtfertigt ist oder nicht sprengt die Möglichkeiten dieses Texts bei weitem. Sicher schnell einig werden kann man sich aber vermutlich darüber, dass Menschen Werkzeuge bevorzugen die sie verstehen und denen sie vertrauen. Und das gilt eben auch für den Datenschutz-Aspekt von Software, bei medizinischer Software vielleicht sogar besonders stark. Wenn angesichts in den letzten Jahren gehäuft auftrender "Leaks" und "Hacks" von vertraulichen Information in diversen Branchen selbst viele Fachleute an der zugrunde liegenden Sicherheit zweifeln können Sie sich diese Verunsicherung beim Verbraucher als exponentiell höher vorstellen.

Datenschutz ist also ein Qualitätsmerkmal insofern als dass es den Nutzer wichtig nimmt.

Wie kann man es besonders falsch machen?

Eine Aussage ala "Wir tun KOMPLIZIERTE_DINGE damit Ihre persönlichen Daten zwar von der deutschen Arztpraxis zwecks Aggregation durch den Cloud- & Big-Data-Dienstleister in Bangalore und anschliessender anonymisierter Zweitverwertung durch einen amerikanischen Pharmakonzern weitergeleitet werden, letztlich aber garantiert sicher auf ihrem Smartphone landen." ist vermutlich ebenso falsch wie schwer zu verstehen. Falls das ganze noch in übliche Juristenfloskeln verpackt ist haben Sie damit garantiert auch den letzten Benutzer abgehängt.

Genauso wichtig und noch viel grundlegender ist Ihr Geschäftsmodell: Falls Sie planen, mit der Verwertung von Nutzerdaten direkt oder indirekt Geld zu verdienen befinden Sie sich in einem klassischen Zielkonflikt. Eine Datenschutz-Orientierung wird für Sie letztlich immer nur ein leicht zu durchschauendes Lippenbekenntnis bleiben.

Wie kann man es besser machen?

Indem Sie von vornherein mit Datenschutz als einer Kern-Anforderung entwerfen, statt ihn als nachgelagerte externe Anforderung zu verstehen. Dezentrale Strukturen, statt der gerade so einfachen und modernen zentralen "Cloud", sind ein möglicher Weg dorthin. Ein aktuelles Beispiel dafür liefert der Barcode auf dem Medikationsplan. "Datensparsamkeit" ist ein weiterer Ansatz. Sie erheben und speichern nur das, was sie zwingend heute brauchen und löschen bei der ersten Gelegenheit.

Wenn Sie es dann noch schaffen, das alles dem Nutzer in seinen Worten zu erklären haben Sie sowohl ein positives Alleinstellungsmerkmal für Ihre Produkte als auch etwas nahezu unbezahlbares gewonnen: Vertrauen.

Anforderungen an Medizingeräte / Medizinprodukte

SGB V

Schlußwort