# Healthcare operations: a business-to-code workbook

Build an internal administrative handoff for an entirely invented healthcare case. Start with the [visual Healthcare business 101 lesson and original video](/training/fde-101?topic=healthcare-business#concept), then use this workbook to turn the vocabulary into code evidence. The five-lesson Academy course adds worked examples, checks, deployment reasoning and a receiving-owner review.

You need Python 3.11 or newer, a terminal and a local folder. No accounts, API keys, model calls or patient records are needed. Estimated working time: 60–90 minutes, including a review rehearsal. This lab does not deliver clinical advice or determine coverage.

## 1. Translate the business language

An operations coordinator asks, “Is everything approved?” Ask what they need to do next. An active plan, an authorized service and a paid claim are different facts.

| Term | Plain meaning | Engineering consequence |
| --- | --- | --- |
| Eligibility | Coverage and benefit information for the relevant date | Keep the checked date, plan and source |
| Prior authorization | A plan decision about a specified request | Do not convert it into payment evidence |
| Claim | A request for payment | Submission is not payment |
| Adjudication | Processing the claim under applicable rules | Preserve the actual outcome and its scope |
| Remittance | Information about payer processing and payment | Reconcile to the correct claim and account |
| EOB | Explanation of benefits | It is not itself a bill or proof of patient payment |

Write a dictionary with five columns: term, staff definition, source, permitted statement and forbidden inference. Add provider and payer. Explain each term to someone who has never worked in healthcare before showing them an API.

## 2. Specify the smallest useful workflow

Use this scope: prepare a private authorization-status note from trusted source facts, then require an authorized review of that exact evidence. The output is an internal handoff, not a clinical decision or a patient-facing promise.

Draw caller → source adapter → meaning check → draft → review → note writer. For every arrow, name the allowed fields, the source of identity, the failure outcome and the receiving owner. Source unavailable means unresolved work; it does not mean coverage denied. An urgent clinical question must use the organization's established human pathway.

The synthetic source says `payer_authorization / approved`. A supported note is `authorization_recorded`. The proposal `payment_recorded` is unsupported. Even a person's accepted review cannot turn that source into payment evidence.

## 3. Run the proof lab

Start with the 101 lesson’s **Try it** stage: predict a handoff, inspect its actual saved notes, and compare the deliberately broken meaning check. The browser presents recorded observations from this same Python lab. Then reproduce them locally below.

The JSON `attempts` array preserves each delivery’s exact `input`, database `before`, `result`, and database `after`. For a retry, inspect attempt two rather than reusing the first delivery’s source. A review must match the exact case ID, proposed note, case revision and source revision. Add an unseen test that changes the case ID or reviewed note; verify `review_content_mismatch` and no new row.


Download the Python lab into an empty exercise folder. It uses only the standard library and creates a new in-memory SQLite database for every scenario. It does not modify your platform account or contact a healthcare system.

```bash
python3 fde-industry-proof-lab.py --domain healthcare --json > healthcare-guarded.json
python3 fde-industry-proof-lab.py --domain healthcare --omit-meaning-check --json > healthcare-broken.json
```

Before opening either report, predict these results:

| Scenario | Question to answer from the actual report |
| --- | --- |
| supported | Does the supported authorization note exist? |
| meaning-trap | Did payment wording escape from authorization evidence? |
| missing-evidence | Can a model summary replace the expected source? |
| stale-review | Does a changed source invalidate the earlier review? |
| wrong-workspace | Does another workspace's review authorize this case? |
| wrong-reviewer | Can the drafting agent accept its own work? |
| specialist-question | Does a clinical decision request stay in this flow? |
| identical-retry | Is there still exactly one saved note? |
| changed-retry | Is changed content rejected without overwriting the first note? |
| supported-final | Does an actual payment source allow payment wording? |

Compare `source`, `proposal`, `outcomes` and `saved_notes`. The broken run deliberately omits one rule. It should show a saved payment note in `meaning-trap`; the guarded run withholds it. Other guards remain active. The defect is a successful write with an unsupported business meaning.

For a compact view:

```bash
python3 fde-industry-proof-lab.py --domain healthcare
```

## 4. Change the code and test your understanding

In a copy of the file, add an `unknown-state` scenario using `replace(base, observed_state="unrecognized")`. Predict the result, run it and inspect the rows. Add a stale case-version scenario too. Keep unknown states unresolved until the contract is intentionally extended.

Then explain what must change before deploying an API around this code. The `Packet` fields are trusted fixtures in the lab. A real caller must not be able to submit its own reviewer role, workspace or accepted review. Those facts need server-side authorization and approved source adapters. The sequential lab does not prove behavior when a source changes between validation and writing; specify that concurrency test and its owning system.

Keep these artifacts: vocabulary dictionary, workflow contract, both original reports, your new-case output, the changed source and a short explanation of the missing deployment tests.

## 5. Rehearse the mentor and receiving-owner review

Use a peer or facilitator for this 20-minute review. If working alone, label the record self-rehearsed. The Academy lesson coach can help prepare explanations; this worksheet does not schedule a human mentor.

1. Explain the coordinator's question without acronyms.
2. Show the failed payment inference and the actual saved row.
3. Let the reviewer change a service date or remove evidence. Predict before running.
4. Explain the human route for a clinical question.
5. Name the next owner, stop condition and evidence needed for a synthetic integration run.

Record: reviewer or self-rehearsal, challenge, initial decision, revised decision, supporting evidence and unresolved work. Assess the explanation, boundary and proof, not confidence or presentation polish.

For the value case, use clearly hypothetical inputs. Potential saved minutes = eligible cases × avoided handling time − review time − exception handling. Include integration and operating costs separately. A lab result is not a measured patient or financial outcome.

## 6. Sources and next practice

Original LockedIn Labs instruction, checked against these primary references on 22 October 2026:

- [HealthCare.gov: preauthorization](https://www.healthcare.gov/glossary/preauthorization/).
- [HealthCare.gov: claim](https://www.healthcare.gov/glossary/claim/).
- [CMS: explanation of benefits](https://www.cms.gov/initiatives/your-patient-rights/medical-bill-rights/get-help/guides-resources/read-explanation-benefits).
- [HL7 FHIR R4: CoverageEligibilityResponse](https://hl7.org/fhir/R4/coverageeligibilityresponse.html). Confirm the actual integration's version and profile.
- [HHS: minimum necessary standard and exceptions](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html). The organization's privacy owner must determine the applicable data contract; replacing names alone does not establish de-identification.

Next, read and run [the FHIR eligibility interpretation lab](/training/guides/healthcare-eligibility) to match the actual response fields before drafting a handoff.

Continue with [the protected healthcare course](/app/academy?course=healthcare-operations&lesson=business-language&view=focus), or compare how the same engineering discipline changes in [financial-services operations](/training/guides/financial-services-operations).