What does a technical due diligence team read in a healthtech startup?

Who is reading your file, and what can they do with what they find?

A buyer's technical reviewers, and what they do with a gap is put a number on it. An auditor works to a standard, writes down what does not conform, and hands you a route to close it. A diligence reader works to a purchase agreement, tells somebody else what your record set will cost to own, and is under no obligation to tell you anything at all.

The reading list is almost the same list. Three events open it: an acquisition or a majority investment, a partnership where your software will sit inside another company's clinical workflow, and an enterprise customer's procurement review before a contract that carries patient data. The emphasis shifts between them. The documents do not, because the documents are the ones regulation already obliged you to hold, and no diligence team has the time or the mandate to invent a new evidence framework for you. A funding round narrows the same read to a shorter checklist, written by an investor and asked earlier in a company's life, and that version is worked through separately at what a healthtech investor's checklist asks about QA before a Series A.

Which records do they open first?

The ones that are cheap to check and impossible to reconstruct. Four sit at the top of almost every list.

The contracts that let health data move. HIPAA states this requirement as a document, which is why it is the fastest thing in the file to verify. 45 CFR 164.308(b)(1) allows a covered entity to put ePHI into a business associate's hands, for it to create, receive, maintain or transmit, on one condition: satisfactory assurances taken in the form 164.314(a) prescribes. 164.308(b)(2) repeats the condition one step further out, between a business associate and its own subcontractor. section 164.308(b)(3), a required implementation specification, says those assurances are documented through a written contract. section 164.314(a)(2)(i)(B) then reaches into the contract itself and requires it to bind the business associate to make its own subcontractors sign one, and the Privacy Rule carries the matching flow-down at 164.502(e)(1)(ii) and 164.504(e)(2)(ii)(D).

A diligence team walks that list outward, and it asks in the direction founders rarely prepare. Which vendors and contractors reach ePHI on your behalf, and where is the signed document for each one. The error tracker that receives stack traces, the log aggregator, the analytics SDK in the mobile build, the transcription API and the contractor holding a database dump on a laptop all belong on it, and each name either has a contract behind it or does not. Whoever compiles that list puts the same questions to a testing supplier next, so our own answers on protected health information, on the agreement and on where project data lives sit at how we work with protected health information.

The half of your record that is already public. If ONC's Health IT Certification Program covers a Module of yours, somebody else published part of your test evidence, and a reviewer reads it before you grant access to anything. section 170.523(f)(1) requires the certifying body to publish, on the Certified Health IT Product List, for each certified Module, the location and means by which the testing was conducted, the dates the Module was tested, the test procedure and test data versions and the test tool version used, and whether any test data was altered and for what purpose. section 170.523(f)(1)(xxii) adds the non-conformities: where surveillance under section 170.556 led to corrective action, the criteria the technology failed, a summary of the deficiency, the developer's own explanation where one is available, and the dates surveillance opened and closed. What the programme asks of a developer year by year is set out at ONC certification testing requirements.

What you already know is broken. IEC 62304 asks for this in two places, and Amendment 1 pushed one of them down to every safety class. Subclause 5.8.2, document known residual anomalies, carries [Class A, B, C] as its Edition 1.1 marker and had applied at Class B and Class C alone in the 2006 text. Clause 9, the software problem resolution process, carries the rest of the machinery: 9.1 prepare problem reports, 9.3 advise relevant parties, 9.5 maintain records and 9.6 analyse problems for trends. A defect list with an impact written against each entry, sitting beside a trend analysis, is a different object from a backlog export, and it is the one the standard names. Which of those subclauses reach your own software is decided by the class markers, set out on the software safety classes IEC 62304 assigns and what each one obliges.

Whether the thing you shipped can be rebuilt. Subclause 5.8.7, archive software, moved the same way in Edition 1.1 and now carries the same three classes. Clause 8, the software configuration management process, is three subclauses: 8.1 configuration identification, 8.2 change control, 8.3 configuration status accounting. A buyer's engineer tests all of it in one move, by naming a release from eighteen months ago and asking to see what went into it.

Five records a buyer opens first in technical due diligence on health software, what each settles, and whether it can be produced once diligence starts.

What gets opened	What it settles for the buyer	Can it be produced during diligence?
The written contract with every third party that reaches ePHI	Whether patient data left the company under documented assurances	A contract can be signed now, and its date says when
The CHPL record for a certified Health IT Module	How the product was tested, and every non-conformity that reached corrective action	No. It was published by the certifying body and is read before the data room opens
The trace from software requirements to tests	Whether anything shipped with no test pointing at it	Yes, out of the records you already hold
The residual anomaly list and the problem records	What the buyer is agreeing to own on day one	Yes, and a list assembled this month is dated this month
The archive of a named past release	Whether a build a customer is running can be reproduced	Only where subclause 5.8.7 was answered at the time

What does a missing record do to the read?

It turns an unknown into a priced one. A reviewer cannot show from an absent record that nothing went wrong, so absence is scored as exposure, and exposure is settled in the agreement: a lower number, a holdback, a condition to closing, or a remediation programme the seller funds after the deal completes.

Two features of this industry make a gap heavier here than it would be in ordinary software diligence. The first is that the contract chain travels with the business. Because 164.308(b)(2) and 164.314(a)(2)(iii) put the duty to hold a written subcontractor contract on the business associate itself, an unpapered vendor survives the closing as a defect the buyer has acquired, and their counsel prices it on that basis.

The second is that part of the record was published by somebody else and cannot be tidied. section 170.581 ends the certification chain with a ban that takes effect immediately under 170.581(a)(1), and reinstatement turns on a written request, a demonstration that affected customers were given appropriate remediation, resolution of the noncompliance, and ONC's satisfaction. A reviewer who has read the list arrives knowing things about your testing that no amount of data room preparation changes.

Which of their questions can you answer in the room?

Any question whose answer is true today, and any question about a decision and the reasoning behind it. Those cost you a meeting. Everything else costs a document that exists or does not, and the second list is the one to work through before access opens.

Six questions a buyer asks in health software due diligence, whether each can be answered in the meeting, and which record has to back it.

What they ask	Where the answer has to come from
Which vendors reach ePHI on your behalf	The room, then the signed contract for every name you gave
Why this software item is safety class B and not class C	The room, where the reasoning was ever settled; the classification record then has to say the same thing
How you would know who reached production last month	The room, then the procedures for regularly reviewing records of information system activity that section 164.308(a)(1)(ii)(D) requires
What you know is broken today	The room, then the residual anomaly list subclause 5.8.2 asks for
The test record for the release you shipped last March	The file. Which parts of a test record can be added later and which cannot is worked through at healthcare software audit preparation
A rebuild of the version a named customer is running	The archive, or an afternoon of guessing in front of the buyer's engineer

The rows split on one property. A question about how the company works now is answered by whoever knows, and a wrong answer is corrected in the same meeting. A question about a past event is answered by a record, and where the record is absent the honest answer is that it is absent. Reviewers price the second answer. They stop trusting the file when they get the first one twice about the same past event from two different people.

What do you do in the fortnight before access opens?

Step 1 is the step that surprises founders. The list built from invoices and manifests is reliably longer than the list built from memory, and the reviewer builds theirs from your code, so a name that appears on their list and not on yours costs more than the missing contract does. Step 3 comes before step 4 because the trace tells you which anomalies matter: a defect against a requirement nothing tests is a different conversation from a defect against a requirement with an executed test behind it. What a finished traceability and validation package contains is set out at what a validation documentation package contains.

What is fixed before you start, and what still moves?

Three things are fixed, and any preparation plan implying otherwise breaks down in front of the buyer's engineer.

The published record is published. A CHPL entry recording that test data was altered, or a non-conformity that went to corrective action, sits on a list maintained under 45 CFR 170.523(f) and was read before your first call.

The dates on old approvals stay where they are. A document approved this week carries this week's date, and a reviewer who finds an approval that postdates the work it governs has learned something about the company that no explanation in the room fully unlearns.

An archive that was never taken cannot be taken retrospectively. Subclause 5.8.7 asked for it while the release was happening.

Everything else moves, and the movable pile is the larger of the two. Contracts get signed now. A test nobody ever ran gets run on Tuesday, and its record shows the tools, the configuration, the date, the build it was run against and the person who ran it, because somebody is present to write all five down. A trace gets built this month out of records that already exist. A policy gets written now, provided it states the day it started and does not imply it was always there.

How long the whole exercise takes is set by three counts, each of them available from documents already in your possession: how many third parties reach ePHI with no signed contract, how many software requirements have no test pointing at them, and how many releases inside your supported window cannot be rebuilt from the archive. Take all three before anyone quotes you a duration, because a supplier who prices this work without them is pricing a guess.

What can a testing supplier do once the data room is open?

We read the record set in the order the reviewer will read it, and we come back with two lists: what can be run, recorded and dated before their questions arrive, and what has to be logged as an open gap with the reasoning beside it. That sorting is the deliverable, and it is the piece a company under time pressure cannot do for itself, because it takes reading your own file as an outsider.

Then the runs, with acceptance criteria fixed before each execution begins, each record naming what it was run against and who ran it on the day it was run, and the trace updated as each run lands so that nothing waits to be reassembled at the end. Alongside those: the residual anomaly list with an impact against every entry, and a dated note for each gap saying what covers the period before it. No supplier's letterhead settles anything in this room. Compliance itself is held by the organisation that ships the product, and what a testing supplier hands over is evidence with dates on it.

Diligence work often calls for an environment nobody has stood up for a year, and whoever rebuilds it decides what goes into it. We do not need production PHI to test. Environments run on synthetic and de-identified data. We sign a Business Associate Agreement before any engagement that touches PHI. How a QA supplier is brought inside an existing process, and on what written terms, is covered at healthcare QA outsourcing.

Every section number, subclause number and publication duty quoted above was read in the primary texts for the ONC Health IT Certification Program, for IEC 62304 and for HIPAA, checked 3 September 2026. Sentences about what a certifying body publishes are kept separate in the text from sentences about what the regulation asks of you.