Why Intelligent People Operate Unsafe Systems — And What Aviation, IT, and Healthcare Reveal About the Invisible Chains of Failure in Our Society.
It Begins With an Ordinary Meeting
It is early morning. Several people are sitting around a table, with documents spread out in front of them, perhaps a laptop, and almost certainly some coffee. They are discussing what lies ahead, which problems are already known, what needs to be done, and who will be responsible for making it happen.
Perhaps we are in a hospital, where doctors and nurses are reviewing patients from the night shift. Perhaps we are at an airport, where two pilots are preparing for their next flight. We might just as easily be in an IT department, where systems administrators are discussing a planned infrastructure change, or in a logistics center, where employees are reviewing incoming deliveries and checking whether sufficient inventory is available.
The location is different, as is the professional vocabulary. The technology may vary considerably, and the consequences of potential mistakes are not always the same.
But all these meetings have something in common.
People bring information together, assess the situation, make decisions, assign responsibilities, and then proceed on the assumption that the agreed actions will actually be carried out.
At first glance, this seems perfectly ordinary. Human collaboration has operated according to similar principles for thousands of years.
There is just one problem, and it is discussed surprisingly rarely.
A decision made is not an action completed. Information handed over is not necessarily information understood. And a meeting successfully concluded does not mean the process discussed has actually been completed.
Anyone who has attended a major workplace meeting will probably recognize the questions that tend to follow.
Wasn’t someone supposed to take care of that? Hadn’t we already passed that information along? Why didn’t the other department know about it? And who was supposed to check whether the task had actually been completed?
Such questions are relatively harmless when the office coffee machine hasn’t been repaired on schedule.
They take on an entirely different meaning when a commercial aircraft carrying hundreds of passengers takes off, a data center supports the infrastructure of an entire region, or a seriously ill patient is discharged from a hospital.
Because at that point, the reliability of human collaboration is no longer merely a financial concern.
Human lives may depend on it.
And that is why simply having people talk to one another is not enough.
A safe process must ensure that the right information actually leads to the right actions — and that someone notices when it doesn’t.
Eike, Marion, and Two Suddenly Incapacitated Pilots
Consider two people who, at first, have absolutely nothing in common.
Eike is 51 years old, technically skilled, and has extensive experience with complex IT systems. Eike is also familiar with aircraft, understands fundamental aerodynamic principles, and has spent considerable time learning about the technical systems found in modern cockpits.
Marion is 80. She has led a different life, developed different skills, and never had any particular reason to study commercial aviation, computer systems, or technical safety procedures.
Both are passengers on the same commercial flight.
They have purchased their tickets, stowed their luggage, and fastened their seat belts. Nothing more is expected of them. Nobody asks them to inspect the aircraft’s maintenance records, understand its technical systems, or determine whether the flight crew has correctly completed every mandatory safety procedure.
And that is exactly how it should be.
Now imagine an extraordinary situation.
During the flight, both pilots become seriously ill from food poisoning and are suddenly unable to operate the aircraft.
Such an event would be rare, but for the purpose of our thought experiment, let us assume it happens.
The question now arises whether anyone among the passengers could help.
Eike volunteers. Thanks to their technical knowledge, they may have a better chance of understanding the instruments, following instructions from air traffic control, and attempting a landing using the aircraft’s available systems.
That would by no means guarantee a safe landing. Flying a commercial airliner requires far more than a general understanding of technology, particularly in poor weather, during complex approaches, or when technical malfunctions are involved.
Without comparable knowledge, Marion would probably face considerably greater difficulties.
But that is precisely the point.
Why should the survival of everyone aboard depend on whether Eike or Marion happens to be the person attempting to land the aircraft?
The answer is obvious: It shouldn’t.
This is why commercial aviation has developed safety systems designed to reduce such risks long before an aircraft ever leaves the ground. These include trained flight crews, mandatory procedures, technical redundancy, maintenance regulations, safety inspections, and defined responses to abnormal situations.
Of course, residual risks remain. No technical system can eliminate every imaginable event.
But the underlying principle is clear: The safety of an airline flight must not be designed around the hope that some technically knowledgeable passenger will be available in an emergency.
Now let us leave the aircraft.
And send Eike and Marion to the hospital.
Two Patients, the Same System Failure
Eike and Marion both require hospital treatment for serious medical conditions.
Both undergo examinations, medical findings are documented, and the relevant reports are prepared. Once their immediate treatment has been completed, they are discharged, although further outpatient care remains necessary.
The hospital has the medical information. The documents already exist, often in digital form.
But let us imagine that these records are not reliably transferred to the electronic patient record. At the same time, the arrangements for follow-up care have not been adequately secured.
Eike notices.
With their technical expertise, Eike can digitize the documents, upload them to the electronic patient record, inspect its activity logs, and determine which healthcare providers have accessed the available information.
Then the real work begins: contacting medical practices, explaining findings, arranging prescriptions, and making sure the necessary medical care continues despite the information gap.
Marion, however, does not know how to do these things.
Perhaps she does not own a suitable smartphone. Perhaps her health leaves her too exhausted to navigate complicated administrative procedures. Perhaps she simply does not understand why her next doctor has no knowledge of certain examination results.
And perhaps there is nobody available to take care of these tasks for her.
What happens next?
There is no universal answer.
Perhaps the missing information is discovered in time. Perhaps the necessary medical treatment proceeds anyway. Or perhaps the gap causes delays, unnecessary repeat examinations, or actual harm.
But the mere possibility of such different outcomes reveals a fundamental problem.
The system failure is identical for both patients. Their ability to recognize and compensate for it is not.
Marion is not less intelligent than Eike. She simply lacks certain technical skills and may not have the physical or mental resources to take on responsibilities that should never have been assigned to a patient in the first place.
In aviation, nobody would expect Marion to inspect maintenance documentation to ensure that her aircraft can take off safely.
Why, then, should she be expected to determine whether her medical records are available wherever her next treatment will take place?
Eike is not an entirely fictional character. The abilities and experiences described are closely based on my own, while Marion represents the perspective of an older person who cannot independently repair gaps in their healthcare.
The aircraft scenario is a thought experiment. So is Marion’s hypothetical medical experience.
The experience underlying Eike’s hospital visit, however, comes from my own life.
And reality provides a punchline that even a satirist might struggle to improve upon.
When the Postal Service Has to Digitize the Hospital
On October 26, 2026, I was examined in the emergency department of the University Medical Center Hamburg-Eppendorf, commonly known as UKE, in Germany.
Because of significant neurological symptoms, further investigations and subsequent specialist care were necessary.
After treatment, I received a five-page hospital discharge report.
So the document existed.
What initially failed was its availability through Germany’s electronic patient record system, the elektronische Patientenakte, or ePA.
The ePA is a nationwide digital health record intended to make relevant medical information accessible to authorized healthcare providers across organizational boundaries. It is not merely a hospital’s internal electronic chart.
While still at the hospital, I photographed the discharge report, converted the images into a PDF, and uploaded the document to my own ePA.
I then made sure that my subsequent doctors were aware of the information and began organizing the medical care I needed.
That should have been the end of the story.
It wasn’t.
On November 2, the UKE produced a printed copy of the five-page discharge report. The document was subsequently sent through the traditional postal system to my registered address.
On November 5, I received it as a PDF through Deutsche Post’s POSTSCAN service, which digitizes incoming physical mail.
Consider that sequence for a moment.
A university hospital creates a digital document, prints it onto paper, places it in an envelope, hands it to a postal operator, and the postal operator digitizes it again so that the recipient can read it electronically.
Digital. Analog. Digital.
A process that would make an excellent demonstration of a historical technological regression, though perhaps a less convincing advertisement for modern healthcare digitalization.
When I checked late on November 5, there was still no corresponding upload by the UKE itself visible in my ePA.
One could argue, of course, that sending the document by post at least ensures that the patient receives it.
There is just one minor logistical detail.
The address registered with a hospital is not necessarily where a person is actually staying.
People may temporarily live with relatives, reside in a care facility, travel, or stay elsewhere because of their medical condition.
A successfully mailed letter therefore proves neither that the patient reads it in time nor that it personally reaches them at all.
And even if the patient receives it, another question remains.
Which doctor is supposed to treat them next?
Their general practitioner? A neurologist? An orthopedic specialist? Another hospital? Perhaps a medical facility that has not even been selected at the time of discharge?
The hospital may not know who the next treating clinician will be. That clinician, in turn, may not even know the patient was previously examined at the UKE.
Knowing a patient’s postal address is simply not the same thing as ensuring that medically necessary information reaches the healthcare professional who needs it.
The postal service knows the recipient. The hospital knows the medical findings. The next doctor needs those findings. Yet everyone involved can consider their individual task completed while the actual transfer of medical information remains unresolved.
This is not a lack of computing power.
It is a failure of process architecture.
And it is not even the only one.
When Treatment Ends but the Medical Problem Remains
To understand the second safety gap, we need to go back several years.
During a drive on a hot summer day, I developed significant symptoms suggesting a possible heart-related problem.
Once home, I recorded an ECG using my Apple Watch and contacted the medical out-of-hours service. Based on the symptoms I described, an ambulance and an additional emergency physician were eventually dispatched.
The emergency team examined me, identified a serious need for cardiac investigation, and transported me to the hospital.
There, I underwent extensive diagnostic testing. Several examinations were performed, but no definitive explanation for my symptoms was established.
I was subsequently discharged.
As I remember it, no specific cardiology follow-up had been arranged, even though the underlying cause remained unresolved.
So I contacted a cardiology practice myself and underwent further examinations. Over time, blood pressure problems and stress emerged as important explanatory factors.
Whether the hospital fulfilled all its medical and organizational obligations at the time could only be assessed by reviewing the complete records. That is not the central question here.
What matters is the structure of the process.
An emergency department is not required to establish the final cause of every conceivable medical condition. Its primary responsibility is to identify, treat, or sufficiently rule out immediate dangers.
But the administrative closure of a hospital case does not automatically mean that the medical question has been resolved.
When further investigation is necessary, that unresolved need must remain visible and traceable.
And this is where two different problems meet at the same interface.
In my earlier cardiac case, the medical cause initially remained unclear, while the continuation of diagnostic care was, from my perspective, not reliably organized.
During my UKE visit in October 2026, specific findings and treatment recommendations existed, but their digital availability and subsequent handling were not reliably ensured.
The first case reveals a gap in continuity of care. The second reveals a gap in continuity of information.
In both cases, I was able to bridge at least part of the gap myself.
But what would have happened if Marion had been the patient instead?
What if nobody had noticed that an important report was missing? What if nobody had arranged the next diagnostic examination? What if the next medical practice had not even known that a previous investigation had taken place?
We cannot calculate the consequences of a hypothetical event after the fact.
But we can identify the underlying structural weakness.
Medical treatment can end at an organizational boundary while the need for medical information or further action continues beyond that boundary.
And that brings us to another industry where such problems are very familiar.
The Server Is Running. The Patient Is Discharged. Three Green Checkmarks.
In my former professional work as an IT systems and network administrator, I repeatedly dealt with comparable problems.
When a central network component is updated, for example, the change can affect numerous other systems.
A router is reconfigured. A firewall receives additional rules. A server is updated. A database is modified.
Initially, everything appears to work.
The affected component is reachable, the configuration change has been successfully saved, and the responsible administrator can close the task.
But what does that actually mean?
Perhaps a dependent service can no longer reach certain databases. Perhaps a backup process has stopped working. Maybe some applications continue to function normally while others have become partially unavailable.
Anyone who checks only the component that was changed may never notice these consequences.
This is why professionally organized IT operations use change-management procedures, automated testing, monitoring, documented rollback plans, and clearly assigned responsibilities.
Not everywhere, of course.
And certainly not always consistently.
Historically grown corporate IT departments can become dominated by informal routines, where experienced employees rely on personal knowledge and habits rather than systematically enforced procedures.
That often works surprisingly well.
Until it doesn’t.
Then the investigation begins.
Was the change documented? Were dependent systems tested? Was a backup available? Did the other department receive the relevant information? And who actually authorized the change to be marked as completed?
Anyone asking these questions for the first time after a major outage is not exactly practicing forward-looking reliability engineering.
They are practicing technical archaeology.
There is an important distinction built into professional change management: It is not enough for a change to be technically accepted. What matters is whether the overall system has subsequently reached the expected operating state.
A successful save operation is not proof of successful functionality.
The same principle applies to information transfers.
A sent status initially proves only that something was sent. An acknowledgment confirms that something was received. But even that does not prove the information was understood, correctly assigned, or considered in a necessary decision.
These are different states requiring different controls.
Now replace the term “network component” with “medical examination,” “dependent service” with “next treating physician,” and “change closure” with “hospital discharge.”
The parallel becomes fairly obvious.
In both cases, information is generated whose significance extends beyond the original organizational unit.
In both cases, dependencies exist that may not be fully visible to individual participants.
And in both cases, an isolated task can be completed successfully while the overall process remains unfinished.
The server is running. The patient has been discharged. The report has been written. Three green checkmarks. And nobody knows whether the overall system is actually functioning.
Anyone who sees merely three independent administrative events misses the essential connection.
Anyone who asks how the information, decisions, and subsequent actions are linked is beginning to think systemically.
The Ability to Recognize Connections
Imagine a systems administrator who starts receiving unusual error reports from a completely different department after an apparently successful infrastructure change.
The affected applications were never modified. The databases also appear to be working normally. Each specialist team initially examines only its own area of responsibility.
But the administrator recognizes a possible connection.
Perhaps the application depends on a network route altered by the new firewall rule. Perhaps the service works only under certain conditions, so the problem remained invisible during superficial testing.
The cause has not yet been proven.
But it is a testable hypothesis.
The administrator is no longer examining individual technical components in isolation, but the relationships between them.
This approach is studied in several scientific disciplines under the term Systems Thinking.
Systems thinking involves recognizing patterns, interactions, feedback loops, time delays, and possible chains of failure within complex systems.
A related scientific concept is known as Systems Intelligence.
Esa Saarinen and Raimo Hämäläinen developed this concept beginning in 2004. Together with Juha Törmänen, they published a measurement instrument in 2016 examining eight dimensions of systemically intelligent thinking and behavior.
This is not, however, a universally accepted independent intelligence quotient.
A high IQ does not automatically guarantee that someone recognizes complex systemic relationships. Conversely, the ability to conduct an effective systems analysis does not establish a particular IQ score.
Professional expertise, practical experience, curiosity, cognitive abilities, and a willingness to think beyond organizational boundaries can all interact.
But the most important question for our discussion is a different one.
What good does it do an organization when individuals recognize systemic failures, but the organization itself cannot translate those insights into binding improvements?
A hospital may employ highly qualified physicians, excellent nurses, and experienced IT administrators, yet still operate inadequately secured processes.
The same applies to businesses, government agencies, and logistics organizations.
The problem often does not arise within individual areas of expertise.
It arises between them.
One employee knows what information is needed. Another knows where it is stored. A third could automate its transfer. A fourth possesses the organizational authority to make the necessary decision.
But nobody brings these separate pieces of knowledge together into a binding, system-wide solution.
Worse still, people who recognize such broader connections and point out necessary changes may encounter resistance.
After all, improving safety often changes established responsibilities and routines. It creates visible effort today, while much of the benefit consists of harmful events that will never occur tomorrow.
And an accident successfully prevented does not make a particularly compelling photograph.
This creates an uncomfortable economic problem for organizations: The investment is visible, but the damage prevented often is not.
As long as nothing happens, the existing process appears adequate.
When something does happen, the search for someone responsible begins.
And if nobody takes responsibility for the complete chain of failure, the underlying structural weakness may remain untouched.
An intelligent overall system does not automatically emerge simply because it employs many intelligent people.
It emerges when the organization reliably connects their knowledge, decisions, and actions.
Individual systems intelligence is the ability to recognize relationships and act accordingly.
Organizational systems intelligence must additionally ensure that such insights do not disappear into hierarchies, departmental boundaries, or unclear responsibilities.
And the technical safety architecture must make the resulting procedures as reliable and verifiable as possible.
These are three different requirements.
None can replace the others.
Aviation Has Known About Human Fallibility for a Long Time
Pilots do not use checklists because they are less intelligent than other people.
They use checklists because they are highly trained professionals who can still make mistakes under pressure, stress, fatigue, or excessive workload.
A checklist is not a personal insult.
It is a safety barrier.
It ensures that defined checks are carried out without relying exclusively on memory and individual attention.
These procedures are reinforced by standardized operating practices, cross-checking, defined responsibilities, and protocols for abnormal situations.
Not every control is technically enforced, and aviation is certainly not immune to human error.
But its safety architecture explicitly treats human fallibility as a predictable characteristic of the system.
The same principle applies to aircraft maintenance.
Under Part-145, the European Union Aviation Safety Agency, EASA, requires maintenance organizations to plan their work appropriately, account for human performance limitations including fatigue, and ensure sufficient transfer of relevant information during shift or personnel changes.
This matters because fatigue is not treated merely as an individual employee’s problem.
It is a factor in operational safety.
Hospitals also have checklists, quality-management systems, standardized handovers, and occupational safety requirements. It would be inaccurate to suggest that healthcare lacks such measures altogether.
But a central question remains.
How consistently do these safeguards operate when a patient leaves a department, or an entire healthcare institution?
Who checks that the information transfer is complete?
Who identifies outstanding medical reports?
Who notices when follow-up care has not been arranged?
And who takes responsibility when the person originally in charge has already gone home?
The working conditions of healthcare professionals make these questions particularly important.
Long shifts, heavy workloads, and sleep deprivation can impair performance. At the same time, concentration, attention, clinical judgment, and reliable documentation are indispensable requirements of medical work.
In April 2025, England’s Health Services Safety Investigations Body, HSSIB, published an investigation into the impact of staff fatigue on patient safety.
The report identified fatigue as a significant but insufficiently understood safety risk. Among the contributing factors were long shifts, high workloads, inadequate breaks, and organizational difficulties in managing fatigue.
Precisely where people must make complex medical decisions under demanding conditions, additional safety barriers can therefore be particularly valuable.
An automated process does not become tired because the previous shift was especially difficult.
It does not forget an outstanding task because someone had to sign a report between two emergencies.
And it does not lose track of information because the responsible person was suddenly called away to another patient.
At least, not if the process has been designed properly.
Because software can fail, too.
And automating a bad process does not magically produce a good one.
It merely produces a bad process capable of repeating its mistakes at an impressive speed.
The Disaster Without a Common Crash Site
The World Health Organization has warned for years that preventable patient harm is a major global problem.
According to its published estimates, approximately one in ten patients experiences harm in healthcare, and more than half of that harm is considered preventable.
These figures cover many different causes. They do not prove that poor information transfers or insufficient automation account for any particular share.
But they illustrate the scale of the broader patient-safety problem.
Now consider two very different events.
In the first, several safety barriers fail aboard a commercial aircraft. The aircraft crashes, and many people die. An investigation follows, reconstructing the technical, organizational, and human factors involved.
Such an event leaves a crash site, a relatively identifiable timeline, and numerous clues that can be connected to one another.
In healthcare, however, a recurring organizational weakness might affect different patients over months or even years.
One patient is missing a crucial medical report.
Another does not receive a necessary follow-up examination in time.
A third undergoes treatment without all relevant information from previous investigations being available.
Perhaps harm occurs. Perhaps it does not. Perhaps the problems are discovered before they become serious.
But when harm does occur, the separate incidents are not necessarily recognized as manifestations of the same underlying weakness.
There is no common crash site.
No single wreckage field.
No one moment when society is forced to recognize that something has gone fundamentally wrong.
The consequences of a systemic failure can be distributed across many people, institutions, and periods of time, while their common cause remains unidentified.
This does not mean that different medical injuries must necessarily share the same cause.
The point is something else.
Just because a causal connection has not been identified does not mean that no connection exists.
Complex technical and organizational systems can propagate failures through numerous intermediate steps. An initial disturbance may be altered, weakened, amplified, or combined with other problems.
Eventually, harm may occur that no longer appears obviously connected to the original disturbance.
We recognize these patterns in IT, supply chains, energy networks, and many other areas of critical infrastructure.
A seemingly minor error in a data system can disrupt downstream processes. Incorrect inventory information can influence purchasing decisions. A delayed delivery can, in turn, affect the availability of medical supplies.
Not every disturbance leads to harm. But the possibility of failure propagation does not disappear simply because every organization examines only its own responsibilities.
If you investigate only the individual department, you may overlook the failure of the system as a whole.
And if you look only for harm that has already occurred, you may overlook safety gaps that have so far remained harmless only because someone intervened in time.
That is why safety management must do more than investigate obvious disasters after the fact.
It must also recognize the connections through which small mistakes could develop into much larger problems.
Why a Law Is Not Yet a Working Safety Mechanism
Let us return to Germany’s electronic patient record.
Germany already has a legal obligation requiring certain medical information to be uploaded.
Under Section 348 of Book Five of the German Social Code, Sozialgesetzbuch V, or SGB V, authorized hospitals must, subject to the applicable conditions, transfer certain electronically processed medical documents into the patient’s ePA.
These include electronic hospital discharge letters, laboratory findings, and reports from diagnostic imaging.
The requirement is therefore not merely a polite suggestion from lawmakers.
However, Germany’s national digital health agency, gematik, also states in its official information that there is no generally applicable deadline specifying how quickly medical findings must be uploaded to the ePA.
And this exposes a significant difference between a legal obligation and a technically enforced process.
A piece of information may be urgently needed for medical treatment even though the relevant regulations do not establish one universally applicable, measurable upload deadline.
Of course, additional medical duties of care and information-sharing obligations exist. Their violation can be legally relevant even without a patient having already suffered harm.
But none of this eliminates the technical weakness.
If information needs to be available in time, why shouldn’t the system automatically verify that it actually is?
Why must a human being remember to initiate a technically standardized action every single time?
Why should the patient have to check whether the transfer worked?
And why must somebody first notice that information is missing before the error is addressed?
Gematik explicitly confirms that uploading information to the ePA can, in principle, be automated.
So the basic technical idea is not missing.
What is missing is a consistently binding, verifiable implementation that connects information transfer with medical process responsibility.
And that is something we can change.
What a Genuinely Safe Process Could Look Like
Imagine a patient being admitted to a hospital.
Their identity is established, permissions for accessing the electronic patient record are checked, and the treatment case is opened in the hospital information system.
During treatment, medical documents are generated. Examination results are recorded, reports are prepared, and further treatment is planned.
So far, nothing particularly unusual has happened.
The crucial difference begins when the patient is discharged.
As soon as the discharge event is registered in the system, a defined transfer process begins automatically.
The hospital information system identifies the finalized documents whose transfer is legally required, respects any applicable objections or restrictions, and sends the appropriate information to the ePA.
The system then verifies whether the transfer was actually successful.
Not whether an employee clicked a button.
Not whether an item on an internal task list was marked as completed.
But whether the data was demonstrably transferred.
If the transfer fails, the error is automatically logged. The system retries the operation or initiates a defined fallback procedure. If the problem persists, it is escalated to a responsible team.
Medical findings that have not yet been finalized remain registered as outstanding tasks and are submitted once approved.
For particularly time-sensitive medical information, additional procedures can ensure active notification and acknowledgment by an accountable recipient.
And what if the hospital does not yet know which medical practice will treat the patient next?
That does not change the fundamental ability to make the legally required information available through the ePA.
Authorized healthcare providers can retrieve it later without first having to know which hospital originally created it.
The patient’s freedom to choose their next doctor therefore does not become a technical obstacle.
Of course, successfully uploading a document to the ePA does not guarantee that the next clinician will read every relevant piece of information or apply it correctly.
That is why a second safety chain is needed.
This one concerns not the availability of medical documents, but the follow-through on necessary medical actions.
When a physician determines that additional specialist investigation is required, that information should not simply disappear when the hospital case is closed.
The system could automatically create a traceable follow-up task, consider available healthcare services, and, with the patient’s consent, assist with appointment arrangements.
The decision about whether further treatment is medically necessary remains a professional clinical judgment.
Whether the resulting organizational task is forgotten, however, should no longer depend primarily on human memory.
Patient rights and data protection must remain intact. Not every local note belongs in the ePA, not every doctor may access every piece of information without restriction, and valid patient objections must be respected.
Likewise, a technical upload failure must not result in someone who is medically fit for discharge being kept in hospital against their will.
But technical failures require documented fallback procedures and accountable follow-up.
The basic idea is simple.
Medical decisions remain human. The reliable execution of standardized follow-up processes is supported by enforceable technical safeguards.
This is not a vision from a science-fiction novel.
These are principles already familiar from professional IT operations and other safety-critical industries.
Who Watches the Watchdogs?
Even the best technical safety architecture cannot prevent every mistake.
Software can fail. Data can be assigned to the wrong patient. Interfaces can malfunction. People can document important information incompletely.
That is why automation alone is not enough.
We also need mechanisms capable of determining whether the safeguards themselves are functioning reliably.
In IT, these include monitoring, automated checks, structured incident reviews, and what are known as blameless postmortems.
Their primary purpose is not to identify someone to punish.
It is to understand why the system allowed a failure to occur and which changes could prevent it from happening again.
Google describes this approach in its publicly available Site Reliability Engineering handbook.
Aviation safety investigations follow a related principle. Regulation (EU) No. 996/2010 explicitly places the prevention of future accidents and incidents at the center of such investigations, rather than the determination of individual blame or liability.
Since October 2023, England has had the Health Services Safety Investigations Body, an independent organization investigating systemic risks to patient safety.
Germany also has medical risk-management systems, incident-reporting mechanisms, and various investigative instruments.
But those mechanisms do not automatically constitute one comprehensive, nationwide safety architecture capable of reliably detecting critical breaks in information and responsibility across different healthcare institutions, investigating their causes, and verifying that corrective measures actually work.
This is where modern safety policy needs to focus.
Not every routine deviation requires a major independent investigation. But recurring technical failures, critical interruptions in healthcare, and dangerous combinations of organizational weaknesses should be detectable and analyzable before they produce serious harm.
That would require suitable technical event logs, clear responsibilities, privacy-protecting analysis, and independent investigative capabilities.
Because the mechanisms responsible for controlling a safety system must themselves be subject to effective oversight.
Otherwise, we merely create another layer of procedures that work beautifully on paper.
And by now, we have had quite enough paper.
Eike, Marion, and the Responsibility of the System
Let us return to our two passengers.
Eike has the skills to recognize a failed transfer of medical information and may be able to repair it independently.
Marion does not.
There is nothing unusual or objectionable about that.
People differ in their knowledge, experience, physical abilities, health conditions, and capacity to understand complex technical relationships.
A society operating critical infrastructure must account for those differences.
It cannot assume that every patient is simultaneously a medical expert, IT administrator, legal specialist, and coordinator of their own healthcare.
Nor would an airline tell its passengers that compliance with aircraft maintenance regulations is ultimately, at least to some extent, their personal responsibility.
The safety architecture must work precisely because not everyone has the skills needed to compensate for its failures.
Eike and Marion should both be able to travel safely.
Both should be able to receive medical care.
And both should be able to trust that essential information will reach the people who need it, without first having to understand how every organization involved operates internally.
The necessary technical and organizational reliability must not depend on the luck of having the right personal skills.
This is not a demand for absolute safety. Absolute safety does not exist.
It is a demand that we stop accepting known, preventable failure mechanisms as unavoidable side effects of human collaboration.
And the issue goes beyond individual systems thinking.
It is not enough for Eike to identify a failure.
The system must be capable of receiving that insight, evaluating its significance, and translating it into a lasting improvement.
Otherwise, Eike simply becomes the person who repeatedly steps in wherever an organization has failed to fulfill its own safety responsibilities.
A kind of human emergency recovery program.
Convenient for the system.
Exhausting for Eike.
And potentially dangerous for Marion when no such recovery program happens to be available.
The Mistake We Can No Longer Afford
At the beginning of this article, several people were sitting around a table.
They reviewed the situation, exchanged information, assigned responsibilities, and made decisions.
This happens millions of times every day in businesses, government agencies, hospitals, airports, workshops, and data centers.
That collaboration is essential.
But its reliability cannot depend entirely on everyone involved being attentive, sufficiently rested, completely informed, and free from mistakes at all times.
Because human beings are human beings.
Even when they are highly trained, experienced, and exceptionally intelligent.
The decisive achievement of modern safety engineering is therefore not the complete elimination of human error.
It is the design of systems that detect, contain, and correct such errors as early as possible, before they produce serious consequences.
And wherever the necessary technical capabilities already exist, we must ask why using them should still depend on additional individual decisions, established habits, and organizational chance.
Germany’s electronic patient record is merely one example.
The underlying question concerns the critical infrastructure on which our entire society depends.
Who ensures that a task is not merely agreed upon but actually completed? Who notices when information is lost along the way? And who takes responsibility for failures that emerge only between the jurisdictions of different organizations?
Perhaps the most dangerous weakness in our modern society is not the individual human being who makes a mistake.
Perhaps it is the assumption that enough intelligent people will somehow ensure that a complex system functions reliably.
Because, remarkably often, that assumption appears to work.
Until it doesn’t.
And then we are left with the same question already familiar from aviation:
Why wasn’t the known weakness addressed before people were harmed?
An intelligent safety system does not wait for Eike to discover the failure. It works for Marion, too.
And if it doesn’t, Marion is not the problem.
The system is.
Sources and Technical References
Aviation and Safety Investigations
EASA — Easy Access Rules for Continuing Airworthiness, Part-145. In particular, 145.A.47 concerning maintenance planning, human performance limitations, and the transfer of relevant information.
EASA — Easy Access Rules for Air Operations. In particular, ORO.FTL concerning flight duty periods, rest requirements, and fatigue.
Regulation (EU) No. 996/2010. Investigation and prevention of accidents and incidents in civil aviation.
Healthcare and Patient Safety
Section 348, German Social Code Book V (SGB V). Transfer of treatment information to Germany’s electronic patient record by authorized hospitals.
Section 39, German Social Code Book V (SGB V). Hospital treatment and discharge management.
gematik — Frequently Asked Questions About Germany’s Electronic Patient Record. Information concerning automated uploads and the absence of a universal upload deadline.
World Health Organization — Patient Safety. International evidence on preventable harm associated with healthcare.
Health Services Safety Investigations Body — The Impact of Staff Fatigue on Patient Safety. Investigation report published April 24, 2025.
IT Reliability and Systems Intelligence
Google — Site Reliability Engineering: Postmortem Culture. Structured incident analysis and organizational learning from failures.
Törmänen, Hämäläinen, and Saarinen (2016) — Systems Intelligence Inventory. The Learning Organization, 23(4), 218–231.
Törmänen — Systems Intelligence: Measurement and Modelling. Aalto University.
Case Background and Editorial Disclosure
The UKE case described in this article is based on my own experiences and documented events between October 26 and November 5, 2026. The earlier cardiac emergency is recounted from personal memory.
Eike and Marion are illustrative characters used to demonstrate how differences in technical knowledge, health, and personal resources can affect a person’s ability to compensate for healthcare failures. Eike’s professional experience and the account of the hospital visit are closely based on my own.
The aircraft emergency and Marion’s medical circumstances are hypothetical scenarios. They are not presented as actual accidents, established medical injuries, or proof that a particular harmful outcome occurred.
The purpose of these comparisons is to examine potentially shared mechanisms of systemic failure, not to claim that aviation, IT, and healthcare operate under identical technical, legal, or organizational conditions.
Previous Article in the Series
ThePattern#A012DE — Die medizinische ePA-Katastrophe, die niemand untersucht!
ThePattern#A014EN is an English-language adaptation of the original German analysis, prepared for an international readership, including the United States and Australia. German legal and institutional terminology is retained where necessary and explained in context.