P-2048 · OBL-0921Elevated BP follow-up, clustered exception.
CLINICALSLA 38m
Nurse AdaPOST-DISCHARGE CONTINUITY · PRODUCT STRATEGY & DESIGN
Own the journey after discharge.
Continuum is a product I’m building for post-discharge continuity.
I work with health-tech founders and product teams to design what happens after the clinical encounter, especially where follow-through gets lost, ownership becomes unclear, and the product stops giving the care team a useful view.
I run focused engagements that combine:
- Clinical workflow analysis grounded in my medical biochemistry background
- Product design across states, exceptions, care-team workflows, and patient flows
- A structured model of continuity: Intent → Obligation → Evidence → Exception → Review → Resolution
The output is not just a report. You get design artifacts your team can use immediately: journey maps, workflow diagrams, exception flows, and prioritized product recommendations.
For: Seed/Series A health-tech startups, digital health companies, and innovation teams building in remote monitoring, chronic care, care coordination, or EMR/EHR-adjacent spaces.
Where post-discharge workflows start costing the team
Your product can collect plenty of data and still leave the care team with a workflow problem.
- The system knows what the patient reported, but the team still has to decide what matters, who owns it, and what happens next.
After discharge, the workflow becomes harder to manage:
- Asynchronous
- Full of exceptions (missed appointments, medication barriers, transport issues)
- Hard to measure (what actually happened? who owns it?)
Common costly mistakes:
- Building engagement features that don’t match how patients actually manage care at home
- Assuming the EHR or care team will “handle it,” when no one owns the workflow
- Designing for an ideal path, without handling exceptions (missed doses, delayed labs, no-shows)
- Building another feature when the real bottleneck is how the care team reviews and acts on exceptions
If you’re building in remote monitoring, chronic care, or care coordination, post-discharge is either a core differentiator or a hidden risk.
My job is to help you see the gaps before you overbuild, and design a post-discharge strategy that:
- Matches real clinical workflows
- Handles exceptions and incomplete evidence
- Gives your product a clear role in the journey
02 / THE EXCEPTION ARCHITECTURE SPRINT
The bottleneck in your RPM program isn't data. It's triage.
A 10-day sprint that maps your current workflow, makes the hidden exception logic explicit, and gives your product and engineering team a clear model for what should reach a human.
Exception Architecture Sprint
For: RPM and post-acute health-tech teams whose care teams are spending too much time reviewing alerts, chasing missing evidence, or deciding manually what needs action.
- Important workflow decisions still live in coordinator judgment instead of an explicit product rule or state
- Your team sees more signals than it can meaningfully review, and the queue does not make the next action obvious
What you get:
DAYS 1–5 / WORKFLOW & EVIDENCE AUDIT
Make the hidden workflow visible.
We map the current workflow from patient evidence to care-team action and identify where the system depends on manual judgment.
- Evidence map: source → interpretation → current alert or task
- Decision audit: what can be encoded clearly and what still requires clinical review
- Current-state review of alert volume, actionable cases, and unresolved work
- Obligation model covering intent, evidence, cadence, ownership, and breach conditions
- Missing-evidence states defined instead of being treated as empty data
DAYS 6–8 / EXCEPTION MODEL
Clear where rules can be clear. Human where they need to be.
The core product artifact: how evidence becomes an exception case, with a clear boundary between automated evaluation and human review.
- State model: Evidence → Evaluation → Exception Case, with transitions and ownership defined
- Prioritization logic that turns competing signals into one reviewable case
- Noise and missing-evidence handling for the signals your workflow actually uses
- Explicit failure states and safeguards for incomplete or conflicting evidence
DAYS 9–10 / BUILD-READY HAND-OFF
Clear enough to build from.
Your team gets a concrete product and workflow specification, not a generic recommendations deck.
- Exception queue behavior, states, actions, and interface requirements
- Human review workspace: episode context, why the case surfaced, owner, and resolution path
- Resolution and audit requirements, with integration considerations for the existing clinical stack
- A prioritized build plan: what to keep, what to change, and what to validate next
WHAT YOUR TEAM WALKS AWAY WITH
Architecture map
A complete map of the patient communication and follow-through loops, with the highest-risk breaks made visible.
Engineering-ready specs
Clear state transitions, exceptions, ownership, evidence, and escalation logic your product and engineering team can build from.
Prioritized next moves
A focused set of product recommendations tied to the gaps that matter most, not a generic audit report.
10 business days. Focused scope.
See if this fits your product →
A concentrated audit that turns a messy care-team experience into a clearer exception architecture and a blueprint your product and engineering team can build from.
03 / WHY THIS PERSPECTIVE EXISTS
I start with the clinical protocol, not the screen.
Healthcare product work often breaks down between clinical intent and the system that has to operationalize it. I work in that gap.
My background working alongside molecular diagnostics teams taught me to look closely at how clinical requirements become operational rules. I treat a recovery protocol as a set of obligations, evidence, decisions, and state changes. The useful question is not only what should happen, but how the product knows whether it happened and what the team does when it did not.
I can design the interface, but I start underneath it. I turn the clinical workflow into states, exception logic, ownership, and review paths that product and engineering teams can actually build and test.
I take on a small number of engagements at a time so I can go deep. Each project also sharpens Continuum, the product I am building around the same architecture.
04 / SELECTED WORK
Clinical Workflow Design
I design the operating layer behind healthcare products: the rules, states, exceptions, and care-team workflows that turn clinical intent into something a system can actually run.
Healthcare · Clinical Systems · Product Design
01
TKA Recovery Exception Workflow
A post-surgical workflow concept for elective total knee replacement, focused on the first 14 days after discharge. Instead of making a care coordinator scan every patient record, the system compares expected recovery obligations with observed evidence and surfaces cases that need human review.
Post-surgical recoveryException architectureCare operations
Design focus: make recovery trajectory, missed obligations, evidence, ownership, and resolution visible in one workflow without turning every patient signal into an alert.
02
Hypertension Clinical Operations
One workflow explored from two connected layers: first, how clinical rules become an executable decision architecture; second, how those rules become a care-team workspace for triage, escalation, transfer, and closure.
Clinical decision architectureCare routingEscalation workflow
Across both projects, the focus is the same: make clinical intent operational, make exceptions explainable, and give the team a workflow it can actually run.
View full specification ↗The architecture has to hold up in the real workflow.
The point is not to automate clinical judgment. It is to make the parts around that judgment explicit enough for a product team to build, test, and operate.
01 / DECISION BOUNDARY
Automate the clear parts.
Rule-based conditions can move through the system consistently. Situations that require clinical interpretation are surfaced with context for human review rather than hidden inside an algorithm.
02 / EVIDENCE
Missing data is still a state.
A missed check-in, delayed signal, conflicting report, or noisy telemetry should not silently disappear. The workflow defines what each evidence state means and when it needs attention.
03 / IMPLEMENTATION
Fit the stack you already have.
The exception workflow is designed around existing clinical systems and integration constraints. Resolution events and audit history can be mapped to the team's current architecture, including FHIR-based workflows where appropriate.
The human review boundary stays visible.
Continuum does not diagnose, prescribe, or replace clinical judgment. It makes the path from evidence to review to resolution clearer.
05 / WHO THIS IS FOR
Who this is for
I work best with health-tech founders and product teams who already have a care workflow, but are running into the operational cost of managing it at scale.
If the workflow is getting harder to operate as you scale, let’s look at it.
We’ll look at the workflow, where the exceptions are getting lost, and whether a focused sprint can help.