Healthcare QA outsourcing: what the arrangement has to contain

What does the law already put in the contract?

A written contract and three promises, before anyone gets access. 45 CFR 164.308(b)(1) lets a covered entity permit a business associate to create, receive, maintain or transmit electronic protected health information only where it obtains satisfactory assurances, in accordance with 164.314(a), that the business associate will appropriately safeguard the information. section 164.308(b)(3) then makes documenting those assurances in a written contract a required implementation specification rather than an addressable one. Whether a particular supplier can give assurances you are willing to accept is a question for that supplier and not for the rule, and it is one to put to us on how we work with protected health information.

The promises themselves are enumerated at section 164.314(a)(2)(i), and there are exactly three. The business associate will comply with the applicable requirements of "this subpart". It will, "in accordance with 164.308(b)(2)", ensure that any subcontractor creating, receiving, maintaining or transmitting ePHI on its behalf agrees to comply with those requirements by entering a contract or other arrangement that itself complies with 164.314. And it will report to the covered entity any security incident of which it becomes aware, "including breaches of unsecured protected health information as required by 164.410". Those three sentences are the whole of the security half. The closing clause of the third is the one templates drop, and it is what ties this contract to the breach clock.

The privacy half sits at 164.502(e) and 164.504(e). It adds ten promises at 164.504(e)(2)(ii), lettered (A) to (J), and around them the permitted use term at (e)(2)(i) and the termination right at (e)(2)(iii). What those ten reach, and what they conspicuously do not, is set out under HIPAA compliance testing.

Are the engineers your workforce or a supplier's?

The definition draws that line, and the phrase is inside it. 45 CFR 160.103 defines a business associate as a person who, on behalf of a covered entity, but other than as a member of its workforce, creates, receives, maintains or transmits protected health information for a function or activity the rules regulate. Engineers engaged as a supplier answer through the contract above. People acting as members of your workforce answer through your own administrative safeguards, and 164.308(a)(3) is where they arrive: authorization and supervision at (a)(3)(ii)(A), workforce clearance at (B), termination procedures at (C).

All three of those implementation specifications are addressable, so what an entity implements and why it stopped there is its own record under 164.306(d)(3). A buyer who wants a named check run on named people writes it into the agreement, because neither shape of the arrangement produces one on its own. Whether a supplier that only tests falls inside the business associate definition at all is answered from 160.103, under HIPAA testing requirements for software. The commercial version of the same choice, growing the team against buying it, is in-house against outsourced QA.

What may the team do with the data once it has it?

Only what the contract permits it to do. 45 CFR 164.502(a)(3) limits a business associate to using or disclosing protected health information as its contract or other arrangement permits, or as the law requires; the rule grants it nothing directly. Ordinary test work is therefore a contract question before it is a tooling question. Pulling a record to reproduce a defect is a use. Attaching a screenshot to a ticket is a disclosure into a system the contract may never have named. Pasting a request payload into a bug report moves data into a store the security review may never have reached.

section 164.504(e)(2)(i) sets the shape of the grant. The contract establishes the permitted and required uses, and it may not authorise the business associate to do what would violate the rules if you did it yourself, with two exceptions: the contract may permit use and disclosure for the proper management and administration of the business associate, and it may permit data aggregation services relating to your health care operations. Neither is required. A template that carries both grants both, whether or not this engagement has any use for them.

The way to shorten that list is to keep the data out of the working artefacts, which is settled at the moment environments are seeded, long before a defect is filed. PHI de-identification for test environments covers what doing it properly costs.

What does the rule leave you to ask for yourself?

Most of the supplier questionnaire. The three required terms at 164.314(a)(2)(i) name no country, no personnel check, no data centre, no access review and no notice when a person leaves the project. A buyer who wants any of it has to require it, and a supplier who volunteers it is answering a question the rule never asked. Five that decide how the arrangement behaves:

• Where do the engineers who would work on this sit, and under which employer?
• Where does project data physically live once it leaves your estate?
• Who builds the test environment, and which named people can reach it?
• What does a person pass before joining, and how quickly does access close when they roll off?
• What comes back at the end, store by store?

Ask them of every supplier on the shortlist, and ask again at contract stage. The answers are cheap to give before an environment exists and expensive to change afterwards. How to weigh the answers, and what to do with a supplier that will not give one, belongs to choosing a healthcare QA vendor.

Where does the chain end when your supplier subcontracts?

At your supplier, by the text of the rule. 164.308(b)(1) states that a covered entity is not required to obtain satisfactory assurances from a business associate that is a subcontractor, and 164.308(b)(2) puts that duty on the business associate instead. 164.502(e)(1)(ii) says the same thing on the privacy side, and 164.504(e)(2)(ii)(D) makes the supplier bind its subcontractors to the same restrictions and conditions that bind it. Nothing in that chain produces a contract between you and the subcontractor, so a current list of who is under it is the thing to ask for, and the moment to ask is before the first one is added.

One pointer inside that chain is broken, and a negotiation that cites it cites a paragraph that does not exist. 45 CFR 164.314(a)(2)(iii) applies the contract requirements to a subcontractor arrangement "required by 164.308(b)(4)", and the current text of 164.308(b) ends at paragraph (3). It never pointed anywhere else. The HITECH Omnibus Final Rule of 25 January 2013 cut 164.308(b) from four paragraphs to three and, in the same document, added the new 164.314(a)(2)(iii) citing the paragraph it had just removed. HHS caught the identical error one paragraph earlier and fixed only that one, writing in its technical corrections of 7 June 2013 that those requirements "were renumbered and are now found at 164.308(b)(3)" and amending 164.314(a)(1) alone. Nothing has amended the section since. Read against the paragraph HHS itself named as the successor, what stands behind the cross-reference is the written contract at 164.308(b)(3), reached through the duty 164.308(b)(2) puts on your supplier.

Which products does this arrangement sit on?

Any product whose test data is a patient record, because that is what decides whether an outside team can work without ePHI at all. In a record system, a portal or a claims product the record is the subject of the test, so a synthetic seed has to carry the whole data model and the edit history behind it. The reach of an outside team into an EHR or EMR under test is that whole model, which is why the seeding decision is made before the team is selected.

Software as a medical device sits differently. Where its inputs are device output and not a record held for a covered entity, the work can fall outside the business associate arrangement entirely and inside a quality system instead.

Which standards does the arrangement itself answer to?

HIPAA, and directly. 45 CFR 164.502(a) puts the same double subject on the Privacy Rule's central prohibition that 164.302 puts on the Security Rule: the duty falls on a covered entity or business associate, in those words, in both rules. A supplier inside the definition is regulated in its own right, and the contract sits on top of that.

Where the product is a medical device, a second regime reaches the same arrangement from a different direction. The MDSAP Audit Approach gives outsourcing an audit task of its own, cited to ISO 13485 clauses 4.1.5 and 4.2.1, so an auditor arrives with a question about the supplier already on the list. What that audit expects the records to look like is under ISO 13485 software validation requirements.

What do you receive?

Six artefacts. Each one exists because a term of the arrangement is otherwise carried by nothing but a sentence in a contract.

The permitted use statement is the one the other five hang off. It gives a row to each thing the team actually does with data, from a defect reproduction to a screenshot in a ticket, and matches the row to the clause of the contract that permits it. A row with no clause behind it is a use nobody authorised, and it is cheaper to find in the register than in a customer's assessment questionnaire.

The named access register answers a question no term of the rule generates: who reached which environment, from which employer, between which two dates. Each subcontractor takes rows of its own, which is what makes the flow-down term observable.

The data reach map lists the stores. Screenshots, run logs, fixtures, ticket attachments, CI artefacts and local checkouts each take a line saying whether the data in them is synthetic or derived from a real record. It is the document that makes the exit statement possible, because you cannot dispose of a store nobody wrote down.

The incident awareness log carries two dates per event: when the supplier became aware, and when you were told. The interval between them is the part of the timeline nobody can reconstruct afterwards from logs alone.

The exit disposal statement closes the engagement store by store, and it records which stores made return or destruction infeasible, with the protections that continue over them. A backup rotation, an immutable log store and an archived ticket system each need a sentence of their own here, because each of them can hold a record long after the environment is gone.

The handover pack is the artefact for the day the arrangement ends, whichever side ends it. It holds the environment definitions, the fixture sources, the credentials route and the run instructions, in a form a different team can execute without the authors in the room.

How does it run next to your release process?

It attaches to people and to access rather than to a release date, which makes it a different thing to run than a test cycle. Two things move constantly in an outsourced arrangement: who is on the team this month, and where the data has been deposited since the last review. Both are documents, and each one is out of date the moment a person or a store is added.

Section numbers and quoted phrases from 45 CFR parts 160 and 164 on this page were read on 2 September 2026 in the eCFR compilation of title 45 current as of 31 August 2026, and for the Privacy Rule and the Breach Notification Rule also against the CFR annual edition revised as of 1 October 2024. The clause numbers for the outsourcing audit task come from the MDSAP Audit Approach, document AU P0002.009. The broken cross-reference at 164.314(a)(2)(iii) was checked in both the eCFR and the CFR annual edition revised as of 1 October 2025, and its history read in the Federal Register texts of the Omnibus rule at 78 FR 5566 and the technical corrections at 78 FR 34264.