Casechek

Many of the devices used in surgery don’t belong to the hospital. Implants and the loaner trays of instruments that go with them are brought in by device vendors for a scheduled case, used, sterilised, sent back, and billed afterwards. That’s bill-only and consignment, and every step crosses between two organisations.

Casechek put it on one platform. A hospital schedules a case, vendors respond and deliver their trays, and every tray is labelled and scanned as it moves through the vendor’s warehouse and the hospital’s sterile processing, so both sides work from the same record.

• The original platform. The first API, from its first commit in 2014: surgeries, hospitals, vendors, users, notifications, sterilisation, printing, billing and the admin. I wrote the first commit of every core module and 4,501 of the repository’s 4,743 commits. It ran in production for ten years.
• Label printing. Every tray needs a label a scanner can read. I wrote the label engine: Zebra ZPL in seven label formats and IPL for Intermec printers, with text, barcodes and QR codes laid out per format.
• The hospital kiosk. I started the kiosk app in 2018, an Angular app that prints and scans at a hospital’s sterile processing, decontamination and vendor stations. In 2023 I separated the app from Electron so it runs in a browser, moved it from Angular 13 to 16, and wrote its hosting as a Terraform module, with CloudFront, S3 and WAF across four environments.
• Hospital integrations. HL7 integrations with hospital systems through a Qvera interface engine, so surgical cases scheduled in the hospital’s own systems arrived in Casechek without being retyped.
• The next platform. In 2023 and 2024 I prototyped Casechek 2.0 on NestJS and Postgres, with ECS in Terraform, an entity-relationship model and OpenAPI documentation.

Moving label printing while two generations of kiosk kept printing

In 2021 the way trays were tracked changed: a tray’s tracking label would be assigned at the moment its labels were printed, and that logic lived in the second API. But the print button in the Tray Management App called the original API.

The original API was also the hardest thing to change. It had no CI/CD: deploying meant building new EC2 instances by hand. And vendor warehouses still ran the older .NET kiosks, which printed from label files the original API rendered and uploaded to S3. The spec named the risk: those warehouses had to keep printing.

I wrote the technical specification for the cut-over, with its risks, its milestones and the acceptance steps for both kinds of kiosk. The plan kept every change in the original API small enough to deploy safely:

1. Keep the endpoint, forward the work. The app keeps calling the original API, which forwards the print to the second API and stops publishing print messages itself. The second API assigns the tracking labels and tells the newer kiosks to print.
2. Leave the warehouses alone, then bring them along. Warehouse prints first stayed on the old path. When they were forwarded too, the first release dropped the .NET files, and a hotfix two days later put them back for warehouses without the newer kiosks.
3. Both generations from one request. From April 2022 every label print went to the second API, and the same request still rendered the ZPL files the .NET kiosks were waiting for.

The same pattern then moved more of the original API’s work across: creating surgeries and status updates were forwarded in 2022. The app never had to change in step with the server, and the original API was never rewritten in one risky release; its work moved to the second API while it kept serving.