Scalable digital solution connecting hypertensive patients and nursing teams in a managed care environment.
Health-tech startup focused on safe, human-centered communication between healthcare companies, physicians and patients.
Special Patient Monitoring Team (MOPE in Portuguese). Nursing team dedicated to remotely monitoring patients from the health insurance company São Cristóvão Saúde (based in Brazil).
The MOPE Team needed to increase patient coverage without increasing nurse workload or clinical risk using a digital solution as a way to expand and enhance its reach, capacity and quality of care.
Align product scope with clinical constraints, operational capacity, and measurable outcomes for remote hypertension programs.
Nurses needed workflows that reduced cognitive load during remote follow-ups while keeping patients engaged between in-person visits.
Clear, timely communication channels and lightweight tasks patients could complete without friction on common devices.
Why was this important?
As patient volume increased, the monitoring team could not scale manual follow-ups without compromising care quality and nurse workload.
Provide safe, scalable, and engaged care for nursing teams monitoring hypertensive patients beyond traditional follow-ups.
To understand the context, exploratory conversations were conducted with the monitoring team (team leaders, nurses, and attendants) to learn how patient monitoring was currently performed, the challenges faced, and unmet needs.
For patient context, the MOPE team helped to select patients that could be part of the pilot solution.
Research focused on understanding existing monitoring workflows, patient engagement, tracked health indicators, data organization, and communication during follow-up. In parallel, we reviewed the hypertension care protocol to identify the key events and indicators that would guide the solution.
Health Indicators
From Insights to Design Decisions
Interviews revealed informal workarounds and unclear prioritization. The protocol defined indicators and thresholds, pointing toward a modular, indicator-specific system with direct communication channels.
The solution was structured around a core insight from research: different health indicators require different monitoring logic. Rather than a single linear flow, the system was designed as a modular architecture where each indicator defines its own communication channel, frequency, and response behavior.
Based on each indicator’s type, relevance, and frequency, different patient contact channels were defined for each monitoring context. This ensured that health data was exchanged through the most appropriate channel, giving nurses and the system the right conditions to act on what patients reported.
Patient monitoring was structured as a set of independent subflows, each designed around a specific indicator’s clinical urgency, measurement frequency, and the patient’s ease of interaction. Together, all subflows form the complete monitoring architecture.
With multiple indicators and explanations to introduce, onboarding was deliberately spread across the first week of app use. Each task and orientation was delivered only when contextually relevant, reducing early friction and improving long-term adherence.
Each health indicator was mapped to the most appropriate contact channel based on its urgency, frequency, and content type, forming the modular foundation of the monitoring system.
The appointment confirmation sub-flow illustrates this logic: if a patient confirms, the system schedules a reminder automatically. If there is no response, escalation triggers nurse intervention after defined time thresholds.
Nurses needed immediate visibility into patient-entered data and timely alerts when readings crossed clinical thresholds. I advocated for contextual triggers that gave the monitoring team a clear, objective view of each patient throughout the monitoring period, enabling faster risk recognition and appropriate response.
Translating Architecture into Tangible Design
With the monitoring logic, communication channels, and interaction points between nurses and patients defined, the work moved into translating these decisions into user flows and low-fidelity interfaces.
The end-to-end flow connects patient tasks, nurse chat, and escalation paths so teams can follow a single journey from first contact through resolution.
The MOPE web workspace brings together patient lists, real-time messaging, and clinical context in one place—aligned with how nurses monitor cases today.
To maximize learning speed during early validation, patient-facing screens were implemented using Web Views instead of native components. This decision significantly reduced deployment friction, allowing the team to iterate on UX, content, and interaction patterns without repeated app store releases and enabling faster response to insights from testing.
I collaborated closely on the definition of the backend data model, advocating for a generic and extensible structure. This approach allowed indicators, flows, and clinical protocols to evolve over time without major structural changes, supporting both scalability and long-term product adaptability.
Rather than automating processes prematurely, early testing relied on manual triggering of tasks and alerts, with the monitoring team acting as test patients. This deliberate choice prioritized understanding real workflows and refining UX and system logic before committing to automation, reducing downstream rework and risk.
Modeling for evolution
Advocating for a generic backend model involved close collaboration with engineering to balance short-term delivery pressure with long-term flexibility. The indicator-based flow model established a reusable foundation that could support additional conditions beyond hypertension without redesigning the system.
Two complementary surfaces
Indicator-specific subflows connect these two components through patient data entry and system events. Together, automated responses and nurse interpretation form a unified monitoring flow that supports continuous, safe patient follow-up.
The solution can be understood as two complementary components:
