Notes

Questions behind the work.

Notes are where I turn a research question around before I decide what I think. I do not treat curiosity as expertise; I treat it as a reason to look closer. I share these working essays to make the reasoning visible enough to examine from another angle.

Open a question to read the longer view. The response button is there for questions, disagreements, and additions.

01Patient experience

Why do most patients leave without telling us what they really experienced?

A closer look at the silent gap between a patient visit, an honest response, and the reason someone chooses to return.

Read the note

Most patients never leave feedback. That silence does not tell us whether the experience was good or bad; it may simply mean that the feedback loop asked for effort after the visit and gave the patient no reason to be candid. Without that response, a hospital can mistake quiet for satisfaction and miss the moments that decide whether someone returns.

We shaped a patient-engagement system that uses lightweight gamification and rewards to make honest feedback easier to give. It can route themes toward the right service-recovery or experience owner, while keeping clinical escalation, safeguarding, grievance handling, and emergency care outside its scope.

The larger opportunity is a patient-retention system built around a return loop: show patients that their feedback changed something, learn what would make the next visit better, and create a reason to choose the same hospital or clinic again. The unresolved design question is how to reward candor without rewarding praise, and how to build retention without making care feel like a loyalty programme.

What would you add from your own work or experience?

02Clinical AI

When should a clinical AI system say, “not here”?

A closer look at how a safe refusal can protect a clinician’s time, a patient’s safety, and the handoff when a case exceeds the model’s intended use.

Read the note

An AI answer can feel helpful even when it is answering the wrong question. In a clinical workflow, a confident response to incomplete context can consume a clinician’s time, hide uncertainty, and send a patient toward a path no one intended.

In the AI Firewall, AI Routing Gateway, and smart-glasses work, I am exploring bounded routing, fail-closed behavior, explicit handoffs, and synthetic tests for missing context, tool failure, and requests outside intended use.

The impact is not measured only by how often a model answers. It is measured by whether the system can recognize when another person must take over, explain that boundary clearly, and make the safer next action easy to follow.

What would you add from your own work or experience?

03Privacy

Can a privacy boundary become something a patient can feel?

A closer look at what should happen before sensitive information reaches a cloud service, and how visible controls can protect trust.

Read the note

People cannot meaningfully consent to a cloud call they cannot see. Sensitive details can leave through a prompt, a log, or an overlooked field long before anyone notices that the boundary has moved.

The AI Firewall is a local gateway prototype that inspects outbound JSON before cloud calls, with allow, redact, and block decisions plus metadata-only audit events. It explores whether privacy can become behavior the team can test and the operator can understand.

The impact is a system that fails safely before exposure and asks for permission instead of silently guessing. A privacy boundary becomes real when the person using the workflow can see it, question it, and trust what happens next.

What would you add from your own work or experience?

04Evidence

What breaks between a good AI demo and a trustworthy system?

A closer look at the failures that appear after the demo: bad routing, weak provenance, unsafe tools, slow responses, and people who cannot tell what happened.

Read the note

A demo can be right once and still fail in a real workflow. The model may choose the wrong specialist, call a tool with unsupported arguments, lose the source behind an answer, respond too slowly, or leave an operator unsure whether the system actually did what it claimed.

SystemBench explores evaluation across task success, reliability, groundedness, tool correctness, safety, performance, operability, and human interaction. The aim is to make the failure visible while there is still time to change the design.

The impact is a better decision about what to ship, what to constrain, and what to keep researching. Evaluation should not be a larger checklist; it should make every claim proportionate to the behavior the system has demonstrated.

What would you add from your own work or experience?

05Translational research

When does a promising signal become a useful test?

A closer look at the decisions that move a health-tech idea from an exciting signal toward a claim clinicians and patients can actually use.

Read the note

Non-invasive sensing can make a biological signal feel like a shortcut to a diagnosis. But a signal becomes useful only when we know what it is being compared against, which people it may fail for, and what decision it is supposed to improve.

BioVOC, NeoGlycemia, and metabolic-risk research planning point to the same discipline: define intended use, reference standard, confounders, provenance, and validation before making a clinical claim.

The impact is not just a device that detects something interesting. It is a study design that tells clinicians when to trust the result, when to ask for another measure, and what to build next without overpromising to the patient.

What would you add from your own work or experience?

06Clinical prototypes

Can a prototype show when it should not be trusted?

A closer look at how poor capture, missing data, and invalid states should change the next action before a measurement becomes a conclusion.

Read the note

Measurements often look more certain than they are. A blurry scan, a lost device connection, or missing context can still produce a number that feels precise enough to act on.

The Clinical LiDAR Framework and Smart Glasses simulator explore how a tool can show poor capture, missing data, or an invalid state before a measurement is mistaken for a conclusion. The prototype uses synthetic inputs, calibration, quality gates, and vendor-neutral contracts to make those limits testable.

The impact is a safer next step: ask for better input, hand the case to a person, or stop the workflow. Uncertainty should be visible where a decision is made, not hidden in a disclaimer after the decision.

What would you add from your own work or experience?

07Personalization

A specific question

If one of these questions overlaps with work you are already doing, the most useful message begins with the specific problem rather than a generic introduction.