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 fields do not work this way. Build on a design 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 what an off-the-shelf EMR cannot. It is built around your real workflow, not the other way round. But that edge is gone fast if the HIPAA design is wrong. This guide covers the technical rules a build must meet. It must meet them before it handles one patient record.
PHI: what it is and what the handling rules actually require
Protected Health Information is health data tied to one named person. It links to their past, present, or future health, care, or payment. The term 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 point to a person in a health setting. 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 changed or destroyed. These are not nice-to-have goals. They are minimum rules. OCR audits check them head on.
Encryption at rest: use AES-256, or a cipher just as strong, for all stored PHI. Database encryption on its own is not enough. You must also control access at the app 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 timestamped logs that no one can alter. They must cover every create, read, update, and delete on PHI. You must keep those 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 job needs. Enforce that 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. No PHI can flow to their systems until they do. This is not a box to tick. It is a legal must. It comes before you use cloud hosting or managed databases. The same goes for email services and analytics tools that touch patient data.
AWS, Google Cloud, and Microsoft Azure all offer HIPAA-eligible services. All three will sign BAAs. But not every service on those platforms is HIPAA-eligible. The BAA covers named 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. Send PHI logs to a service the BAA does not cover and you may have a breach. That holds true even for another AWS service.
Many common dev tools will not sign BAAs. That list includes Slack, Zapier, standard email providers, and analytics tools built for other fields. Those tools cannot receive PHI. So check any link that might expose PHI before you build it. Do not wait for a security review to catch 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 backend service, built for that job alone. That service owns all PHI access. It checks the user's rights before it returns any health data. Every other service that needs patient data asks this one for it. They never query the PHI database on their own. This pulls access control and audit logging into one place. It keeps the compliance surface easy to predict. 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.
Where you can do it, de-identification cuts your compliance scope a lot. HIPAA's Safe Harbor method strips out 18 specific identifiers. Some use cases can run on de-identified data. That includes analytics, reporting, and machine learning. Those pipelines can then run on a standard stack. They need no HIPAA controls. Build the step into your data pipeline early. Do that even if today's use case does not need it. The analytics stack you build for product metrics will touch patient groups 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 need. It is not an add-on at the end. Every healthcare project opens with an architecture review. That review covers PHI boundaries and the BAA stack you pick. It also covers audit log design and access control models. All of it happens before any product code is written. The result is software that passes security reviews. It also lets you grow with no compliance retrofit later. Maybe you are looking at a custom build. It could be 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).
