I started paying close attention to Apple’s Health Records feature because it promised something we all want: one place on our phones where medical data from different providers can live together. As a reader and editor who covers technology and public policy, I’m fascinated by tools that make life simpler. But the more I dug into how Health Records actually works in practice, the more I noticed a troubling gap: the feature can leave patients outside the hospital setting—those who rely on community clinics, independent specialists, telehealth platforms, or paper-based records—vulnerable in ways most users don’t anticipate.

How Apple Health Records is supposed to help

Apple pitched Health Records around two core promises: interoperability and user control. Using standards like FHIR (Fast Healthcare Interoperability Resources), many hospitals and large health systems can send structured clinical data—lab results, medications, allergies—directly to the Health app on your iPhone. That information is encrypted on the device and, if you enable iCloud backup, encrypted in transit and at rest by Apple’s infrastructure.

In practice, that means a patient who moves between hospital systems that support Health Records can see a consolidated timeline of key medical events. For busy clinicians and patients, that’s undeniably useful—no more faxing records or waiting on patient portals to produce PDFs.

Where the privacy gaps show up

But those benefits primarily apply to interactions within hospitals and health systems that have invested in electronic health record (EHR) integration. Outside that world—think small independent clinics, many mental health providers, urgent care centers, and third-party telehealth services—things look very different. Here are the main gaps I’ve identified:

  • HIPAA protections don’t automatically follow your data on your phone. Covered entities (hospitals, clinics, health plans) must follow HIPAA rules. Apple is not a covered entity; it’s a tech company. That means while your hospital must secure data and restrict access, Apple and many third-party apps that access Health data are not bound by HIPAA. The result: patients can think their data is protected by healthcare law when, technically, it may not be.
  • Third-party apps can access Health Records data once you grant permission. HealthKit and the Health app let you choose which apps can read certain health categories. That’s powerful, but it also introduces risk: many smaller health apps request broad permissions and may use data for purposes beyond care—analytics, targeted advertising, or selling insights—unless restrained by contract or regulation.
  • Interoperability is uneven. The FHIR-based flows Apple relies on are increasingly standard in big systems, but many providers still exchange records via secure email, paper, or proprietary systems. Those records don’t necessarily make it into Health Records, meaning your phone’s dataset can be incomplete—and you may assume it is complete.
  • Identity and provenance can be murky. Health Records aggregates data from multiple sources but doesn’t always make provenance obvious to users. A lab result from a hospital has a different legal and clinical pedigree than an entry typed by a therapist into a patient portal that syncs only occasionally. Misunderstanding where data came from can affect decisions if clinicians or patients rely on incomplete or improperly attributed records.
  • Metadata and inference risks. Even if the clinical fields are encrypted, metadata—timestamps, which providers you interact with, frequency of data sync—can reveal sensitive patterns. For example, frequent visits to a mental health clinic or an HIV clinic may be inferred from timestamps and provider names, creating privacy exposures that most people don’t expect their phones to broadcast.

    • Real-world scenarios that worry me

    Consider a patient who uses a small community clinic that emails PDF visit notes. The clinic is careful with the PDF and follows standard security practices, but it does not support FHIR-based record sharing. The patient manually saves the PDF to the Files app, then copies data into a symptom-tracking app that has permission to read Health data. That app later shares anonymized data with a startup partner. Suddenly, highly personal clinical notes have pathways Apple’s ecosystem neither controls nor necessarily protects.

    Or a different example: someone uses telehealth for behavioral health with a provider that isn’t a HIPAA-covered entity—perhaps a startup that says it’s “health-focused” but not a covered medical provider. The patient authorizes a mental wellness app to read mood-tracking entries alongside hospital lab results. If that app uses data for targeted offers or partners with advertisers, sensitive behavioral health details could seep into places outside clinical care—unknown to the patient’s providers and regulators.

    Comparing protections: inside vs outside traditional hospitals

    Setting Typical legal protections Data flow to Apple Health Risks
    Large hospital / health system HIPAA-covered; contractual controls Often direct FHIR integration into Health Records Lower legal risk; still potential metadata exposure
    Independent clinics / small practices Usually HIPAA-covered, but limited EHR integration Often PDFs, portals; manual transfers by patients Incomplete records on phone; manual steps create exposure
    Telehealth startups / wellness apps May not be HIPAA-covered May sync via APIs or manual entry Higher risk of data use for non-clinical purposes

    What patients and clinicians should watch for

    I tell people to be pragmatic: the convenience of consolidated records is real, but you should use it with awareness. Here are practical steps I recommend:

  • Ask your provider how they share records. Does the clinic use FHIR APIs? Will their notes appear in the Health app automatically, or will you need to export and upload files manually?
  • Limit third-party app permissions. In the Health app settings, only permit apps to read the categories they absolutely need. Check app privacy policies and, when possible, favor apps that explicitly commit (and are contractually bound) to not sell health data.
  • Understand what’s not covered by HIPAA. If a provider or app says it’s not covered by HIPAA, that’s a red flag: data protections will rely on contracts and the company’s privacy policy, both of which can change.
  • Keep provenance in mind. When you share Health data with a new provider, clarify where each item came from—lab, hospital, self-reported—and, if possible, provide source documents for critical decisions.
  • Use device protections. Enable passcodes, Face ID/Touch ID, and two-factor authentication for your Apple ID. Encryption helps, but controlling physical and account access is crucial.

    • How policymakers and companies could do better

    I believe this is not just a technical problem but a policy one. Technology companies like Apple can build clearer consent flows that surface legal protections and provenance for each clinical item. App stores could require stricter transparency for health data uses. Regulators could extend baseline privacy protections to health data handled outside traditional covered entities or at least tighten rules for de-identified data reuse.

    Hospitals and smaller providers should be supported to adopt standard APIs so patient data is less fragmented. And patients deserve clearer language at every step: when you connect a provider to your phone, you should see not only the clinical data but who legally controls it and how it might be used beyond your care.

    I’m excited by the promise of phone-based health records, but excitement should be paired with caution. As these tools become core parts of healthcare workflows—beyond hospital walls and into our daily lives—we need design and policy that protect the most vulnerable users, not just the well-resourced systems that can afford integration. Otherwise, we’ll trade an important convenience for privacy gaps that could be hard to close.