Medical ethics

In one line

Four principles — autonomy, beneficence, non-maleficence, justice — have organised medical ethics for decades. The reason they belong in a health informatics knowledge base is simple: every design decision you make is an ethical decision, and most of them are never labelled as one.

The four, and what they mean at a keyboard

Autonomy — the patient decides about their own body and their own data. In software this is consent, and it's where design does its quietest damage. A consent flow with a bright "Accept" and a grey "Manage preferences" is not neutral. You have made a choice about someone else's autonomy and dressed it as a layout.

Beneficence — act for the patient's benefit. The uncomfortable question for our field: whose benefit does this feature serve? A great deal of health software optimises for billing capture, throughput, or an administrator's dashboard. Those aren't illegitimate. They're just not the patient, and pretending otherwise is where the dishonesty starts.

Non-maleficence — first, do no harm. The informatics translation is alert fatigue. Every warning you add spends attention that is finite and shared. An alert that fires ten times a day and is right once has trained a clinician to dismiss the one that mattered. You did not add safety; you moved harm somewhere it won't be attributed to you.

Justice — fair distribution of benefit and burden. This is the one software breaks at scale, silently. A model trained on one population and deployed on another. An app that assumes a smartphone, data, literacy, and a language. A pulse oximeter calibrated on light skin. None of these are malice. All of them distribute benefit unevenly, and the people who lose are usually the ones already losing.

The principles conflict — that's the point

Newcomers expect a decision procedure. There isn't one, and the framework isn't pretending there is. Its value is that it names the tensions so you argue about the right thing:

• Autonomy vs beneficence — the patient refuses the treatment that would help. Classic, and autonomy generally wins in modern practice.
• Autonomy vs justice — a patient withholds data from research that would benefit thousands. Both positions are defensible.
• Beneficence vs non-maleficence — the alert that saves one life and exhausts a thousand clinicians. This one is ours, and we usually resolve it by not measuring the second half.

The framework doesn't tell you the answer. It tells you which argument you're actually having, which is more than most product meetings manage.

Where informatics has its own ethics

Some problems are genuinely new, and the four principles stretch to cover them rather than answering them:

• Aggregation. Data that is harmless individually becomes identifying in combination. Consent given for each piece was never consent for the composite.
• Permanence. A clinical error in paper faded into an archive. In a database it propagates, is copied to a warehouse, trains a model, and is quoted back for a decade.
• Scale of error. A clinician's mistake harms one patient. A rule with a bug harms everyone it fires on, simultaneously, before anyone notices.
• Diffusion of responsibility. When a closed-loop system or an algorithm decides, the decision has been spread across a tuning parameter, a validation study and a procurement choice. Everyone contributed; nobody decided.

That last one is the defining ethical problem of our field, and it's why governance is an ethical instrument rather than paperwork.

For the person building it

Two habits worth more than a policy document:

Ask who is absent. Whose experience isn't represented in the room, the data, or the test set? That's where injustice enters, and it enters by default rather than by decision.

Name the trade-off out loud. "This alert will fire 400 times a month to catch maybe two real events — is that trade worth it?" is an ethical question wearing a product hat. Asking it in the meeting is the whole job. The teams that never ask it aren't unethical; they just never noticed they were deciding.