Eight Months Inside a Hospital Software Team: What Nobody Warned Me About
"The system had a field called Date of Death. It had been there since 1994. The handling logic hadn't been updated since 2003. Both facts mattered on the same day."
I took the job because the interviewer described it as "patient-facing software that handles real clinical workflows." I heard that as a description of a healthcare startup. I pictured a clean API, a React frontend, maybe some FHIR integration work. I imagined something modern built by a small team that had avoided the legacy debt of traditional hospital systems.
The product I actually joined was a clinical module used inside three regional hospitals. It had been running in production, continuously, since 1998. The codebase had been through three rewrites and two acquisitions. The team that maintained it had an average tenure of nine years. I was the newest hire by four years.
What followed was the most educational eight months of my career, and not because of the technology.
The First Thing I Got Wrong: The Patient Is Not the User
In most software I had worked on, the person using the system is the person the system is about. In clinical software, this is frequently not the case. The nurses, clinicians, ward clerks, and administrative staff using the system are performing actions on behalf of, or in relation to, patients who are lying in a bed somewhere and have not consented to any particular software design decision.
This distinction shapes everything. A typo in an e-commerce address form costs the user an extra minute correcting it. A typo in a patient's medication field, or a misidentified patient encounter, has entirely different consequences. The verification requirements that felt bureaucratic to me, double-checking patient identifiers before displaying any clinical information, mandatory confirmation before certain state transitions, explicit audit logging of who changed what and when, were not vestigial compliance theater. They were responses to actual incidents that had happened, at hospitals, with real patients.
Understanding this shifted how I read requirements. When a clinical manager said "the user should not be able to proceed without entering all required fields," I had previously heard a UX preference. I learned to hear: "a clinician once proceeded without entering a required field and something bad happened downstream." The rules weren't arbitrary. They were load-bearing.
HL7 Messages and Why They're Not Like Other APIs
The system received data from other hospital systems, lab equipment, pharmacy systems, order management, primarily through HL7 v2.x messages. If you haven't worked in healthcare, HL7 v2.x is a message format that was standardized in the late 1980s and remains in wide use in hospitals today. It looks nothing like a REST API. A message is a pipe-delimited string where each segment starts with a three-letter identifier (MSH for message header, PID for patient identification, OBX for observation results, and so on), and the semantic meaning of each value depends on its position within the segment.
Here's what HL7 actually looks like:
MSH|^~&|LABSYS|HOSP|CLINSYS|HOSP|20260512084500||ORU^R01|MSG00001|P|2.3
PID|1||123456^^^HOSP^MR||SHARMA^PRIYA^||19820403|F
OBX|1|NM|2345-7^GLUCOSE^LN||5.4|mmol/L|3.9-6.1||||F
This is a lab result. The patient is Priya Sharma. The glucose reading is 5.4 mmol/L. The reference range is 3.9-6.1. The status F means final result (not preliminary). The date of birth is April 3, 1982. This is all there, it's just encoded in a format that requires knowing where to look.
The practical engineering challenge is that the HL7 standard is a set of guidelines rather than a rigid specification, and different hospital systems interpret those guidelines differently. The same semantic concept, a patient's encounter identifier, for example, might be in segment PV1 field 19 in one system, PID field 18 in another, and a custom Z-segment in a third. Integration work with hospital systems is largely a process of mapping each sending system's specific implementation of the standard to your own data model, one field at a time, through a combination of documentation review and empirical observation of actual message traffic.
Our integration team had a spreadsheet. It had been maintained for eleven years. It was the most valuable document in the organisation.
The Edge Cases Nobody Plans For
After about two months, I started getting assigned to bugs in the patient data handling layer. This is where I encountered the edge cases that clinical software accumulates over decades of real-world use.
Twins and multiple births. Two patients admitted on the same day with nearly identical names, different middle names, same date of birth, same home address. The patient matching logic had to handle this without merging their records. Getting it wrong meant one patient receiving another's test results or medication record. The matching rules were subtle, manually tuned over years, and extremely sensitive to change.
Gender and name changes. A patient whose legal name or recorded gender had changed since their last admission. The system needed to display current information while preserving historical clinical records under the name and identifiers that were in use at the time of each encounter, for audit and medico-legal reasons. Updating one without preserving the other created problems in either direction.
Deceased patient records. The Date of Death field had been in the database schema since 1994. When a patient died, the field was populated by the ward clerk. Several downstream workflows, appointment reminders, prescription renewals, billing, had been added over the years and had varying degrees of awareness that a patient might be deceased. Some checked the field correctly. Some didn't check it at all and continued sending communications. One had a check that was inverted, it sent appointment reminders to patients who had a Date of Death set, and suppressed them for patients without one, because someone had confused the condition logic during a maintenance update in 2003 and nobody had noticed because deceased patients don't call to complain about receiving appointment reminders.
Babies born during an admission. A baby born in the maternity unit while the mother is an admitted patient arrives in the system without a name, because names are typically registered after birth, not before. Clinical staff need a working identifier immediately. The system had a convention: the baby's record was created with the mother's surname and a temporary given name that followed a pattern, BABY GIRL PATEL, for instance. This caused problems when twins were born: BABY GIRL PATEL and BABY GIRL PATEL. The matching and display logic had never been designed for this scenario, and the workaround, appending A and B, had been added as a one-line if-statement by someone who is no longer at the organisation, without documentation, approximately eight years before I joined.
What Downtime Actually Means
In every other domain I had worked in, system downtime was a business problem. Customers couldn't complete purchases. Users couldn't access their accounts. Revenue was lost and customers were frustrated. All serious, all worth preventing, but not catastrophic in a life-or-death sense.
Hospital clinical systems are different. The clinical module I worked on was used in the process of admitting patients, tracking their location within the hospital, recording care decisions, and communicating between wards. If it was unavailable, nurses and clinicians fell back to paper-based downtime procedures, handwritten patient lists, physical communication between wards, manual tracking of admissions and discharges. This is not a hypothetical: downtime procedures existed, were trained, and were exercised periodically.
The practical consequence for the engineering team was a different relationship with system availability than I had experienced before. A forty-minute outage at midnight in an e-commerce context is mostly invisible, traffic is low, the support queue stays quiet, most customers never know. A forty-minute outage at midnight in a hospital is not mostly invisible. There are patients in beds. There are clinicians making decisions. There are prescriptions being verified. The system being unavailable during a shift handover, in particular, was considered a high-severity incident regardless of the time of day.
Deployments happened during a defined maintenance window, 2am to 4am on Sundays, and required sign-off from the clinical informatics lead, not just engineering. Rollback procedures were documented, tested, and mandatory. The difference between a one-hour maintenance window and a two-hour one was not two hours of inconvenience. It was a conversation with the hospital's clinical governance team.
What I Took Away
The eight months taught me that every domain has invisible knowledge, assumptions so fundamental to how the domain works that the people inside it have stopped noticing they make them. In healthcare, those assumptions cluster around patient identity, clinical state, regulatory evidence, and the consequences of error. None of them appear in a feature spec or a user story. They are learned by working in the domain, asking questions, and encountering the edge cases that the codebase has quietly accumulated over years.
The developer who arrived after I did, a strong engineer, technically more capable than me in several areas, spent their first three months confused about why certain requirements seemed arbitrary and overconstrained. The requirements weren't overconstrained. The constraints were correct, and the reasons for them were just not obvious from the outside. That gap between the technical specification and the domain rationale is where most domain-switching developers get stuck, and most of them don't know it's where they're stuck.
I left healthcare IT after those eight months to take a different role. The thing I carried with me is a preference for asking "why does it work this way" before "how do I implement this." The answers to that first question change what you build. In healthcare, they change what you build in ways that matter quite a lot.
Tags