kaya
Home
Produkt

Produkt

kaya WebPatienten-AppMitarbeiter-App
Module

Module

Compliance

Compliance

ÜbersichtSicherheitDatenschutz im ProduktDatenschutzSubunternehmerNutzungsbedingungen Patienten-AppNutzungsbedingungen Mitarbeiter-AppImpressum
Konfigurator
Demo buchen

Datenschutz im Produkt

Diese Datenschutzhinweise erklären, wie personenbezogene Daten im Kaya-System verarbeitet und geschützt werden. Sie betreffen Kaya Web auf der Praxisinstanz, die Kaya Patienten-App, die Kaya Mitarbeiter-App, app.mykaya.de sowie die zugehörigen Support-, Betriebs- und Sicherheitsfunktionen.

1. Verantwortlicher, Datenschutzkontakt und Rollen

Anbieter
trainity GmbH
Anschrift
August-Wilhelm-Kühnholz-Straße 5, 26135 Oldenburg
Geschäftsführer
Kimon Schulz
Register
Amtsgericht Oldenburg, HRB 222843
E-Mail
mail@mykaya.de
Datenschutzkontakt
datenschutz@mykaya.de
Website
https://mykaya.de

Für die zentralen Kaya-Dienste der trainity GmbH, insbesondere mykaya.de, app.mykaya.de, Kaya Meets, eigene System-E-Mails, interne CRM- und Betriebsfunktionen sowie neutrale Konto- und Verzeichnisdienste, ist die trainity GmbH Verantwortliche im Sinne der DSGVO.

Für fachliche Daten aus der Behandlung, Praxisorganisation und Patientenkommunikation ist die jeweilige Praxis Verantwortliche. Dazu gehören insbesondere Patientenakten, Behandlungsdaten, medizinische Dokumente, Praxis-Chats, Aufgaben, Termine, Formulare, Telefonnotizen und sonstige Gesundheitsdaten. Diese Daten werden in der jeweiligen Praxisinstanz und damit im Datenraum der Praxis verarbeitet. trainity betreibt dafür keine zentrale Gesundheitsdaten-Cloud und keinen zentralen Gesundheitsdatenbestand. Eine Verarbeitung durch Kaya-Inferenzressourcen findet nur zweckgebunden statt, wenn eine Praxis aktiv KI-, Speech- oder Telefon-KI-Funktionen nutzt.

Die Rolle der trainity GmbH ist auf die Bereitstellung der Kaya Software, neutrale Konto- und Verzeichnisdienste sowie eng begrenzte technische Betriebs- und Supportleistungen beschränkt. Soweit trainity bei Einrichtung, Updates, Störungsbeseitigung, Sicherheitsmaßnahmen oder dem funktionsfähigen Betrieb der Praxisinstanz unterstützt, erfolgt dies auf das notwendige technische Mindestmaß beschränkt, zweckgebunden, protokolliert und ohne regulären Zugriff auf fachliche Klartexte.

Patientinnen, Patienten und Mitarbeitende einer Praxis können sich mit Datenschutzanliegen jederzeit an ihre Praxis wenden. Die trainity GmbH unterstützt die Praxis technisch bei Auskunft, Berichtigung, Löschung, Einschränkung, Datenübertragbarkeit, Widerspruch und sonstigen Betroffenenrechten, soweit Kaya-Systeme betroffen sind und die Unterstützung ohne fachliche Einsicht durch trainity erfolgen kann.

2. Grundmodell: getrennte Datenräume statt zentraler Gesundheitsdaten-Cloud

Kaya ist nicht als zentrale Cloud für Gesundheitsdaten aufgebaut. Das System besteht aus zentralen Diensten für neutrale Konto-, Verzeichnis-, CRM-, Betriebs- und Sicherheitsfunktionen sowie aus getrennten Praxisinstanzen. Die fachliche Wahrheit einer Praxis liegt in der jeweiligen Praxisinstanz.

Eine Praxisinstanz ist ein eigener technischer Datenraum der Praxis. Sie enthält Kaya Web, die lokale API, das lokale Rollen- und Rechtesystem, Datenbank, Speicher, Schlüssel, Module, Sicherheitskonfiguration und die fachlichen Daten dieser Praxis. Die Praxisinstanz verarbeitet nicht die Daten anderer Praxen.

app.mykaya.de ist demgegenüber Control Plane, internes CRM, neutrale Konto- und Login-Grundlage, Praxisverzeichnis, Betriebsportal, Provisioning-, DNS-, Release-, Heartbeat- und Meeting-Dienst. app.mykaya.de ist kein zentraler Speicher für Patientenakten, keine zentrale Gesundheitsdaten-Cloud, kein fachlicher Proxy, kein Relay und kein Tunnel für Praxisdaten.

app.mykaya.de speichert keine zentrale Nutzer-Praxis-Beziehung, keine Geräte-Praxis-Beziehung und keinen Praxisverbindungs-Vault. Die zentrale Schicht liefert nur eine neutrale Praxis- und Adressliste sowie die Konto- und Login-Grundlage. Die eigentliche Kopplung mit einer Praxis findet danach zwischen App und Praxisinstanz statt und wird lokal in der App beziehungsweise in der Praxisinstanz geführt. trainity sieht im zentralen System nicht, welches Konto, welches Gerät oder welche IP-Adresse sich wann mit welcher Praxis fachlich verknüpft hat.

3. Überblick über die Kaya-Bereiche

BereichZweckDatenraum
mykaya.deÖffentliche Website, Produktinformationen, Kontakt-, Demo- und Preisanfragen.Zentraler Web- und Kommunikationsbereich der trainity GmbH.
app.mykaya.deNeutrale Konto- und Login-Grundlage, CRM, Praxisverzeichnis, Betriebsfunktionen, Kaya Meets und technische Steuerung.Zentraler Datenraum der trainity GmbH ohne Patientenakten und ohne Behandlungsdaten.
Kaya WebFachliche Web-Anwendung der Praxis mit Patienten-, Team-, Dokument-, Chat-, Aufgaben-, Termin-, Telefonie- und Modul-Funktionen.Praxisinstanz der jeweiligen Praxis.
Kaya Patienten-AppMobile Verbindung von Patientinnen und Patienten mit ihrer Praxis.Neutrales Konto zentral; Praxisverbindung lokal in der App und fachlich direkt mit der Praxisinstanz.
Kaya Mitarbeiter-AppMobile Arbeitsoberfläche für Praxisteams mit Praxis-, Standort-, Rollen- und Modulbindung.Neutrale Suche zentral; fachliche Daten, Rollen und Module direkt in der Praxisinstanz.

4. Welche Daten app.mykaya.de verarbeitet

app.mykaya.de verarbeitet personenbezogene Daten, soweit dies für Konto, Login, Sicherheit, Praxisverzeichnis, CRM, Kommunikation, Kaya Meets und den technischen Betrieb erforderlich ist. Dazu gehören insbesondere:

  • neutrale Accountdaten wie Name, E-Mail-Adresse, Telefonnummer, Login-Kennung, Verifizierungsstatus, Passwort- und Wiederherstellungsprozesse;
  • technische Login-, Session-, Sicherheits- und Geräteinformationen, insbesondere Token-Status, Ablaufzeiten, letzter Zugriff, IP-Adresse, User-Agent und sicherheitsrelevante Ereignisse;
  • Praxisverzeichnis- und Organisationsdaten wie Praxisname, Standort, Kontaktangaben, Domain, technische Verbindungsinformationen und freigegebene öffentliche Praxisinformationen;
  • CRM- und Kommunikationsdaten der trainity GmbH, insbesondere Demo-, Preis-, Kontakt-, Vertrags- und Supportkommunikation;
  • Betriebsdaten wie Serverregistrierung, Release-Versionen, gewünschter Zielzustand, Heartbeats, Health-Status, technische Warnungen und Deploy-Ereignisse;
  • Planungs- und Meetingdaten für Kaya Meets, soweit Meetings angelegt oder durchgeführt werden.

app.mykaya.de verarbeitet keine Patientenakten, keine medizinischen Dokumente, keine Diagnosen, keine Behandlungsnotizen, keine fachlichen Praxis-Chats, keine Telefontranskripte und keine Gesundheitsdaten als zentralen Kaya-Datenbestand. Die zentrale Konto- und Verzeichnisebene ist bewusst von fachlichen Praxisdaten getrennt.

app.mykaya.de führt außerdem keine zentrale Liste darüber, welche Patientin, welcher Patient, welches Teammitglied oder welches mobile Gerät mit welcher Praxis verbunden ist. Die zentrale Praxisliste ist eine neutrale Adress- und Directory-Funktion. Nach Auswahl einer Praxis nutzt die App den practiceBaseUrl der jeweiligen Praxisinstanz; fachliche Memberships, Wiedererkennung, Rollen und Praxiszugriffe liegen dort.

5. Kaya Web und die Praxisinstanz

Kaya Web ist die Web-Anwendung der jeweiligen Praxisinstanz. Hier verarbeitet die Praxis ihre fachlichen Daten in ihrem eigenen Datenraum. Je nach aktivierten Modulen können dort insbesondere folgende Daten verarbeitet werden:

  • Patientenstammdaten, Kontaktdaten, Versicherungs- und Behandlungsbezug;
  • Anamnesen, Befunde, Diagnosen, medizinische Notizen, Dokumente, Formulare, Fragebögen und Signaturen;
  • Termine, Aufgaben, Workflows, Teamkommunikation, Praxis-Chats, interne Kommentare und Zuständigkeiten;
  • Mitarbeiterdaten, Rollen, Standorte, Gruppen, Modulfreigaben, Arbeitszeit- und Organisationsdaten;
  • Telefonie- und Telefon-KI-Ereignisse, soweit die Praxis diese Funktionen nutzt;
  • technische Audit-, Sicherheits-, Zugriffs-, Backup-, Fehler- und Betriebsdaten der Praxisinstanz.

Die Praxisinstanz nutzt eigene Domains oder technische Kaya-Subdomains, eigene Transportverschlüsselung, lokale Authentisierung, lokale Rollen, eigene Schlüssel, eigene Secrets und getrennte Speicherbereiche. Der fachliche Datenverkehr der Praxis läuft direkt zur Praxisinstanz und nicht über app.mykaya.de als zentralen Fachdienst.

Für sensible Praxisdaten setzt Kaya auf mehrere Schutzebenen: verschlüsselte Verbindungen, getrennte Praxisserver, feld- und objektbezogene Verschlüsselung, clientseitige Schlüsselableitung, getrennte Schlüsselräume, rollenbasierte Berechtigungen, Auditierung und technische Härtung der Praxisinstanz. Damit ist die Praxisinstanz nicht nur organisatorisch, sondern auch technisch stark vom zentralen Kaya-Betrieb getrennt.

Für bestimmte serverseitige Funktionen kann ein Trusted Processor eingesetzt werden. Der Trusted Processor ist kein allgemeiner Klartextzugang und hält nicht die Benutzer- oder Praxis-Privatschlüssel. Er nutzt einen eigenen, getrennten Schlüsselraum und kann verschlüsselte Inhalte nur für ausdrücklich freigegebene Zwecke verarbeiten, wenn die Praxis hierfür einen entsprechenden Grant aktiviert und ein zusätzlicher Trusted-Processor-Wrap vorhanden ist. Ohne diesen Grant bleiben Inhalte auch für den Trusted Processor nicht lesbar.

6. Kaya Patienten-App

Die Kaya Patienten-App nutzt ein neutrales Kaya-Konto für Registrierung, Login und Wiederherstellung. Die zentrale Kontoebene dient dazu, dass Patientinnen und Patienten die App nach einem Gerätewechsel, nach Löschung der App oder nach erneuter Installation wieder sicher verwenden können.

Die Praxisliste ist neutral. Nach Auswahl einer Praxis läuft die Kopplung und die fachliche Nutzung direkt zwischen Patienten-App und der Praxisinstanz dieser Praxis. Dazu gehören je nach Freigabe der Praxis insbesondere Termine, Nachrichten, Dokumente, Fragebögen, Signaturen, Benachrichtigungen und sonstige Behandlungs- oder Patientenkontexte.

app.mykaya.de erhält für diese fachliche Nutzung keine zentrale Patientenakte, keine Behandlungsinhalte und keine zentrale Information darüber, welche Patientin oder welcher Patient mit welcher Praxis verbunden ist. Wird eine lokale Praxisverbindung aus der App entfernt oder geht sie durch Neuinstallation verloren, wird sie nicht zentral durch trainity wiederhergestellt. Die Verbindung muss erneut mit der jeweiligen Praxisinstanz aufgebaut werden; die Praxisinstanz kann ein bereits berechtigtes Konto dann anhand ihres eigenen Patientenkontexts wieder zuordnen.

Die Patienten-App verwendet technisch notwendige lokale Speicherungen auf dem Endgerät, insbesondere für Login-Zustand, ausgewählte Praxisverbindung, Sprache, Gerätesicherheit, verschlüsselte Schlüsselzustände und Push-Zuordnung. Diese Speicherungen dienen der sicheren App-Nutzung und werden nicht für Werbung, Tracking oder fremde Profilbildung eingesetzt.

Patientinnen und Patienten erhalten zwei Datenschutzebenen: Die trainity-Datenschutzhinweise betreffen zentrale Kaya-Konto-, App-Login-, app.mykaya.de-, Support- und Betriebsdaten. Die Datenschutzinformationen der jeweiligen Praxis betreffen fachliche Behandlungs-, Kommunikations-, Organisations- und Gesundheitsdaten in der Praxisinstanz. Die trainity-Hinweise ersetzen den Praxis-Datenschutzhinweis nicht.

7. Kaya Mitarbeiter-App

Die Kaya Mitarbeiter-App ist eine zentrale mobile App für Praxisteams. Sie ist fachlich aber an die jeweilige Praxisinstanz gebunden. Praxis- und Standortauswahl, aktive Staff-Memberships, Rollen, Gruppen, Module und die Freischaltung des Moduls mitarbeiter_app stammen aus der jeweiligen Praxisinstanz.

Nach Auswahl oder Kopplung einer Praxis verarbeitet die Mitarbeiter-App fachliche Daten direkt gegen die Praxisinstanz. Dazu gehören insbesondere Mitarbeiterprofil, Rollen, Aufgaben, Chats, Arbeitszeit, Kalender, Standorte, Patientenkontext, Push-Zuordnung, Dokumentzugriffe und sonstige Praxisfunktionen.

app.mykaya.de speichert und verarbeitet diese fachlichen Mitarbeiter-App-Daten nicht als zentraler Cloud-Speicher. Die App trennt zentrale Konto- und Verzeichnisfunktionen von praxisbezogener fachlicher Nutzung. Für die fachliche Nutzung gilt das Rollen-, Rechte-, Sicherheits- und Löschkonzept der jeweiligen Praxisinstanz.

Die Mitarbeiter-App kann lokale, technisch notwendige Speicherungen auf dem Endgerät verwenden, etwa für ausgewählte Praxisverbindung, aktive Organisation, Gerätesicherheit, Sprache, Login-Zustand, Push-Zuordnung und verschlüsselte lokale Schlüsselzustände. Diese Speicherungen dienen Sicherheit und Bedienbarkeit und werden nicht für Werbung, Tracking oder fremde Profilbildung eingesetzt.

8. Authentisierung, Sessions und Zugriffsschutz

Kaya nutzt moderne Login- und Session-Verfahren. Web und mobile Apps verwenden sichere OIDC-basierte Login-Flows mit Authorization Code und PKCE. Passwörter werden nicht unnötig durch Fachanwendungen verarbeitet. Sitzungen und Token sind zeitlich begrenzt und werden bei fehlender Berechtigung oder abgelaufener Sitzung beendet.

Fachliche Berechtigungen entstehen nicht allein durch einen zentralen Login. Maßgeblich sind die aktive Praxisverbindung, lokale Mitgliedschaften, Rollen, Gruppen, Modulrechte und Sicherheitsfreigaben der jeweiligen Praxisinstanz. Sensible Vorgänge können zusätzliche Sicherheitsprüfungen, Step-up-Verfahren, höhere Trust-Level oder administrative Freigaben erfordern.

Technisch notwendige Cookies und lokale Speicherungen werden für Login, Session-Schutz, Sicherheit, Funktionsfähigkeit und ausdrücklich gewünschte Dienste eingesetzt. Rechtsgrundlage für Zugriffe auf das Endgerät ist § 25 Abs. 2 TDDDG, soweit die Speicherung oder der Zugriff für den gewünschten Dienst erforderlich ist. Kaya nutzt diese Speicherungen nicht für Marketing-Tracking.

9. Rechtsgrundlagen der Verarbeitung

Für zentrale Kaya-Dienste der trainity GmbH erfolgt die Verarbeitung personenbezogener Daten insbesondere auf Grundlage der folgenden Rechtsgrundlagen:

  • Art. 6 Abs. 1 lit. b DSGVO für Vertrag, Vertragsdurchführung, vorvertragliche Kommunikation, Konto, Login, App-Nutzung und angefragte Produktfunktionen;
  • Art. 6 Abs. 1 lit. f DSGVO für sicheren Betrieb, Missbrauchsschutz, Fehleranalyse, CRM, B2B-Kommunikation, Nachvollziehbarkeit, IT-Sicherheit und Produktverbesserung ohne Marketing-Tracking;
  • Art. 6 Abs. 1 lit. c DSGVO für gesetzliche Aufbewahrungs-, Nachweis-, Mitwirkungs- und Sicherheitsmeldepflichten;
  • Art. 6 Abs. 1 lit. a DSGVO, wenn eine freiwillige Einwilligung eingeholt wird;
  • § 25 Abs. 2 TDDDG für technisch notwendige Cookies und lokale Speicherungen.

Für Gesundheitsdaten und sonstige fachliche Praxisdaten ist die jeweilige Praxis Verantwortliche. Die Praxis verarbeitet diese Daten in ihrer Praxisinstanz im Rahmen ihrer Behandlung, Praxisorganisation, Dokumentation, Kommunikation und gesetzlichen Pflichten. Die hierfür maßgeblichen Rechtsgrundlagen ergeben sich aus der Datenschutzerklärung und den Informationspflichten der Praxis, insbesondere aus Art. 6 DSGVO, Art. 9 DSGVO und den einschlägigen berufs-, sozial- und gesundheitsrechtlichen Vorgaben. Die trainity GmbH betreibt hierfür keine zentrale Gesundheitsdaten-Cloud und keinen zentralen Gesundheitsdatenbestand. Eine technische Unterstützung durch trainity ist auf Betrieb, Bereitstellung, Sicherheit, Updates und Fehlerbehebung der Praxisinstanz begrenzt. Soweit eine Praxis KI-, Speech- oder Telefon-KI-Funktionen nutzt, erfolgt die Inferenzverarbeitung nach den Abschnitten zu KI und Speech.

10. Support- und Administrationszugriffe

Support- und Administrationszugriffe dienen dem technischen Instanzbetrieb, nicht der fachlichen Verarbeitung von Gesundheitsdaten. Sie sind auf das notwendige Mindestmaß begrenzt, etwa für Einrichtung, Erreichbarkeit, Updates, Sicherheitskonfiguration, Backup-/Restore-Fähigkeit, Störungsbeseitigung und die funktionsfähige Bereitstellung der Praxisinstanz auf der genutzten Infrastruktur.

Kaya setzt für solche Zugriffe auf Zweckbindung, Rollen- und Rechtekonzepte, Freigabeprozesse, Protokollierung, Zugriffsbeschränkung, Sperr- und Rotationsmöglichkeiten sowie getrennte administrative Zuständigkeiten. trainity nutzt Supportzugriffe nicht, um Patientenakten, Behandlungsinhalte, Praxis-Chats oder sonstige Gesundheitsdaten fachlich einzusehen oder auszuwerten.

Durch die Verschlüsselungsarchitektur bedeutet ein technischer Betreiberzugriff auf Infrastruktur nicht automatisch einen fachlichen Klartextzugriff. Fachliche Inhalte werden über Schlüsselräume, clientseitige Schutzmechanismen und zweckgebundene Verarbeitung abgesichert.

Soweit für einzelne Serveroperationen ein Trusted Processor genutzt wird, verarbeitet er Inhalte nur im freigegebenen Zweck und gibt keine zugrunde liegenden fachlichen Klartexte an den zentralen API-Betrieb zurück, sondern nur das jeweilige Verarbeitungsergebnis.

11. Telefonie und Telefon-KI

Bei aktivierter Telefonie oder Telefon-KI bleibt die jeweilige Praxis Eigentümerin beziehungsweise Nutzungsberechtigte ihrer Telefonnummern und verantwortet die eingesetzten Rufnummern und Telefonieverträge. trainity stellt keine Telefonnummern bereit.

Der Kaya-Standardpfad für Telefon-KI ist praxisgebunden. Eingehende Telefonie wird über den freigegebenen SIP-/Telefoniepfad der Praxis zur jeweiligen Praxisinstanz geführt. Dort werden Anrufereignisse, Telefon-KI-Verarbeitung und Ergebnisdaten im Datenraum der Praxis verarbeitet. Für Signalisierung und Medientransport werden verschlüsselte Verfahren wie SIP-TLS und SRTP eingesetzt, soweit der jeweilige Telefonieanbieter dies technisch unterstützt.

Der Telefonieanbieter verarbeitet die für Telefonie, Routing und Transport erforderlichen Rufnummern, Verbindungsdaten und Telefonie-Metadaten. Kaya übergibt im Standardpfad keine Patientenakten, keine strukturierten Kaya-Anwendungsdaten, keine Prompts, keine Transkripte und keine LLM-Anfragen an den Telefonieanbieter.

Telefon-Audio, Transkripte und KI-Kontext können Gesundheitsdaten sein, sobald sie Patientenbezug haben. Kaya behandelt diese Daten als besonders schutzbedürftig und verarbeitet sie im Gesundheitsdatenpfad praxisgebunden, protokollarm und ohne Inhaltslogs in zentralen Kaya-Systemen.

Telefon-KI mit Patientenkontext darf im Kaya-Standard erst nach ausdrücklicher Zustimmung der anrufenden Person fachlich arbeiten. Vorher darf sie nur die Opt-in-Ansage ausspielen und die Zustimmung prüfen. Ohne eindeutige Zustimmung wird kein fachlicher KI-Pfad fortgesetzt, sondern ein von der Praxis vorgesehener Alternativweg genutzt.

12. KI, Speech und Inferenzverarbeitung

Kaya nutzt KI- und Speech-Funktionen nur innerhalb klar abgegrenzter Datenflüsse. Gesundheitsdaten werden nicht über eine externe Modell-Cloud als Standardpfad verarbeitet. Für gesundheitsbezogene LLM-, Speech-to-Text- und Text-to-Speech-Verarbeitung nutzt Kaya feste, von trainity selbst betriebene Inferenzressourcen über private Netzverbindungen.

Diese Inferenzressourcen bestehen aus leistungsstarken physischen Rechnern mit jeweils einer modernen GPU. Sie stehen unter Kontrolle der trainity GmbH, befinden sich physisch in von trainity kontrollierten Firmenbereichen, werden nicht durch Dritte betrieben und nicht durch Dritte mitgenutzt. Die Rechner sind nach aktuellem Stand der Technik technisch und organisatorisch abgesichert. Sie sind keine Cloud: Praxen erhalten keinen frei skalierenden Cloud-Dienst, es gibt keine automatische Skalierung, kein elastisches Worker-Pooling und kein automatisches Load-Balancing zwischen austauschbaren Cloud-Ressourcen.

Die Inferenzressourcen stellen LLM, Speech-to-Text und Text-to-Speech bereit. Dabei können gesundheitsbezogene Inhalte, insbesondere Telefon-Audio, Transkripte, Prompts, Praxis- und Patientenkontext oder Workflow-Kontext, für die konkrete Anfrage an diese Rechner übermittelt und dort verarbeitet werden. Die Verarbeitung erfolgt flüchtig, zweckgebunden, ohne Trainingsnutzung und ohne Inhaltslogging für Prompts, Audio, Transkripte oder Antworten. Technische Logs werden auf Fehlerklassen, Zeiten, Status, pseudonyme Kennungen und sicherheitsrelevante Betriebsdaten begrenzt.

Audioaufnahmen, Transkriptionen und strukturierte KI-Ausgaben für die Patientenkartei setzen voraus, dass die Praxis die betroffene Person offen informiert und die erforderliche ausdrückliche Zustimmung oder eine anderweitig tragfähige Rechtsgrundlage dokumentiert hat. Die Praxis bleibt für Rechtsgrundlage, Patienteninformation, Widerruf, Alternativweg und fachliche Übernahme der KI-Ergebnisse verantwortlich.

Soweit verschlüsselte Praxisdaten für solche KI- oder Workflow-Verarbeitung serverseitig benötigt werden, erfolgt die Freigabe zweckgebunden über die Praxisinstanz beziehungsweise über grant-basierte Trusted-Processor-Mechanismen. Daraus entsteht kein allgemeiner Klartextzugriff auf Praxis- oder Patientendaten.

Kaya-KI stellt keine medizinischen Diagnosen, gibt keine Therapie- oder Behandlungsempfehlungen und ersetzt keine ärztliche Beratung. Medizinische Entscheidungen und Auskünfte erfolgen ausschließlich durch das behandelnde Fachpersonal. Kaya unterstützt Kommunikation, Organisation, Dokumentation und administrative Praxisprozesse. Schutzmechanismen im Prompting und in der Produktgestaltung sind darauf ausgerichtet, medizinische Ratschläge und unzulässige Deutungen standardmäßig zu unterbinden. Die KI-Funktionen sind in den Vertrags- und Produktunterlagen an DSGVO, EU AI Act, AVV, TOMs, Human Oversight, Patiententransparenz und Praxisfreigaben ausgerichtet; maßgeblich ist der jeweils dokumentierte Nutzungsscope.

Wenn Kaya im administrativen Kontext Abrechnungspositionen vorschlägt, geschieht dies nur unterstützend und kontextbezogen auf Grundlage der Praxisdaten und einer deterministischen Abrechnungslogik. Die Auswahl, Prüfung, Freigabe und Verantwortung für Abrechnung, Dokumentation, medizinische Einordnung und Kommunikation verbleiben immer bei der Praxis.

Praxen können eigene Workflows konfigurieren, in denen KI-Ausgaben Abläufe vorbereiten, strukturieren oder anstoßen. Die sachgemäße Einrichtung, Freigabe, Überwachung und Nutzung solcher Workflows liegt in der Verantwortung der jeweiligen Praxis. Kaya stellt hierfür technische Schutzmechanismen, Protokollierung, Rollen- und Berechtigungskonzepte sowie die vereinbarten TOMs und vertraglichen Grundlagen bereit.

Für Text-to-Speech kann eine Praxis im Rahmen ihrer Telefon-KI eigene Stimmen erzeugen oder nutzen lassen. Dabei können Audiodaten zur Stimmerzeugung an die Kaya-Inferenzressourcen übermittelt werden. Die Praxis ist dafür verantwortlich, nur Stimmen und Audiodaten von Personen zu verwenden, die hierfür ausdrücklich zugestimmt haben, und keine Stimmen Dritter ohne entsprechende Berechtigung einzusetzen. Die erzeugten Stimmen dürfen nur im rechtlich zulässigen, vereinbarten Praxiszweck verwendet werden.

Optionale Medienfunktionen, etwa für generische Avatar- oder Aufklärungsinhalte, sind nicht für individuelle Patientendaten bestimmt. Sie werden getrennt von Gesundheitsdaten behandelt und dürfen nicht mit Patientenbildern, Patientenstimmen, patientenbezogenen Prompts oder Gesundheitsdaten befüllt werden.

13. Push-Benachrichtigungen

Push-Benachrichtigungen der Kaya Patienten-App und Kaya Mitarbeiter-App sind so gestaltet, dass externe Push-Transportdienste keine fachlichen Inhalte, keine Patientennamen und keine Gesundheitsdaten erhalten. Push-Payloads enthalten neutrale Texte, technische Kennungen und eine Benachrichtigungs-ID.

Fachlicher Kontext wird erst nach Authentisierung in der jeweiligen App aus der Praxisinstanz nachgeladen. Push-Tokens werden bei der jeweiligen Praxisinstanz registriert und dienen ausschließlich der technischen Zustellung angeforderter Benachrichtigungen.

Benachrichtigungsrouten sind zeitlich begrenzt. Geöffnete oder abgelaufene Routen werden nach Ablauf der vorgesehenen Fristen gelöscht. Push-Tokens werden widerrufen, wenn sie über einen längeren Zeitraum nicht erneuert werden, und anschließend gelöscht. Bei Logout, Gerätewechsel oder Entzug der Berechtigung werden Push-Zuordnungen deaktiviert oder entfernt.

14. E-Mail und Praxisnachrichten

Die trainity GmbH verwendet E-Mail für eigene System- und Betriebskommunikation, insbesondere Registrierung, Verifizierung, Login-, Sicherheits-, Demo-, Vertrags- und Supportkommunikation. Der Versand erfolgt über eigene E-Mail-/SMTP-Infrastruktur und beauftragte E-Mail-Dienstleister der trainity GmbH.

Praxisnachrichten aus der jeweiligen Praxisinstanz laufen über die Kommunikationsanbieter und SMTP-Zugangsdaten der Praxis, wenn die Praxis solche Anbieter in ihrer Instanz hinterlegt. Diese Anbieter sind dann Anbieter der Praxis und nicht Subunternehmer der trainity GmbH für den Versand der jeweiligen Praxisnachrichten.

Kaya ist darauf ausgerichtet, fachliche Gesundheitsdaten nicht über zentrale trainity-System-E-Mails zu versenden. Für medizinische Kommunikation, Praxisnachrichten und patientenbezogene Inhalte gelten die Freigaben, Einstellungen und Datenschutzinformationen der jeweiligen Praxis.

15. Kaya Meets und Videomeetings

Kaya Meets ist ein eigener Meeting-Dienst der trainity GmbH für Produktdemos, Abstimmungen, Support, Kundenkommunikation und interne Organisation. Bei Planung und Durchführung eines Meetings werden insbesondere Name, E-Mail-Adresse, Meeting-Titel, Raum-ID, Token, Startzeit, Dauer, Status, Teilnehmerdaten, Join-/Leave-Zeiten sowie technische Verbindungsdaten verarbeitet.

Kamera, Mikrofon und Bildschirmfreigabe werden nur nach Freigabe im Browser oder Betriebssystem genutzt. Eine dauerhafte Aufzeichnung von Kaya Meets findet nicht statt. Chat- und Raumzustände werden nur verarbeitet, soweit dies für das jeweilige Meeting technisch erforderlich ist.

16. Backups, Wiederherstellung und Datenverfügbarkeit

Praxisinstanzen verfügen über eigene Backup- und Wiederherstellungsprozesse. Backups dienen der Wiederherstellung nach technischen Störungen, Sicherheitsereignissen, Fehlbedienung oder Infrastrukturproblemen. Sie werden getrennt vom zentralen app.mykaya.de-Datenraum geführt und gehören zum Datenraum der jeweiligen Praxisinstanz.

Kaya setzt für Praxisinstanzen auf verschlüsselte Sicherungen, beschränkte Retention, automatische Bereinigung, Zugriffsbeschränkung und überprüfbare Wiederherstellungsprozesse. Backup-Metadaten, die für den Betrieb sichtbar sind, enthalten keine Backup-Inhalte, keine fachlichen Dateilisten und keine Gesundheitsdaten.

Löschungen wirken zunächst auf die produktiven Datenbestände. Sicherheitskopien werden im Rahmen der jeweiligen Backup-Retention überschrieben oder bereinigt, soweit keine gesetzlichen Aufbewahrungspflichten, Sicherheitsvorfälle oder vertraglichen Nachweispflichten entgegenstehen.

17. Logs, Audit und Nachvollziehbarkeit

Kaya unterscheidet technische Logs und fachliche Auditdaten. Technische Logs dienen Betrieb, Stabilität, Sicherheit, Missbrauchsschutz und Fehleranalyse. Sie enthalten nach Möglichkeit nur technische Informationen wie Zeitpunkte, Status, Fehlerklassen, pseudonyme Kennungen, Routen, Versionsstände und Betriebsereignisse.

Fachliche Inhalte wie Patientenakten, Gesundheitsdaten, medizinische Dokumente, Prompts, Audio, Transkripte, Chat-Klartexte, Zugangsdaten, private Schlüssel und vertrauliche Providerantworten gehören nicht in technische Standardlogs. Für administrative und sicherheitsrelevante Aktionen werden Auditdaten geführt, damit Zugriffe, Änderungen und Freigaben nachvollziehbar bleiben.

Serverlogs zentraler Kaya-Dienste werden grundsätzlich nach 30 Tagen gelöscht oder anonymisiert, sofern kein Sicherheitsereignis, Missbrauchsverdacht, technischer Vorfall oder gesetzlicher Nachweiszweck eine längere Speicherung erfordert. Für Praxisinstanzen gelten die mit der jeweiligen Praxis vereinbarten Retentions- und Auditvorgaben.

18. Löschung, Sperrung und Aufbewahrung

Personenbezogene Daten werden nur so lange gespeichert, wie es für den jeweiligen Zweck, die Vertragserfüllung, die Sicherheit, die Nachvollziehbarkeit oder gesetzliche Pflichten erforderlich ist.

  • Zentrale Kaya-Kontodaten werden gelöscht oder anonymisiert, wenn das Konto nicht mehr benötigt wird und keine Aufbewahrungs- oder Sicherheitsgründe entgegenstehen.
  • Fachliche Praxisdaten werden nach den Vorgaben und gesetzlichen Pflichten der jeweiligen Praxis gelöscht, gesperrt oder archiviert.
  • Push-Routen, Push-Tokens, Sessiondaten und technische Kurzzeitdaten werden nach Ablauf der vorgesehenen technischen Fristen gelöscht oder widerrufen.
  • Serverlogs werden grundsätzlich zeitlich begrenzt gespeichert und bei Sicherheitsvorfällen nur zweckgebunden länger aufbewahrt.
  • Backups werden über ihre Retention bereinigt; produktive Löschungen werden nicht durch zentrale Kaya-Systeme in fachliche Praxisdaten zurückgespielt.
  • Handels-, steuer-, berufs- oder gesundheitsrechtliche Aufbewahrungsfristen bleiben unberührt.

19. Betroffenenrechte und Unterstützung der Praxis

Betroffene Personen haben nach Maßgabe der DSGVO insbesondere das Recht auf Auskunft, Berichtigung, Löschung, Einschränkung der Verarbeitung, Datenübertragbarkeit, Widerspruch und Widerruf erteilter Einwilligungen.

Für zentrale Dienste der trainity GmbH können Rechte direkt gegenüber der trainity GmbH geltend gemacht werden. Für fachliche Praxisdaten ist die jeweilige Praxis der richtige Ansprechpartner. Die trainity GmbH unterstützt die Praxis technisch und organisatorisch, soweit dies zur Bearbeitung eines Betroffenenanliegens in Kaya erforderlich ist.

Zur eindeutigen Zuordnung und zum Schutz vor unberechtigter Auskunft können angemessene Identitäts- und Berechtigungsprüfungen erforderlich sein. Daten anderer Personen, Daten anderer Praxen, Sicherheitsgeheimnisse und Rechte Dritter werden dabei geschützt.

20. Empfänger, Subunternehmer und praxis-eigene Anbieter

Personenbezogene Daten werden nur an Empfänger übermittelt, soweit dies für Bereitstellung, Betrieb, Sicherheit, Support, Kommunikation, Telefonie, Push-Transport, Meeting-Funktionen oder gesetzliche Pflichten erforderlich ist. Empfänger können insbesondere sein:

  • berechtigte Mitarbeitende und Administratoren der trainity GmbH;
  • die jeweilige Praxis und berechtigte Nutzerinnen und Nutzer ihrer Praxisinstanz;
  • von trainity selbst betriebene Kaya-Inferenzressourcen für LLM, Speech-to-Text und Text-to-Speech, soweit die jeweilige Praxis diese Funktionen nutzt;
  • Hosting-, Infrastruktur-, DNS-, Domain- und E-Mail-Dienstleister;
  • Telefonie- und SIP-Anbieter bei aktivierter Telefonie oder Telefon-KI;
  • Push-Transportdienste der jeweiligen Mobilplattform;
  • Meeting-Teilnehmer, soweit Daten für Einladung, Durchführung und Nachvollziehbarkeit eines Meetings erforderlich sind;
  • optionale Medien- und Funktionsanbieter bei aktivierten, nicht gesundheitsdatenbezogenen Medienfunktionen;
  • Behörden, Gerichte, Versicherer, Berater oder sonstige Stellen, soweit eine gesetzliche Pflicht besteht oder Rechte geltend gemacht, ausgeübt oder verteidigt werden.

Eine aktuelle Übersicht über Subunternehmer und externe Dienste steht unter Subunternehmer und externe Dienste. Anbieter, die eine Praxis selbst beauftragt und in ihrer eigenen Praxisinstanz hinterlegt, insbesondere SMTP-, SIP-, Telefonie- oder Kommunikationsanbieter, sind für diese Praxisverarbeitung Anbieter der Praxis und nicht Subunternehmer der trainity GmbH.

Die trainity GmbH verkauft keine personenbezogenen Daten und gibt personenbezogene Daten nicht für fremde Werbung weiter.

21. Drittlandübermittlungen

Kaya betreibt zentrale Dienste und Praxisinstanzen im dokumentierten Standard über sorgfältig ausgewählte Infrastruktur in Deutschland beziehungsweise der Europäischen Union. Bei einzelnen Diensten können gleichwohl Übermittlungen oder Zugriffe außerhalb der Europäischen Union oder des Europäischen Wirtschaftsraums stattfinden, insbesondere bei Mobilplattformen, Push-Transportdiensten oder optionalen Medien- und Funktionsanbietern.

Solche Übermittlungen erfolgen nur auf Grundlage der gesetzlichen Voraussetzungen, insbesondere eines Angemessenheitsbeschlusses, geeigneter Garantien wie EU-Standardvertragsklauseln oder einer sonstigen zulässigen Rechtsgrundlage. Wo eine Praxis eigene Anbieter nutzt, bewertet und verantwortet die Praxis deren Datenübermittlungen im Rahmen ihrer eigenen Verarbeitung.

22. Technische und organisatorische Schutzmaßnahmen

Kaya ist für den Einsatz im sensiblen Praxisumfeld konzipiert. Die Schutzmaßnahmen kombinieren Architektur, Verschlüsselung, Zugriffskontrolle, Betriebssicherheit und organisatorische Prozesse. Dazu gehören insbesondere:

  • getrennte Praxisinstanzen mit eigener Datenbank, eigenen Schlüsseln, eigenen Secrets, eigener Domain und eigenem Berechtigungsraum;
  • Transportverschlüsselung für Web-, App-, API-, Meeting- und Telefoniepfade;
  • feld- und objektbezogene Verschlüsselung für sensible fachliche Inhalte;
  • clientseitige Schlüsselableitung, getrennte Login- und Verschlüsselungsgeheimnisse sowie verschlüsselte Schlüsselzustände;
  • grant-basierte Trusted-Processor-Verarbeitung für freigegebene Serveroperationen ohne allgemeinen Klartextzugriff der zentralen API und ohne Trusted-Processor-Zugriff ohne aktiven Grant;
  • rollenbasierte Berechtigungen, lokale Mitgliedschaften, Modulrechte, Step-up-Mechanismen und administrative Zugriffsbeschränkungen;
  • private Netzwerkpfade zu eigenen physischen Kaya-Inferenzrechnern für gesundheitsbezogene LLM-, Speech-to-Text- und Text-to-Speech-Verarbeitung;
  • keine externe Modell-Cloud im Standardpfad, keine automatische Cloud-Skalierung, keine Trainingsnutzung von Praxis- oder Patientendaten und keine zentralen Inhaltslogs für Prompts, Audio, Transkripte oder Antworten;
  • KI-Schutzmechanismen gegen medizinische Diagnosen, Therapieempfehlungen und unzulässige medizinische Deutungen durch Kaya-KI;
  • neutrale Push-Payloads ohne Patientennamen, Gesundheitsdaten oder fachliche Inhalte;
  • gehärtete Praxisserver, getrennte interne Dienste, Firewall-Regeln, beschränkte öffentliche Endpunkte und sichere Release-Prozesse;
  • verschlüsselte Backups, begrenzte Retention, Wiederherstellungsprozesse und technische Evidence-Metadaten ohne Backup-Inhalte;
  • technische Log-Reduktion, Auditierung sicherheitsrelevanter Aktionen und Trennung von Betriebslogs und fachlichen Klartexten;
  • Zweckbindung, Freigabe, Protokollierung und Begrenzung von Support- und Administrationszugriffen;
  • regelmäßige Aktualisierung von Sicherheitskonfiguration, Abhängigkeiten, Betriebsprozessen und Datenschutzunterlagen.

23. Keine automatisierte Entscheidungsfindung

Kaya trifft im Rahmen der hier beschriebenen Produkt-, App- und Betriebsfunktionen keine ausschließlich automatisierten Entscheidungen mit rechtlicher Wirkung oder vergleichbarer erheblicher Beeinträchtigung im Sinne von Art. 22 DSGVO. KI-Funktionen unterstützen Kommunikation, Organisation, Dokumentation, Zusammenfassung, Telefonie, administrative Workflows und Abrechnungsvorbereitung. Kaya-KI stellt keine medizinischen Diagnosen, gibt keine Therapie- oder Behandlungsempfehlungen und ersetzt keine ärztliche Beratung. Medizinische Bewertung, Behandlung, Auskunft, Freigabe, Workflow-Nutzung und Abrechnung verbleiben bei der jeweiligen Praxis und den dort berechtigten Personen.

24. Verhältnis zu weiteren Datenschutzinformationen

Diese Hinweise beschreiben den Datenschutz im Kaya-Produkt. Ergänzend gelten die Datenschutzerklärung für mykaya.de und app.mykaya.de, die Subunternehmerübersicht sowie die Datenschutzinformationen der jeweiligen Praxis für die fachliche Behandlung, Praxisorganisation und Patientenkommunikation.

Bei Abweichungen zwischen allgemeinen Produktinformationen und den konkreten Datenschutz- und Vertragsunterlagen einer Praxis ist der tatsächlich aktivierte Leistungsumfang der jeweiligen Praxisinstanz maßgeblich.

25. Beschwerderecht bei der Aufsichtsbehörde

Betroffene Personen haben das Recht, sich bei einer Datenschutzaufsichtsbehörde zu beschweren. Für die trainity GmbH ist insbesondere zuständig:

Aufsichtsbehörde
Der Landesbeauftragte für den Datenschutz Niedersachsen
Anschrift
Prinzenstraße 5, 30159 Hannover
Telefon
0511 120-4500
E-Mail
poststelle@lfd.niedersachsen.de
Website
https://www.lfd.niedersachsen.de

26. Änderungen dieser Hinweise

Die trainity GmbH passt diese Datenschutzhinweise an, wenn sich das Kaya-System, die eingesetzten Dienste, die Verarbeitungsvorgänge, die Sicherheitsmaßnahmen oder rechtliche Anforderungen ändern. Es gilt die jeweils veröffentlichte Fassung.

Stand: Juli 2026

Weitere Compliance-SeitenDatenschutzerklärungNutzungsbedingungen Patienten-AppNutzungsbedingungen Mitarbeiter-AppSubunternehmerSicherheit & Compliance