What more than a decade in critical care taught me about software, systems, and the humans holding everything together.
Hospitals are strange places.
They contain some of the most advanced technology humanity has ever developed. Machines can temporarily replace the function of failing organs. Imaging systems can reveal structures inside the human body. Laboratory instruments can detect abnormalities that would have been unimaginable a century ago.
We can monitor a patient's cardiovascular system in extraordinary detail, support their breathing with a mechanical ventilator, and continuously filter their blood through an extracorporeal circuit.
And yet, somewhere in that same hospital, a nurse is probably trying to figure out why a printer won't work.
Or calling another department because an order hasn't appeared.
Or manually entering information that already exists somewhere else in the system.
Or trying to find out whether a patient is actually supposed to be transferred.
After more than a decade working as a registered nurse, primarily in critical care, I've become accustomed to this contradiction.
Hospitals are simultaneously technological marvels and remarkably inefficient information systems.
Recently, as I've started learning software development, I've found myself thinking about hospitals differently.
The more I learn about computer systems, the more familiar certain concepts become.
Networks. Dependencies. Interfaces. Data synchronization. Fault tolerance. Bottlenecks. Technical debt.
I've encountered versions of all of them in healthcare.
And I've started to wonder whether a hospital might be one of the most complicated computers we interact with.
Not because it literally functions like a computer, but because so much of its operation depends on information moving between interconnected systems.
The difference is that when the software doesn't work, the people inside the hospital have to compensate.
And those people are often already busy keeping someone alive.
In software engineering, a distributed system consists of multiple independent components that communicate and coordinate to accomplish a larger task.
The individual components may run on different machines, operate independently, and exchange information over a network.
A hospital works in a surprisingly similar way.
Consider a single patient admitted to an intensive care unit.
Their care may involve physicians, nurses, respiratory therapists, pharmacists, laboratory personnel, radiology technicians, physical therapists, case managers, transport staff, and specialists from several departments.
Each group performs a different function.
Each has its own workflows, priorities, information systems, and responsibilities.
Yet all of them must coordinate around one patient.
A physician enters an order for a medication.
The pharmacy verifies it.
The medication becomes available through the appropriate dispensing process.
A nurse retrieves it, verifies the order and patient, administers the medication, and documents what happened.
The patient's response is monitored.
If the treatment isn't working as expected, that information needs to make its way back into the decision-making process.
What appears to be one clinical action is actually a sequence of dependent operations across multiple systems.
And any one of those operations can fail.
The order might be incomplete.
The pharmacy might need clarification.
The medication might be unavailable.
The electronic medication administration record might not reflect a recent change.
The patient might develop a contraindication before administration.
The problem isn't necessarily that any individual component is broken.
It's that coordinating independent components is difficult.
Software engineers spend enormous amounts of time solving exactly this kind of problem.
Hospitals do too.
We just don't always describe it that way.
One of the first things I noticed while learning software development was the distinction between an interface and the underlying system.
An interface is how someone interacts with software.
It isn't necessarily a complete representation of everything happening behind it.
The electronic health record is a perfect example.
When I open a patient's chart, I'm looking at a structured representation of their care.
I can review vital signs, medications, laboratory results, orders, clinical notes, and documentation from other departments.
But the chart isn't the patient.
And it isn't a complete representation of what's happening in the hospital.
It is an interface to information that has been collected, entered, transmitted, and organized by many different people and systems.
Some information is automatically imported.
Some is manually documented.
Some arrives after a delay.
Some is duplicated.
Some is missing.
And some may technically be present but buried in a location where nobody thinks to look.
A laboratory result might be available in one section of the chart before someone notices it.
A medication might appear active even though the clinical plan has changed.
A note might describe a patient's condition accurately when it was written but no longer reflect their current status.
This is a fundamental problem with information systems.
The data displayed on a screen is not necessarily the complete or current state of reality.
In software, developers have to think about stale data, synchronization delays, and inconsistent representations of the same information.
In healthcare, we deal with those problems constantly.
Except the consequences can be considerably more serious than displaying an outdated shopping cart.
This might be the most interesting comparison of all.
In software architecture, an integration layer helps different systems communicate and work together.
It connects components that weren't necessarily designed to interact directly.
In hospitals, nurses often perform a substantial amount of that integration work.
Think about how much of a nurse's day involves coordinating information between people, departments, and technologies.
A patient's blood pressure is falling.
The nurse recognizes the trend, assesses the patient, reviews relevant information, communicates with the provider, implements appropriate interventions, coordinates additional testing or treatment, and evaluates the response.
Meanwhile, another department may need to be contacted.
A medication may need to be obtained.
An order may require clarification.
The patient's family may need an update.
And the electronic record needs to reflect what happened.
The nurse isn't simply executing a predefined set of instructions.
They're continuously interpreting information, identifying discrepancies, coordinating resources, and adjusting to changing conditions.
In many ways, they're connecting systems that would otherwise struggle to function together.
This is especially apparent in a system-wide float pool.
Working across intensive care units, progressive care, emergency departments, and medical-surgical floors exposes you to different workflows, different expectations, and different ways of solving the same operational problems.
You begin to recognize which processes are standardized and which depend heavily on local knowledge.
You also notice how much of the hospital's functionality relies on experienced people knowing whom to call, where to look, and how to work around limitations.
That's an impressive demonstration of human adaptability.
But it also raises an uncomfortable question.
How much of the hospital works because its systems are well designed, and how much works because its employees have learned to compensate for systems that aren't?
Those are very different things.
Software developers use the term technical debt to describe the future costs created by shortcuts, compromises, or outdated design decisions.
Sometimes technical debt is intentional.
A team needs to deliver something quickly, so it accepts a less-than-ideal solution with the understanding that it may need improvement later.
Other times, technical debt accumulates gradually.
Systems become more complicated.
Temporary fixes become permanent.
New features are layered on top of old architecture.
Eventually, changing anything becomes difficult because so many other things depend on the existing structure.
Hospitals have their own versions of this.
Consider a workflow that requires a nurse to document the same information in multiple places.
Perhaps each documentation requirement originally served a legitimate purpose.
One was introduced for clinical communication.
Another supported regulatory reporting.
Another was added for quality improvement.
Another became necessary after a software implementation.
Over time, the combined process may become cumbersome.
But removing any individual step can be difficult because different stakeholders depend on it.
The result is a workflow that nobody would deliberately design from scratch.
Yet everyone is expected to follow it.
That's operational technical debt.
And like software technical debt, it creates hidden costs.
Time.
Attention.
Training requirements.
Additional opportunities for error.
Frustration.
And reduced flexibility when something needs to change.
The difficult part is that individual requirements may be reasonable even when the overall system is inefficient.
Optimizing one component doesn't necessarily optimize the whole.
An intensive care unit produces an extraordinary amount of information.
Heart rate.
Blood pressure.
Oxygen saturation.
Respiratory rate.
Temperature.
Urine output.
Laboratory values.
Ventilator measurements.
Infusion rates.
Hemodynamic parameters.
Depending on the patient, we may also be monitoring invasive pressures, cardiac output, continuous renal replacement therapy, or mechanical circulatory support.
Much of this information changes continuously.
And not all of it is equally important.
A single abnormal value may mean very little.
A trend across several measurements may mean everything.
A monitor displaying a heart rate of 115 doesn't tell you why the patient's heart rate is elevated.
Is the patient in pain?
Are they febrile?
Hypovolemic?
Anxious?
Developing an arrhythmia?
Experiencing a compensatory response to another physiological problem?
The number is data.
Understanding its significance requires context.
This is where healthcare begins to resemble another challenge in software engineering: observability.
In complex software systems, observability refers to the ability to understand what's happening internally by examining the information the system produces.
Developers use metrics, logs, traces, and alerts to identify problems.
Clinicians use vital signs, laboratory results, physical assessments, monitoring devices, and clinical history.
Both environments generate signals that must be interpreted.
And both struggle with the difference between having information and understanding it.
There's a temptation to assume that collecting more information always improves performance.
Sometimes it does.
But information has a cost.
Every additional measurement competes for attention.
Every alert demands some degree of evaluation.
Every dashboard adds another place to look.
When everything is presented as important, it becomes harder to identify what actually matters.
This is one reason alarm fatigue is such a serious issue in clinical environments.
A monitoring system that generates excessive nonactionable alarms can make meaningful warnings harder to distinguish.
The problem isn't simply that the system produces too much information.
It's that the system doesn't always communicate the significance of that information effectively.
A well-designed system shouldn't merely collect data.
It should help people recognize when the data requires action.
That's true whether you're monitoring a server or a patient.
One of the most vulnerable moments in any complex system occurs when responsibility moves from one component to another.
In hospitals, we call this a handoff.
A patient transfers from the emergency department to the intensive care unit.
A nurse gives report to the next shift.
A patient moves from the operating room to a recovery area.
A specialist assumes responsibility for a particular aspect of care.
Each transition requires information to move between people.
And that information needs to be accurate, relevant, and sufficiently complete.
Imagine transferring a file between two computers.
If part of the file is missing, the receiving computer may not be able to use it correctly.
Clinical handoffs are far more complicated because the information isn't a static file.
The patient's condition may be changing during the transfer.
Some details are objectively measurable.
Others depend on clinical judgment.
Some information is urgent.
Other information provides background context.
And the receiving clinician needs to understand not just what has happened, but what might happen next.
A good handoff communicates the current state of the patient, the important events leading up to that state, and the anticipated problems or next steps.
A poor handoff can leave the receiving clinician reconstructing the situation from incomplete information.
That's why structured communication tools can be valuable.
They create a shared expectation about what information should be transferred.
But even a structured handoff cannot eliminate every problem.
The quality of the transfer still depends on the accuracy of the underlying information, the judgment of the people involved, and the opportunity to clarify uncertainties.
In software terms, the interface matters.
But so does the integrity of the data moving through it.
When something goes wrong in a hospital, it's tempting to look for the individual component that failed.
Was an order entered incorrectly?
Did someone miss an abnormal result?
Was a medication delayed?
Did a clinician misunderstand the plan?
These are important questions.
But they don't always explain the full problem.
Sometimes every individual involved was operating reasonably within the information available to them.
The failure occurred between components.
Information wasn't transmitted.
Responsibilities weren't clearly assigned.
Two systems displayed conflicting information.
A process depended on an assumption that turned out to be incorrect.
This is one of the reasons complex systems are difficult to manage.
Their behavior isn't always predictable from the behavior of their individual parts.
You can have excellent clinicians, sophisticated equipment, and carefully designed procedures while still experiencing failures in coordination.
Software engineering has an entire vocabulary for these kinds of problems.
Race conditions.
Dependency failures.
Interface mismatches.
Synchronization errors.
Single points of failure.
Hospitals have analogous problems, although the mechanisms and consequences differ.
Consider a transfer where one department believes another has assumed responsibility, while the receiving team believes the transfer is still pending.
Neither group necessarily intends to neglect the patient.
But the ambiguity itself creates risk.
That's a systems problem.
And solving it requires more than telling individuals to be more careful.
It requires designing workflows where responsibilities, information, and transitions are explicit.
In computing, fault tolerance describes a system's ability to continue operating when some of its components fail.
Redundant servers, backup power supplies, replicated databases, and failover mechanisms can help prevent a single failure from bringing down an entire service.
Hospitals also use redundancy.
Backup generators.
Emergency equipment.
Independent safety checks.
Escalation procedures.
Alternative treatment pathways.
But healthcare relies heavily on another form of resilience.
Human adaptability.
When an expected process fails, people improvise within the boundaries of safe practice.
They communicate directly.
They locate alternative resources.
They escalate problems.
They reconcile conflicting information.
They recognize that a displayed value doesn't match the patient's clinical presentation.
They catch discrepancies that automated systems missed.
This flexibility is one of healthcare's greatest strengths.
It's also a potential weakness.
Because a system that depends on people constantly compensating for its limitations may appear more reliable than it actually is.
If a nurse catches a documentation discrepancy before it causes harm, the patient benefits.
But the underlying problem may remain.
If a pharmacist identifies a problematic order, an error may be prevented.
But that doesn't necessarily explain why the order reached that point.
Human vigilance is essential in healthcare.
It shouldn't be treated as an unlimited resource.
People become tired.
They get interrupted.
They manage competing demands.
Their attention is finite.
A resilient system should support human judgment without depending on extraordinary effort to make ordinary processes function.
When I encounter a frustrating software problem, it's easy to imagine replacing the entire system with something better.
Start over.
Simplify the architecture.
Remove unnecessary dependencies.
Design a cleaner interface.
But hospitals aren't applications that can simply be taken offline and rebuilt.
They're living organizations.
They have to continue functioning while changes are made.
Patients still need care.
Medications still need to be administered.
Emergency departments still receive patients.
Operating rooms still run.
Staff members still need to understand their responsibilities.
Every change interacts with existing clinical, operational, financial, and regulatory requirements.
And unlike a small personal software project, the consequences of a poorly designed change may affect patient safety.
That makes improvement difficult.
But not impossible.
It suggests that healthcare technology needs to be designed with a deeper understanding of how work actually happens.
Not just how a workflow appears in a process diagram.
Not just how administrators expect a process to function.
Not just how software developers imagine people will use an interface.
But how clinicians behave when the unit is busy, a patient is deteriorating, multiple alarms are sounding, and the expected workflow no longer matches reality.
The difference between the intended process and the actual process is where many of the most important design problems become visible.
Healthcare technology is advancing rapidly.
Artificial intelligence may help summarize clinical information, identify patterns, reduce documentation burdens, and support certain decisions.
Automation may eliminate repetitive administrative tasks.
Better interoperability could allow information to move more reliably between organizations and systems.
More sophisticated monitoring could help clinicians identify meaningful changes earlier.
These possibilities are exciting.
But I don't think the ultimate goal should be to make hospitals more technologically complicated.
It should be to make them easier to operate safely.
Those aren't necessarily the same thing.
Adding another dashboard doesn't automatically improve situational awareness.
Adding another alert doesn't automatically improve safety.
Adding another automated process doesn't automatically eliminate work.
Sometimes it simply moves the work somewhere else.
The question shouldn't be how much technology we can introduce.
It should be whether the technology reduces unnecessary complexity for the people providing care.
Does it make important information easier to find?
Does it reduce duplication?
Does it clarify responsibility?
Does it help clinicians recognize meaningful changes?
Does it make the safest action easier to perform?
Does it free up attention for the parts of healthcare that genuinely require human judgment?
Those seem like better measures of progress than the number of features a system contains.
There's a limit to comparing hospitals with computers.
And it's an important one.
Patients aren't data structures.
Nurses aren't software processes.
Clinical judgment isn't simply an algorithm.
A hospital is not a deterministic machine where identical inputs always produce identical outputs.
Human physiology is complex.
People have different needs, values, histories, and responses to treatment.
Clinical decisions often involve uncertainty that cannot be eliminated by collecting more information.
And some of the most important parts of healthcare are difficult to quantify.
Reassuring a frightened patient.
Recognizing that a family member doesn't understand what's happening.
Noticing a subtle change in someone's behavior.
Helping a person make a difficult decision.
Being present when there isn't anything left to fix.
These aren't problems that can be solved by optimizing data transfer.
They're fundamental parts of caring for people.
So the computer analogy is useful, but incomplete.
It helps explain how information moves, how processes interact, and why coordination failures occur.
It doesn't explain everything that makes healthcare work.
And it shouldn't.
I'm still very much a beginner in software development.
I don't pretend to understand all the complexities of designing large distributed systems.
But learning how software is built has given me a new vocabulary for problems I've encountered throughout my nursing career.
Things I previously thought of as frustrating workflows now look like interface design problems.
Repeated documentation looks like unnecessary duplication.
Unclear handoffs look like poorly defined boundaries between components.
Communication delays look like coordination failures.
Workarounds look like evidence of accumulated operational debt.
And the experienced nurse who somehow keeps everything moving?
That person looks a lot like the human integration layer holding an imperfect system together.
I find that perspective fascinating.
Because it suggests that some of healthcare's most persistent problems aren't exclusively medical problems.
They're problems of information architecture, system design, human factors, communication, and organizational complexity.
Those are areas where healthcare and software engineering have a great deal to learn from each other.
I don't know exactly where my interest in software development will lead.
Maybe I'll build useful healthcare tools.
Maybe I'll create educational resources.
Maybe I'll continue making websites and experimenting with technology simply because I enjoy it.
But I already know that learning something outside my profession has changed how I understand the profession I've spent years practicing.
And that's been one of the most unexpected rewards of starting something new.
If a hospital really is a kind of enormous distributed computer, it's one of the strangest ever constructed.
Its components are spread across buildings and departments.
Its information moves through software, machines, conversations, and handwritten notes.
Its operating conditions change constantly.
Its users are simultaneously operators, decision-makers, and participants in the system.
And its most important outputs cannot always be reduced to numbers.
But what makes it truly unusual is that the people operating it are also part of its resilience.
When information is incomplete, they investigate.
When systems disagree, they reconcile.
When processes fail, they adapt.
When the unexpected happens, they make judgments that no workflow can fully anticipate.
The hospital's technology is extraordinary.
But the technology alone doesn't make the hospital function.
The people do.
And maybe that's the most important lesson software engineering can teach us about healthcare.
The best systems aren't the ones that demand the most from the people using them. They're the ones that make it easier for those people to do their best work.
I'm a critical care nurse learning to build software. Simpyll is where I explore the unexpected connections between those two worlds—and whatever else catches my curiosity along the way.