Health Connect kann jetzt echte Krankenakten – was das für App-Entwickler heißt

Wenn ich mit jemandem über Gesundheits-Apps auf Android rede, landen wir fast immer bei Schritten, Puls und Schlaf. Das ist die Welt, die Google Fit jahrelang war. Und genau die läuft jetzt aus: Die alten Google-Fit-APIs werden bis Ende 2026 abgeschaltet – die Neuanmeldung ist längst zu, der endgültige Schnitt kommt in wenigen Monaten. Darüber habe ich hier schon geschrieben. Was dabei fast immer untergeht: Der Nachfolger Health Connect ist in aller Stille etwas geworden, das Google Fit nie war. Er kann inzwischen echte medizinische Daten – nicht bloß Schritte, sondern Medikamente, Allergien, Laborwerte, Impfungen. Ich finde das die spannendste Entwicklung im Android-Gesundheitsbereich dieses Jahres, und kaum jemand redet darüber.

Von „Schritte zählen" zu „Krankenakte lesen"

Health Connect war anfangs eine reine Sammelstelle für Fitnessdaten: eine App schreibt hinein, eine andere liest heraus, der Nutzer entscheidet, wer was darf. Nützlich, aber überschaubar.

Die neue Ebene heißt Medical Records (in der API: Personal Health Record, kurz PHR). Damit darf eine App – natürlich nur mit ausdrücklicher Erlaubnis – die tatsächlichen Gesundheitsdaten einer Person lesen und schreiben. Und zwar nicht in irgendeinem selbst­gebastelten Format, sondern in FHIR (Fast Healthcare Interoperability Resources), dem offenen Standard der Organisation HL7, auf dem die halbe digitale Gesundheitswelt aufbaut. Health Connect unterstützt die Fassungen FHIR R4 (4.0.1) und R4B (4.3.0).

Konkret sind es aktuell elf Datenkategorien, jede mit ihrer eigenen Berechtigung:

• Medikamente (aus den FHIR-Ressourcen Medication, MedicationRequest, MedicationStatement)
• Allergien und Unverträglichkeiten (AllergyIntolerance)
• Laborwerte (Observation aus der Laborkategorie)
• Diagnosen (Condition)
• Impfungen (Immunization)
• Vitalzeichen, Schwangerschaft, Prozeduren, Sozialanamnese,

Arztbesuche und Stammdaten zur Person

Jede dieser Kategorien braucht eine eigene Leseberechtigung wie READ_MEDICAL_DATA_MEDICATIONS oder READ_MEDICAL_DATA_ALLERGIES_INTOLERANCES. Das ist keine Kleinigkeit, sondern die eigentliche Idee dahinter: Eine App bekommt nicht „die Gesundheitsdaten", sondern genau die Schublade, die sie wirklich braucht – und der Nutzer sieht das auf einem eigenen Berechtigungs-Bildschirm, getrennt von den normalen Fitness-Freigaben.

Warum mich das als Android-Entwickler interessiert

Ich baue Android-Apps in Kotlin und Jetpack Compose. Bisher hieß „Gesundheits-App" fast immer: Sensoren, Schritte, vielleicht eine Herzfrequenz von der Uhr. Mit den Medical-Records- APIs kann eine App plötzlich sinnvoll auf der Ebene arbeiten, auf der Ärztinnen und Apotheken denken. Ein paar Beispiele, die vorher unrealistisch waren:

• Eine Medikations-App, die den echten Medikationsplan liest und bei einer neuen

Verordnung vor einer Wechselwirkung warnt – statt dass der Nutzer alles abtippt.

• Ein Allergie-Pass, der beim Arztbesuch nicht auf Erinnerung baut, sondern auf die

hinterlegten AllergyIntolerance-Einträge.

• Eine Reha- oder Chroniker-App, die Laborverläufe über Zeit zeigt, weil sie echte

Observation-Werte bekommt statt manuell eingetippter Zahlen.

Und weil das Ganze auf FHIR steht, spricht die App dieselbe Sprache wie die Systeme dahinter. In Deutschland ist das kein Zufall: Die elektronische Patientenakte und viele Klinik­systeme setzen ebenfalls auf FHIR. Wer heute sauber auf diesem Standard baut, hat es morgen leichter, wenn es um Anbindung geht.

Der ehrliche Teil: Das ist noch nicht fertig

Ich will dir das nicht schöner malen, als es ist. Die Medical-Records-APIs sind aktuell ausdrücklich experimentell – im Code tragen sie die Markierung @ExperimentalPersonalHealthRecordApi, und das heißt: Die Schnittstellen können sich noch ändern. Dazu kommt:

• Man braucht das Android-16-SDK und Health Connect über die Jetpack-Bibliothek ab

1.1.0-beta02. Die alten Framework-APIs reichen nicht.

• Die Play-Store-Richtlinie für den Umgang mit medizinischen Daten ist selbst noch in

Arbeit. Bevor so eine App in den Store darf, wird Google zusätzliche Auflagen machen – bei Gesundheitsdaten völlig zu Recht.

• Und alles Rechtliche, das ich hier schon zu DiGA und DiPA geschrieben habe, gilt weiter:

Sobald eine App diagnostiziert oder behandelt, kann sie ein Medizinprodukt sein. Die bloße technische Möglichkeit, Laborwerte zu lesen, macht deine App noch nicht zugelassen.

Für mich heißt das nicht „Finger weg", sondern „jetzt anschauen, aber noch nicht die App darauf verwetten". Genau der richtige Moment, um zu verstehen, wie FHIR in Health Connect funktioniert – solange die Sache noch klein und überblickbar ist. Wenn die APIs stabil werden, kennst du dann schon den Weg.

Wenn du über eine Gesundheits-App nachdenkst und wissen willst, ob dein Vorhaben mit Health Connect, FHIR und dem deutschen Rechtsrahmen überhaupt zusammenpasst, schau auf bymw.de vorbei – ich baue genau solche Android-Apps in Kotlin und Compose und schaue mir das gern konkret mit dir an. Bei allem, was Richtung Diagnose oder Behandlung geht, ersetzt mein Blog aber keine Rechts- oder Regulierungsberatung – das gehört sauber geprüft, bevor Code entsteht.

Quellen

• Health Connect – Medical Records (Android Developers)
• Medical Records – Data format: FHIR-Versionen und Ressourcentypen (Android Developers)
• Health Connect – Jetpack Release Notes (Google Fit wird bis Ende 2026 unterstützt)