For ten years, my relationship with PACS was one-directional. I'd finish a study, hit send, and trust that the images landed somewhere a radiologist could read them. What happened between those two points was invisible to me, a black box that occasionally broke and became someone else's problem to fix.
This month I built the black box.
Why this, why now
I've spent the last few months building GRC and cloud security projects aimed at compliance engineering roles. Somewhere in that process I kept running into Imaging Systems Administrator postings, and I kept having the same reaction: I already know this world. Not the infrastructure side, but the side that infrastructure exists to serve. I know what it looks like when a modality can't reach the PACS. I know what a department does when the system goes down mid-shift. I've lived on the other end of every interface I was about to start building.
So instead of another generic systems admin project, I decided to build the actual thing: a real PACS, a real interface engine, and a set of demos that show what the daily and quarterly rhythms of that job actually look like.
What's actually running
Underneath everything is Orthanc, an open source PACS, and Mirth Connect, an open source HL7 interface engine, both running in Docker. I uploaded real DICOM studies and confirmed they routed correctly. I built an HL7 channel that listens for order messages and returns a proper acknowledgment. This part isn't a simulation. It's the same category of software that sits inside a real radiology department, configured by me, doing the job it's meant to do.
Building that channel is also where I got the best story of the whole project, and I didn't have to invent it.
The failure that taught me the most
Mirth Connect's newer versions replaced the old dedicated MLLP connector with a generic TCP Listener and a pluggable transmission mode architecture. I didn't know that going in. I wrote the channel configuration the way older documentation described, and it failed. Not with an error. Not with a logged exception. It just didn't work, and nothing in the interface told me why.
Diagnosing it meant going past the UI and into the server's own source, reading the actual class and field names the newer architecture expected. Two smaller traps were buried in there too: the connector wants its start-of-message and end-of-message bytes as raw hex, not the 0x-prefixed form that looks correct but silently parses into the wrong bytes, and getting a standard HL7 acknowledgment back requires an explicit response generation setting that isn't obvious from the defaults.
None of that is the kind of thing you learn from a tutorial. It's the kind of thing you learn from an afternoon of genuine, unglamorous troubleshooting, the exact skill an Imaging Systems Administrator gets hired for.
Six demos, six different parts of the job
Once the real lab was running, I built six interactive demos that each isolate one piece of what the role actually involves:
HL7 interface routing shows an order message traveling from RIS to PACS through the interface engine, and what happens to that traffic when the channel goes down mid-shift instead of gracefully failing.
DICOM routing shows the same idea on the image side, with one detail that matters more than it looks: radiology studies and cardiology studies don't always go to the same place. Echo and cath studies often route to a separate cardiovascular archive, administered separately from the general PACS. It's a small detail, but it's the kind of thing that only someone who's actually worked in imaging would think to model.
Storage forecasting answers a question every PACS environment eventually asks: when do we run out of room, and what's actually driving the growth.
A monitoring dashboard is the daily counterpart to that quarterly question, the status board an admin actually watches shift to shift.
Vendor coordination and incident tracking models the liaison work between a vendor, the infrastructure team, and clinical IT, plus the unplanned side: incidents, logged and timed to produce a real mean time to resolution.
A Windows Server patch runbook walks through a disciplined change cycle, including what a rollback actually looks like when a patch doesn't go as planned.
Why I built it this way
Anyone can write "experience troubleshooting clinical interfaces" on a resume. It reads the same regardless of whether it's true. What doesn't read the same is a working demo someone can click through in thirty seconds, or a real lab they can ask me to walk through live, or a specific, slightly embarrassing story about a config file that failed silently until I went digging through source code to find out why.
Ten years on one side of the PACS taught me what the job needs to protect. Building this taught me what it actually takes to protect it.
All six demos are live at chamb.dev/projects/imaging-systems.html. The source, including the config that broke and the fix that resolved it, is on GitHub.