DevOps in Healthcare

What is DevOps in healthcare?

DevOps in healthcare is the practice of building, testing, releasing and running healthcare software through automated, repeatable pipelines while keeping ePHI inside approved systems, recording every change and access, and planning for downtime. It lets a product team ship small changes often without putting patient data or clinical workflows at risk.

The toolchain is the same one any software team uses. What healthcare adds is a set of boundaries: which cloud services may hold ePHI, which environments may see it, which customers must hear about a change, and what clinicians do when the system is down during a clinic day.

What does healthcare change about a standard DevOps setup?

Healthcare changes six defaults. Each one turns into a concrete rule for the pipeline or the cloud account.

• Cloud services: ePHI may only sit in services covered by the cloud provider's business associate agreement, so the service catalog is restricted.
• Environments: Production is the only place real ePHI belongs. Development and staging run on synthetic data.
• Integrations: EHR, lab and payer interfaces cannot be started inside a CI job the way a database container can, so integration testing needs its own design.
• Customers: Hospital customers can set change windows, ask for release notes and freeze changes around their own EHR upgrades.
• Downtime: A contingency plan is a Security Rule requirement, and clinicians need a defined way to keep working when the product is unavailable.
• Regulated software: If the product is a medical device, release records and vulnerability handling connect to FDA expectations.

Setting up a cloud account that can hold ePHI

The business associate agreement comes before the first byte of ePHI. HHS guidance on HIPAA and cloud computing says a cloud service provider that creates, receives, maintains or transmits ePHI for a covered entity or business associate is itself a business associate, even when it stores only encrypted data and holds no key.

• 1. Sign the BAA: Accept the provider's BAA for the account or organization before any patient data arrives.
• 2. Limit services: Keep a list of the services the BAA covers, and block the rest in ePHI accounts with organization policies.
• 3. Separate accounts: Use separate accounts or projects for production, staging and shared tooling, so a mistake in a test account cannot reach patient data.
• 4. Lock down identity: Single sign-on for engineers, no shared root credentials, multi-factor authentication on every human login, and short-lived credentials for pipelines.
• 5. Encrypt by default: Encryption at rest and in transit for every data store and connection, with managed keys and logged key use.
• 6. Log from day one: Turn on cloud audit trails and send them to an account application engineers cannot alter.
• 7. Define it as code: Accounts, networks, policies and alerts live in infrastructure as code, so the setup can be reviewed, repeated and rebuilt.

Treat every third-party tool the same way. An error tracker, a log platform or a support desk that receives ePHI is a business associate too, so either sign a BAA with it or strip identifiers before data leaves the application.

How should EHR and payer integrations be tested in a pipeline?

Test integrations in layers, because a real EHR cannot run inside a CI job. Contract tests run on every change, and end-to-end tests run against vendor sandboxes and customer test systems on a schedule.

• Message fixtures: A library of synthetic HL7 v2 messages, such as ADT, ORM and ORU, and FHIR R4 resources, including awkward cases like repeated segments, empty fields and unexpected code systems.
• Contract tests: Parsers and mappers run against those fixtures on every commit, with the expected output checked into source control.
• Interface engine config as code: Channel definitions for engines such as Mirth Connect are exported, versioned and deployed through the pipeline instead of edited live.
• Vendor sandboxes: Scheduled runs against EHR vendor sandboxes, such as Epic's open.epic and fhir.epic.com programs, catch authorization and version changes early.
• Customer test systems: A release checklist for each hospital's test environment, because a customer's EHR build rarely matches the vendor sandbox.
• Payer endpoints: Eligibility and claim flows tested against clearinghouse test modes, with synthetic member data only.

The release this prevents is one that passes every unit test and then breaks an ADT feed at one hospital, because that site sends a custom Z-segment the fixtures never covered. Every production interface defect should become a new fixture.

When should a healthcare team release?

Release when users can absorb a problem and the customer agreements allow it. For clinical software that means outside peak clinic hours, inside any change windows hospital customers set, and never during a customer's go-live.

• Small batches: Small changes are easier to review, test and roll back than a quarterly bundle.
• Feature flags: Ship code dark and turn features on per customer, so a clinic can adopt a workflow change when its staff are trained.
• Customer notice: Send release notes and advance notice for changes that touch clinical workflows, in the form customer contracts ask for.
• Freeze periods: Pause non-urgent releases around customer EHR upgrades, go-lives and other agreed dates.
• Rollback first: Every release has a tested rollback path, and database migrations are written to stay backward compatible for one release.
• Security fast lane: Patches for exploitable vulnerabilities follow their own approval path so they do not wait for the next window.

Planning for downtime and incidents

Downtime planning is a legal requirement before it is an engineering one. The HIPAA Security Rule requires a contingency plan with a data backup plan, a disaster recovery plan and an emergency mode operation plan (45 CFR 164.308(a)(7)), and audit controls that record activity in systems holding ePHI (45 CFR 164.312(b)).

• Restore tests: Scheduled restores into an isolated account, with the date, duration and result recorded each time.
• Recovery targets: Recovery time and data loss targets agreed with customers and tested against, not just written down.
• Emergency mode: A decision on what the product does when a dependency fails, such as read-only mode, queued writes or a paper downtime procedure for clinicians.
• Runbooks: Step-by-step runbooks for likely failures, such as an EHR feed outage, an identity provider outage or a database failover.
• Clinical context on call: The on-call engineer knows which customers run clinics at which hours and whom to contact at each site.
• Post-incident review: A blameless review after every incident, with the fixes tracked in the backlog until they ship.

Keep ePHI out of the observability stack by default. Logs, traces and error reports should carry record IDs rather than names, notes or results, which keeps those tools out of the BAA question and makes logs safe to share during an incident.

What changes when the software is a medical device?

Device software adds a regulator to the release process. For a cyber device under section 524B of the FD&C Act, the premarket submission must include a software bill of materials, a plan to monitor and address postmarket vulnerabilities, and processes that provide reasonable assurance of cybersecurity.

The pipeline is the natural place to meet those duties. Generate the SBOM on every build, store it with the release, and feed dependency alerts into the postmarket vulnerability process with an owner and a due date.

Release approvals for device software belong to the quality system. Map the pipeline's reviews, test records and sign-offs to the QMS procedures so one record serves both, instead of running a parallel paper process beside the pipeline.

Not every healthcare product is a device. Scheduling, billing and administrative tools usually fall outside device rules, and that call belongs with regulatory counsel before the release process is designed.

Failure points in a healthcare DevOps setup

These failure points appear in setups that grew without a plan. Each one is cheaper to prevent than to clean up after a customer security review finds it.

• Shadow services: A developer adds an analytics or error-tracking tool that receives ePHI and has no BAA.
• Hand-edited interface channels: Production interface engine changes made in a console and never captured in source control.
• Production copies for debugging: A database snapshot restored into staging to chase a bug, which puts ePHI in a system built for test data.
• Untested restores: Backups that run nightly but have never been restored, so recovery time is unknown.
• Clinic-hours releases: Deploys timed for engineers' convenience rather than for the clinics using the product.
• Shared admin credentials: One cloud login used by several people, which breaks unique user identification and the audit trail.
• No owner: On a small team the pipeline, cloud account and on-call rota belong to everyone, so nobody keeps them current.

How Agnotic can help

On a small healthcare team, the pipeline, cloud account and release rules need one accountable owner, and Agnotic Technologies' fractional CTO service fills that gap. Agnotic sets up BAA-scoped cloud accounts as code, CI pipelines with HL7 v2 and FHIR contract tests, release and rollback rules that fit hospital change windows, and runbooks for backup, recovery and incidents.

The work ends in a handover. Your engineers own the pipeline, the runbooks and the decision record, and Agnotic's role can shrink to periodic reviews as the team grows.

Sources

• eCFR: 45 CFR Part 164 Subpart C, HIPAA Security Rule (164.308(a)(7) contingency plan, 164.312(b) audit controls)
• HHS: Guidance on HIPAA and cloud computing
• FD&C Act section 524B, 21 U.S.C. 360n-2: cybersecurity requirements for cyber devices