Module 5 Handout — Ethics, Governance & the Local Regulatory Context

How this module works. Take the short Preview Quiz first — five minutes, ungraded. Then work through this handout (or the companion slide deck) at your own pace. Section C's checklist is the practical core of the module — Section E asks you to apply it to a proposed tool before reading the discussion, so don't skip ahead. Finish with the Post-Test.

By the end of this module you will be able to:

Apply data-privacy and patient-consent principles to AI tool use in the local health system context.
Identify what governance currently exists — or doesn't — for AI-enabled clinical tools in Timor-Leste, and what that means for individual physician responsibility.
Assess a proposed AI tool for fitness in a setting where imported validation data may not transfer.

Section A — Data Privacy and Patient Consent in AI-Assisted Care (KNOW)

Modules 2 and 3 put patient data into AI systems without dwelling on where that data actually goes. An ambient scribe hears a consultation. A diagnostic support tool receives a symptom description or an image. Both processes happen inside a tool that isn't the clinic's own record system — and the question this section asks is simple: did the patient actually consent to that, and do you know enough about the tool to tell them honestly what you're doing?

Ordinary clinical consent — the patient agreeing to be examined, treated, and have a record kept — doesn't automatically extend to a specific third-party AI tool processing their data in a specific way. That's a separate, narrower question, and it's one most clinicians haven't been trained to ask.

Question to ask about any tool	Why it matters
Where does the data go?	Many cloud-hosted tools process data on servers outside Timor-Leste, under a different jurisdiction's data-protection rules — or none in particular.
Is it used to train future models?	Some consumer-grade AI tools retain and reuse conversation data by default. Clinical use typically calls for an enterprise or opt-out configuration, not the free consumer version.
Can identifiers be avoided or stripped?	De-identifying what you enter, where the tool's workflow allows it, limits exposure even when the tool's own data practices are unclear.
Does the patient know, and can they decline?	A patient who was never told a recording tool or chatbot was involved in their care hasn't meaningfully consented to that specific use, even if they consented to being treated.

Baseline principle

De-identify what you reasonably can. Know, at least in outline, where a tool's data goes before you rely on it routinely. Tell the patient plainly when a tool is materially involved in their care — the same disclosure habit Module 3 Section F built for AI-assisted findings applies here to AI-assisted data handling.

Continuity from Module 2 The ambient scribe you practiced with in Module 2 is the clearest everyday example: it's listening to the whole encounter, not just the note-worthy parts. Whether that audio is processed locally or sent to a remote server, whether it's retained afterward, and whether the patient was told it was recording — those are exactly the questions this section is asking you to start treating as routine, not exceptional.

Silence isn't consent A patient not objecting to a device or a screen in the room is not the same as an informed choice to have their conversation or their data processed by a third-party AI system. If you can't explain in one sentence what the tool does with the data, you're not yet in a position to say the patient consented to it.

Section B — What Regulatory Oversight Exists in Timor-Leste Today, and What Doesn't (KNOW)

Module 4 closed by pointing here directly: most published guidance on clinical AI assumes a regulatory scaffolding — a clearance pathway, a device registry, an institutional AI governance committee — built for health systems with the staff and infrastructure to run one. As of this writing, Timor-Leste has no AI-specific regulatory framework of that kind for clinical software. That's not a gap unique to this country; even well-resourced health systems are still building AI-specific oversight. But the absence is real, and it's the starting fact this section works from.

What does exist, and continues to apply in full regardless of whether a tool involves AI: general standards of medical practice, the ordinary duty of care, whatever data-protection and patient-rights principles already govern health records in Timor-Leste, and your own professional accountability as a licensed physician. An AI-specific gap in the rules doesn't create a gap in your responsibility — it just means there's no AI-specific safety net to lean on if something goes wrong.

This section gives you a framework for thinking about that gap — not a legal ruling on any specific tool or situation. For anything institution-specific, urgent, or genuinely uncertain, the Ministry of Health, your professional licensing body, and your own institutional leadership are the authorities to consult directly, not this handout.

Because this lesson is delivered as a live seminar, treat this section as the orienting summary rather than the full discussion. Come with your own answer to these prompts:

1. When a new AI tool was last introduced at your institution — a scribe, a triage tool, anything — who actually made that call, and what oversight, if any, was applied before it went live?

2. If a locally-used AI tool produced a harmful output tomorrow, is it clear to you who within your institution you'd report that to?

Section C — Evaluating a New AI Tool Before Adopting It: A Practical Checklist (FIND)

This is a tool for the moment a new AI product is proposed — to you, your clinic, or your institution — before it's adopted. It's deliberately not something to memorize; it's something to pull up and run through, the same way you'd consult a reference rather than recall it from memory.

The Adoption Checklist

What is it validated on? Population, setting, and disease prevalence — and how different is that from where you actually practice?
Where does patient data go, and who else can access it? Section A's questions, applied at the point of adoption rather than after the fact.
What happens when it's wrong? Does it fail visibly, with a flag or a low-confidence signal, or does it fail silently, the way Module 3's tools sometimes did?
Is there a real human-override path? Not just a theoretical one — can a clinician actually override it inside a normal, time-pressured encounter?
Who is accountable if the output contributes to harm? The vendor, the institution, or the individual clinician — and is that answer written down anywhere, or assumed?
Does it work on the connectivity and hardware you actually have? A tool that needs constant high-bandwidth connectivity may simply not function as advertised in many Timor-Leste settings.
What does it cost, on an ongoing basis, and who is paying? A free pilot and a sustained subscription are different commitments — the second is the one that matters.
Has anyone locally used it, and can you ask them directly? A colleague's actual experience is worth more than a vendor's marketing material.

In the live workshop, you'll run this checklist against a real or proposed tool from your own setting — bring one in mind if you have it.

Section D — Professional Responsibility in a Governance Gap (KNOW)

Module 4 established the individual version of this principle: using an AI tool doesn't shift accountability away from the physician who acts on its output. This section extends the same idea one level up — to what a physician's responsibility looks like when the surrounding system, not just a single decision, has no AI-specific governance to fall back on.

In a governance gap, professional responsibility runs in two directions at once: exercising ordinary judgment carefully in the absence of AI-specific rules, and, where you're in a position to, contributing to building the oversight that doesn't yet exist rather than treating the gap as someone else's problem.

Why this section exists This course was built without a ready-made regulatory answer to hand you, because one doesn't yet exist locally. That's not a flaw in the material — it's the actual state of the field, and the honest response to it is a framework for judgment and advocacy, not a false sense of settled rules.

Section E — Worked Exercise: Applying the Checklist (THINK)

Proposal A regional health office is considering a smartphone-based AI tool that screens photographs of skin lesions and flags ones warranting urgent referral. It was developed and validated on patient populations in Southeast Asia, though not specifically in Timor-Leste, and is being proposed as a way to extend dermatology triage capacity to rural health posts that currently have none. The office is asking for your clinical input before deciding whether to pilot it.

Before reading on — run Section C's checklist against this proposal yourself. Where are you most confident, and where are you most uncertain?

Discussion — reasoning through a few of the items

Validation population: "Southeast Asia" is closer to Timor-Leste than a tool validated in Europe or North America would be, but it's still not the same as validation on local skin tones, disease prevalence, and presentation patterns — this is a real gap to name, not a disqualifying one on its own, per Module 3's validation-gap habit.
Failure mode: A triage tool that under-flags a genuinely urgent lesion fails silently and dangerously; a tool that over-flags creates unnecessary referral burden on an already-stretched system. Which failure mode the tool leans toward, and whether that's disclosed, matters as much as its overall accuracy.
Override path and end users: If this is used by non-specialist staff at rural health posts rather than by a dermatologist, the override path has to be usable by someone without dermatology training — a theoretical override that requires specialist judgment isn't a real override in this setting.
Accountability: A regional-office-level rollout raises the accountability question at an institutional scale, not just an individual one — worth surfacing explicitly before a pilot begins, not after an adverse outcome forces the question.

Notice that none of this says "adopt it" or "reject it" — the checklist's job is to surface the right questions clearly enough that whoever ultimately decides is deciding with real information, not a vendor's pitch alone.

Section F — Advocating for Locally Validated Tools (THINK)

Identifying a gap is only useful if it leads somewhere. This section is about the language for raising what Sections A through E equip you to notice — with leadership, with vendors, and with regulators — in a way that opens a conversation rather than closing one down.

Raising a validation concern with institutional leadership

Say: "Before we roll this out system-wide, I'd like to see how it performs on a small local pilot — can we test it against outcomes we already know, on our own patients, before wider adoption?"

Avoid: Framing it as a blanket refusal ("we shouldn't use any of these tools") — that forecloses a conversation about legitimate benefit rather than opening one about safe adoption.

Engaging a vendor or ministry contact

Say: "Can you share what population this was validated on, and whether there's a plan for local validation here?"

Avoid: Assuming silence or a vague answer means there's no gap — the absence of a clear answer is itself the finding worth documenting and acting on.

In the live group discussion, you'll compare notes on what has actually worked, or hasn't, when advocating for this in your own institution — the practical obstacles are usually more instructive than the principle itself.

Layer	What this module put there
KNOW	Data-privacy and patient-consent principles for AI tool use; the current state of AI-specific regulatory oversight in Timor-Leste and why its absence doesn't reduce accountability; the physician's role in helping close that gap rather than just working around it.
FIND	A practical, reusable tool-adoption checklist covering validation population, data handling, failure mode, override path, accountability, connectivity fit, cost, and local track record.
THINK	Applying the checklist to a real proposed tool, and practiced language for advocating for locally validated tools with leadership, vendors, and regulators.

Ethics, Governance & the Local Regulatory Context