Rescuing a HealthTech Codebase: The Safe First Week

Rescuing a HealthTech codebase follows the same order as any rescue, with patient data raising the stakes: first recover access to accounts you own; then confirm patient data is in a covered cloud; then audit the critical and access-control paths and rank the risks; then pin current behaviour with tests; and only then change code. Changing anything before you understand the access rules turns a rescue into a leak.

This is general engineering information, not compliance advice; keep production and patient data in your own covered cloud and confirm obligations with your adviser. If you would rather have the rescue run for you, see how RAITHub would fix this below.

What do I do in the first 48 hours?

Secure control and secure the data, in that order, before touching code. If the previous developer still holds the keys, nothing else is safe. The access-recovery steps are the same as any takeover, which the code rescue playbook sets out.

• Move the repository, hosting, domain and database to accounts you own, and rotate every credential the old developer could know.
• Confirm where patient data lives. It should be in a covered cloud account you control, not a personal account, a shared drive or a developer's laptop.
• Check backups exist and restore. A rescue with no working backup is one bad migration from disaster.
• Freeze deploys until you understand what each one does. The urge to "just fix the one thing" is how a leak ships.
• Write down what you do not know yet, especially who can see patient data today.

What should the first-week audit cover?

Audit the paths that lose money, lose data or leak records, and rank every finding by business and patient risk. In health, access control is first, because one bug there can expose many records. The full handover checklist is in the software handover checklist; the health-specific additions are below.

Area	What to check	Why it is first
Access control	Can one user reach another patient's record via the API?	A single bug can expose many records
Data location	Is patient data in a covered cloud you control?	Everything else depends on it
Secrets	Any keys in client code, the repo or logs?	An exposed key is a leak you cannot see
Audit log	Is access recorded, and is the log append-only?	You must be able to answer "who saw what"
Backups and migrations	Do backups restore? Are migrations reversible?	A rescue often starts with a near-miss here

How do I change code without breaking it further?

Pin current behaviour before you touch it. Characterisation tests capture what the system does today, so a fix does not silently change something you did not understand. Then make the smallest change that removes the top risk, behind a test and a branch preview.

// Pin the current behaviour before changing it: this test documents
// what the system does today, right or wrong, so a later fix is visible.
test('other clinician is refused another patient (current behaviour)', async () => {
  const other = await signIn('clinician-x@example.test')  // synthetic data
  const res = await fetch(`/api/patients/${patientB.id}/records`, {
    headers: { cookie: other.cookie },
  })
  // If this returns 200 today, that IS the bug: pin it, then fix it.
  expect([403, 404]).toContain(res.status)
})

Order the work by the risk register: fix the record-swap leak before you touch styling. The access-testing matrix is in preventing a patient-data leak, the pre-launch version in testing a HealthTech app before launch, and release safety in every release breaks something.

Buy, build or hire the rescue?

Option	Choose this when	Trade-off
Rebuild from scratch	The code is beyond repair and holds little real logic	Throws away fixes already made; slow, and risky with live patient data
Rescue it yourself	You have an engineer who can read unfamiliar code safely	Lowest cost; needs discipline not to deploy before understanding access
An on-call contractor	You have an active outage right now	Stops the bleeding; does not find the root cause
A code rescue engagement	You want access secured, risks ranked and the critical paths stabilised	An outside dependency; keep the tests and runbooks in your repository

Doing the first week yourself is realistic if you have the right engineer: plan 3 to 5 days for access recovery and the audit. The main risk of going alone is deploying a fix before you understand who can currently see patient data.

Why RAITHub for this

• Taking over someone else's code is a core service. RAITHub's code rescue secures access, writes tests around critical paths before changing them, and keeps the code that works. In a pre-launch review of its own site, tracing one admin action to the database exposed a data-wiping bug green tests had missed; the fix shipped with regression tests.
• Access and audit patterns from real systems. Sundor Skin runs 146 tables under row-level security with a hash-chained audit log and 530+ tests; RAITHub has also built a healthcare scheduling app for a client.
• Honest limits. This is stabilisation engineering, not a compliance exercise. RAITHub has not shipped a regulated health product and holds no SOC 2 or ISO 27001 certification. Patient data stays in your own covered cloud; development uses synthetic data.

When you don't need us

• The app is small and your own engineer can run the first week safely.
• You have an active outage: use an on-call contractor for the outage, then bring a rescue in for the root cause.
• You already have a stable codebase and only wanted the handover checklist.

How RAITHub would fix this

• Scope: a free 15-minute call on the symptoms, the stack and where patient data lives; you confirm you own or are authorised over the accounts.
• Secure: move repositories, hosting, domains and database to accounts you control, rotate credentials, and confirm backups restore.
• Diagnose: a 2-week diagnostic with a written risk register, access control and data location first, against synthetic data.
• Stabilise: fix the ranked risks inside an agreed fixed scope, each change behind a test and a branch preview.
• What you receive: an audit memo, regression tests gated in CI, runbooks and full IP; an NDA is standard. A rescue typically runs 2 to 4 weeks.

The diagnostic and the stabilisation are each fixed-price, quoted in writing. See code rescue, the HealthTech industry page, and the sibling guide on preventing a patient-data leak. To book it, ask for a code rescue.

General engineering information only; confirm compliance obligations with your adviser. Documentation checked on 11 October 2026.

Frequently asked questions

What is the first thing to do when I inherit a HealthTech codebase?

Recover access, then secure the data. Move the repository, hosting, domain and database into accounts you own, rotate every credential the old developer could know, and confirm patient data is in a covered cloud you control. Do this before touching code; if someone else holds the keys, nothing else is safe.

Why not just start fixing bugs right away?

Because in a health app you do not yet know who can currently see patient data. Changing code before you understand the access rules can turn a rescue into a leak. Audit access control first, pin current behaviour with tests, then fix the ranked risks in order.

Should I rewrite the app or rescue it?

Rescue it by default. A rewrite throws away bugs already fixed and is especially risky with live patient data. Rebuild only when the audit shows the code holds little real logic and keeps failing. Keep what works, replace only what the risk register proves is broken.

What are characterisation tests and why do they matter in a rescue?

They are tests that capture what the system does today, right or wrong, before you change it. In an unfamiliar codebase they stop a fix from silently breaking behaviour you did not understand, and they document the bug you are about to fix, such as a user who can currently reach another patient's record.

How long does a HealthTech rescue take?

The safe first week covers access recovery and the audit. A full rescue typically runs 2 to 4 weeks: a 2-week diagnostic ending in a written risk register and fixed-scope plan, then stabilisation of the critical and access-control paths. Larger platforms are split into phases.

Does RAITHub handle compliance during a rescue?

No. RAITHub does the stabilisation engineering and secures access, logs and data location; compliance is an obligation on your organisation, decided with a compliance adviser. RAITHub has not shipped a regulated health product and holds no SOC 2 or ISO 27001 certification. Pair the rescue with a compliance partner.