Case Study — Digital Health
SATUSEHAT Resep: closing the data gap in Indonesia's pharmacy network.
"When a patient walks out of a pharmacy, their medication should follow them — not disappear into a paper trail that no one can trace."
The Scene Before This Product Existed
Picture a pharmacist at a community pharmacy in South Jakarta. A patient walks in and hands over a piece of paper — a handwritten prescription from their doctor, folded and softened from being carried in a wallet for two days. The pharmacist squints at the handwriting, works out the drug name, pulls the medication from the shelf, and dispenses it. Transaction complete.
Except that "complete" is a generous word for what actually happened. No record of this transaction existed outside that pharmacy's own logbook, if they even kept one. The patient's doctor at another clinic wouldn't know what had been dispensed. The Ministry of Health had no visibility into it. And if the patient came back the following week and claimed they never received the medication — or received the wrong one — there was no reliable way to verify anything.
Multiply this across more than 47,000 pharmaceutical distribution points spread across Indonesia's 17,000 islands, and you start to understand the scale of the problem this project was trying to solve.
The Real Problem
Indonesia's national health platform, SATUSEHAT (Satu = one, Sehat = healthy), was built to be the single source of truth for patient health data across the country. Hospitals, community health centers (Puskesmas), and clinics were all being integrated into this ecosystem. But there was a blind spot: independent pharmacies.
When a patient received a prescription from a doctor and filled it at a hospital pharmacy, that dispensing data was captured in SATUSEHAT. When they filled the same prescription at a standalone community pharmacy — which is where a large portion of the population actually gets their medication — it wasn't. The patient's health record in SATUSEHAT was, in those cases, missing a whole chapter.
This created two compounding problems that couldn't be ignored:
For patients: Their medication history was incomplete. A doctor at a different facility could prescribe something without knowing what the patient was already taking, raising the risk of interactions and duplications.
For the Ministry of Health: Without dispensing data from pharmacies outside the hospital system, accurate monitoring of national drug distribution was effectively impossible. Strategic decisions about medicine availability, stockpile needs, and controlled substance oversight were being made with gaps in the data.
The physical prescription paper itself added its own layer of fragility. It could be lost. It could be damaged. It could be misread. And when it was, the consequences landed entirely on the pharmacist and the patient.
My Role
This project sat at the intersection of a government mandate and a genuine operational gap. Our company was commissioned to design a portal that would allow pharmacies to record and submit dispensing data directly into the SATUSEHAT ecosystem.
As the Product Designer on this project, my work covered two main areas:
Research — Working alongside our UX Researcher, I helped understand the day-to-day workflows of pharmacists and pharmacy staff: how they currently handled prescriptions, where friction and errors crept in, and what they actually needed from a tool like this in order to change their workflow.
Design — Translating those findings into wireframes and an interactive prototype for the MVP. This meant making calls about which features belonged in the first release and what each one should actually look and feel like.
In practice, I also found myself doing a third thing that doesn't show up in a job title: acting as a filter between a large, opinionated group of stakeholders and a product that needed to stay focused and usable. More on that later.
Getting to Know the People Behind the Counter
Before any sketching happened, we made a deliberate choice about our research process: because this product was built exclusively for licensed pharmacy personnel, we would only research and test with pharmacists and pharmacy staff. No stand-ins.
That decision took more effort — scheduling interviews with pharmacists means working around their shifts, which aren't nine-to-five — but it kept us honest about what we were actually designing for.
A few things we learned that shaped everything that followed:
Pharmacy staff work in a hierarchy, not a flat team. Every pharmacy has a licensed Apoteker Penanggung Jawab (Pharmacist-in-Charge) who holds professional and legal accountability for what's dispensed. Under them are assistants and administrative staff who handle much of the day-to-day work. Any digital tool that didn't reflect this division of responsibility would either create security vulnerabilities or put administrative burden in the wrong place.
The prescription paper functions as a working document, not just documentation. Pharmacists don't read a prescription once and put it away. They glance at it while counting pills, refer to it while labeling, check it again before handing medication over. The paper lives in their hands throughout the process. A digital replacement needed to work the same way — always visible, easy to reference without navigating away.
First impressions carry weight. Pharmacists are professional users who expect tools to work reliably. A product that crashed, loaded slowly, or made them question whether their data was actually being submitted correctly would lose their trust quickly and get abandoned.
The Product We Built
The MVP covered seven core areas. Rather than walk through them as a feature list, I want to explain the reasoning behind each — because most of the interesting design work happened in the why, not the what.
Getting In: Login That's Secure Without Being Hostile
We couldn't use a standard username-and-password setup. Pharmacists dispensing controlled medications through a national health system needed to be verified professionals, not just registered email addresses.
The solution was to tie registration and login to SATUSEHAT SDMK, the Ministry's professional credentials portal for health workers. Only staff who had verified their pharmacy license there could access this portal. Once inside, they'd also select which health facility they were currently working at — because data accuracy required knowing where each dispensing transaction actually happened.
This created a more complex onboarding than users were used to. We knew that. We'll come back to it.
Who Can Do What: Role-Based Access Control
The pharmacist-in-charge needed meaningful control over their team's access. We built a management panel where they could add staff members, assign appropriate access levels, and revoke access when needed — for example, when a staff member left.
This wasn't just bureaucratic housekeeping. In a setting where every dispensing record becomes part of a patient's national health history, accountability matters. Knowing exactly who submitted what, and ensuring only qualified staff could submit certain types of records, was a functional safety requirement.
Finding the Prescription: Number or QR Code
This feature replaced the paper prescription as the entry point for the entire dispensing workflow.
After every doctor's visit, patients receive a National Prescription Number (Nomor Resep Nasional) in their SATUSEHAT Mobile app. At the pharmacy, they either read out the number or show the QR code from their phone. The pharmacist enters the number or scans the code — and the full prescription appears, pulled directly from SATUSEHAT. No paper needed.
The QR option was particularly important. It meant patients didn't need to remember or write down anything. The prescription lived in their phone, couldn't be lost, and couldn't be damaged. For patients who regularly dealt with chronic illness prescriptions or multiple medications, this was a genuine quality-of-life improvement.
The Prescription View: Everything the Pharmacist Needs, In One Place
We structured this screen the same way a pharmacist reads a prescription: patient and administrative information at the top (name, date, prescribing doctor), then a table of medications below.
For each drug, the table showed: the drug name, the prescribed quantity, the number of iters (how many times the prescription can be refilled), and the remaining doses still available if the patient had refilled before.
Pharmacists could expand any row to reveal additional clinical details: dosage timing, drug formulation, and any special instructions the doctor had noted. This mirrored how they already used the physical prescription paper — something to dip into for specific information while handling the medication, not a document that demanded full attention.
Redemption History: Know What Came Before
Before handing over medication, a pharmacist benefits from knowing what the patient has already picked up. Has the first refill already been dispensed elsewhere? Were they given a different formulation last time?
The redemption history panel surfaced exactly this context — a log of all previous dispensing events tied to the current prescription. This supported pharmaceutical review: the professional act of a pharmacist checking the full medication picture before proceeding. It transformed the portal from a transaction tool into something closer to a clinical decision aid.
The Dispensing Itself: Structured, Flexible, Accountable
The redemption flow was where the most interaction design work happened.
Pharmacists press "Redeem" for each drug on the prescription. If a drug has already been fully dispensed, the button becomes inactive — a simple but important guardrail against accidental double-dispensing. Within the redemption form, they can choose to dispense exactly as prescribed or select a substitute drug (a standard practice when the prescribed brand isn't in stock).
The drug search field queries a standardized national drug database maintained by the Ministry of Health. This was a deliberate design decision with strategic implications: every drug that can be selected through this portal is one that the government officially recognizes. At national scale, this means SATUSEHAT Resep becomes not just a dispensing tool but a real-time data source for monitoring which medications are actually being distributed across the country — and in what quantities.
A reference panel on the right side of the screen kept the prescribing doctor's original instructions visible while the pharmacist was filling in the dispensing form, directly replacing the function that the physical prescription paper served.
Sending It to SATUSEHAT: The Moment It All Connects
After all medications have been entered, the pharmacist submits the record to SATUSEHAT. A confirmation screen appears first, showing everything about to be sent — a final check before any record becomes permanent.
Once submitted, the data is live in the SATUSEHAT ecosystem. The patient's SATUSEHAT Mobile app is updated with their new dispensing record. They can open their phone and see exactly what they received, when they received it, and from where.
That moment — a patient's phone reflecting a complete medication history — was the end state we were designing toward. Not just "data saved to a database." A patient who actually knows what they've taken.
The Messy Middle: Stakeholders, Scope, and What Got Cut
No product that touches government policy moves in a straight line. This one didn't either.
Throughout the design process, input came from a wide range of stakeholders — ministry officials, policy teams, pharmacy industry representatives — each with a different idea of what this product should prioritize. The ideas were often legitimate. The challenge was that they frequently conflicted with each other, with the timeline, and sometimes with what actual pharmacists needed.
The PM and I developed a working approach to manage this: every incoming request got assessed on two dimensions — urgency (does this meaningfully affect what users can do right now?) and effort (how much development capacity does this require?). High urgency and feasible effort went into the current sprint. Low urgency or high effort got documented, communicated to stakeholders with a clear rationale, and deferred to a post-launch iteration.
The key to making this work in practice was framing. Rather than saying "we can't do this," we learned to say: "We don't have user data to support this prioritization yet — let's validate what we have in the first release and then add this with evidence behind it." Most stakeholders respond to that framing. Design decisions feel less like personal opinions when they're grounded in a process.
There were moments of friction. There were requests we declined and had to defend more than once. That's a normal part of building products inside institutions with multiple competing interests. What mattered was keeping the actual users — pharmacists at their counters, handling medications — at the center of every conversation.
Testing It in the Real World
Before any broader rollout, we piloted the product at several hospitals and pharmacies in the Jakarta area. The goal was to catch real problems in a manageable context — not to validate that everything was perfect.
A few things stood out from that process.
What worked well
The majority of pharmacists and pharmacy staff who participated in the pilot completed their assigned tasks successfully and independently. The core dispensing flow — finding a prescription, reviewing it, redeeming medications, submitting the record — held up. Most users said they understood the product fairly quickly once they were inside it.
The expected friction
Network reliability was a recurring issue. The portal connects to a large national health database, and on weak or unstable connections, the experience degraded noticeably. This wasn't a design failure, but it was a real user experience problem — designing for Indonesia means accounting for connectivity that isn't always ideal.
The insight we weren't prepared for
The biggest source of confusion wasn't any feature inside the portal — it was getting into the portal. The SDMK-based authentication flow was disorienting for people used to just entering an email and a password. We still believe the security requirement was correct; the pilot showed the experience of completing that step needed more support.
What Came Out of It
The final design went to development and into the initial pilot rollout. The product addressed the core gap it was built to close: dispensing records from pharmacies that previously had no connection to SATUSEHAT could now be captured, standardized, and fed into the national health data ecosystem.
From the pilot, key takeaways included:
Most participating pharmacists completed core dispensing tasks independently on first use, without needing to be guided through the flow. The standardized drug database search reduced ambiguity in drug selection compared to paper-based processes — pharmacists were selecting from a verified, government-approved list rather than hand-interpreting a doctor's shorthand. The primary opportunity for improvement was the onboarding experience: the SDMK verification step needed better in-context guidance to reduce confusion for first-time users.
At the broader level, this product contributed to a national initiative where the stakes were genuinely high. SATUSEHAT's goal of integrating data from health facilities across Indonesia — with pharmacies as a newly connected node — wasn't just a technical milestone. More complete medication records mean fewer preventable errors, more accurate prescribing, and better oversight of drug distribution across a country of 270 million people.
Research consistently shows that transitioning from paper-based to digital prescription systems can reduce medication errors by 30 to 84%. SATUSEHAT Resep was designed to make that transition possible for the pharmacy sector — and to ensure that every dispensed medication left a trail that actually mattered.
If I Were Starting Over
Looking back, a few things I'd approach differently.
Push harder on the onboarding problem, earlier
The authentication complexity was known from the beginning, but it was treated as a constraint to design around rather than a problem to solve. The pilot showed that users struggled with it in ways we could have anticipated and mitigated earlier. I'd spend more time exploring whether an equally secure but less cognitively demanding first-time experience was possible before accepting the status quo.
Design more explicitly for bad network conditions
Building a data-heavy portal in a country with significant connectivity variation requires specific choices about loading states, error handling, and how to gracefully handle a submission when the signal drops mid-way. Some of this was addressed, but it deserved earlier and more deliberate attention.
Build in more structured decision-logging during stakeholder reviews
There were periods where too many competing inputs were in flight at once, with no clear documentation of what had been decided and why. This created rework and occasional confusion about direction. A more disciplined review cadence — with written decisions and rationale — would have reduced the noise and kept everyone more aligned.
This project reminded me that design inside complex institutions is as much about navigating organizational reality as it is about the craft of interface design. The pharmacist who successfully looked up a prescription and submitted a dispensing record during the pilot — without anyone helping them — made the complexity of getting there feel worth it.