Healthcare IT Outsourcing

What is healthcare IT outsourcing?

Healthcare IT outsourcing is a contract under which an outside firm builds, operates or supports software and systems for a healthcare organization. When the firm can reach PHI, it becomes a business associate or a subcontractor, so the deal needs a business associate agreement, a security review and clear terms on ownership and exit.

Outsourcing moves the work, not the accountability. The client still answers to its patients, customers and regulators for what the vendor builds and how it handles data.

Which healthcare IT work suits an outside team?

Work with a defined outcome and a clear interface to the rest of the organization suits an outside team best. Decisions about risk, priorities and product direction should stay with the client.

• Product builds: A new patient app, clinician tool or SaaS platform with a written scope and acceptance criteria.
• Integration work: HL7 v2 interfaces, FHIR APIs and SMART on FHIR apps, where the vendor brings interface engine and EHR experience the client lacks.
• Modernization: Moving a legacy system to new code or a new platform, including data migration and parallel running.
• Testing and quality: Test automation, accessibility testing and performance testing for an existing product.
• Run and support: Application support, monitoring and patching under agreed service levels.
• Keep in house: Risk acceptance, the HIPAA risk analysis sign-off, product priorities, vendor selection and the final say on releases.

One middle path is a client-side technical lead, employed or fractional, who owns architecture and priorities while an outside team does the build. That lead also reviews the vendor's work, so quality does not depend on trust alone.

How should the scope be written?

Write the scope around outcomes, data and acceptance tests, not hours. A scope that names the PHI involved and the tests that prove completion avoids most later disputes.

• 1. Outcome: What the work must achieve, in terms a user would recognize, such as clinicians signing results in the app instead of on paper.
• 2. Data inventory: Which PHI the vendor will see, where, and why. If the vendor can work on synthetic or de-identified data, say so and limit access to production.
• 3. Environments: Which development, test and production environments exist, who owns them, and whether the vendor works in the client's cloud accounts or its own.
• 4. Access model: Named accounts for each vendor engineer, least-privilege roles, multi-factor sign-in as good practice, and a process to remove access within a set time when someone leaves.
• 5. Interfaces: Every system the work touches, such as the EHR, interface engine, identity provider and data warehouse, with the owner of each.
• 6. Acceptance criteria: Functional tests, security tests, accessibility targets and performance limits that must pass before the client accepts a release.
• 7. Deliverables beyond code: Architecture notes, runbooks, test suites, infrastructure as code and handover sessions, so the work can be run by someone else.

Agree the scope in a short discovery phase before committing to the full build. Time spent confirming interfaces, data access and acceptance tests with both teams costs far less than a fixed-price contract renegotiated halfway through because the EHR could not support a write the scope assumed.

What must the BAA and subcontractor terms cover?

The business associate agreement must limit how the vendor uses PHI, require safeguards, require breach reporting, flow the same terms down to any subcontractor, and require return or destruction of PHI at the end. Those terms come from 45 CFR 164.504(e).

• Safeguards: The vendor protects ePHI to the same Security Rule standard the client meets, on its own laptops, accounts and tools as well as inside client systems.
• Breach reporting: The vendor reports any disclosure the contract does not allow, including breaches. Set a notice window short enough for the client to meet its own duties, and name who receives the call.
• Subcontractor flow-down: Any subcontractor of the vendor that handles PHI agrees in writing to the same restrictions and conditions before it gets access.
• Return or destroy: At the end, the vendor returns or destroys all PHI where feasible, and keeps protecting anything it cannot.
• Shared accountability: Both sides carry HIPAA duties. The vendor answers for its own handling of PHI, and the client still answers for choosing and overseeing the vendor.

Ask the vendor for a list of every subcontractor that may touch PHI, including cloud hosts, ticketing and logging tools and any staffing partner. Cloud hosts that store PHI belong on that list even when the data is encrypted.

Check the client's own contracts too. Some payer, government and health system contracts restrict where PHI may be accessed from or require notice before new subcontractors are added, and those limits must pass to the vendor.

Keep the BAA and the scope consistent. If the scope says the vendor works only on synthetic data, the BAA still covers the day a support ticket or a log file carries real PHI, and the access model should make that day unlikely.

How do you review a vendor's security?

Review the vendor's security against how it will actually touch the client's data and systems, not against a generic checklist. Start with the access model in the scope, then ask for evidence that each control works.

• Accounts and devices: How engineers sign in, whether laptops are managed and encrypted, and how access is removed when someone leaves.
• Code and secrets: Where code is stored, who can merge to the main branch, and how secrets are kept out of repositories.
• Logging and monitoring: What the vendor logs about its own access to client systems, and whether the client can see it.
• Incident response: Who the vendor calls first, how fast the client hears about an incident and what the vendor preserves for investigation.
• Independent evidence: Any penetration test summaries or third-party attestation reports the vendor can share, read for scope and date.
• People: Background check practice, security training and confidentiality agreements for staff who reach PHI.

The HHS Healthcare and Public Health Cybersecurity Performance Goals, a voluntary set, list vendor and supplier cybersecurity requirements among their essential goals: identify, assess and mitigate risks from third-party products and services. That one line is a fair summary of what this review is for.

Who owns the code an outside team writes?

The client owns the code only if the contract assigns it in writing. Under U.S. copyright law, work by an independent contractor is a work made for hire only in listed categories and under a signed agreement, so an assignment clause is the safer route.

• Assignment: The contract assigns all code, designs, documentation and test assets created for the client, on payment or on creation.
• Vendor background IP: Any libraries or tools the vendor brings are listed, with a perpetual licence for the client to use them in the delivered product.
• Open source: The vendor keeps an inventory of open source components and their licences, so the client knows its obligations before release.
• Repositories and accounts: Code lives in the client's repositories and cloud accounts from the first commit, not in the vendor's, so ownership and access never depend on a handover.

Investors and acquirers check this in diligence. A missing assignment from an early contractor can delay a funding round or a sale until it is fixed.

Governance and the exit plan

Governance keeps outsourced work visible while it runs, and the exit plan makes sure the client can continue without the vendor. Write both into the contract before work starts.

• Regular demos: Working software shown to the client's product owner on a fixed schedule, against the acceptance criteria.
• Access reviews: A periodic check that every vendor account still belongs to someone on the project, with removals recorded.
• Change control: A written process for scope changes, with cost and schedule effect agreed before work starts on them.
• Exit checklist: Code, infrastructure definitions, credentials, runbooks, open defects and a knowledge transfer plan, delivered on notice.
• Data at exit: Written confirmation that PHI has been returned or destroyed, as the BAA requires, including copies in subcontractor systems.
• Transition support: A period during which the vendor helps a new team or the client's own staff take over.

Test the exit plan before it is needed. Ask someone outside the vendor team to build and deploy the product from the client repositories using only the delivered runbooks. Gaps found that way are cheap to fix while the vendor is still engaged.

How Agnotic can help

Outsourced healthcare work goes well when scope, data access, ownership and exit are agreed before the first sprint. Agnotic Technologies provides healthcare fractional CTOs who write that scope with the client, set the access model and review delivery, and engineers who build healthcare software for the client under those terms.

Agnotic works in the client's repositories and cloud accounts, delivers runbooks and test suites with the code, and plans the handover from day one, so the client can take the work in house or move it at any time.

Sources

• 45 CFR 164.504(e): Business associate contract requirements
• HHS: Healthcare and Public Health Cybersecurity Performance Goals
• U.S. Copyright Office: Circular 30, Works Made for Hire