HIPAA and SOC 2 ready software, built in Nashville.
I build web apps, portals and integrations that help your company meet HIPAA and pass a SOC 2 audit. Encryption, role-based access, audit logs and backups go in from the first phase, along with the paperwork your auditor will ask for.
I usually reply within a couple of hours.
caleb@calebdorris.com · Call or text (615) 914-1073
The honest version
Nashville runs on healthcare, and a lot of the software behind it is built by small teams who get one question from every buyer: "Is it HIPAA compliant?" Here is what I can promise and what I can't.
- There is no such thing as "HIPAA certified." HHS says it does not endorse or recognize private HIPAA certifications. Compliance is something your company does, every day, not a badge a vendor sells you.
- A developer can't be "SOC 2 compliant" for you. A SOC 2 report is an independent CPA firm's examination of your organization's controls, including people and processes as well as code.
- What I do: build the software so it has the safeguards HIPAA's Security Rule describes and the controls a SOC 2 auditor tests, and document all of it so your team can show its work.
I'm a developer, not a lawyer or an auditor. Your compliance officer, attorney or auditor makes the call on what your company needs. I make sure the software doesn't stand in the way.
What goes into every build
Encryption
TLS for everything in transit, and encryption at rest for the database, file storage and backups. Keys and secrets live outside the code and outside the data they protect.
Access by role
Every person gets their own login, and each role sees only what the job needs. That's HIPAA's "minimum necessary" idea built into the screens, not left to a policy document.
Sign-in that holds up
Multi-factor authentication, sessions that time out when nobody is using them, and a way to cut off a person's access the day they leave.
Audit logs
A record of who viewed, changed, downloaded or deleted sensitive records, and when. Written so a person can read it, and protected so nobody can quietly edit it.
Clean logs and alerts
Error logs, analytics and notification emails carry record IDs, not names, Social Security numbers or diagnoses. Debug logs and alert emails are easy places for sensitive data to end up by accident, so I keep it out on purpose.
Secure file handling
Signed forms and scanned records go into private storage, not a public folder. Uploads are checked, downloads use short-lived links, and every access lands in the audit log.
Backups you've tested
Encrypted backups on a schedule, kept separate from the live system, with a written restore plan that has actually been run. A backup nobody has restored is a guess.
Vendors with a BAA
Every hosting, database, email, SMS and file service that touches health information needs a business associate agreement with your company. I help you pick vendors that will sign one, and we confirm it before we build on them, not after.
BAAs, in plain words
A business associate agreement, or BAA, is the contract HIPAA requires between a healthcare organization and any outside company that handles its patients' health information. It spells out what that company may do with the data, commits it to protect the data under HIPAA's Security Rule, and makes it report security incidents and breaches.
It matters for software because every service in the chain counts. HHS says a cloud provider that stores protected health information is a business associate even if the data is encrypted and the provider can't read it. So before we pick a host, a database, an email sender or a texting service, I confirm it will sign a BAA on the plan we're paying for. If it won't, health data doesn't go through it.
Most of the BAAs on a project are between your company and those vendors, and my job is to help you choose services that will sign one. I sign a BAA myself only when my work actually exposes me to your patient data, such as supporting a live system that holds it. When that's the case, you should expect to ask me for one. Most of the time it isn't, because I build and test with fake data and never need the real records.
Evidence your auditor can use
A SOC 2 auditor or a HIPAA risk assessment will ask how the system works and for proof that it does. You get these with the code:
- A data map: where sensitive data comes in, where it's stored, who can see it and where it leaves.
- An access matrix: every role, what it can see and do, and how access is granted and removed.
- Change history: every change goes through version control with a reviewable record of what changed and when it shipped.
- Vendor list: each outside service, what data it touches, and whether a BAA is in place.
- Backup and restore notes: what's backed up, how often, where, and the date of the last restore test.
- Audit log guide: what's recorded, how long it's kept, and how to pull a report when someone asks who opened a file.
HIPAA's Security Rule expects its required documentation to be kept for six years, so I write it to be read by someone who wasn't in the room.
Where this comes from
At my day job I build and run systems that handle Social Security numbers, military service records and signed physician forms describing medical conditions for elderly clients. Those forms explain why someone needs assisted living or outside care, which is about as sensitive as a document gets.
Everything I build there has to stay compliant, so care is part of every decision, not a final check. That work keeps me sharp. By default I collect only what the job needs, give each role its own view, keep an audit trail, and keep sensitive details where they belong. I bring the same defaults to every client build.
What I build
- Client and staff portals for intake, secure document upload, review and the screens a care team uses all day.
- CRM and API integrations that move records between systems without spilling them into email, spreadsheets or logs.
- PHP applications and upgrades, including older systems that need modern access control and logging added.
- WordPress custom plugins and themes, with health data kept off the public site and sent to a system built to hold it.
- Next.js on Vercel web apps, set up on a plan where Vercel signs a BAA when health information is involved.
More about how I work with businesses here: Nashville web developer. For the longer explanation, read what "HIPAA-compliant" actually means when you're building an app.
How a project works
Map the data
Before any code, we list what sensitive data the software will touch, who needs it, and which vendors are in the path. That list shapes everything after it.
Build in phases
Each phase has a fixed price in a written scope, and the safeguards ship with the first one, not in a cleanup phase at the end.
Hand off with proof
You get the repository, the documentation above, and notes for the next developer. You own the code.
FAQ
Are you HIPAA certified?
No, and nobody is. HHS says it does not endorse or recognize private "HIPAA certifications," and a certificate does not change what a company owes under the law. What I can do is build software with the safeguards the HIPAA Security Rule describes and document them so your compliance team can check my work.
Can you make my company SOC 2 compliant?
No developer can. A SOC 2 report is an examination of your organization's controls by an independent CPA firm, and it covers people and processes as well as code. I build the software side so it supports those controls, like access, logging, change management and backups, and I hand over evidence your auditor can use.
Will you sign a BAA?
Only when my work actually exposes me to your patient data. If a project means I will create, receive, maintain or transmit your protected health information, for example by supporting a live system that holds it, HHS treats me as your business associate and we sign a BAA before I start. Most projects never get there: I build and test with fake data, and the BAAs that matter are between your company and the vendors that hold the data, like your host, database and email service. I help you pick vendors that will sign one.
Is encryption required by HIPAA?
Under the current Security Rule, encryption is "addressable," which HHS says does not mean optional. You either use it or document why something else works as well. A proposed update would make encryption in transit and at rest required, with limited exceptions. I encrypt both ways by default, so that question is settled before it comes up.
Can a WordPress site be part of a HIPAA-ready setup?
Yes, with a clear line. Your marketing site can run on WordPress as long as health information does not flow through it. Forms that collect health details should send them to a hardened application or a vendor that has signed a BAA, not into the WordPress database or a contact-form email.
Can a Next.js app on Vercel handle protected health information?
It can, with the right plan. Vercel says it signs BAAs with eligible Pro and Enterprise customers, and not on the free Hobby plan. The same check applies to every other service that touches the data, like your database, email and file storage.
Do you only work with healthcare companies in Nashville?
No. I am based in Nashville and meet in person around Middle Tennessee when that helps, and I work with remote teams nationwide.