Healthcare software due diligence
You are acquiring a clinical or health-data product, and its compliance posture arrives as a set of documents: a HIPAA policy, a SOC 2 report, a signed BAA, a slide that says “de-identified”. None of those tell you where protected health information lands once the system is running, who else already holds a copy of it, or what it would cost to bring the product to where it has to be. That gap does not stay with the seller — it closes onto your balance sheet. I read the architecture, the data paths and the evidence behind the certificates, then tell you what the PHI exposure amounts to, which obligations the target is carrying but not meeting, and what remediation costs in engineering months and dollars.
What makes diligence different in healthcare
A generalist reviewer treats healthcare compliance as paperwork: is there a policy, is there a certificate, is the BAA signed. Those questions are necessary and they tell you very little.
HIPAA is an architecture constraint. It decides where data may be stored, which logs are allowed to exist, who can read a support ticket, how long a backup lives, and what has to happen within sixty days of a breach. A system that was not designed against those constraints does not get to them through a policy rewrite; it gets there through engineering work, and that work has a cost and a schedule someone has to own after close.
Which makes the first question a simple one: where does PHI come to rest? Not where the data model says it lives, but every place a copy ends up. Each of those copies is in scope, and each one that sits with a third party needs a business associate agreement behind it. The chain is nearly always incomplete, and it is incomplete in the direction of the newest vendors.
The evidence deserves the same scrutiny. A SOC 2 Type II report tells you something, but the useful part is which systems were excluded from the scope and what the auditor recorded in the exceptions. A de-identification claim is a statement about re-identification risk that has to survive someone actually trying to break it. And where the product touches clinical research or a regulated workflow, a second body of rules applies — consent and provenance governing what the data may be used for, and, for validated systems, 21 CFR Part 11 obligations around audit trails and electronic signatures that are a build rather than a configuration.
What I look for
The technical foundation is assessed on every engagement — architecture, code quality, security, intellectual property, key-person risk and running costs. What follows is specific to health data, written as the things that go wrong.
PHI in places nobody inventoried
Protected health information does not stay where the schema says it lives. It ends up in application logs, in the error tracker, in analytics events, in a support tool, in an export someone emailed, and in a staging environment seeded from a production dump. The non-production copy is the most common finding of all, and it is the one that turns an incident into a notifiable breach.
A business-associate chain with holes in it
Every vendor that can see PHI needs a BAA, including the ones an engineer added with a credit card and the subprocessors sitting behind them. The chain is usually complete for the vendors procurement knows about and incomplete for everything added in the last two years. Each gap is a live obligation you inherit at close.
De-identification that would not survive a challenge
“De-identified” is a legal claim about how hard it would be to re-identify someone. Dropping a name column does not establish it. Dates, ZIP codes, rare diagnoses and free-text notes routinely survive the process. Where that dataset is part of the revenue story or the training set, the claim starts to carry valuation weight.
Access control that cannot answer who read the record
Role hierarchies collapse into an admin role half the company holds, support engineers query production directly, and break-glass access is logged but never reviewed. HIPAA assumes you can reconstruct who accessed which record and why. A surprising number of otherwise competent systems simply cannot.
Certification that covers less than it appears to
A SOC 2 Type II report has a scope, a period and a list of exceptions, and the acquired product is sometimes outside the scope. HITRUST on one environment says nothing about the others, and a penetration test is often a vulnerability scan with a cover page. I read what the auditor wrote, against an architecture that may be a year newer than the evidence.
Remediation that is really a rebuild
Tenant separation enforced only in application code, encryption keys the vendor holds on the target’s behalf, audit logging that has to be retrofitted through every service. These are the findings that move price, because fixing them costs quarters of engineering time.
Where AI changes the picture
Clinical AI concentrates every one of these problems. The model was trained on patient records, and the question is whether there was a right to use them for that purpose — an authorization covering treatment and operations does not automatically extend to building a product, and a de-identification that does not hold takes the training set down with it.
Then there is what the product claims. The line between clinical decision support and a regulated medical device is drawn by what is claimed and how much the clinician is expected to defer to the output; a marketing page can move a target across that line without anyone inside the company noticing. Where a wrong output changes a clinical decision, reproducibility stops being an engineering nicety: you need to know whether a given output can be reconstructed months later, and whether anyone is watching performance per site and per population as well as in aggregate, because site-level numbers are where drift shows up first.
And if the model is a call to a foundation-model API, that provider is a business associate. There needs to be a BAA, a commitment that your data is not used for training, and an answer for the day the terms or the pricing change.
Why me for this
I was Director of Software Engineering for a decentralized clinical-trials SaaS platform, where I defined the architecture and the technical stack and advised teams on HIPAA, SOC 2 and privacy law. In practice that meant deciding where patient data was allowed to go, and saying no when the answer was nowhere. Before that I was Senior Principal Software Engineer architecting edge-and-cloud processing and hardening mobile security for decentralized clinical research — the part of the system that collects data from patients at home, where a design shortcut becomes an unencrypted copy of somebody’s health record sitting on a phone.
I have also been through an acquisition from the target’s side of the table. I know what a company looks like while it is preparing for diligence, and I know where the tidy answer usually stops.
Common questions
- Do you assess HIPAA compliance as part of technical due diligence?
- Yes, as an architecture question rather than a document review. Policies, a SOC 2 report and signed BAAs tell you what the target intends; the code, the data paths, the logs, the backups and the vendor list tell you where protected health information actually lands and which obligations are being carried but not met. Where a legal opinion is required, I say so — what I give you is the technical picture the legal work has to sit on, and the cost of closing the gap.
- Can you assess a healthcare target without access to patient data?
- Yes, and that is how the work is done. An assessment that required a copy of PHI would itself be a compliance problem. I work from architecture and schemas, code and configuration, infrastructure and access models, vendor and subprocessor lists, BAAs, audit evidence and redacted log samples. If a demonstration needs real records, it happens in the target’s environment with their staff at the keyboard.
- The target has SOC 2 and HITRUST certification. Is that not enough?
- It is evidence, and it has limits. A SOC 2 Type II report has a defined scope, a defined period and a list of exceptions, and the product you are acquiring is sometimes outside that scope; HITRUST on one environment says nothing about the others. The report is also frequently older than the architecture it describes. I read what the auditor wrote, against the system as it is built today.
Have a deal in motion?
Tell me the target, what you need to know, and your timeline. I will tell you whether and how I can help, usually the same day.
Engagements are confidential and run under a mutual NDA.