Home/Services/HIPAA-compliant development
HIPAA-Compliant Software Development
There is no such thing as HIPAA certification. Nobody can be certified, accredited, or stamped compliant, no matter what a vendor's badge says.
What exists is a set of obligations under the Security and Privacy Rules, a Business Associate Agreement, and the actual work of meeting them. We do that work, and we'll show you how we did it.
Covered entity or business associate
If you handle protected health information, you're either a covered entity or a business associate. As your development partner, we're a business associate — which means we sign a BAA before any work starts, not after.
Where PHI flows
Most teams think about the database and stop there. In practice PHI also ends up in logs, error trackers, analytics tools, staging environments, support tickets, and the AI tools your developers use. We map all of it before we write anything.
What we actually implement
Technical
- Encryption in transit and at rest, including backups
- Role-based access control with unique user IDs — no shared accounts
- Audit logging of every access to PHI, with retention
- Automatic logoff and session controls
- Integrity controls so records can't be altered silently
- Encrypted backups and a tested restore path
- Non-production environments hardened to the same standard
Administrative and hosting
- Documented access management, including offboarding
- Written policies and workforce training where we're responsible for them
- An incident response plan built around the breach notification timeline
- Hosting only on HIPAA-eligible services under a signed cloud BAA
- Third-party vendors reviewed for whether a BAA is required
The gaps we look for first
These are the problems that show up most often in an inherited codebase.
- PHI in application logs, error trackers, and product analytics
- Production data copied into development and staging environments
- Third-party vendors with no BAA — email, SMS, hosting, and AI APIs
- Access that was granted for one project and never revoked
- Unencrypted backups nobody has ever tried to restore
- Security treated as a phase after launch, which is roughly ten times the cost of doing it first
- PHI pasted into AI tools by well-meaning developers
- Deletion and retention rules that exist in policy but not in code
What we don't do
We are not your compliance officer. We don't sign off on your risk assessment, conduct your OCR audit, or make the judgement calls that are legally yours.
What we do is build and document the technical controls, and hand you the evidence to support your own obligations. We'd rather draw that line clearly at the start than blur it later.
How we work
- BAA first — before any data moves
- Security review and threat model — of the system as designed, not as imagined
- Environment hardening — including secrets management and least-privilege access
- Build — with security in the definition of done, not as a final phase
- Documentation — written so you can hand it straight to a security questionnaire
Common questions
Are you HIPAA compliant?
That question doesn't have a yes-or-no answer, and anyone who gives you one is guessing. Compliance is an ongoing obligation, not a status. We sign a BAA, implement the technical safeguards, and document them.
Will you sign a BAA?
Yes, before work starts.
Can you complete a security questionnaire or vendor review?
Yes. We'd rather do it before the contract than after.
Do your developers use AI coding tools?
Some of them do, and we have rules for it. PHI never goes into a third-party AI service, and any tool that touches our code runs under terms that don't permit training on the data. We'll walk your compliance team through the specifics.
What happens if there's a breach?
We follow the incident response plan in the BAA, including notification timelines and the documentation your compliance process requires.
Do you also handle GDPR?
Not currently. We work with clients in the US and Canada.
The reason is data transfer rather than capability. Moving EU personal data to a team based outside the EU requires Standard Contractual Clauses and a transfer impact assessment, and health data is a special category under GDPR with its own rules on legal basis, consent, and the data subject rights the software has to implement. We'd rather tell you we're not set up for that yet than take the work and find out mid-project.