Interactive Document Map
A connected view of the guideline: policy structure, knowledge foundations, and frontline roles. Use this to orient yourself before you pick a specific human moment to design for.
End-to-end strategy
The full sequence behind the document — this doesn't change by section.
Click a section to see what's inside, what it assumes, and its internal logic.
Selected section
{sel.purpose}
What lives here
Internal logic
Underlying assumption
{assumptions[sel.id]}
Prerequisite knowledge
What you need to understand before the policy logic makes sense.
{item.summary}
Frontline execution
Composite personas built from Bhutan healthcare sources. Each has a "day arc" (what their shift looks like) and "touchpoints" (specific moments the guideline cares about).
{/* Persona tabs */}{persona.framing}
Sources used for this persona
What they need to remember
Guideline references
Failure risk if missed
{tp.failure}
Design gap
{tp.gap}
Reference documents
The Bhutan government documents used to build the personas and validate the guideline analysis.
Prioritization layer
Research from similar healthcare settings tells us where infections actually concentrate. The guideline's weak spots tell us where the policy doesn't help enough. The intersection is where the highest-value design problems sit.
Where infections concentrate (research)
From evidence across lower-resource hospital settings similar to Bhutan's
Where the guideline doesn't help enough
Policy gaps and packaging problems in the Bhutan MDRO guideline
The highest-value design problems sit at the intersection:
Where research says infections actually happen (left column) AND where the guideline doesn't adequately support the person in that moment (right column). A touchpoint that scores "Weak" on coverage AND sits on a high-burden pathway is a stronger design target than one that scores "Weak" but affects a low-frequency scenario.
Implementation reality
Your solution has to work in this setting. Bhutan has real digital infrastructure at referral hospitals, but don't assume uniform maturity everywhere.
You can assume exists (at referral hospitals)
You should not assume
Implementation ladder — from simplest to most complex
The question is not "what is theoretically possible?" — it's "what is reliable enough to support workflow in Bhutan now?"
{item.example}
Core design principle
The operational formula for your design:
Staff do not need the whole MDRO guideline in the middle of the day. They need small, role-specific supports at the moments where failure is most likely.
Sprint 3 starting point
1. Orient: Read the overall policy logic and skim the 8 sections to get the system picture. Don't try to memorize — just get the shape.
2. Understand the stakes: Read "Where Failures Hit Hardest." This tells you where infections actually concentrate and where the guideline leaves gaps. Use this to aim at high-impact problems, not just interesting ones.
3. Pick a role: Choose doctor, nurse, or support staff. Read their day arc first (how the shift flows), then look at the touchpoints (where the guideline intersects their real work).
4. Find your moment: Look for a touchpoint that sits on a high-burden pathway AND has a "Partial" or "Weak" coverage badge. That intersection is where design effort matters most.
5. Check your constraints: Before designing a solution, check the implementation ladder. What level can Bhutan's system reliably support? A laminated door card that gets used beats an app that doesn't get built.
6. Stake your problem: Use the touchpoint details — what they need to remember, the failure risk, the gap — to write a specific problem statement. Apply the design rule: don't add guidance, add support at the memory-failure point.