Custom Software for Healthcare: Building HIPAA-Ready Systems
Off-the-shelf clinical software forces your workflows into someone else's model. Custom software built HIPAA-ready from day one gives you both the compliance and the fit.
In custom software healthcare projects, the software choice is also a legal choice. That is rare. Most industries do not work this way. Build on an architecture that mishandles Protected Health Information (PHI), and the risk is not just bad software. You also face HHS breach notifications and OCR investigations. The fines are steep. In 2024, they ran from $100 per violation to $1.9 million per violation category per year. Compliance is not a layer you bolt on at the end. It is a set of design rules. You must build them in from the first line of code.
Many healthcare groups need this kind of software. That includes specialty clinics, group practices, and telehealth platforms. It also includes care coordination tools and behavioral health apps. Custom software gives them something an off-the-shelf EMR cannot. It is built around your real workflow, not the reverse. But that edge vanishes fast if the HIPAA architecture is wrong. This guide covers the technical rules a build must meet. It must meet them before it handles a single patient record.
PHI: what it is and what the handling rules actually require
Protected Health Information is health data tied to one specific person. It links to their past, present, or future health, care, or payment. The definition is broad. It covers diagnosis codes and treatment records. It also covers names, addresses, and dates, including birth dates. Phone numbers and email addresses count too. So does any device ID that could identify a person in a health context. If your software touches any of it, HIPAA applies.
HIPAA's Security Rule sets technical safeguards you must meet. You must encrypt PHI at rest and in transit. You must keep audit controls that log who viewed or changed each record, and when. Systems with PHI need automatic session timeouts. Each user needs a unique ID, and no one shares credentials. You also need integrity controls. These confirm data has not been altered or destroyed. These are not nice-to-have goals. They are minimum rules, and OCR audits check them directly.
Encryption at rest: use AES-256 or an equivalent for all stored PHI. Database encryption alone is not enough. You must also control access at the application level.
Encryption in transit: use TLS 1.2 at a minimum, and TLS 1.3 is better. Never use plain HTTP for any endpoint that carries PHI.
Audit logging: keep immutable, timestamped logs of every create, read, update, and delete on PHI. You must retain these logs for at least six years.
Access control: use role-based access so each user sees only the PHI their role needs. Do not use admin "god mode" accounts for routine work.
Minimum necessary: the system should never return more PHI than the function actually needs. Enforce this at the query layer, not just in the UI.
Business Associate Agreements and your infrastructure stack
Any vendor that handles PHI for you is a Business Associate (BA). Every BA must sign a Business Associate Agreement (BAA) first. PHI cannot flow to their systems until they do. This is not a formality. It is a legal must before you use cloud infrastructure, managed databases, email services, or analytics tools with patient data.
AWS, Google Cloud, and Microsoft Azure all offer HIPAA-eligible services and will sign BAAs. But not every service on those platforms is HIPAA-eligible. The BAA covers specific services, and only those. A build on AWS must keep PHI inside BAA-covered services. That means HIPAA-eligible EC2, RDS, and S3 setups, and so on. Logging PHI to a service the BAA does not cover is a possible breach. That is true even for another AWS service.
Many common dev tools will not sign BAAs. That group includes Slack, Zapier, standard email providers, and non-healthcare analytics tools. These tools cannot receive PHI. So evaluate any integration that might expose PHI before you build it. Do not wait until a security review finds it later.
Architecture patterns that make HIPAA defensible
A PHI service layer is the cleanest pattern for HIPAA compliance in custom software. It is one dedicated backend service. That service owns all PHI access. It checks authorization before it returns any health data. Every other service that needs patient data asks this service for it. They never query the PHI database directly. This centralizes access control and audit logging. It keeps the compliance surface predictable. It also makes the audit far simpler. One service owns PHI. One team owns that service. There is one set of logs to hand to OCR.
De-identification cuts your compliance scope a lot, where it is feasible. HIPAA's Safe Harbor method removes 18 specific identifiers. Some use cases can run on de-identified data. That includes analytics, reporting, and machine learning. Those pipelines can then use standard infrastructure with no HIPAA controls. Build de-identification into the data pipeline early. Do this even if the current use case does not need it. The analytics infrastructure you build for product metrics will touch patient cohorts in time.
A system not built for HIPAA can be hardened later. But that fix usually means a near-complete rewrite of the data layer. It is cheaper to build it right the first time. Fixing it under regulatory pressure costs far more.
TTGC's approach to healthcare software builds
The TTGC development team treats compliance as a first-class requirement, not an afterthought. Every healthcare engagement opens with an architecture review. That review covers PHI boundaries and BAA stack selection. It also covers audit log architecture and access control modeling. All of this happens before any product code is written. The result is software that passes security reviews. It enables growth with no compliance retrofit later. Exploring a custom build, like a telehealth platform, a specialty EMR module, or a patient engagement tool? See building an MVP that scales for the scoping framework. Then connect at /growth-assessment.
Building healthcare software? TTGC builds HIPAA-ready systems from the architecture up - not patched in at the end.
Book a free Brand and Growth Assessment and see exactly how Through The Glass Creatives would approach it.
Sources
- U.S. Department of Health & Human Services - HIPAA Security Rule: Technical Safeguards (45 CFR § 164.312) (2024).
- HHS Office for Civil Rights - HIPAA Audit Program Results and enforcement actions (2024).
- AWS - HIPAA-Eligible Services and the AWS Business Associate Agreement (2024).
- NIST - Special Publication 800-66 Rev. 2: Implementing the HIPAA Security Rule (2023).
