In-house vs outsourced QA for healthcare software

Who is telling you this, and what do they sell?

This site sells outsourced QA for regulated medical software, so read the page with that in mind and check the citations. The honest position is that the choice splits by the kind of work and not by a preference: some of what a QA function does cannot be bought at all, some of it is bought routinely by companies with large in-house teams, and the regulated part of the decision is narrower than the commercial part. Where this page says "hire", it means hire.

Two of the seven questions on how we work with protected health information carry no published answer: who builds a test environment and who can reach it, and what an engineer passes before joining a project with PHI. Both are questions to put to any supplier you are weighing against a hire, and both are unanswered here today. We sign a Business Associate Agreement before any engagement that touches PHI. We do not need production PHI to test. Environments run on synthetic and de-identified data.

What actually changes on the day the work moves outside?

Two things change: the category the people sit in, and the document that has to exist before anyone gets access. 45 CFR 160.103 defines a business associate as a person who, other than as a member of the covered entity's workforce, creates, receives, maintains or transmits protected health information for a regulated function, and quality assurance is named in the list of functions the definition gives. An in-house tester is workforce. An outside tester is a business associate, and section 164.308(b)(1) permits the arrangement only where you obtain satisfactory assurances in accordance with 164.314(a), documented under 164.308(b)(3) in a written contract.

Nothing in that shift reduces what you owe. 164.302 applies Subpart C to a covered entity or a business associate in one sentence, so both parties end up regulated at once. The three security promises the contract must carry are enumerated at section 164.314(a)(2)(i), and the clause by clause reading of that agreement, along with the chain that continues past your supplier under 164.308(b)(2), belongs to what an outsourced QA arrangement has to contain.

The in-house side has its own paperwork, and buyers routinely miss that it exists. Workforce testers reach the same data through the administrative safeguards at 164.308(a)(3), and what you implemented there and why is a record of yours. Each arrangement leaves a record, and the choice decides which file it sits in.

Which obligations can you not hand to anybody?

There are four, and each is stated by the document a supplier would otherwise be working to.

Outsourced processes stay yours under the quality system. The published abstract of ISO 13485:2016 states that processes required by the standard which apply to the organization but are not performed by it remain the organization's responsibility, and are accounted for by monitoring, maintaining and controlling those processes. Buying the work therefore buys you a second job, which is evidencing the control of the party doing it. What ISO 13485 asks of software validation is where that lands in practice.

Device validation and final release sit outside the software life-cycle standard altogether. Subclause 1.2 of IEC 62304 ends with the sentence "This standard does not cover validation and final release of the MEDICAL DEVICE, even when the MEDICAL DEVICE consists entirely of software." A supplier working to that standard is working inside a boundary the standard itself draws, and the part beyond the boundary was never on the table. What IEC 62304 requires of software testing sets out what is inside it.

The record is the manufacturer's even when the work was not. FDA's computer software assurance guidance, issued on 3 February 2026 and expressly nonbinding, permits a manufacturer to leverage validation activities performed by other entities such as developers, suppliers and cloud service providers. Section V.A(6) then describes the record the manufacturer should still capture: the intended use of the feature, the result of the risk-based analysis, a description of the testing, the issues found, a conclusion statement declaring acceptability, and who performed the testing together with the date.

The risk decisions recur and stay with management. The risk analysis at section 164.308(a)(1)(ii)(A) and the periodic evaluation at 164.308(a)(8) are obligations of the regulated entity, and no contract term at 164.314(a)(2)(i) mentions either of them.

Which parts are worth hiring for?

Hire for the work that repeats at every change and needs someone with the authority to accept a risk. Three named provisions mark that boundary, and all three point the same way.

FDA's guidance analyses software per feature, function or operation instead of per system, because features of one system can carry different risks, and it recommends that the manufacturer document the decision-making process behind each determination. That decision arrives again with every feature you ship. Clause 5.8.1 of IEC 62304 requires that all software verification activities are complete and the results evaluated before the software is released, at safety classes A, B and C alike, so a release decision exists on every release. The periodic evaluation at 164.308(a)(8) sets no interval and no method, which makes choosing the interval an act of judgement that nobody outside will perform for you.

If you ship a regulated product every week, the person who holds the intended-use determination and signs off the release is a hire, and an engagement bought for that job repeats the decision without ever holding it. The same logic reaches the operational side of the Security Rule, and what a digital health startup needs to switch on first takes that sequencing at the stage it usually arrives.

Bounded work sorts the other way. A test campaign against a named build, with acceptance criteria fixed beforehand and a defined artefact at the end, starts and finishes. It can be bought, and it can be bought again next year without carrying a salary between the two.

What does each choice put in front of an auditor?

Each choice puts a different task in front of the auditor, and neither removes one. The MDSAP Audit Approach used by the regulators of Australia, Brazil, Canada, Japan and the United States gives outsourcing an audit task of its own, cited to ISO 13485:2016 clauses 4.1.5 and 4.2.1. Outsource, and an auditor arrives with that task on the list. Keep the work inside, and the competency and training task, cited to 4.2.1 and 6.2, carries the weight instead.

Only the outsourced branch produces a vendor assessment, and FDA's guidance names four ways of doing one. Exactly one of them reads paperwork the vendor already holds before you arrive, which the guidance describes as its accreditations and certifications, naming Service Organization Controls reports and ISO certifications as examples. This site publishes no certificate, so that route returns nothing here and a buyer would be left working through the three that require the vendor to produce something. That is a cost of the outsourced option as this supplier currently stands, and it belongs in the comparison. How to choose a healthcare QA vendor walks the remaining routes in the order a procurement team uses them, and how FDA's computer software assurance guidance changes the effort covers the framework the four sit inside.

An acquirer's diligence team reads the same split from the other end, because the supplier evaluation and the competence records are both things they can ask for and neither exists by default. What such a team opens first is described at the technical review before a funding round or an acquisition.

What is left behind when either arrangement ends?

What is left is whatever the records say without the people who made them. Clause 5.7.5 of IEC 62304 states its purpose as supporting the repeatability of tests, and four of the seven items it obliges a system test record to carry are the ones an incoming team needs to reproduce a result it did not produce: the software version under test, the hardware and software test configurations, the test tools, and the person responsible for running the test and recording what came back. clause 5.7.4 adds that traceability between software requirements and tests must be recorded, at every safety class.

Read those two as an exit test and they apply symmetrically. A supplier's suite that only its authors can run fails it. An in-house suite that only the tester who is resigning can run fails it in exactly the same way, and the date that team stops answering questions is set by the person resigning. The arrangement that survives its own ending is the one where the seven items were filled in while the test was being run.

One asymmetry is real. An outside team brings its own tooling, and under FDA's guidance a development tool that tests or monitors software systems or automates testing activities counts as software used to support production or the quality management system, so it carries validation effort of its own. Ask which tools are coming in while the proposals are open, because each one enters your file and stays there after the supplier leaves.

The date is already fixed. Does that decide it?

Usually, and the constraint is written into the evidence itself. Clause 5.7.5 requires the version of the software tested and the date tested to appear in the record, and Section V.A(6) of FDA's guidance asks for who performed the testing and the date. Test records therefore carry the date they were made, and a file assembled in the weeks before an audit reads as a file assembled in the weeks before an audit.

That fact does not favour either arrangement on its own. It rules out the version of the question most CEOs are actually asking, which is whether a hire made this quarter can produce evidence for the quarters that have already shipped. Nobody can. What either arrangement can do inside a fixed window is run tests against the current build and record them properly, and what is decided alongside that is who holds the same job at the next deadline. We test against the requirements in these standards and prepare the artefacts an auditor asks for. Compliance itself is held by the organisation that ships the product.

Sequence it the way the dates allow. Buy the bounded work against the forced deadline, and hire for the recurring decisions in the months after it. Reversing the two produces a hire who arrives after the deadline and a supplier engagement that never ends.

Sources for this page: the HIPAA definitions and section numbers are read in the eCFR compilation of 45 CFR parts 160 and 164 current as of 31 August 2026, on 2 September 2026. The ISO 13485 statements are read in the published ISO abstract carried by a national standards body's catalogue, and the MDSAP Audit Approach, document AU P0002.009, for the clause numbers attached to each audit task. The IEC 62304 statements are read in Edition 1.1, through the IEC preview of the standard and of Amendment 1. The FDA statements are read in the computer software assurance guidance issued on 3 February 2026, Sections V, V.A(1), V.A(5), V.A(6) and Appendix A.