Protecting access to user’s health data
HealthKit provides a central repository for health and fitness data on iPhone and Apple Watch. HealthKit also works directly with health and fitness devices, such as compatible Bluetooth Low Energy (BLE) heart rate monitors and the motion coprocessor built into many iOS devices. All HealthKit interaction with health and fitness apps, healthcare institutions, and health and fitness devices require permission of the user. This data is stored in the Data Protection class Protected Unless Open. Access to the data is relinquished 10 minutes after the device locks, and data becomes accessible the next time user enters their passcode or uses Face ID or Touch ID to unlock the device.
Collecting and storing health and fitness data
HealthKit also collects and stores management data, such as access permissions for apps, names of devices connected to HealthKit, and scheduling information used to launch apps when new data is available. This data is stored in the Data Protection class Protected Until First User Authentication. Temporary journal files store health records that are generated when the device is locked, such as when the user is exercising. These are stored in the Data Protection class Protected Unless Open. When the device is unlocked, the temporary journal files are imported into the primary health databases, then deleted when the merge is completed.
Health data can be stored in iCloud. End-to-end encryption for Health data requires iOS 12 or later and two-factor authentication. Otherwise, the user’s data is still encrypted in storage and transmission but isn’t encrypted end-to-end. After the user turns on two-factor authentication and updates to iOS 12 or later, the user’s health data is migrated to end-to-end encryption.
If the user backs up their device using the Finder (macOS 10.15 or later) or iTunes (in macOS 10.14 or earlier), health data is stored only if the backup is encrypted.
Clinical health records
Users can sign in to supported health systems within the Health app to obtain a copy of their clinical health records. When connecting a user to a health system, the user authenticates using OAuth 2 client credentials. After connecting, clinical health record data is downloaded directly from the health institution using a TLS 1.3 protected connection. Once downloaded, clinical health records are securely stored alongside other health data.
Health data authenticity
Data stored in the database includes metadata to track the provenance of each data record. This metadata includes an app identifier that identifies which app stored the record. Additionally, an optional metadata item can contain a digitally signed copy of the record. This is intended to provide data authenticity for records generated by a trusted device. The format used for the digital signature is the Cryptographic Message Syntax (CMS) specified in RFC 5652.
Health data access by third-party apps
Access to the HealthKit API is controlled with entitlements, and apps must conform to restrictions about how the data is used. For example, apps aren’t allowed to use health data for advertising. Apps are also required to provide users with a privacy policy that details its use of health data.
Access to health data by apps is controlled by the user’s Privacy settings. Users are asked to grant access when apps request access to health data, similar to Contacts, Photos, and other iOS data sources. However, with health data, apps are granted separate access for reading and writing data, as well as separate access for each type of health data. Users can view, and revoke, permissions they’ve granted for accessing health data under Settings > Health > Data Access & Devices.
If granted permission to write data, apps can also read the data they write. If granted permission to read data, apps can read data written by all sources. However, apps can’t determine access granted to other apps. In addition, apps can’t conclusively tell whether they’ve been granted read access to health data. When an app doesn’t have read access, all queries return no data—the same response that an empty database would return. This is designed to prevent apps from inferring the user’s health status by learning which types of data the user is tracking.
Medical ID for users
The Health app gives users the option of filling out a Medical ID form with information that could be important during a medical emergency. The information is entered or updated manually and isn’t synced with the information in the health databases.
The Medical ID information is viewed by tapping the Emergency button on the Lock Screen. The information is stored on the device using the Data Protection class No Protection so that it’s accessible without having to enter the device passcode. Medical ID is an optional feature that lets users decide how to balance both safety and privacy concerns. This data is backed up in iCloud Backup in iOS 13 or earlier. In iOS 14, Medical ID is synced between devices using CloudKit and has the same encryption characteristics as the rest of health data.
Health sharing
In iOS 15, the Health app gives users the option sharing their Health data with other users. Health data is shared between the two users using end-to-end iCloud encryption, and Apple can’t access data that is sent through Health sharing. To use the feature, both the sending and receiving users must be running iOS 15 or later and have two-factor authentication enabled.
Users can also choose to share their Health data with their healthcare provider using the Share with Provider feature in the Health app. Data shared using this feature is made available only to the health institutions selected by the user using end-to-end encryption, and Apple doesn’t maintain or have access to the encryption keys to decrypt, view, or otherwise access the Health data shared through the Share with Provider feature. Further details about how the design of this service protects users’ Health data can be found in the Security and Privacy section of the Apple Registration Guide for Healthcare Organizations.