HealthOps

HealthOps, as this Atlas uses the word, is healthcare operations management: the work of getting the right patient to the right clinician, bed, test or video call at the right time, with the right information, safely and within the law. It spans flow and capacity, scheduling, electronic health record (EHR) and interface operations, revenue-cycle basics, telehealth, and quality and safety reporting.

The label is rare and has no agreed definition (see the naming story); the practice is old and well studied.

For operations managers, informatics and integration staff, clinical leaders, health-tech engineers and curious beginners. Sources last verified 2026-10-23.

Four different things use the name; none is a field with a body, a standard or a certification:

1. A company philosophy. HealthAxis, a US health-plan administration vendor, called “HealthOps” its philosophy for combining services, technology and data integration (an excerpt of its chief executive’s post survives on an archived tag page).^[1]
2. DevOps for connected healthcare. A 2019 guest post on TechTarget’s IoT Agenda blog, “Introducing HealthOps: When DevOps meets connected healthcare”, argued that healthcare would adopt “DevOps-based approaches” and warned of the security risks of more connected devices.^[2] Only an archived copy survives.
3. A software project. A June 2026 paper from an engineering college names a hospital-management system “HealthOps”.^[3]
4. A legal term that sounds similar. The US HIPAA Privacy Rule defines “health care operations” as activities of a covered entity “to the extent that the activities are related to covered functions”, such as quality assessment, underwriting, auditing and business planning.^[4] It governs permitted uses of patient data, not hospital operations.

The work behind the name is established as healthcare operations management, with a College of Healthcare Operations Management in the Production and Operations Management Society^[5] and Institute for Healthcare Improvement (IHI) guidance on hospital-wide flow.^[6] This page uses “HealthOps” as a handle for that practice and claims no more for the label.

• Not HIPAA “health care operations” (the legal category above): in a contract, ask a privacy lawyer.
• Not DevOps with a stethoscope. Software delivery belongs to DevOps; beds, staff and discharge are not deployment problems.
• Not clinical decision-making. Operations decides where and when; clinicians decide what care.
• Not the whole privacy programme (PrivacyOps); this page keeps health-specific obligations.
• Not the laboratory (LabOps) or genomic pipelines (BioOps).

Without deliberate operations, hospitals fail predictably. Elective surgery booked unevenly through the week fills mid-week wards; IHI says such uneven scheduling “is often a significant contributor” to problems such as emergency department (ED) boarding.^[7] Clinic slots go unused: a review of 105 studies put the average no-show rate “of the order of 23%”.^[8] Data feeds stop unnoticed, so bed boards show yesterday’s patients; when the EHR or a key supplier goes down, staff improvise. The cost is harm, waits and money.

Mental model: a network of queues with a safety brake. Patients arrive (some scheduled, many not), wait for resources and move on. As utilisation approaches 100%, waits grow sharply, so slack is a safety feature, not waste. The brake: operations never trades safety for throughput, and every change is checked for new ways to harm.

Three sourced roots:

• Operations research. Little’s 1961 result L = λW (average number in a system = arrival rate × average time in it) became “widely known as ‘Little’s Law’”.^[9] A 1999 BMJ simulation of a hypothetical English hospital found bed-shortage risks “discernible” above about 85% average occupancy, with regular shortages and periodic crises at 90% or more.^[10]
• Quality improvement. IHI’s hospital-wide flow work (2017; second edition 2020) framed flow as a system problem with three approaches: shape demand, match capacity to demand, redesign the system.^[6]
• Interoperability. HL7 v2 was first released in October 1987 and is, in HL7’s words, “one of the most widely implemented standards for healthcare information in the world”.^[11] FHIR’s first normative content arrived in R4 (December 2018; the 4.0.1 technical correction of October 2019 is the version in use),^[12] and later US rules made FHIR APIs obligations (see the regulatory map).

flowchart LR
  H["HealthOps<br>flow, capacity, health data exchange"]
  PRIV["PrivacyOps<br>privacy programme"]
  LAB["LabOps<br>samples, LIMS"]
  BIO["BioOps<br>genomic pipelines"]
  INT["IntegrationOps<br>integration patterns"]
  INC["IncidentOps<br>incident command"]
  DR["DisasterRecoveryOps<br>restore and failover"]
  FIN["FinTechOps<br>payment rails"]
  H -->|"health-specific rules only"| PRIV
  H -->|"orders out, results in"| LAB
  LAB -->|"sequencing data"| BIO
  H -->|"engine and API practice"| INT
  H -->|"major outages"| INC
  H -->|"EHR recovery targets"| DR
  H -->|"patient payments"| FIN
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class H core
  class PRIV,LAB,BIO,INT,INC,DR,FIN neutral

No official HealthOps charter exists. The following is this Atlas’s proposal.

1. Safety first, then flow, then cost. Assess every process or system change for patient harm before judging speed or money.
2. Manage the system, not the ward. A full ED is often a discharge or theatre-scheduling problem elsewhere.^[6]
3. Plan for variation; keep slack. Peaks, not averages, cause harm. Smooth what you control (elective work) and keep capacity for what you do not (emergencies).^[7][10]
4. Data that moves is part of care. Admission messages, results and discharge notifications are care events; monitor them.
5. Rehearse failure. Downtime is certain over time; unpractised procedures fail.^[13]
6. Measure with variation in mind. Use run charts, not red/amber/green snapshots that react to noise.^[14]
7. Respect the patient’s data and time. Use the minimum data needed for operations, and treat a patient’s wasted trip as a cost.

Non-goals: clinical decisions, maximising occupancy, replacing local law.

Titles vary; the roles below are functions, and a small clinic may combine many in one person.

A revenue-cycle lead owns claims and denials (A/R) and joins downtime drills: claims stop when systems stop.

R = responsible, A = accountable, C = consulted, I = informed. In England the clinical-safety role for health IT is the clinical safety officer; one trust’s procedure brings that team into the review of new digital systems before deployment.^[15]

The patient journey: referral or arrival → registration → triage or booking → treatment → admission → transfers → discharge planning → discharge and hand-over to primary or community care → follow-up. Each arrow is a queue, a hand-off and usually a data event.

The system lifecycle: Day 0 plans capacity and assesses the clinical safety of new systems; Day 1 goes live with rehearsed cut-over and downtime plans; Day 2 runs daily flow, monitors interfaces and learns from incidents.

A workable cadence, adapted from IHI’s hospital-wide flow huddles, real-time demand and capacity management, and census levels coded green, yellow or red with roles and lines of authority:^[7]

Escalation must name decision rights: who may cancel electives, open beds, divert ambulances (where allowed) or invoke downtime, at which level.

A generic, vendor-neutral pattern of core systems and the messages between them; real estates add dozens of departmental systems.

flowchart TB
  PAS["PAS / EHR<br>ADT, orders"]
  SCH["Scheduling"]
  LIS["Lab and<br>imaging"]
  ENG["Interface engine<br>HL7 v2, MLLP"]
  API["FHIR API<br>SMART auth"]
  DT["Downtime<br>kit"]
  BED["Bed board"]
  NOT["Event<br>notifications"]
  RCM["Revenue<br>cycle"]
  QS["Quality and<br>safety reports"]
  MON["Silence<br>monitoring"]
  PAS --> ENG
  SCH --> ENG
  LIS --> ENG
  PAS --> API
  PAS -.-> DT
  ENG --> BED
  ENG --> NOT
  ENG --> RCM
  MON -.->|watches| ENG
  API --> QS
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class ENG,API core
  class MON,DT risk
  class PAS,SCH,LIS,BED,NOT,RCM,QS neutral

In the US, a Medicare-participating hospital whose system supports the required content standard must use it to send event notifications (ED registration, inpatient admission, discharge or transfer) and make a reasonable effort to reach post-acute providers and the patient’s primary care practitioner,^[16] so the “notifications” box is a regulatory duty there.

The trigger is a decision to admit in the ED; the exception path is what happens when there is no bed. Event codes follow HL7 v2.5.1, where an ED visit typically starts as a non-admitted registration (A04) and A06 “changes a patient’s status from non-admitted to admitted”; some systems open a new inpatient visit with A01 instead.^[17]

flowchart TB
  R["ED arrival registered<br>ADT A04"] --> A["Decision to admit<br>ADT A06 (or A01)"]
  A --> B["Bed request with<br>specialty and acuity"]
  B --> C{"Suitable bed<br>ready now?"}
  C -->|"yes"| D["Transfer to ward<br>ADT A02 sent"]
  D --> E["Expected discharge date<br>set on first round"]
  E --> F["Discharge, ADT A03,<br>notification sent"]
  F --> G["Bed cleaned and<br>marked ready"]
  G -->|"next request"| C
  C -->|"no"| X["Patient boards in ED<br>clock keeps running"]
  X --> Y{"Escalation level<br>reached?"}
  Y -->|"yellow"| Y1["Pull forward discharges,<br>discharge lounge"]
  Y -->|"red"| Y2["Named executive decides:<br>open capacity, defer electives"]
  Y1 --> C
  Y2 --> C
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class R,A,B,D,E,F,G core
  class X,Y1,Y2 risk
  class C,Y decision

Three details make or break it: the bed is not free when the patient leaves (cleaning and the “bed ready” event take time; measure them); expected discharge dates set early show tomorrow’s capacity today; and escalation actions are agreed in advance with an owner, so the red-level conversation is about execution, not authority.

1. Forecast arrivals by hour, weekday and season for each entry route; IHI recommends forecasting seasonal variation to plan staffing and close or repurpose units in quiet periods.^[7]
2. Smooth what you control: spread elective admissions needing beds across the week.^[7]
3. Run a short flow meeting at fixed times from live ADT data, not phoned-in numbers.
4. Set expected discharge dates on the first ward round; review blockers daily.
5. Define escalation levels with numeric triggers and pre-agreed actions.
6. Review weekly with time-series charts and adjust templates, not just today’s beds.

Acceptance: every level has triggers, actions, an owner and a stand-down rule; the board shows data age. Contingency: if live data fails, run a structured phone round with the same template.

In a 2013 Cochrane review of eight trials, text reminders improved attendance over no reminder (risk ratio 1.14, moderate-quality evidence), worked about as well as phone calls and cost less in the two studies that measured cost; overall evidence was low to moderate.^[18] Long lead times and previous no-shows are the predictors most often reported.^[8]

1. Measure the no-show rate correctly by clinic, lead time and patient group (see metrics).
2. Remind through the channel patients use, with one-step cancel or rebook: a cancelled slot can be reused, a no-show cannot.
3. Shorten lead times where possible and keep a short-notice list for freed slots.
4. Ask repeat non-attenders why before penalising (see the anti-patterns).
5. Treat overbooking as a last resort with limits (see the judgement call).

1. Catalogue every interface (template in Artefact 2).
2. Monitor silence, not just errors: a daytime admissions channel silent for ten minutes is an incident. Alert on queue depth and oldest-message age too.
3. Check acknowledgements. In HL7 v2 original mode, AA means accepted, AE an application error (details in ERR segments) and AR a rejection for reasons unrelated to content, which may succeed later.^[19] Count AE and AR per channel.

sequenceDiagram
  participant PAS as PAS / EHR
  participant ENG as Interface engine
  participant FHIR as FHIR server
  participant BED as Bed board
  PAS->>ENG: ADT^A01 over MLLP
  ENG-->>PAS: ACK with MSA AA
  ENG->>FHIR: create or update Encounter
  FHIR-->>ENG: 200 or 201, or OperationOutcome
  FHIR->>BED: subscription notification
  Note over ENG: on AE, AR or timeout,<br>queue, retry, alert

4. Version and test mappings like code; a changed source code table breaks downstream logic silently. Test the cancel events too: A11 (cancel admit), A12 (cancel transfer) and A13 (cancel discharge) must reverse bed state.^[17] A bed board that ignores an A13 shows an occupied bed as free.
5. Write a runbook per critical channel, including ordered replay (see the worked runbook).

The Healthcare Financial Management Association (HFMA) describes revenue cycle management as everything “from patient registration to verification of benefits to care delivery, claim submission and reimbursement”.^[20] Under US HIPAA, professional, institutional and dental claims travel as ASC X12 837 version 005010, which continues; retail pharmacy claims move from NCPDP D.0 to NCPDP F6, with both allowed from 2027-08-14 and only F6 from 2028-04-14 (as of October 2026).^[21] Operations owns the front end, where denials caused by wrong patient or coverage data are prevented:

1. Check eligibility at booking and again before the visit (eligibility is its own standard transaction).^[22]
2. Audit a weekly sample of registrations for patient and coverage errors.
3. Feed denial reasons back to registration. HFMA’s initial denial rate counts all first denials, these included (metrics).^[23]

Payment models differ elsewhere; accurate activity data at the point of care matters everywhere.

Telehealth adds new failure modes (patient cannot connect, interpreter missing). Run it like a clinic: templates, reminders with tested links, a phone fallback, identity checks at the start, and documentation in the same record. Reimbursement rules change often: in the US, Medicare’s telehealth waivers lapsed after 2026-01-30 and were extended through 2027-12-31 by the Consolidated Appropriations Act, 2026, retroactively, as reported in February 2026.^[24]

The US SAFER Contingency Planning guide (2025 edition) is a practical checklist whatever your country. Its recommended practices include paper forms that replace key EHR functions, data and configuration backups that are regularly tested, patient-identification procedures before, during and after downtime, staff trained and tested on downtime procedures, a downtime communication method “independent of the computing infrastructure that supports the EHR”, orderly stop and restart of interfaces, and an in-depth review of any unexpected downtime longer than 24 hours.^[13] US hospitals must also exercise their emergency plan at least twice a year under Medicare conditions of participation.^[25] See the worked runbook; recovery engineering belongs to DisasterRecoveryOps.

In England, DCB0160 applies to “health organisations responsible for ensuring clinical safety in the deployment, use, maintenance or decommissioning” of IT systems.^[34] NHS England consulted on revised DCB0129 and DCB0160 from 29 June to 11 September 2026, citing advances such as “artificial intelligence supporting clinical decisions”; revised standards may follow (as of October 2026), so check the current version before relying on it.^[35]

Breach notification, consent and cross-border transfers belong to PrivacyOps; evidence management to ComplianceOps.

Lock-in watch: the EHR is the stickiest decision; interface mappings are the second. Keep mapping specifications and interface catalogues in your own repository, not only inside a vendor tool.

Automation already routes messages, sends reminders and checks eligibility. The useful AI questions are narrower than the marketing:

• Forecasting demand is a common use; IHI recommends analytics combined with clinicians’ knowledge.^[7] Beat a simple seasonal baseline before trusting a complex model.
• No-show prediction can target reminders and support, or overbook particular patients; the second can widen inequity, because no-shows are associated with lower socio-economic status and distance.^[8] Decide the use before building the model.
• Software that informs clinical decisions may be a regulated device; US FDA guidance (final, January 2026) clarifies which clinical decision support falls outside the device definition.^[51] In England, deployment falls under DCB0160, whose 2026 review names AI that supports clinical decisions.^[35]
• Generative AI for letters and summaries needs the same hazard analysis, human review and data-protection checks as other health IT; model lifecycles belong to MLOps and LLMOps.

Three artefacts carry much of the operating model; set every number from your own data.

Artefact 1: escalation levels.

# escalation-levels.yaml - illustrative values, set triggers from local data
trigger_rule: any  # one met trigger raises the level
levels:
  green:
    triggers: {adult_beds_free_min: 15, ed_admitted_waiting_max: 3}
    actions: [routine flow meetings, discharge lounge open from 10:00]
    decision_owner: site manager
  yellow:
    triggers: {adult_beds_free_below: 15, ed_admitted_waiting_above: 3}
    actions: [extra flow meeting, senior review of all expected discharges today]
    decision_owner: site manager with on-call manager informed
  red:
    triggers: {adult_beds_free_below: 5, ed_longest_wait_hours_above: 8}
    actions: [executive decision on extra capacity or deferring elective work,
              notify patient safety lead, record decisions and times]
    decision_owner: on-call executive
stand_down: two consecutive flow meetings at which no trigger of the current level is met
review: monthly, against boarding hours and incidents at each level

Artefact 2: interface catalogue entry.

# interface-catalogue entry - one per critical channel
id: ADT-PAS-TO-BEDBOARD
source: PAS
destination: bed board
messages: [ADT^A01, ADT^A02, ADT^A03, ADT^A04, ADT^A06, ADT^A08]
cancel_events: [ADT^A11, ADT^A12, ADT^A13]  # must reverse bed state
business_owner: site management
technical_owner: integration team
clinical_impact_if_stopped: bed board shows wrong census; risk of wrong bed allocation
silence_alert_minutes: {day: 10, night: 30}
oldest_queued_message_alert_minutes: 5
runbook: runbooks/adt-pas-to-bedboard.md
replay_rule: in original order, after source confirms complete, with duplicate check

Artefact 3: hazard-log entry (format inspired by the clinical risk management process in DCB0160 and one NHS trust’s procedure, which uses a hazard workshop, a hazard log and a clinical safety case before deployment).^[34][15]

hazard_id: HZ-BED-007
system: bed board v3 go-live
hazard: bed board shows a bed as free while the patient is still in it
cause: discharge (A03) sent at decision time, not at physical departure
effect: second patient sent to an occupied bed; delay; infection-control risk
existing_controls: [ward confirms bed ready before acceptance]
added_controls: [separate "bed ready" status set by ward, training, go-live audit]
severity: moderate
likelihood: medium
residual_risk: acceptable after added controls, per clinical safety review
owner: clinical safety lead
review_trigger: any incident involving bed allocation, or a change to ADT mappings

Example status: all three YAML blocks syntax-checked by the Atlas validator; illustrative content, not taken from a real organisation.

All labs use synthetic data. Never load real patient data into a lab or a public test server.

Objective: see why average occupancy hides crowding; check Little’s Law. Prerequisites: Python 3.8+; no cost or risk; 30 minutes.

1. Save the data below as stays.csv and the script as flow.py.
2. Run python3 flow.py stays.csv.
3. Change BEDS = 10 to BEDS = 8 and run again.

stay_id,admit,discharge
S01,2026-03-01T08:00,2026-03-04T11:00
S02,2026-03-01T14:00,2026-03-03T10:00
S03,2026-03-01T22:00,2026-03-06T12:00
S04,2026-03-02T09:00,2026-03-05T16:00
S05,2026-03-02T11:00,2026-03-03T15:00
S06,2026-03-02T19:00,2026-03-08T00:00
S07,2026-03-03T07:00,2026-03-04T09:00
S08,2026-03-03T13:00,2026-03-07T10:00
S09,2026-03-03T23:00,2026-03-05T12:00
S10,2026-03-04T10:00,2026-03-06T17:00
S11,2026-03-04T15:00,2026-03-08T00:00
S12,2026-03-04T21:00,2026-03-07T14:00
S13,2026-03-05T08:00,2026-03-06T10:00
S14,2026-03-05T12:00,2026-03-08T00:00
S15,2026-03-05T18:00,2026-03-07T09:00
S16,2026-03-06T09:00,2026-03-08T00:00
S17,2026-03-06T16:00,2026-03-07T18:00
S18,2026-03-07T08:00,2026-03-08T00:00

Example status: executed with Python 3.8.10 on 2026-10-23; output below is the actual output.

"""Flow arithmetic for one ward over a fixed window (standard library only)."""
import csv
import sys
from datetime import datetime, timedelta

BEDS = 10
START = datetime(2026, 3, 1)
END = datetime(2026, 3, 8)  # exclusive: 7 days = 168 hours

stays = []
with open(sys.argv[1], newline="") as f:
    for row in csv.DictReader(f):
        a = max(datetime.fromisoformat(row["admit"]), START)
        d = min(datetime.fromisoformat(row["discharge"]), END)
        stays.append((row["stay_id"], a, d))

window_h = (END - START).total_seconds() / 3600
occupied_h = sum((d - a).total_seconds() / 3600 for _, a, d in stays)
occupancy = occupied_h / (BEDS * window_h)

# Census at every hour; peak and hours at or above 85 % / full.
census, t = [], START
while t < END:
    census.append(sum(1 for _, a, d in stays if a <= t < d))
    t += timedelta(hours=1)
peak = max(census)
full_h = sum(1 for c in census if c >= BEDS)
over85_h = sum(1 for c in census if c / BEDS >= 0.85)

# Midnight census (the traditional count) for comparison.
midnights = [sum(1 for _, a, d in stays if a <= START + timedelta(days=i) < d)
             for i in range(1, 7)]

# Little's Law: L = lambda * W, using completed stays only for W.
done = [(a, d) for _, a, d in stays if d < END]
w_days = sum((d - a).total_seconds() for a, d in done) / 86400 / len(done)
lam = len(stays) / 7  # admissions per day in the window
print(f"stays={len(stays)} completed={len(done)} beds={BEDS}")
print(f"occupancy (bed-hours) = {occupancy:.1%}")
print(f"mean hourly census L = {sum(census) / len(census):.2f}")
print(f"midnight census = {midnights} -> mean {sum(midnights) / len(midnights):.2f}")
print(f"peak census = {peak}; hours full = {full_h}; hours >= 85% = {over85_h}")
print(f"admissions/day lambda = {lam:.2f}; mean LOS W (completed) = {w_days:.2f} d")
print(f"Little's Law lambda*W = {lam * w_days:.2f} beds (compare with L)")

Expected output (step 2):

stays=18 completed=13 beds=10
occupancy (bed-hours) = 61.0%
mean hourly census L = 6.10
midnight census = [3, 6, 7, 8, 9, 8] -> mean 6.83
peak census = 10; hours full = 1; hours >= 85% = 28
admissions/day lambda = 2.57; mean LOS W (completed) = 2.25 d
Little's Law lambda*W = 5.79 beds (compare with L)

In step 3 occupancy becomes 76.2%, with 61 hours full, 87 hours at or above 85% and a peak of 10 patients for 8 beds. The census is demand, not physical beds: above 8, extra patients would board in the ED or outlie. Validation: at 61% average the ward still spent 28 hours at or above 85%; the midnight census (6.83 on average) misses daytime peaks and same-day stays; and λW = 5.79 undershoots the observed 6.10 because five long stays had not finished, so W from completed stays is biased low. Use long windows before trusting Little’s Law. Troubleshooting: Invalid isoformat string usually means a space instead of T. Teardown: delete the files.

Objective: a no-show rate with the correct denominator from FHIR R4 Appointment resources, by lead time. Prerequisites: Python 3.8+; no cost or risk.

1. Save and run make_bundle.py to write appointments.json (14 synthetic appointments).
2. Save noshow.py and run python3 noshow.py appointments.json.

Example status: both scripts executed with Python 3.8.10 on 2026-10-23.

"""Write a small synthetic FHIR R4 Appointment searchset Bundle (no real patients)."""
import json

ROWS = [  # id, status, created (booking date), start
    ("a01", "fulfilled", "2026-02-27", "2026-03-02T09:00:00Z"),
    ("a02", "noshow", "2026-01-20", "2026-03-02T09:20:00Z"),
    ("a03", "fulfilled", "2026-02-25", "2026-03-02T09:40:00Z"),
    ("a04", "cancelled", "2026-02-10", "2026-03-02T10:00:00Z"),
    ("a05", "fulfilled", "2026-01-28", "2026-03-02T10:20:00Z"),
    ("a06", "noshow", "2026-01-15", "2026-03-03T09:00:00Z"),
    ("a07", "fulfilled", "2026-03-01", "2026-03-03T09:20:00Z"),
    ("a08", "noshow", "2026-02-01", "2026-03-03T09:40:00Z"),
    ("a09", "fulfilled", "2026-02-20", "2026-03-03T10:00:00Z"),
    ("a10", "fulfilled", "2026-02-02", "2026-03-03T10:20:00Z"),
    ("a11", "noshow", "2026-02-28", "2026-03-04T09:00:00Z"),
    ("a12", "fulfilled", "2026-01-30", "2026-03-04T09:20:00Z"),
    ("a13", "booked", "2026-03-01", "2026-03-20T09:00:00Z"),
    ("a14", "fulfilled", "2026-02-26", "2026-03-04T09:40:00Z"),
]
entries = [{"resource": {
    "resourceType": "Appointment", "id": i, "status": s, "created": c, "start": st,
    "participant": [{"actor": {"reference": f"Patient/synthetic-{i}"},
                     "status": "accepted"}]}} for i, s, c, st in ROWS]
bundle = {"resourceType": "Bundle", "type": "searchset", "total": len(entries),
          "entry": entries}
with open("appointments.json", "w") as f:
    json.dump(bundle, f, indent=2)
print(f"wrote {len(entries)} appointments")

"""No-show rate by booking lead time from a FHIR R4 Appointment searchset Bundle."""
import json
import sys
from datetime import date

bundle = json.load(open(sys.argv[1]))
counts = {"lead < 14 d": [0, 0], "lead >= 14 d": [0, 0], "no created date": [0, 0]}
skipped = {}
for entry in bundle.get("entry", []):
    appt = entry["resource"]
    status = appt.get("status")
    if status not in ("fulfilled", "noshow"):
        # cancelled, booked, entered-in-error ... are not attendance outcomes
        skipped[status] = skipped.get(status, 0) + 1
        continue
    if "created" in appt and "start" in appt:
        start = date.fromisoformat(appt["start"][:10])
        lead = (start - date.fromisoformat(appt["created"][:10])).days
        band = "lead < 14 d" if lead < 14 else "lead >= 14 d"
    else:
        band = "no created date"
    counts[band][1] += 1
    counts[band][0] += status == "noshow"

ns = sum(c[0] for c in counts.values())
n = sum(c[1] for c in counts.values())
print(f"no-show rate = {ns}/{n} = {ns / n:.1%}" if n else "no attendance outcomes")
print(f"not counted: {skipped}")
for band, (b_ns, b_n) in counts.items():
    if b_n:
        print(f"  {band}: {b_ns}/{b_n} = {b_ns / b_n:.1%}")

Expected output:

no-show rate = 4/12 = 33.3%
not counted: {'cancelled': 1, 'booked': 1}
  lead < 14 d: 1/6 = 16.7%
  lead >= 14 d: 3/6 = 50.0%

Validation: the denominator is attended plus no-show; cancelled and future (booked) appointments are excluded, consistent with FHIR’s noshow meaning participants who “have not/did not appear”.^[52] Counting cancellations as no-shows, or dividing by all bookings, distorts the rate. The toy lead-time split mirrors the review’s pattern.^[8] Troubleshooting: KeyError: 'resource' means the file is not a searchset Bundle. Teardown: delete the files.

Objective: map a synthetic ADT^A01 message to a FHIR R4 Encounter and build an acknowledgement. Prerequisites: Python 3.8+; field positions follow HL7 v2.5.1 (A01 is “Admit/Visit Notification”).^[17]

1. Save the message as adt_a01.hl7 (one segment per line; live MLLP feeds use carriage returns, which the script also accepts).
2. Save the script as adt2fhir.py and run python3 adt2fhir.py adt_a01.hl7.

MSH|^~\&|ADT|GENHOSP|BEDBOARD|GENHOSP|202603020815||ADT^A01^ADT_A01|MSG00042|P|2.5.1
EVN|A01|202603020814
PID|1||MRN123456^^^GENHOSP^MR||TESTPATIENT^ALEX||19800101|U
PV1|1|I|WARD7^12^B^GENHOSP|||||||MED|||||||||V0001^^^GENHOSP^VN|||||||||||||||||||||||||202603020800

Example status: executed with Python 3.8.10 on 2026-10-23; not connected to any real interface engine.

"""Parse one HL7 v2 ADT^A01 message, map it to a FHIR R4 Encounter, build an ACK."""
import json
import sys
from datetime import datetime, timedelta, timezone

# v2 times here carry no offset: they are site-local. Use the offset in force on that
# date (daylight saving time changes it); +00:00 is right for London on 2 March.
SITE_OFFSET = timezone(timedelta(hours=0))

raw = open(sys.argv[1], newline="").read()
segs = {}
for line in filter(None, raw.replace("\n", "\r").split("\r")):
    fields = line.split("|")
    segs[fields[0]] = fields

msh, pid, pv1 = segs["MSH"], segs["PID"], segs["PV1"]
# MSH-1 is the field separator itself, so MSH field n is at list index n-1.
msg_type, control_id = msh[8], msh[9]
if not msg_type.startswith("ADT^A01"):
    sys.exit(f"unsupported message type {msg_type}")
mrn = pid[3].split("^")[0]
unit, room, bed = pv1[3].split("^")[:3]
visit = pv1[19].split("^")[0]
local = datetime.strptime(pv1[44], "%Y%m%d%H%M").replace(tzinfo=SITE_OFFSET)
admit = local.isoformat()

encounter = {
    "resourceType": "Encounter",
    "identifier": [{"system": "urn:example:visit-number", "value": visit}],
    "status": "in-progress",
    "class": {"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
              "code": "IMP", "display": "inpatient encounter"},
    "subject": {"identifier": {"system": "urn:example:mrn", "value": mrn}},
    "period": {"start": admit},
    "location": [{"location": {"display": f"{unit} room {room} bed {bed}"}}],
}
print(json.dumps(encounter, indent=2))

ack = "\r".join([
    "|".join(["MSH", msh[1], msh[4], msh[5], msh[2], msh[3],
              datetime.now().strftime("%Y%m%d%H%M"), "", "ACK^A01^ACK",
              "ACK" + control_id, "P", "2.5.1"]),
    f"MSA|AA|{control_id}",
])
print(ack.replace("\r", "\n"))

Expected output: an Encounter with "status": "in-progress", class IMP (“inpatient encounter”),^[53] "start": "2026-03-02T08:00:00+00:00" and location WARD7 room 12 bed B, then an ACK with sender and receiver swapped, ending MSA|AA|MSG00042. Validation: change the message type to ADT^A03^ADT_A03; the script must refuse it. Troubleshooting: an IndexError means a segment lost fields; real feeds need an interface engine, not a script. Teardown: delete the files. Lesson: v2 timestamps here carry no offset; assuming UTC would shift every admission by an hour in British summer time.

Objective: use FHIR REST capabilities, search and error handling.^[54] Prerequisites: curl, Python 3, internet. Risk: the HAPI FHIR public test server is open to everyone; never send real or realistic patient data; use only GET.

Example status: executed on 2026-10-23; the public server’s data changes constantly, so counts will differ.

BASE=https://hapi.fhir.org/baseR4
H="Accept: application/fhir+json"
curl -s -H "$H" "$BASE/metadata" | python3 -c 'import json,sys; d=json.load(sys.stdin);
print(d["resourceType"], d["fhirVersion"], d["software"]["name"])'
curl -s -H "$H" "$BASE/Appointment?status=noshow&_summary=count" \
  | python3 -c 'import json,sys; print(json.load(sys.stdin)["total"])'
curl -s -H "$H" -o public.json "$BASE/Appointment?status=fulfilled,noshow&_count=50"
python3 noshow.py public.json
curl -s -H "$H" -o /dev/null -w "%{http_code}\n" "$BASE/Appointment/does-not-exist-123"

Expected output (2026-10-23): CapabilityStatement 4.0.1 HAPI FHIR Server, a count (3 that day), a no-show rate on whatever public records exist (3/8, five lacking a created date), then 404. Validation: FHIR 4.0.1 reported; the missing resource returns 404 with an OperationOutcome. The script reads only the first page of the searchset (_count=50); for complete data, follow the Bundle’s link with relation next. Troubleshooting: timeouts happen; the public server has no service level. Teardown: delete public.json.

Objective: test whether a ward and the integration team can run four hours without the EHR and recover cleanly. Prerequisites: 90 minutes; a facilitator, ward manager, clinician, integration engineer and revenue-cycle colleague; the SAFER Contingency Planning guide.^[13] Status: paper exercise; not executed by the Atlas.

1. Inject (minute 0): “At 02:10 the EHR is unavailable for about four hours.” Who declares downtime, and how are staff told if email and chat run on the same network?
2. Inject (minute 20): a patient arrives; the wristband printer is down. Identify the patient on paper.
3. Inject (minute 40): how does a critical lab result reach the ward?
4. Inject (minute 60): systems return. In which order are interfaces restarted, who enters the paper records, and how are duplicates and wrong-patient entries prevented?
5. Debrief: list gaps with owners and dates; schedule a live drill for the worst gap.

Expected output: a gap list with owners. Validation: each SAFER practice marked met, partly met or not met. Troubleshooting: an argument about who decides is the first finding: decision rights are not written down. Teardown: file the notes for emergency-preparedness review.

Worked calculation (illustrative). A 30-bed ward admits 7.5 patients a day with an average stay of 3.6 days. Little’s Law gives average census L = λW = 7.5 × 3.6 = 27, so occupancy is 27 ÷ 30 = 90%, where the 1999 simulation found regular shortages.^[10] For 85% (25.5 patients) at the same admission rate, W must fall to 25.5 ÷ 7.5 = 3.4 days, about 5 hours less per patient (for example, earlier-in-the-day discharge). Or keep W and add beds: 27 ÷ 0.85 = 31.8, so two more staffed beds. The law describes long-run averages, not Tuesday’s peak; report hourly census beside it.

Targets and variation. Some targets are set by governments: NHS England asks every trust to maintain or improve to 82% of A&E patients within four hours by March 2027 (85% nationally in 2028/29) and aims for at least 92% of elective patients waiting 18 weeks or less by 2028/29, as summarised by NHS Providers (now NHS Alliance).^[62] Show every KPI as a time series; red, amber and green snapshots distract boards with random variation.^[14] Leading: discharges before noon, beds ready by 10:00, reminders delivered. Lagging: boarding, cancellations, no-shows, denials.

• Clinical safety of change. A new bed board, mapping or booking rule is a potential hazard: run a hazard workshop, hazard log, safety case, sign-off and review after change (required by DCB0129/DCB0160 in England; a good method anywhere).^[15][34]
• Incident learning. Report incidents, near misses and unsafe conditions in one system (AHRQ Common Formats in the US, PSIRF learning responses in England);^[37][38] a silent feed or a missed transfer belongs there too.
• Least privilege. Bed boards need location and status, rarely diagnoses; in the US minimum necessary applies to operations uses.^[39] Log who viewed what.
• Security of patient data is an operations control. Two of this page’s three sourced cases are ransomware that stopped care or payment. A US baseline is HHS’s voluntary Healthcare and Public Health Cybersecurity Performance Goals: ten essential goals, including mitigating known vulnerabilities, multifactor authentication, basic incident planning and vendor or supplier cybersecurity requirements, and ten enhanced goals such as asset inventory and network segmentation (as of October 2026).^[63] Operationally: critical suppliers (pathology, clearing houses) on the risk register with contract terms and a rehearsed manual pathway, and patching and MFA tracked like safety controls. Depth: SecOps, VulnerabilityOps.

Staff, beds and theatre time are the expensive resources; the cheapest capacity is that lost to waiting: a patient ready at 11:00 who leaves at 17:00 costs a bed for the evening’s admissions. Useful unit costs: per occupied bed-day, per cancelled operation, per recovered clinic slot. Do not chase 100% utilisation; slack absorbs emergencies.^[10] Fewer wasted trips (suitable telehealth, fewer no-shows) also cut patient travel; IT footprints belong to GreenOps.

Audit sampled escalation decisions against the written levels; compare the bed board with a monthly ward walk-round; test silence alerts on a non-production channel; close drill findings; review the hazard log after system-related incidents.

flowchart TB
  A["Alert: no ADT messages<br>for 10 minutes (day)"] --> B{"Source system<br>up?"}
  B -->|"no"| C["Invoke EHR downtime<br>procedure"]
  B -->|"yes"| D{"Engine queue<br>growing?"}
  D -->|"yes"| E["Destination down:<br>tell site manager, hold queue"]
  D -->|"no"| F["Source not sending:<br>check sender, network, TLS"]
  E --> G["Fix and restart<br>channel"]
  F --> G
  G --> H["Replay in order,<br>check duplicates"]
  H --> I["Reconcile census with<br>ward walk-round"]
  I --> J["Close, then review;<br>in-depth if over 24 h"]
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class A,C,E risk
  class B,D decision
  class F,G,H,I,J core

• “85% occupancy is the safe level” (or “full is efficient”). The 85% comes from one simulation of a hypothetical hospital,^[10] not a law; use your own peaks.
• The command centre as the answer. Screens without decision rights, clean data and changed processes are wallpaper; evidence on effect is limited.^[56]
• Penalising no-shows first. Punitive policies hit patients with the most barriers; fix reminders, lead times and rebooking first.
• Interfaces as IT plumbing. A stopped results feed is a clinical risk; give critical channels clinical owners.
• Downtime binders nobody has opened. Untested procedures fail at 02:10.
• “HealthOps” as a rebrand. Renaming a team changes nothing unless decision rights, data and cadence change.

Use deliberate healthcare operations (owners, cadence, data, runbooks) when you run beds, theatres or busy clinics, when staff rely on real-time data from several systems, when a supplier outage would stop care or payment, or when access targets are missed despite enough nominal capacity.

Do not build a separate function for a small single-site practice: one accountable lead, the supplier’s tools and a written downtime plan are enough. Do not start with a command centre or AI forecasting before data quality, escalation rules and discharge work.

flowchart TB
  A{"Do you deliver or<br>directly support care?"} -->|"no"| N["Use a neighbour page:<br>PrivacyOps, LabOps, RevOps"]
  A -->|"yes"| B{"Beds, theatres or<br>busy clinics?"}
  B -->|"no, small practice"| S["One accountable lead,<br>vendor tools, downtime plan"]
  B -->|"yes"| C{"Live data trusted<br>and monitored?"}
  C -->|"no"| D["Start with interface<br>catalogue and alerts"]
  C -->|"yes"| E{"Escalation levels with<br>owners exist?"}
  E -->|"no"| F["Write levels, actions,<br>decision rights"]
  E -->|"yes"| G["Improve flow: smoothing,<br>discharge, forecasting"]
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class A,B,C,E decision
  class D,F,G core
  class N,S neutral

This is this Atlas’s model, not an industry standard.

Operating readiness (new unit, service or system)

• Escalation levels with triggers, actions and decision owners, rehearsed
• Critical interfaces with clinical owner, silence alert and runbook
• Hazard log and safety sign-off for system changes
• Downtime kit current, with an off-network contact list
• Minimum data on operational screens; access logged

Weekly flow review

• Occupancy peaks and hours above threshold by ward
• Boarding median and 90th percentile; longest waits reviewed
• Discharges before noon; delayed-discharge bed-days
• Elective admissions by weekday against plan

Downtime and recovery

• Downtime declared by a named role; staff told via an independent channel
• Patient identification procedure in use
• Interfaces restarted in order; replay checked for duplicates
• Paper records entered and verified; review scheduled

Daily flow meeting (15 minutes)

FLOW MEETING  date ____  time ____  chair ____  escalation level now: G / Y / R
1. Data age on board: ____ min   (if > 15 min: switch to ward phone round)
2. ED: patients waiting for a bed ____  longest wait ____ h
3. Expected discharges today ____  before noon ____  blockers (owner, time):
   ____________________________________________________________
4. Elective admissions today ____  needing a bed ____  at risk ____
5. Staffing gaps by ward: ____________________________________
6. Decisions (who, what, by when): ____________________________
7. Level after meeting: G / Y / R   next meeting ____

No-show review (one clinic, monthly)

Clinic ____  month ____   booked ____  attended ____  no-shows ____  cancelled ____
No-show rate = no-shows / (attended + no-shows) = ____ %
By lead time:  < 14 d ____ %   >= 14 d ____ %
By patient group (local equity categories): ______________________
Reminder delivery rate ____ %   rebooked via reminder ____
Changes tried last month and effect: ______________________________
Decision: keep / change / stop  owner ____  review date ____

Interface runbook header

Channel ____  source ____  destination ____  clinical owner ____  on call ____
Normal volume (day / night) ____ / ____ msgs per hour   silence alert ____ min
If silent: 1) source up?  2) queue growing?  3) network / certificate / disk
Replay rule: original order, duplicate check, confirm with destination owner
Clinical workaround while down: ____________________________________________
Last tested ____  next review ____

Is HealthOps a job title to hire for? Rarely. Hire for the role (operations manager, integration engineer, revenue-cycle analyst).

Should we move from HL7 v2 to FHIR? Not wholesale: HL7 calls v2 “the workhorse of electronic data exchange in the clinical domain”;^[11] FHIR suits APIs, apps and regulated access, and many estates run both, so monitor both.

Can AI fix patient flow? Forecasts help when processes can act on them. Without escalation rules and discharge capacity, a better forecast only predicts the crisis better.

What changes outside the US? The flow and safety methods travel; the law does not. This page gives US, EU and England examples only.

Who owns a silent interface at 3 a.m.? The on-call integration engineer fixes it; the site manager owns the clinical workaround. Write both names into the runbook.

• Established now: FHIR R4 Patient Access APIs at Medicare Advantage, Medicaid, CHIP and QHP issuers on federally facilitated exchanges;^[64][29] SMART-authorised apps;^[32] queueing-informed capacity planning.
• Arriving: most CMS-0057-F payer API requirements from 2027-01-01;^[45] FHIR R6, still ballot and snapshot builds (the latest labelled “FHIR R6 Stable (Sept 2026)”) rather than a published release on 2026-10-23;^[28] the EU’s health data space applies in stages from 2029;^[47] the proposed HIPAA Security Rule changes are not final.^[43]
• Active research with thin evidence: command and control centres;^[56] machine-learning forecasts of admissions and discharges; digital twins of hospitals.
• Marketing to treat with care: claims that a platform “solves” flow; ask for evaluations with comparators.^[55]

Situation (illustrative). A respiratory clinic has a 25% no-show rate and a 20-week wait. The manager proposes overbooking: 25 bookings for each 20-slot session, with extra bookings placed on patients predicted to miss. The clinical lead proposes two-way text reminders with rebooking, outreach to repeat non-attenders, and shorter lead times.

Assumptions. Non-attendance is not random: it is associated with long lead times, previous no-shows, younger age, lower socio-economic status and distance from the clinic.^[8] Text reminders raise attendance modestly.^[18] Attendance is treated as independent with a 75% chance per booking (a simplification).

Option A: overbook. Expected attendance is 25 × 0.75 ≈ 19, which looks right. But binomial arithmetic gives about a 21% chance that 21 or more attend, so roughly one session in five overruns, while about 7% of sessions still lose 5 or more slots. Placing the extra bookings on “high-risk” patients means the most disadvantaged patients are the most likely to meet a crowded, rushed clinic.

Option B: fix the reasons. Slower, needs staff time, uncertain effect. But a cancelled-and-rebooked slot is reused, outreach can find fixable barriers (transport, times), and progress can be measured by patient group.

Decision. Run B for eight weeks in two clinics with run charts of no-shows by group. If the rate stays high, add modest, capped overbooking spread across the session, not targeted at individuals, and monitor overruns. Option A alone is attractive because the average works; it is wrong because the variance and the fairness do not. Uncertainty: local results may differ from published averages.

You can now explain the label’s ambiguity; calculate occupancy, peaks and Little’s Law; compute a no-show rate; monitor ADT feeds; design escalation levels; run a downtime tabletop; and place obligations in their jurisdiction.

1. A ward reports 82% average occupancy. Why might it still be unsafe?

2. Your clinic had 80 attended, 20 no-shows and 25 cancellations. What is the no-show rate?

3. The bed board has shown no admissions since 01:50 while the ED is busy. What do you check first, and what do you do clinically?

4. A medical unit admits 12 patients a day with an average stay of 5 days and has 66 staffed beds. What is average occupancy, and how many beds would bring it to 85%?

5. Why is a new bed-board status design a clinical-safety matter, not only an IT change?

“HealthOps” is a label looking for a meaning (the naming story). The work it points to is old, hard and important: hospitals are networks of queues in which delays become harm, run on data feeds that fail silently unless someone watches. The durable lessons are modest: manage the whole system, keep slack for peaks, treat data hand-offs as part of care, assess changes for harm and rehearse the day the systems stop. Ignore the label if you like; do not ignore the practice.

Every source was opened on 2026-10-23; dates are the source’s own. Claim-level support is in research/healthops-ledger.md.

Changelog. 2026-10-23, r0: first draft (research, ledger, outline, five labs with four executed, six diagrams); awaiting independent fact-check review. 2026-10-23, r1: revised after independent review r1 (HL7 v2.9.1; claims standards through 2028; ED event codes A04/A06 and cancel events; DCB0129/DCB0160 review of 2026; security baseline with the HPH CPGs; UK GDPR row; payer FHIR basis; durable Change Healthcare sources; wording and dating fixes; repeated HIPAA text cut). 2026-10-23, post-score polish: payer, ICO, HFMA and HL7 v2 wording; revenue-cycle steps; RACI clinic owner; two diagram edges.