Building a Healthcare Platform That Treats Compliance as Architecture, Not Afterthought
Healthcare software carries a burden that most applications never face: the legal and ethical obligation to protect the most sensitive data a person can generate. Patient health information is not simply "user data." It is a record of vulnerability, and any system that handles it must be engineered from the foundation up to honor that responsibility. When we began architecting Seed Health — a HIPAA-compliant healthcare platform currently in development — we made a deliberate choice to treat compliance not as a checklist bolted onto a finished product, but as the fundamental architectural constraint that shaped every technical decision.
This case study details how we are building Seed Health using Elixir and the Phoenix framework, leveraging the BEAM virtual machine's unique properties to create a platform where security, fault tolerance, and real-time communication are not competing priorities but mutually reinforcing design principles. For organizations evaluating healthcare software development partners, this project illustrates our approach to the hardest problems in medical technology.
Why Elixir and Phoenix for Healthcare
Choosing a technology stack for a healthcare platform is not a matter of developer preference. It is a risk management decision. We selected Elixir 1.17+ running on the Phoenix 1.8.4 framework for reasons that are directly tied to HIPAA's requirements for availability, integrity, and confidentiality.
The BEAM VM's Actor Model and Process Isolation
The Erlang virtual machine (BEAM) was originally designed for telephone switches — systems where a failure in one call must never bring down another. This property translates directly to healthcare. In Seed Health, each patient session runs as an isolated BEAM process. If an error occurs during one patient's interaction, it is contained within that process. The supervisor tree detects the failure, restarts the process, and no other patient session is affected.
This is not a theoretical advantage. In a traditional threaded runtime, an unhandled exception or memory corruption in one request can cascade across the entire application. In a healthcare context, that cascade could mean a clinician losing access to critical patient data during an active consultation. The BEAM's "let it crash" philosophy, combined with supervisor hierarchies, gives us fault tolerance that most platforms can only approximate through complex infrastructure layering.
Soft Real-Time Guarantees
Phoenix Channels provide WebSocket-based real-time communication with remarkably low latency. For Seed Health, this enables features like live clinical notifications, real-time care coordination between providers, and instant updates to patient dashboards — all running over encrypted connections with the same HIPAA-compliant data handling as the rest of the platform. The BEAM's preemptive scheduler ensures that no single long-running process can starve others of CPU time, providing the soft real-time guarantees that healthcare applications demand.
Encryption Strategy: AES-256-GCM with Blind Indexing
HIPAA's Security Rule requires that electronic Protected Health Information (ePHI) be encrypted both at rest and in transit. Many platforms satisfy this requirement at the database level with transparent disk encryption. We went further. Seed Health implements field-level encryption on all PHI using the Cloak library with AES-256-GCM, meaning that even if an attacker gains direct access to the database, they encounter only ciphertext.
How Field-Level Encryption Works in Practice
Every field containing PHI — patient names, medical record numbers, diagnoses, treatment notes, contact information — is encrypted before it is written to the database and decrypted only when retrieved by an authorized process. AES-256-GCM (Galois/Counter Mode) provides both confidentiality and authenticity: the ciphertext cannot be read without the key, and any tampering with the encrypted data is detected automatically upon decryption.
The encryption keys themselves are managed through a dedicated vault configuration, supporting key rotation without requiring re-encryption of the entire dataset. When a key is rotated, new writes use the updated key while existing records are decrypted with their original key and re-encrypted lazily during normal read operations.
HMAC Blind Indexing for Encrypted Search
Field-level encryption introduces a practical challenge: you cannot run SQL queries against ciphertext. Searching for a patient by name or medical record number would ordinarily require decrypting every row, which is computationally prohibitive and defeats the purpose of encryption at rest.
Seed Health solves this with HMAC-based blind indexing. When a field is encrypted, a corresponding HMAC (Hash-based Message Authentication Code) digest is computed and stored alongside it. This digest is deterministic — the same input always produces the same hash — but it is computationally infeasible to reverse. Queries run against the blind index, matching the HMAC of the search term to stored digests, and only the matching records are decrypted. The result is the ability to search encrypted data without ever exposing plaintext values to the database engine.
The combination of AES-256-GCM encryption with HMAC blind indexing allows Seed Health to maintain full query capability over encrypted patient data — a capability that many healthcare platforms sacrifice in the name of simpler encryption implementations.
Authentication and Access Control
Authentication in a healthcare system must satisfy two competing demands: it must be rigorous enough to prevent unauthorized access to patient data, and it must be frictionless enough that clinicians are not slowed down during time-sensitive care delivery.
JWT RS256 with Guardian
Seed Health uses the Guardian library for JWT-based authentication with RS256 (RSA Signature with SHA-256) signing. Unlike symmetric algorithms like HS256 where the same secret is used to sign and verify tokens, RS256 uses an asymmetric key pair. The private key signs tokens and never leaves the authentication service; the public key is distributed to any service that needs to verify token authenticity. This architecture is essential for healthcare platforms where multiple services may need to validate a user's identity without sharing sensitive key material.
Tokens carry encoded claims about the user's role and permissions, and token lifetimes are configured to balance security with clinical workflow continuity. Refresh token rotation ensures that long clinical sessions are not interrupted by premature expiration, while revocation lists handle immediate access termination when required.
Role-Based Access Control with Granular Permissions
HIPAA's minimum necessary standard requires that users access only the PHI they need for their specific role. Seed Health implements granular role-based access control (RBAC) that maps directly to clinical roles and organizational hierarchies. A referring physician sees a different subset of data than a billing specialist, and an administrative user has different permissions than a primary care provider.
Permissions are enforced at the context layer in Phoenix — the boundary between the web interface and the business logic — so that no matter how a request reaches the data layer, the access control check has already occurred. This defense-in-depth approach means that even if a controller-level check were bypassed (through a bug or misconfiguration), the context layer would still reject unauthorized access attempts.
Immutable Audit Logging
HIPAA requires that covered entities maintain records of who accessed what data, when, and what they did with it. Seed Health implements immutable audit logs that record every data access and modification event with the following properties:
- Append-only storage — log entries cannot be modified or deleted after creation, even by administrators
- User identification — every entry records the authenticated user, their role, and the session context
- Action specificity — logs distinguish between read, create, update, and delete operations, capturing the specific fields accessed or changed
- Timestamp integrity — server-side timestamps prevent client-side clock manipulation
- PHI reference tracking — logs record which patient records were accessed without duplicating the PHI itself in log storage
These audit logs serve a dual purpose. During normal operations, they provide administrators with visibility into data access patterns that may indicate inappropriate use. During a compliance audit or breach investigation, they provide the defensible evidence trail that regulators require. The immutability guarantee means that an attacker who compromises the application cannot cover their tracks by altering log entries.
AI Integration with PHI Scrubbing
Seed Health is designed to incorporate AI and machine learning capabilities through AWS Bedrock integration. However, sending raw patient data to any external service — even one with a Business Associate Agreement — introduces unnecessary risk. Our approach implements a PHI scrubbing pipeline that strips all identifying information from data before it reaches any AI/ML processing endpoint.
The scrubbing process operates on structured data, replacing identifiers with tokens that can be re-associated with the original patient record only within the secured application boundary. This means the AI models operate on de-identified clinical data, and their outputs are re-contextualized within the platform. The result is the ability to leverage machine learning for clinical decision support, pattern recognition, and operational analytics without ever exposing PHI to external processing systems.
Testing and Security Analysis
A HIPAA-compliant platform that is not rigorously tested is not truly compliant — it is merely lucky. Seed Health employs a comprehensive testing strategy that validates both functional correctness and security properties.
Testing Framework
- ExUnit — Elixir's built-in testing framework provides the foundation for unit, integration, and end-to-end tests
- ExMachina — factory-based test data generation ensures that tests operate on realistic but synthetic patient data, never real PHI
- Mox — behavior-based mocking allows us to test encryption, authentication, and external service integrations in isolation without depending on live infrastructure
Static Analysis and Security Scanning
- Credo — static code analysis enforces consistency and identifies potential code quality issues before they reach production
- Sobelow — a security-focused static analysis tool purpose-built for Phoenix applications, scanning for SQL injection vulnerabilities, XSS vectors, insecure configuration, and other common web security issues
- Dialyxir — Dialyzer integration provides success typing analysis, catching type-related bugs that unit tests might miss, particularly important in a system where a type confusion error could lead to PHI exposure
Every pull request runs the full test suite alongside all three static analysis tools. Code that introduces a Sobelow warning does not merge. This is not a guideline; it is an automated gate in the CI/CD pipeline.
Architecture Decisions That Compound
What distinguishes Seed Health's architecture is not any single technical choice in isolation, but the way these decisions reinforce each other:
- Process isolation means that an encryption failure in one patient's session does not compromise another's data
- Field-level encryption means that even infrastructure-level compromises do not expose plaintext PHI
- Blind indexing means that encryption does not sacrifice the query performance clinicians depend on
- Immutable audit logs mean that every interaction with encrypted data is permanently recorded
- RBAC at the context layer means that authorization is enforced regardless of the entry point
- PHI scrubbing means that AI capabilities do not expand the attack surface
Each layer assumes the others might fail and provides independent protection. This defense-in-depth approach is what transforms a collection of security features into a genuinely HIPAA-compliant architecture.
Current Status and What Comes Next
Seed Health is currently in active development. The encryption layer, authentication system, audit logging infrastructure, and core data models are implemented and under continuous testing. Real-time communication via Phoenix Channels is functional, and the RBAC system is undergoing refinement as clinical workflow requirements are finalized with stakeholders.
The platform is being built with the expectation of third-party security assessment prior to any production deployment. Our goal is not to pass an audit — it is to build a system where passing the audit is an inevitable consequence of the architecture.
For a deeper exploration of HIPAA compliance requirements and how they translate to software architecture decisions, read our comprehensive guide: HIPAA-Compliant App Development: The Complete Guide for 2026.
Partner With Us on Healthcare Software
Building healthcare software that is both genuinely compliant and genuinely useful requires a team that understands the regulatory landscape as deeply as the technical one. At Of Ash and Fire, we do not treat HIPAA compliance as a feature to be added — we treat it as the foundation everything else is built upon.
If you are evaluating partners for a healthcare platform, telemedicine application, or any system that handles protected health information, we would welcome the conversation. Contact our team to discuss your project requirements and how our approach to HIPAA-compliant architecture can serve your organization's mission.