Leitfaden für App-Entwickler

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

Der neue Standard „FHIR“® (Fast Healthcare Interoperability Resources, ausgesprochen wie englisch "fire") wurde von Health Level Seven International (HL7) ins Leben gerufen. Der Standard unterstützt den Datenaustausch zwischen Softwaresystemen im Gesundheitswesen. Er vereinigt die Vorteile der etablierten HL7-Standard-Produktlinien Version 2, Version 3 und CDA mit jenen aktueller Web-Standards und legt einen starken Fokus auf eine einfache Implementierbarkeit.

weitere Informationen:

• FHIR auf HL7.de
• FHIR-Spezifikation

REST

FHIR verwendet kompakte, in sich geschlossene Datenpakete (Ressourcen), mit einheitlichem, wohldefiniertem Verhalten, Semantik, Kontext- und Metadaten, die basierend auf dem REST-Paradigma zwischen Client und Server ausgetauscht werden können. Der Vorteil von REST liegt darin, dass ein Großteil der benötigten Infrastruktur (z. B. Webserver, HTTP-fähige Clients, XML/JSON-Parser, Verschlüsselungs- und Autorisierungsmechanismen) etabliert, erprobt und allgemein bekannt sind. Die Verwendung von Bibliotheken und die Wiederverwendbarkeit von Code erhöhen die Software-Qualität und verkürzen Entwicklungszyklen.

Für die Repräsentation der Ressourcen sieht FHIR wahlweise XML oder JSON vor.

weitere Informationen:

• REST in der FHIR-Spezifikation
• REST auf Wikipedia

Sichere Kommunikation

FHIR erfordert die Verschlüsselung mittels TLS/SSL für jeglichen Datenaustausch in produktiven Umgebungen. Da die TLS/SSL-Verschlüsselung vor der HTTP-Kommunikation etabliert wird, ist die gesamte FHIR-Interaktion zwischen Client und Server geschützt. Für die jeweiligen Endpunkte der Kommunikation muss ein Risiko-Management betrieben werden in dem Sinne, dass bspw. Zugriffe in ein Audit protokolliert werden. FHIR verfügt über entsprechende Resourcen, um Audit-Events standardkonform aufzuzeichnen.

weitere Informationen:

• TLS/SSL in der FHIR-Spezifikation
• TLS/SSL auf Wikipedia

Authorisation und Authentifikation

Um sicher auf Online-Dienste zugreifen zu können, müssen sich Endanwender authentifizieren, um den Zugriff durch nicht berechtigte Personen zu verhindern und ihre eigene Identität zu verifizieren. Für Apps, die auf Dienste von Dritt-Anbietern zugreifen, muss die Applikation darüber hinaus die Berechtigung erhalten, im Namen des Endanwenders zu agieren.

OAuth ist ein offenes Protokoll, das eine standardisierte, sichere Endanwender-Authentifikation und API-Autorisierung für REST-basierte Applikationen erlaubt.

Die Spezifikation von Authorisierungs- und Authentifikationsmechanismen ist nicht Bestandteil des FHIR Standards. Jedoch bietet OAuth eine standardisierte und etablierte Lösung, die bei der Implementierung von FHIR zu präferieren ist.

Das SMART-on-FHIR-Framework stellt ein OAuth-Profil mit enger Integration in FHIR zur Verfügung.

weitere Informationen:

• Authentifikation in der FHIR-Spezifikation
• Audit Logging in der FHIR-Spezifikation
• OAuth Spezifikation
• OAuth mit SMART-on-FHIR

SMART-on-FHIR

SMART (Substitutable Medical Applications, Reuseable Technology) ist ein Framework zur sicheren Integration mobiler und webbasierter Apps in Healthcare-Systeme, entwickelt vom Boston's Children Hospital und der Harvard Medical School. Das Framework basiert auf FHIR asl Basis-Technologie und liefert darüber hinaus:

• Syntax für die Übergabe von Parametern und Kontextinformationen an Apps
• OpenID Connect und OAuth2-Profile für die Authentifizierung und Authorisierung
• Libraries für JavaScript, Python, Swift
• eine Sandbox für Entwickler
• eine App-Gallery

weitere Informationen:

• Über SMART
• Spezifikation des Frameworks
• App-Galerie

HEART

Die HEART-Arbeitsgruppe beabsichtigt die Harmonisierung und Entwicklung eines Paketes von Privacy und Security-Spezifikationen um es Endanwendern eine Zugriffskontrolle auf medizinische Informationen über REST-basierte APIs zu ermöglichen und die Entwicklung interoperabler Implementierungen dieser Spezifikationen zu erleichtern.

Folgende Profile werden von der HEART-Arbeitsgruppe entwickelt:

• HEART Profil für OAuth 2.0
• HEART Profil für OpenID Connect
• HEART Profil für Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 scopes
• HEART Profil für User-Managed Access (UMA)
• HEART Profil für FHIR UMA

Die Profile werden in Abstimmung mit der SMART-Initiative erstellt

weitere Informationen:

• HEART - Profiles for Healthcare

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.

Der vom Hersteller vorgesehene Zweck einer App ist maßgeblich dafür, ob es sich bei der App um ein Medizinprodukt handelt oder nicht. Um nachträglichen Zeit- und Kostenaufwand für fehlende Validierungen, Zertifizierungen etc. zu vermeiden, sollte sich der Hersteller einer App frühzeitig über die genaue Zweckbestimmung im Klaren sein und diese eindeutig formulieren und kommunizieren.

Wenn sich aus der Zweckbestimmung ergibt, dass die App dazu dient, Krankheiten oder Verletzungen zu erkennen, zu überwachen, zu behandeln oder zu lindern (vgl. § 3 Abs. 1 MPG), muss die App die rechtlichen Anforderungen an ein Medizinprodukt erfüllen (siehe 8.2 Anforderungen an Medizingeräte / Medizinprodukte).

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 Erstellung und Pflege eines Medikationsplans

Einführung

Das E-Health Gesetz sieht vor, dass Versicherte, denen mindestens drei Medikamente verordnet werden, ab Oktober 2016 einen Anspruch auf die Erstellung eines Medikationsplan haben.

Der Medikationsplan ist auf Papier zu drucken und dem Patienten physisch zu übergeben. Der Plan soll in übersichtlicher und verständlicher Form den Patienten unterstützen seine Medikation gemäß den ärztlichen Vorgaben durchzuführen. Ein zweiter wichtiger Punkt ist, den unterschiedlichen behandelnden Ärzten ein möglichst vollständiges Bild über die Medikation des Patienten zu geben.

Um den Plan einfach, schnell und ohne Fehler in ein System einzulesen ist in der oberen rechten Ecke ein Barcode aufgebracht. Dort sind die Informationen, die in dem Medikationsplan eingetragen sind, gespeichert. Der Barcode soll mit einem Scanner gelesen werden und ein Datenstring mit den Informationen wird an das System geschickt.

Der Barcode auf dem Medikationsplan ermöglicht es mit einem entsprechenden Scanner die Informationen abzurufen und nutzbar zu machen. Diese Tatsache kann verwendet werden, um den Plan mithilfe der Kamera eines Smartphones zu lesen und für den Patienten in einer App zu speichern.

Um möglichst wenig Information in den beschränkten Barcode schreiben zu müssen, wird dort nur die Pharmazentralnummer (PZN) gespeichert. Diese Nummer bezeichnet eindeutig jede in Deutschland zugelassene Packung eines Medikaments. Zu jeder Packung gehört also eine PZN. Jedes Präparat kann aber mehrere Packungsgrößen besitzen und somit auch verschieden PZNs. Die PZN wird im Medikationsplan dazu genutzt, die verordnete Packung zu identifizieren und alle dazugehörigen Daten aus einer Arzneimitteldatenbank zu laden.

Datenfelder:

- Wirkstoff

- Handelsname

- Wirkstärke

- Einheit

- Darreichungsform.

Alle weiteren Informationen werden direkt im Barcode gespeichert und können von dort übernommen werden.

Teilnehmer

Laut Gesetz ist der Hausarzt verpflichtet, den Patienten bei bestimmten Bedingungen (drei Medikamente oder mehr) über den Medikationsplan aufzuklären und den Plan initial zu erstellen. Sollte der Patient keinen Hausarzt haben, kann diese Verpflichtung auf den behandelten Facharzt übergehen.

Liste der Teilnehmer:

- Hausarzt (in der Regel initialer Ersteller)

- Facharzt

- Apotheker

- Patienten

- Klinik (Ambulanz)

- Klinik (Station)

- Serviceanbieter (z.B. Patientenakten im Internet).

Kursiv: Keine gesetzliche Verpflichtung

Quelle

Um die PZN zu entschlüsseln und die notwendigen zusätzliche Informationen zu erhalten muss eine elektronische Arzneimitteldatenbank eingesetzt werden. Die Datenbank muss vollständig und aktuell sein. Es gibt drei Anbieter am Markt die die Kriterien erfüllen:

- Abdata

- ifap

- MMI.

Um den Plan korrekt darzustellen, muss eine Schnittstelle zu einer Datenbank erstellt werden.

Schnittstelle

Die Kommunikation zwischen der App und der Datenbank:

App zu Datenbank: - PZN.

Datenbank zu App:

- Wirkstoff

- Handelsname

- Wirkstärke

- Einheit

- Darreichungsform.

Um zusätzliche Dienste, wie eine AMTS Prüfung durchzuführen muss die App auch weitere Daten an einen entsprechenden Service übergeben können:

App zu Service:

- PZN

- Alter

- Geschlecht

- Diagnosen (ICD, Alpha ID)

- Laborwerte (Serum Kreatinin Wert usw.)

- Risikogruppen (Raucher, Schwanger usw.)

- Allergien.

Service zu App:

- Interakionen

- Kontra-Indikationen

- Allergie-Hinweise

- Dosisanpassung (bei Niereninsuffizienz)

- Doppelmedikation

- Hinweis auf Gefährdung durch hohes Alter (Priscus)

- Weitere Hinweise je nach Service.

Es kann auch eine Kommunikation zwischen Apps sinnvoll sein. zum Beispiel um die Daten mit einer anderen Medikationsapp zu teilen (z.B. Erinnerung an die Einnahme)-

App MedPlan zu App:

- PZN

- Dosierung

- Hinweise zur Einnahme (Freitext in Feld Hinweis)

- Wirkstoff

- Handelsname

- Wirkstärke

- Einheit

- Darreichungsform.

Wenn eine Datenbank bei der empfangenden App hinterlegt ist benötigt man die kursiven Elemente nicht.

App zu App MedPlan:

- Keine Kommunikation nötig.

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

Herstellung von Interoperabilität

Mapping von Standards

FHIR <---> XDT

Mapping-Beispiele

In diesem Kapitel soll ausschließlich das Mapping von FHIR- in xDT-Datensätze betrachtet werden. Übertragungswege und die damit verbundenen Fragen zu Datenschutz- Datensicherheit, Verschlüsselung, Transaktionsmanagemnt und Reidentifikation werden an anderer Stelle diskutiert.

Szenario 1

Messung von Körpergewicht. Die Patientin erfasst ihr Körpergewicht an einer Mobile App oder der Messwert wird von einer Waage an eine Mobile App übermittelt. Von dort wird der Wert an die Arztpraxis übermittelt.

Patient: Marianne Musterfrau, geboren am 3.6.1972 mit der Versicherten-Nummer U995367527 und der praxis-internen ID 334799 (vergeben von der Praxis Dr. Müller und dem Patienten vorab mitgeteilt).

Wohnhaft in Musterstrasse 42, 88888 Musterhausen

Messwert: 67kg, gemessen am 2.6.2016 um 17:30h bei einer Körpergröße von 165cm

Gemessen von einer Waage, Modell: SmartBodyAnalyzer, Hersteller: Withings, Seriennummer: 123456

Der Datensatz soll von der MobileApp an die Arztpraxis Dr. Müller übermittelt werden.

FHIR-Resource(n):

<Patient xmlns="http://hl7.org/fhir">
  <name>
    <family value="Musterfrau"/>
    <given value="Marianne"/>
  </name>
  <gender value="female"/>
  <birthDate value="1972-06-03"/>
  <address>
    <use value="home"/>
    <line value="Musterstrasse 42"/>
    <city value="Musterhausen"/>
    <postalCode value="88888"/>
  </address>
</Patient>

<Observation xmlns="http://hl7.org/fhir">
  <category>
    <coding>
      <system value="http://hl7.org/fhir/observation-category"/>
      <code value="vital-signs"/>
      <display value="Vital Signs"/>
    </coding>
  </category>
  <code>
    <coding>
      <system value="http://loinc.org"/>
      <code value="29463-7"/> <!--   more generic methodless LOINC   -->
      <display value="Body Weight"/>
    </coding>
    <coding>
      <system value="http://loinc.org"/>
      <code value="3141-9"/><!--   translation is more specific method = measured LOINC   -->
      <display value="Body weight Measured"/>
    </coding>
  </code>
  <subject>
    <reference value="Patient/example"/>
  </subject>
  <effectiveDateTime value="2016-06-02T17:30:00"/>
  <valueQuantity>
    <value value="67"/>
    <unit value="kg"/>
    <system value="http://unitsofmeasure.org"/>
    <code value="kg"/>
  </valueQuantity>
</Observation>

xDT-Datensatz:

013 8000 6310                       ; Satzart
016 8004 0001111                    ; Satzlänge

022 8002 Obj_Kopfdaten	            ; Start Informationsobjekt Kopfdaten
017 8315 PRAX_PVS                   ; GDT-ID des Empfängers
017 8316 SBAN_SYS                   ; GDT-ID des Senders
014 9218 03.10                      ; Versions-Nr. GDT
022 8003 Obj_Kopfdaten	            ; Ende Informationsobjekt Kopfdaten

020 8002 Obj_Patient	            ; Start Informationsobjekt Patient
015 3000 334799                     ; Patienten-Nummer
019 3101 Musterfrau                 ; Nachname
014 3102 Marianne                   ; Vorname
017 3103 19720603                   ; Geburtsdatum
000 3105 U995367527                 ; Versichertennummer des Patienten
022 3107 Musterstrasse              ; Straße des Patienten
011 3109 42                         ; Hausnummer des Patienten
010 3110 2                          ; Geschlecht (2=weiblich)
014 3112 88888                      ; PLZ des Patienten
021 3113 Musterhausen               ; Wohnort des Patienten
020 8002 Obj_Patient	            ; Ende Informationsobjekt Patient

028 8002 Obj_Basisdiagnostik	    ; Start Informationsobjekt Basisdiagnostik
015 3622 165.00                     ; Größe in cm
015 3632 067.00                     ; Gewicht in Kg
000 3700 Geraet.Modell              ; freie basisdiagnostische Kategorie
000 3701 SmartBodyAnalyzer          ; Inhalt der zuvor genannten Kategorie
000 3700 Geraet.Hersteller          ; freie basisdiagnostische Kategorie
000 3701 Withings                   ; Inhalt der zuvor genannten Kategorie
000 3700 Geraet.SN                  ; freie basisdiagnostische Kategorie
000 3701 123456                     ; Inhalt der zuvor genannten Kategorie
028 8002 Obj_Basisdiagnostik	    ; Ende Informationsobjekt Basisdiagnostik

011 8005 30                         ; Satzende

Infrastrukturvoraussetzungen

Online

Online-Szenarien setzen voraus, dass ein Nutzer einer mobilen Anwendung über ein mobiles Endgerät interagiert, das über eine drahtlose Netzwerkverbindung (z.B. Mobilfunknetz, WLAN o.Ä.) mit den zur Anwendung gehörenden Online-Diensten verbunden ist. Neben der Online-Konnektivität spielen natürlich weitere Fragestellungen bei mobilen Anwendungen eine Rolle:

• Sind die Übertragungswege dem Schutzbedarf entsprechend abgesichert?
• Sind die an der Datenübertragung beteiligten Kommunikationspartner hinreichend stark authentifiziert (z.B. durch kryptografisch prüfbare Identitäten für Geräte und Nutzer)?
• Sind die authentifizierten Kommunikationspartner zum gewünschten Zugriff autorisiert?

Kryptografisch prüfbare Identitäten werden in der Regel durch den Einsatz einer PKI mit X.509 Zertifikaten von dedizierten Sicherheitsdiensten (z.B. IdentityProvider) erzeugt. Zur Unterstützung der Sicherheitsarchitektur einer mobilen Anwendung wird das Idenitätsmanagement der Nutzer oftmals an einen vertrauenswürdigen IdentityProvider ausgelagert, der den mobilen Nutzer authentifiziert und dem Online-Dienst erforderliche Nutzerinformationen bzw. Profildaten des Nutzers bereitstellt. Ein Industrie-Standard, der sich im Bereich mobile Anwendungen etabliert hat, ist OpenId connect 1.0. Hierbei wird sichergestellt, dass der mobile Nutzer bei erfolgreicher Authentifizierung eine Identitätsbestätigung (ID-Token) erhält, nachdem er die betreffende Online-Anwendung zum Abruf bestimmter Attribute seiner Online-Identität durch explizite Einwilligung autorisiert hat. Das Verfahren der Nutzerauthentisierung kann dabei variieren und sollte dem Schutzbedarf der Daten angemessen ausgewählt werden (Username/Password, OTP, Multi-Faktor Authentisierung, Smartcard).

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)

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

Die Anforderungen an Medizinprodukte – also bei entsprechender Zweckbestimmung auch an Apps (siehe 3.1 Zweckbestimmungen) – ergeben sich aus:

• europäischen Richtlinien, insbesondere Richtlinie 93/42/EWG über Medizinprodukte, Richtlinie 90/385/EWG über aktive implantierbare medizinische Geräte und Richtlinie 98/79/EG über In-vitro-Diagnostika

• und deren Umsetzungen in deutsches Recht, insbesondere MPG (Medizinproduktegesetz) und MPBetreibV (Medizinprodukte-Betreiberverordnung)

Zur Erfüllung der Richtlinien und Gesetze ist die Einhaltung internationaler Normen wie EN ISO 14971, EN IEC 62366, EN IEC 62304 und EN ISO 13485 erforderlich. Da die meisten Apps mit Patientendaten arbeiten, ist zusätzlich ISO/IEC 27001 zur Informationssicherheit zu beachten.