Na een onrustige nacht download je een slaapapp, koppel je je wearable en tik je op 'Sta toe' bij een reeks toestemmingsschermen. De volgende ochtend zie je een overzichtelijk dashboard met slaapfasen, hartslagpatronen en inzichten over herstel. Wat je misschien niet ziet, is de route achter dat dashboard: welke informatie op je telefoon blijft, welke gegevens de servers van de app bereiken en of externe analyse- of advertentiepartners ze kunnen ontvangen.
Die onzekerheid is het kernprobleem bij de privacy van gezondheidsgegevens. Een patiëntenportaal van een ziekenhuis en een losse welzijnsapp kunnen allebei je hartslag of klachten tonen, maar er kunnen verschillende wetten, contracten, technische systemen en verdienmodellen voor gelden. Deze gids legt die lagen in gewone taal uit, zodat je een echte privacybescherming kunt onderscheiden van een geruststellende zin in de beschrijving van een app.
Waarom privacy van gezondheidsgegevens belangrijker is dan je denkt
Een slaapapp kan gewone metingen omzetten in een intiem profiel. Hartslagvariabiliteit kan wijzen op stress of herstel. Herhaaldelijk 's nachts wakker worden kan patronen van slapeloosheid blootleggen. Notities over klachten kunnen een chronische aandoening, een medicatieroutine, een zorg over voortplanting of psychische problemen prijsgeven. De informatie wordt nog gevoeliger als een app die combineert met locatie, apparaat-ID's, leeftijd, surfgedrag of aankoopgedrag.
De gegevensstroom kan moeilijk te zien zijn. Een wearable legt een signaal vast, de telefoon importeert het, de app analyseert het en softwareontwikkelkits kunnen gebruiks- of meetgegevens naar externe diensten sturen. Die diensten kunnen bijvoorbeeld crashrapporten, productanalyse, personalisatie, advertenties of andere functies ondersteunen die in een privacybeleid staan beschreven. Misschien heb je de eerste koppeling goedgekeurd zonder te beseffen dat de zakenpartners van de app, en niet de interface van de app zelf, bepalen waar sommige informatie naartoe gaat.
Waarom deze informatie zo moeilijk te vervangen is
Een wachtwoord kun je na een datalek veranderen. Een geschiedenis van je hartritme, een tijdlijn van klachten of een dossier over reproductieve gezondheid kun je niet zo makkelijk vervangen. Zelfs als een dataset je naam niet bevat, kunnen combinaties van tijdstempels, locaties, apparaatgegevens en gedrag iemand herkenbaar maken.
De omvang van de blootstelling laat zien waarom de architectuur ertoe doet. Een collegiaal getoetst overzicht registreerde 2.216 datalekken in de zorg in 65 landen in 2018 en meldde dat tussen 2005 en 2019 249,09 miljoen mensen werden getroffen, van wie 157,40 miljoen in de laatste vijf jaar van die periode. Hetzelfde overzicht telde 3.912 incidenten met datalekken in de zorgsector in de bredere dataset van 2005 tot 2019. Deze cijfers komen uit het collegiaal getoetste overzicht van datalekken in de zorg.
Vuistregel: behandel een stroom hartslaggegevens, een klachtendagboek of een slaapgeschiedenis als gevoelig, ook als een app zichzelf een 'welzijnsapp' noemt.
De privacygrens die veel gebruikers missen
Traditionele privacyregels in de zorg kunnen informatie beschermen die in handen is van een ziekenhuis, kliniek, verzekeraar of een dienstverlener die voor hen werkt. Ze volgen de gegevens niet automatisch als je ze naar een consumentenapp kopieert, een wearable koppelt of een rapport naar een andere dienst exporteert.
Dat onderscheid betekent niet dat elke consumentenapp onveilig is. Het betekent dat je preciezere vragen moet stellen: Wie ontvangt de gegevens? Waar worden ze verwerkt? Worden ruwe gegevens opgeslagen? Kun je ze verwijderen? Gebruikt de app analysediensten van derden? Zodra je die vragen kunt beantwoorden, wordt privacy iets wat je kunt beoordelen in plaats van iets wat je moet aannemen.
De bescherming van HIPAA en de AVG begrijpen
HIPAA legt in de Verenigde Staten een belangrijke basis, maar het is geen universeel label dat aan elk gezondheidsproduct hangt. Het moderne privacytijdperk wordt vaak teruggevoerd op de invoering van HIPAA op 21 augustus 1996. De Privacy Rule werd uitgevaardigd in december 2000, werd van kracht op 14 april 2001, en de meeste betrokken zorgaanbieders en zorgverzekeraars moesten er in april 2003 aan voldoen, volgens de tijdlijn van HIPAA van de CDC.
HIPAA geldt meestal voor zogenoemde covered entities, zoals ziekenhuizen, klinieken, zorgverzekeraars en clearinghouses in de zorg, en voor business associates die beschermde informatie voor hen verwerken. Een patiëntenportaal dat aan een ziekenhuis is verbonden, kan daarom onder HIPAA-verplichtingen vallen. Een losse app voor meditatie, fitness of klachten valt daar misschien niet onder, ook al verzamelt die informatie die onmiskenbaar medisch aanvoelt.
Waar je op let in de taal van een app
'HIPAA-compliant' moet een praktische vraag oproepen en niet het gesprek beëindigen. Werkt een app voor een zorgorganisatie die onder HIPAA valt, vraag dan of de relatie is vastgelegd in een Business Associate Agreement, waarin de verantwoordelijkheden voor het verwerken van beschermde gezondheidsinformatie staan. 'HIPAA-aligned' of 'HIPAA-ready' kan een ontwerpaanpak beschrijven, maar die termen alleen bewijzen niet dat de wet van toepassing is.
De AVG (GDPR) werkt anders. Die kan van toepassing zijn als een organisatie persoonsgegevens verwerkt van mensen in de Europese Economische Ruimte, afhankelijk van de omstandigheden. Gezondheidsgegevens gelden als een bijzondere categorie persoonsgegevens, die sterker wordt beschermd en waarvoor een geldige rechtsgrond en een voorwaarde voor verwerking nodig zijn. De AVG kan ook rechten geven zoals inzage, verwijdering en gegevensoverdraagbaarheid, al kunnen die rechten beperkingen hebben.
| Aspect | HIPAA (VS) | AVG (EU/EER) |
|---|---|---|
| Belangrijkste reikwijdte | Zorgorganisaties die onder de wet vallen en hun business associates | Organisaties die persoonsgegevens van betrokkenen verwerken in de situaties waarin de wet geldt |
| Gezondheidsinformatie | Beschermde gezondheidsinformatie in handen van zorgorganisaties die onder de wet vallen en relevante partners | Gezondheidsgegevens zijn een bijzondere categorie die extra bescherming vraagt |
| Toestemming | Privacyregels bepalen welk gebruik en welke verstrekking zijn toegestaan; toestemming speelt in specifieke situaties een rol | Toestemming kan één rechtsgrond zijn, maar organisaties kunnen waar toegestaan ook andere rechtmatige grondslagen gebruiken |
| Controle voor gebruikers | Rechten op inzage en correctie gelden binnen het kader van HIPAA | Rechten op inzage, verwijdering, overdraagbaarheid en andere rechten kunnen gelden, met beperkingen |
| Consumentenapps | Vallen vaak buiten HIPAA, tenzij ze verbonden zijn aan een zorgorganisatie die onder de wet valt | Kunnen onder de AVG vallen als de territoriale en verwerkingsregels van toepassing zijn |
Een privacybeleid kan je helpen de positie van een app te begrijpen, maar wettelijke naleving is alleen de ondergrens. Het technische ontwerp bepaalt of ruwe gegevens op een server staan, of medewerkers erbij kunnen en of externe code ze ontvangt. Je kunt het privacybeleid van Cardiogram bekijken als voorbeeld van het soort details over architectuur en gegevensverwerking waar gebruikers naar moeten zoeken.
Hoe technische privacymodellen werken
De privacyarchitectuur bepaalt hoeveel informatie je apparaat moet verlaten. Neem twee gezondheidsapps die een trend in de rusthartslag berekenen. De ene stuurt ruwe metingen naar een server voor analyse. De andere berekent de trend op de telefoon en bewaart het resultaat lokaal of in een beveiligde persoonlijke back-up. De schermen kunnen er hetzelfde uitzien, maar de gegevens gaan door verschillende systemen en leveren verschillende routes van blootstelling op.
De plaats van verwerking verandert het risico
Bij verwerking op het apparaat blijven sensorgegevens op de telefoon zelf. De telefoon leest het signaal, voert de berekening uit en toont het resultaat zonder de ruwe gegevens naar een server van het bedrijf te sturen. Zo zijn er minder systemen die de oorspronkelijke gegevens ontvangen en moeten beschermen. Het neemt niet elk risico weg. Een gehackt apparaat, een screenshot, een export of een gekoppelde integratie kan de informatie nog steeds blootstellen.
Apple geeft aan dat gegevens van de Gezondheid-app en HealthKit op het apparaat worden versleuteld en alleen toegankelijk zijn als het apparaat is ontgrendeld met een toegangscode, Touch ID of Face ID. Met twee-factor-authenticatie en een ondersteunde iOS-versie krijgen gezondheidsgegevens die via iCloud worden gesynchroniseerd end-to-end-versleuteling, wat betekent dat Apple ze niet kan lezen, zoals beschreven in de uitleg van Apple over de beveiliging van gezondheidsgegevens.
Toestemmingen zijn een tweede poort. Kaders voor gezondheidsgegevens kunnen een app laten vragen om bepaalde categorieën, zoals stappen of hartslag, terwijl leestoegang en schrijftoegang gescheiden blijven. Vergelijk elk verzoek met het doel dat de app opgeeft. Een tool die je hartslag analyseert, heeft misschien metingen nodig, maar hoort niet automatisch je contacten, een niet-gerelateerde locatiegeschiedenis of toestemming om je gezondheidsdossier te wijzigen te krijgen.
Versleuteling beschermt verschillende momenten
Versleuteling tijdens het transport beschermt informatie terwijl die over een netwerk gaat. Ze kan voorkomen dat buitenstaanders de overdracht lezen, maar de ontvangende dienst kan de gegevens misschien nog steeds openen en verwerken. Versleuteling in opslag beschermt opgeslagen informatie op een apparaat of server, zoals een kluis de inhoud beschermt nadat die is afgeleverd.
End-to-end-versleuteling gaat verder. De afzender versleutelt de informatie, alleen het apparaat van de bedoelde gebruiker kan die ontsleutelen en de dienstverlener kan de inhoud niet inzien. Dat beperkt wat de aanbieder met de gegevens kan doen. Het ontwerp van accountherstel en back-ups blijft belangrijk, omdat dat kan bepalen wie uiteindelijk toegang heeft.
Apple zegt ook dat sommige gezondheidswaarden, waaronder Trends, Hoogtepunten, rusthartslag en voorspellingen van Cyclusregistratie, op het apparaat worden berekend. De whitepaper van Apple over privacy van gezondheidsgegevens laat het verschil zien tussen ruwe signalen lokaal houden en ze naar een clouddienst sturen om er conclusies uit te trekken.
Architectuurtest: vraag of de aanbieder je ruwe gegevens nodig heeft om de functie te leveren. Is dat niet zo, dan zorgen lokale verwerking en minimale verzameling meestal voor een kleiner blootstellingsoppervlak.
Differentiële privacy kan een extra laag toevoegen door gecontroleerde ruis in samengevoegde resultaten te brengen. Organisaties kunnen dan brede patronen bestuderen zonder een individueel dossier te publiceren. Het is geen toverstaf. De uitvoering, de instellingen, de toegangscontrole en de bewaartermijnen bepalen nog steeds het praktische resultaat.
Zoek naar bewijs in plaats van bijvoeglijke naamwoorden. Onafhankelijke beveiligingsaudits, penetratietests, duidelijke technische documentatie en controleerbare opensourceonderdelen geven meer vertrouwen dan alleen woorden als 'beveiliging van militair niveau'.
Verwerking op het apparaat of synchronisatie via de cloud
Bij lokale verwerking blijven metingen op de telefoon. Bij synchronisatie via de cloud gaan ze naar de infrastructuur van een aanbieder. Beide aanpakken kunnen nuttige gezondheidsfuncties ondersteunen, maar ze brengen verschillende privacyrisico's met zich mee voor hartslagmetingen, notities over klachten en gegevens van wearables.
De route van de gegevens is belangrijker dan het label. Een app kan een resultaat op het apparaat berekenen, gegevens kopiëren via een persoonlijke back-updienst of ruwe informatie naar de eigen servers uploaden. Elke route verandert wie de gegevens kan opslaan, herstellen, analyseren of erbij kan bij een supportverzoek.
Het lokale model
Lokale verwerking kan geschikt zijn voor informatie die je niet bij een app-bedrijf wilt hebben, zoals hartslagvariabiliteit, gedetailleerde slaappatronen of notities over klachten. De telefoon kan een patroon berekenen zonder de onderliggende metingen naar een extern systeem te sturen. Dat kan minder serverdatabases, analysepijplijnen en toegang door medewerkers opleveren, en de functie kan blijven werken zonder constante verbinding.
Het nadeel is de continuïteit. Gaat het apparaat kapot en is er geen beveiligde back-up, dan kan lokaal opgeslagen informatie moeilijk of onmogelijk te herstellen zijn. Lokale apps bieden ook vaak beperkte toegang op meerdere apparaten. Misschien moet je zelf een export regelen voordat je een rapport met een arts deelt.
Een toestemmingsinstelling bewijst op zichzelf niet dat de verwerking lokaal blijft. Controleer of de app alleen een resultaat ontvangt, zoals een trend, of ook de ruwe metingen uploadt waarmee dat resultaat wordt berekend. Het privacyverschil lijkt op het verschil tussen een uitgerekende som ontvangen en elk kladblaadje inleveren.
Het cloudmodel
Synchronisatie via de cloud maakt herstellen en toegang makkelijker. Je kunt een geschiedenis terugzetten na het vervangen van een telefoon, meer dan één apparaat gebruiken en een back-up bijhouden zonder handmatig bestanden te exporteren. Dat gemak brengt meer plekken met zich mee die beschermd moeten worden, waaronder applicatieservers, back-upsystemen, logbestanden, supportsystemen en integraties.
De praktische vraag is in wiens cloud de informatie staat. Controleer welke versleuteling van toepassing is, wie de sleutels beheert en of de aanbieder de inhoud kan lezen. Een persoonlijke cloudback-up met end-to-end-versleuteling volgt een andere privacyroute dan opslag bij een derde partij waar het app-bedrijf leesbare kopieën bewaart. Een wearable kan hartslaggegevens naar de telefoon sturen, de telefoon kan geselecteerde gegevens naar een persoonlijk account synchroniseren en de app kan daarnaast klachten naar de eigen servers uploaden.
De privacybescherming op het niveau van zorgaanbieders volgt consumentengegevens niet automatisch naar elke app. Een dienst die aan een ziekenhuis is verbonden, kan gegevens verwerken binnen een gereguleerde relatie, terwijl een onafhankelijke welzijnsapp onder haar eigen beleid kan werken. Bekijk de route en de verantwoordelijke organisatie, in plaats van aan te nemen dat alle gezondheidsgerelateerde gegevens dezelfde bescherming krijgen.
| Vraag | Ontwerp met verwerking op het apparaat | Ontwerp met synchronisatie via de cloud |
|---|---|---|
| Locatie van ruwe gegevens | Blijft vooral op het apparaat | Kan naar de infrastructuur van de aanbieder worden verstuurd |
| Herstel | Hangt af van het apparaat en de beschikbare back-up | Ondersteunt meestal herstel via een account |
| Blootstellingsoppervlak | Kleinere voetafdruk aan de serverkant | Meer systemen en integraties moeten worden beschermd |
| Gebruik op meerdere apparaten | Kan beperkt zijn | Meestal handiger |
| Complexiteit van verwijderen | Richt zich op het apparaat en persoonlijke back-ups | Moet rekening houden met servers, back-ups, exports en partners |
Geen van beide modellen is automatisch veilig. Een lokale app kan gegevens blootstellen via te ruime toestemmingen of onveilige exports. Een cloudapp kan informatie beschermen met sterke toegangscontrole en end-to-end-versleuteling, maar toch meer kopieën bewaren en meer toegangspunten creëren. Stem de architectuur af op de gevoeligheid van de gegevens en het doel van de functie. Dit overzicht van digitale gezondheidsoplossingen geeft meer context over hoe het ontwerp van software werkprocessen in de zorg beïnvloedt.
Privacyclaims van gezondheidsapps beoordelen
Lees privacyclaims alsof je een gegevensroute inspecteert, niet alsof je reclametekst beoordeelt. Loop de vragen hieronder door voordat je klachten invoert of een wearable koppelt.
Begin bij de juridische relatie
Zoek de juridische identiteit van de ontwikkelaar op en stel vast of de app verbonden is aan een ziekenhuis, kliniek, verzekeraar of andere zorgorganisatie die onder de wet valt. Claimt de app onder HIPAA te vallen, zoek dan naar uitleg over die relatie en de bijbehorende verantwoordelijkheden als business associate. Claimt de app dat niet, ga er dan van uit dat HIPAA misschien niet geldt voor de dienst aan consumenten, tenzij de ontwikkelaar iets anders uitlegt.
Dit is geen oordeel over kwaliteit. Het vertelt je welke bescherming je van de wet kunt verwachten en welke bescherming moet komen uit het eigen beleid en de architectuur van de app.
Lees het onderdeel over delen zorgvuldig
Zoek naar termen als analyse, advertenties, partners, databrokers, dienstverleners, onderzoek en geanonimiseerde gegevens. 'Vertrouwde partners' zegt minder dan een benoemde categorie, een vermeld doel en een duidelijke uitleg van welke velden de app verlaten.
Let op combinaties. Een app kan zeggen dat ze geen gezondheidsgegevens verkoopt en tegelijk toestaan dat een derde partij identificatiegegevens, gebeurtenisgegevens of apparaatinformatie ontvangt voor advertenties of metingen. Die details kunnen ertoe doen, ook als het beleid het woord 'verkopen' vermijdt.
Vergelijk de toestemmingen met de functie
Een toestemmingsverzoek moet duidelijk samenhangen met de functie van de app. Een meditatieapp die om je contacten vraagt, verdient een kritische blik. Een menstruatie-app die om niet-gerelateerde locatietoegang vraagt, moet dat uitleggen. Een tool voor hartslaganalyse die om alleen-lezentoegang tot je hartslag vraagt, is makkelijker te rechtvaardigen dan een tool die brede schrijftoegang tot je hele gezondheidsdossier vraagt.
Gebruik de toestemmingsinstellingen van het besturingssysteem om categorieën te weigeren die de functie niet nodig heeft. Kijk na updates opnieuw naar die toestemmingen, omdat de toegang die een app vraagt kan veranderen.
Test de belofte zelf
Controleer voordat je op een app vertrouwt of die het volgende biedt:
- Gegevens exporteren: kun je een bruikbare kopie van je gegevens krijgen zonder contact op te nemen met de support?
- Account verwijderen: wordt bij verwijderen uitgelegd wat er gebeurt met actieve gegevens, back-ups, logbestanden en informatie die wettelijk moet worden bewaard?
- Toestemmingsinstellingen: kun je een toestemming intrekken zonder niet-gerelateerde functies te verliezen?
- Details over verwerking: staat in het helpcentrum of de analyse op het apparaat of op externe servers plaatsvindt?
- Bewijs van beveiliging: beschrijft de ontwikkelaar audits, penetratietests, versleuteling en toegangscontrole met genoeg detail om ze te beoordelen?
Een nuttig waarschuwingssignaal: vage verwijzingen naar 'dienstverleners' zijn niet automatisch onjuist, maar moeten je laten vragen wat die dienstverleners ontvangen, waarom ze het ontvangen en hoe lang ze het bewaren.
Een app met privacy by design verzamelt standaard zo weinig mogelijk, scheidt toestemmingen, vermijdt onnodige software van derden en legt de levenscyclus van gegevens uit. Die keuzes garanderen geen perfecte bescherming, maar zijn sterker bewijs dan een badge of slogan.
Je eigen privacykader opbouwen
Privacy van gezondheidsgegevens is geen kwestie van alles of niets. Het is een reeks beslissingen op basis van de gevoeligheid van de informatie, het voordeel van de functie en de gevolgen als de gegevens bij iemand anders terechtkomen.
Begin bij zeer gevoelige gegevens, zoals gedetailleerde notities over je mentale gezondheid, informatie over reproductieve gezondheid of gegevens die met een chronische aandoening samenhangen. Kies bij voorkeur voor analyse op het apparaat, alleen-lezentoegang waar dat kan, beperkte exports en geen onnodige kopie in de cloud. Gebruik je wel synchronisatie, controleer dan het versleutelingsmodel en zorg dat je weet wie de sleutels voor het ontsleutelen beheert.
Gemiddeld gevoelige gegevens kunnen slaapregistratie, sportgeschiedenis en algemene fitnesswaarden omvatten. Versleutelde synchronisatie via de cloud kan een redelijke keuze zijn als herstel en toegang op meerdere apparaten belangrijk zijn, maar bekijk het deelbeleid van de aanbieder en verwijder oude integraties die je niet meer gebruikt.
Bij minder gevoelige welzijnsgegevens mag gemak redelijkerwijs zwaarder wegen. Ook dan geef je alleen de toestemmingen die de functie nodig heeft, beveilig je je telefoon met een sterke toegangscode en voer je geen identificerende gegevens in als de app die niet nodig heeft.
Stapel de maatregelen
Gebruik drie lagen in plaats van op één label te vertrouwen:
- Wettelijke laag: stel vast of een gereguleerde zorgrelatie of toepasselijke wetgeving voor gegevensbescherming de verwerking regelt.
- Technische laag: controleer de versleuteling van het apparaat, de toestemmingen van de app, lokale verwerking, end-to-end-versleuteling en de bewaartermijn op servers.
- Gedragslaag: controleer toestemmingen, bekijk wijzigingen in het beleid, exporteer belangrijke gegevens en dien verwijderverzoeken in als dat passend is.
Een persoonlijk dreigingsmodel maakt die lagen praktisch. Iemand met een gevoelige diagnose geeft misschien voorrang aan zo weinig mogelijk kopieën boven soepele toegang. Iemand die algemene activiteit bijhoudt, accepteert misschien een betrouwbare back-up in ruil voor continuïteit. Geen van beide keuzes is altijd de juiste.
Beslisprincipe: deel de minst gevoelige informatie waarmee de functie die je nodig hebt nog werkt, en bekijk die keuze opnieuw als de app, het apparaat, je gezondheidssituatie of het beleid verandert.
Heb je gestructureerde rapporten of instelbare samenvattingen nodig, bekijk dan in deze gids over het aanpassen van rapporten hoe aanpassingen invloed hebben op de gegevens die worden verzameld en geëxporteerd. Hetzelfde kader geldt: begrijp de invoer, de plaats van verwerking, de ontvangers en de kopieën die ontstaan.
Veelvoorkomende misverstanden over toestemming voor gezondheidsgegevens
Op 'Ik ga akkoord' tikken geeft je geen blijvende controle over elk toekomstig gebruik van je informatie. Bij consumentenapps kan toestemming het eerste verzamelen toestaan, terwijl andere teksten in het beleid analyse, dienstverleners, onderzoek, advertenties of latere wijzigingen regelen. Zie toestemming als het begin van een beoordeling, niet als een privacyschild.
Een app verwijderen is ook niet hetzelfde als de gegevens verwijderen. Als je de app van je telefoon haalt, kunnen er nog servergegevens, gesynchroniseerde back-ups, exports, logbestanden of informatie die al met een andere organisatie is gedeeld achterblijven. Vraag de ontwikkelaar wat verwijderen omvat en of voor samengevoegde of wettelijk bewaarde informatie een ander proces geldt.
Ook bij 'anoniem' is voorzichtigheid op zijn plaats. Een dossier zonder je naam kan nog steeds datums, locaties, apparaatgegevens en kenmerkende patronen bevatten waarmee je opnieuw te identificeren bent als het wordt gecombineerd met een andere dataset. De privacy van gezondheidsgegevens hangt af van de volledige context, niet alleen van de vraag of een directe identificatie is verwijderd.
Toestemming is onder de AVG ook niet de enige mogelijke rechtsgrond. In sommige situaties kan een organisatie informatie verwerken op een andere rechtmatige grondslag, zoals een gerechtvaardigd belang, als aan de bijbehorende eisen is voldaan. Daarom kan een toestemmingsscherm je niet het hele verhaal vertellen.
Een betere gewoonte is om toestemmingen, deelinstellingen, gekoppelde diensten en beloften over bewaartermijnen regelmatig te controleren. Gegevens die je vandaag deelt, kunnen beschikbaar blijven, gekopieerd worden of een ander doel krijgen onder voorwaarden die je zelf niet opnieuw hebt bekeken.
Cardiogram analyseert hartslaggegevens uit de Gezondheid-app op het apparaat met alleen-lezentoegang tot HealthKit, en synchroniseert app-gegevens daarna via het iCloud-ecosysteem van de gebruiker in plaats van gebruikersaccounts op eigen servers bij te houden. Past die architectuur bij je behoeften, ga dan naar Cardiogram om te zien hoe het hartslagpatronen, klachten en trends omzet in samenvattingen die klaar zijn voor je arts, terwijl privacyoverwegingen zichtbaar blijven.
