HealthKit, ResearchKit & CareKit: Building iOS Health Apps with Apple Frameworks

Apple's health framework trilogy — HealthKit, ResearchKit, and CareKit — gives iOS developers a foundation for building medical applications that no other platform can match. But choosing the right backend architecture is just as critical as the client-side framework choices. Here's a comprehensive guide to building with Apple's health frameworks, powered by Elixir Phoenix backends built for the demands of healthcare.

Understanding Apple's Health Framework Ecosystem

Apple provides three complementary frameworks, each serving a distinct purpose in the healthcare application lifecycle:

HealthKit: The Health Data Foundation

HealthKit is Apple's centralized health data store. It reads and writes over 100 health data types across categories including:

• Body measurements: Height, weight, BMI, body fat percentage
• Vital signs: Heart rate, blood pressure, respiratory rate, blood oxygen saturation
• Activity: Steps, distance, flights climbed, active energy burned
• Sleep: Sleep analysis with stages (Core, Deep, REM)
• Nutrition: Macronutrients, micronutrients, water intake, caffeine
• Clinical records: Allergies, conditions, immunizations, lab results, medications, procedures, vital signs (FHIR R4)
• Reproductive health: Menstrual cycle tracking, ovulation tests
• Hearing: Environmental sound levels, headphone audio levels

Technical implementation considerations:

HealthKit data is stored encrypted in a SQLite database on the device. Your app must request specific read and write permissions — users grant access per data type, not blanket access. This is fundamentally different from Android's Health Connect, where permissions are coarser.

// Requesting HealthKit permissions
let healthStore = HKHealthStore()
let typesToRead: Set<HKObjectType> = [
    HKQuantityType(.heartRate),
    HKQuantityType(.bloodGlucose),
    HKCategoryType(.sleepAnalysis),
    HKClinicalType(.allergyRecord)
]
let typesToWrite: Set<HKSampleType> = [
    HKQuantityType(.bodyMass),
    HKCategoryType(.mindfulSession)
]
try await healthStore.requestAuthorization(toShare: typesToWrite, read: typesToRead)

Clinical records access (available since iOS 12) is particularly powerful. Patients can download their medical records from participating hospitals directly into the Health app. Your app can then access allergies, conditions, immunizations, lab results, medications, procedures, and vital signs — all in standardized FHIR R4 format. This eliminates the need to build custom EHR integrations for basic patient data access.

ResearchKit: Clinical Studies Made Accessible

ResearchKit provides pre-built modules for conducting medical research studies through iOS apps:

• Informed Consent: Multi-step consent flow with document review, comprehension quiz, and digital signature capture
• Surveys: Question types including boolean, date, image choice, location, numeric scale, text, time interval, and value picker
• Active Tasks: Standardized clinical assessments including Timed Walk, Spatial Span Memory, Tower of Hanoi, Reaction Time, and audio/speech recording
• Charts: Visualizations for study results and participant feedback

ResearchKit studies have already enrolled millions of participants. Stanford's MyHeart Counts study enrolled over 50,000 participants in its first week — more than most traditional clinical trials enroll in their entire duration.

CareKit: Ongoing Care Plan Management

CareKit manages the day-to-day experience of living with a medical condition:

• Care plans: Structured schedules of activities, medications, and check-ins
• Task management: Track medication adherence, symptom logging, and therapeutic exercises
• Contact cards: Connect patients with their care team
• Health data sync: CareKit integrates with HealthKit to correlate care plan adherence with health outcomes
• CloudKit sync: Native support for syncing care data across devices and to care providers

The Backend Architecture: Why Elixir Phoenix

The frontend frameworks matter, but the backend architecture determines whether your medical app can handle real-world healthcare demands. We build our iOS medical app backends on Elixir Phoenix for specific, technical reasons.

The BEAM VM: Purpose-Built for Systems That Cannot Go Down

Elixir runs on the BEAM (Bogdan/Bjorn's Erlang Abstract Machine), a virtual machine originally designed by Ericsson in the 1980s for telecom switches. The BEAM was not designed for web applications — it was designed for systems where failure means dropped emergency calls. That same DNA makes it uniquely suited for medical software.

Process isolation: BEAM processes are not OS threads. Each process occupies roughly 2KB of memory at spawn and runs in complete isolation. A single BEAM node can run millions of concurrent processes. Each patient session, each device connection, each background task runs as its own isolated process.

Preemptive scheduling: The BEAM scheduler uses preemptive scheduling based on "reductions" (roughly ~4,000 function calls per time slice). No single process can monopolize the CPU. This is fundamentally different from Node.js's cooperative scheduling, where a single blocking operation can freeze the entire event loop — unacceptable when processing real-time vital signs.

Per-process garbage collection: Each BEAM process has its own heap and garbage collector. When GC runs, it only pauses that single process (microseconds), not the entire VM. Traditional JVM or .NET applications suffer "stop-the-world" GC pauses that can last hundreds of milliseconds — a problem when displaying real-time cardiac rhythm data.

The Actor Model (OTP/GenServer) for Healthcare

OTP (Open Telecom Platform) implements the actor model through GenServers — processes that maintain isolated state and communicate via message passing:

• No shared mutable state: Eliminates race conditions without locks
• Sequential message processing: Each GenServer processes messages from its mailbox one at a time, guaranteeing consistency within a process
• Supervision trees: Hierarchical process monitoring with automatic restart. If a patient session crashes, only that session restarts — all others continue unaffected
• "Let it crash" philosophy: Instead of defensive try/catch blocks for every possible failure, let processes crash and restart in a known-good state. No partial state corruption. No silent failures.

This matters for healthcare because in a traditional Node.js or Rails application, an unhandled exception in processing one patient's data can crash the entire server process, affecting all connected patients. In Elixir, failures are isolated by design.

Phoenix LiveView for Real-Time Clinical Dashboards

Phoenix LiveView provides rich, real-time interfaces with server-rendered HTML over persistent WebSocket connections:

• No client-side PHI: The browser receives rendered HTML, not raw patient data. No Redux store, no localStorage, no IndexedDB containing PHI to secure.
• Automatic reconnection: Nurses moving between rooms with tablets get seamless reconnection with full state re-sync.
• Minimal data over the wire: LiveView computes HTML diffs and sends only what changed — 5-10x less data than JSON-based React/Vue approaches.
• Phoenix PubSub: Subscribe to real-time vital sign updates per patient. When a new reading arrives, the dashboard updates instantly for every subscribed provider.

WebRTC Telemedicine with elixir-webrtc

For telemedicine video capabilities, we use elixir-webrtc — a W3C-compliant WebRTC implementation written in native Elixir by Software Mansion.

Unlike JavaScript WebRTC solutions that require separate media servers (Janus, mediasoup, Kurento), elixir-webrtc runs media processing in the same Elixir application:

• Each peer connection is an isolated BEAM process — one peer's failure cannot affect others
• Simulcast support for adaptive video quality based on bandwidth
• Membrane framework integration for HIPAA-compliant encrypted session recording
• Elixir Nx integration for real-time ML tasks (speech-to-text for clinical notes)

HIPAA Compliance Architecture

Every HealthKit-integrated medical app must address HIPAA if it handles PHI on behalf of a covered entity.

Data Flow Security

1. On-device: HealthKit data encrypted at rest by iOS. Your app accesses it through HealthKit APIs with user-granted permissions.
2. In transit: TLS 1.3 for all API communication to the Phoenix backend. Certificate pinning prevents MITM attacks.
3. At rest on server: AES-256 encryption for all stored PHI. Encryption keys managed via AWS KMS or similar HSM-backed service.
4. Access controls: Role-based permissions (patient, nurse, physician, admin) enforced at the API layer.
5. Audit logging: Every PHI access logged with user identity, timestamp, action, IP address, and device identifier.

Why Outsourcing Medical Development Creates Compliance Risk

A critical but often overlooked aspect of HIPAA compliance is where your development team is located.

HIPAA obligations follow PHI across borders, but enforcement does not. The HHS Office for Civil Rights has untested jurisdiction over foreign entities. Healthcare compliance attorneys note that OCR "probably wouldn't go after an offshore company unless it was phenomenally egregious" — meaning all risk falls on the US covered entity.

Specific risks of offshore medical app development:

• Unenforceable Business Associate Agreements: BAAs signed with entities in developing nations are difficult to enforce in foreign courts. A covered entity could be "out of luck if the vendor is located in a lawless jurisdiction."
• Data sovereignty conflicts: GDPR requires data protection impact assessments for health data transfers. China's PIPL requires domestic storage of Chinese citizen data. India's proposed data protection bill has its own localization requirements. These laws can directly conflict with HIPAA requirements.
• Developer access to PHI: Offshore teams frequently access staging environments with real or poorly de-identified patient data. Every developer with access must be covered by a BAA, trained on HIPAA, and subject to the same access controls as domestic employees.
• Breach notification complications: HIPAA requires breach notification within 60 days. GDPR requires 72 hours. Different jurisdictions create conflicting legal obligations about who to notify and when.
• Audit trail gaps: Time zone differences complicate real-time access review. Shared workstations in offshore development centers make individual attribution difficult.

Our approach: All development stays domestic with US-based engineers under direct BAA coverage. We use synthetic test data (never real PHI) in development environments, and maintain comprehensive audit trails for every system access.

Getting Started

Building an iOS medical app with HealthKit, ResearchKit, or CareKit requires careful planning around both technical implementation and compliance requirements. Our discovery process maps clinical workflows, identifies required data types, assesses EHR integration points, and determines whether your app may qualify as a Software as a Medical Device (SaMD).

If you're building a medical iOS application, contact us to discuss your project. We bring deep expertise in Apple's health frameworks, HIPAA-compliant architecture, and fault-tolerant Elixir Phoenix backends that healthcare demands.