HIPAA-compliant software development
Digital Scientists builds software that handles PHI the way HIPAA, security reviewers and acquirers expect. Every engagement starts with a signed BAA. Our security plan is mapped to NIST CSF 2.0, and each client gets a security addendum for its project. Encryption, access control, audit logging, minimum necessary access, backups and incident response go into the architecture from the first sprint. NeverAlone, the virtual care platform we built and run, has handled PHI 24/7 since March 2021. Most clients start with a Blueprint that maps where PHI moves.
Updated
NeverAlone live with PHI, 24/7
Patients across six states on NeverAlone
Signed before any PHI moves or access is granted
Security plan mapping, plus an addendum per client
What does "HIPAA compliant" mean for software?
It means the software, and the team that builds and runs it, meets the HIPAA Security and Privacy Rules for the PHI it holds. There's no official HIPAA certification for software or for vendors. A "HIPAA certified" badge is a vendor's own label, not a government one.
HIPAA applies to covered entities (providers, health plans and clearinghouses) and to their business associates. A business associate is any vendor that creates, receives, stores or transmits PHI on their behalf. When we build or run your platform, that's us, so we sign a BAA before we touch PHI.
Code alone isn't compliant. Compliance is the controls in the code and the cloud, plus the policies and people that run them. A HIPAA-eligible cloud service is a starting point: AWS covers its data centers, and everything configured on top is on you and us. That's why we design for it in the architecture, and why NeverAlone, which has carried PHI every hour since March 2021, is where our controls get tested.
This page is how we build. Our posture for procurement and security teams is on security and PHI.
NeverAlone live with PHI, 24/7
Patients across six states
Calls a year
Managed devices under MDM
Which HIPAA controls do you build into the software?
The same set on every build: encryption, access control, audit logging, minimum necessary access, backups and incident response. They go into the architecture in the Blueprint and the first sprint, because retrofitting them after launch costs more and misses things.
Most HIPAA gaps sit around the features: application logs that capture PHI, an analytics or error-tracking tool with no BAA, a storage bucket left open. We treat those as part of the build. Every vendor that touches PHI is under a BAA or stays out of the data path.
AI gets its own rule. On every build, every AI output is logged with its input, the source it drew on, the model version and the reviewer's action, and a person approves the output before it's used.
HIPAA controls we build into every platform that holds PHI
| Control | Where HIPAA asks for it | How we build it |
|---|---|---|
| Encryption | 45 CFR 164.312(a)(2)(iv) and 164.312(e)(1) | AES-256 at rest for databases, file storage and backups. TLS in transit, including between internal services. Keys and secrets in a managed service, never in code. |
| Access control | 45 CFR 164.312(a)(1) and 164.312(d) | Unique user IDs, role-based access, MFA and automatic logoff. Access reviewed on a schedule and revoked when it's no longer needed. |
| Audit logging | 45 CFR 164.312(b) | Every read, change and export of PHI logged with who, what and when. Application and error logs kept free of PHI. |
| Minimum necessary | 45 CFR 164.502(b) and 164.514(d) | Each role sees only the fields its job needs. Reports, exports and integrations send only what the recipient needs. De-identified data in development and test. |
| Backups and recovery | 45 CFR 164.308(a)(7) | Encrypted, automated backups and a written contingency plan with recovery steps in the runbook. |
| Incident response | 45 CFR 164.308(a)(6) | Alerting, an escalation path, notification within your BAA's timeframes and a post-incident review. |
| AI outputs | Our rule, on every build | Every output logged with input, source, model version and reviewer action. A person approves it before it's used. |
Encryption is an "addressable" specification under the HIPAA Security Rule. We treat it as required.
Can you build software that holds substance use disorder records under 42 CFR Part 2?
Yes. 42 CFR Part 2 is the federal rule that protects records from federally assisted substance use disorder (SUD) treatment programs, and it sits on top of HIPAA. We design for it in the Blueprint, so consent and record tagging live in the data model from the start.
The 2024 final rule moved Part 2 closer to HIPAA, with a compliance date of February 16, 2026. A single consent can now cover treatment, payment and operations, but consent still carries more weight than it does for other PHI. In software, the platform has to know which records are Part 2 and what each patient agreed to.
We've run behavioral health workflows on NeverAlone since August 2023. The rule-by-rule design table is in the 42 CFR Part 2 section of our security and PHI page. Your counsel decides how Part 2 applies to your program, and we build the software to match.
Consent as data
Scope, date and revocation are stored with the patient. Every disclosure, export and feed checks consent first.
Tags from intake
Records are tagged by source program when they arrive. Tags follow the data into reports, integrations and AI prompts.
Notice travels with the data
Each consented disclosure carries its redisclosure notice. Outbound feeds filter on consent scope.
Counseling notes apart
SUD counseling notes are their own note type with their own consent check.
What evidence can we hand a security reviewer or an acquirer?
A standard set of documents, from the BAA to your system's audit logs. The full list, with when you get each one, is our diligence packet.
Health systems, payers and investors ask the same questions: who touches PHI, where it lives, how access is controlled and what happens in an incident. We build so each answer is a document you can hand over. You own the code, the cloud accounts and the evidence.
We don't hold SOC 2 or HITRUST, and neither is on our roadmap. Reviewers find our controls in the security plan, the addendum and the completed questionnaire, and they can put follow-up questions to the engineers who built the system.
Business Associate Agreement
Signed before any PHI is exchanged or system access is granted. Our template or yours.
Security plan
Our written information security program with a HIPAA annex, mapped to NIST CSF 2.0.
Security addendum
Written for your project: hosting, access, data handling, AI use and rules such as Part 2.
Completed questionnaire
SIG, CAIQ, HECVAT or your own format, from pre-filled answers we keep current.
Architecture and PHI data flow
Your system's architecture and every place PHI moves, delivered in the Blueprint.
Access rosters and audit logs
Who has access to your PHI and what they did with it, on request.
Platforms where we've built and run PHI controls
NeverAlone · CommuniCare
PHI 24/7 since March 2021
A virtual care platform for 30,000 patients across six states, with PointClickCare and Netsmart data, AWS Chime video and Bandwidth E911 under BAAs. We built it and still run it.
See the work
CommuniCare MDS
$10M+ recovered to date
AI recommendations on PointClickCare data, each linked to its source and validated by an MDS coordinator, plus $24M+ in forecast PDPM revenue. Built from April 2024 and handed to CommuniCare's own team.
See the work
Guardian · Vigilant Medical
99.9% transcription accuracy
Vital signs streamed from operating room devices into an encrypted AWS environment with WAF, GuardDuty, CloudTrail and MFA.
See the workTrusted by healthcare leaders.
“I have worked with many technology teams during my career, and Digital Scientists is one of the best. They take the time to understand the customers' needs, deliver innovative solutions, are always professional, and work with your team as a true partner to achieve success.”
Amy Severino
Chief Innovation Officer, NeverAlone
“Thank you to the Digital Scientists team, this has been a long time coming! We finally have something that will be useful for our team so I want to take this opportunity to thank you for your hard work and your diligence. You took an idea and made it come to life!”
Dr. Charles Clayton Daniels Jr.
CEO & Founder, Fathers' UpLift
Where do we start if our software will hold PHI?
Most new builds start with a Blueprint, where we map every place PHI moves and draft your security addendum before any code is written. The table shows common starting points, not rules.
The earlier the controls are designed, the cheaper they are. A Blueprint settles where PHI lives, which vendors touch it, which controls apply and what your reviewers will ask for, and it ends with a build plan and budget you can take to your board.
If the product already exists, we start by reviewing it against the controls on this page and give you the gaps in priority order. If you need AI on PHI, the same Blueprint decides where the model runs and how its outputs are reviewed. See ways to start.
Common starting points for HIPAA-compliant software
| Where you are | A common first step | What you get |
|---|---|---|
| A new product that will hold PHI | Blueprint | Architecture, PHI data-flow map, control plan, draft security addendum and a build plan. |
| A built product facing a security review or a sale | A review against the controls above, through healthcare IT consulting | Gaps in priority order, with a plan and estimate to close them. |
| Adding AI to a platform that holds PHI | A Blueprint scoped to the AI workflow | Where the model runs, what it reads, who approves outputs and how each one is logged. See healthcare AI development. |
| A platform that will hold SUD records | Part 2 design inside the Blueprint | Consent model, record tags and disclosure rules in the data model. |
Your counsel and compliance officer own your HIPAA policies. We build and run the software to match them.
Related healthcare services
Healthcare security and PHI protection
Our posture for procurement: BAA, NIST CSF 2.0 plan and the diligence packet.
Healthcare security and PHI protection →Cloud and HIPAA hosting
HIPAA-eligible AWS environments, built as code.
Cloud and HIPAA hosting →HIPAA-compliant chatbots
Patient and staff chat with PHI handled under the same controls.
HIPAA-compliant chatbots →Healthcare product development
From Blueprint to MVP to a product in production.
Healthcare product development →Healthcare AI development
AI in your own AWS account, with a person approving every output.
Healthcare AI development →Behavioral health software
Platforms for behavioral health and SUD programs, with Part 2 designed in.
Behavioral health software →Latest thinking on HIPAA and PHI
Questions about HIPAA-compliant software
Is there such a thing as HIPAA certification?
No. HHS and its Office for Civil Rights enforce HIPAA, but they don't certify software, vendors or developers. A "HIPAA certified" label is a private assessment or a vendor's own claim. What a reviewer should look for is a signed BAA, the controls in the system and evidence that they run: a security plan, access rosters, audit logs and an incident response plan.
Are you SOC 2 certified?
No. We don't hold a SOC 2 report, and SOC 2 isn't on our roadmap. What we do instead: a BAA with every covered entity, a security plan mapped to NIST CSF 2.0, and a security addendum written for each client's project. Your reviewers can put follow-up questions to the engineers who built the system.
What's in your BAA?
Permitted uses and disclosures of PHI, the safeguards we maintain, breach and incident notification, the terms our subcontractors sign, and how data is returned or destroyed when the engagement ends. We use our standard template or yours, and it's signed before any PHI is exchanged or system access is granted.
How do you handle Part 2?
We design for 42 CFR Part 2 in the Blueprint. Consent is stored as data with its scope, date and revocation, records are tagged by source program at intake, the redisclosure notice travels with each disclosure, and SUD counseling notes get their own consent check. Your counsel decides how Part 2 applies to your program, and we build the software to match.
Who is responsible for HIPAA compliance, you or us?
Both, for different things. As the covered entity, you own your HIPAA policies, your risk analysis and your patients' rights. As your business associate under a BAA, we're responsible for the safeguards in the software we build and the systems we run, and for reporting incidents to you within the BAA's timeframes.
Talk it over
Tell us what you are trying to do. A senior person from our Atlanta team replies within one business day, and you can book a 30-minute call right after you send this.
- We tell you if we're the right fit, and if we're not, who is.
- Most work starts small, so you see how we work before you commit to more.
- We sign a BAA before we touch patient data.