
A patient engagement app for a provider network: scheduling, visits, prescriptions, lab and pharmacy journeys, documents, and notifications—so people spend less time navigating the system and more time getting care.
The problem: Meet Daniel Okonkwo, VP of Patient Access at a multi-site care network. His clinicians were respected; his contact centre was underwater. Patients did not fail to care—they failed to find the next step. A lab order lived in one message thread, a pharmacy coupon in another, and the radiology prep sheet in a fourth. The product question was not “can we ship an app?” It was: can a family complete a care path without feeling like they joined an escape room?
“We didn’t need another brochure with a logo,” Daniel says. “We needed a single front door that still respected how clinicians and fulfilment partners work.” The breaking moment was peak flu season: great medical outcomes, brutal wait times, and reviews that blamed ‘the process,’ not the doctors.
The mandate was a patient-grade mobile product on top of existing services: authenticated access, real schedules, and traceable actions—not a wrapper around a desktop-only portal.
One mobile product for iOS and Android: booking, visits, prescriptions, diagnostics, pharmacy, and documents share navigation patterns so patients learn the app once.
Integrated with existing provider services—authenticated sessions, real schedules, traceable actions—not a marketing shell over a desktop-only portal.
Where partner journeys change quickly, embedded flows complement native screens so you are not blocked on a full rebuild for every policy tweak.
Screens are grouped around jobs to be done—book, attend, refill, investigate—rather than one undifferentiated menu. Shared list and card patterns keep behaviour predictable as modules roll out.
Differentiation
On this engagement, the patient app was the member-facing surface; the same programme shipped an AI-heavy EHR and revenue cycle behind it so eligibility, coding, denials, and cost clarity could feed APIs the mobile product consumed.
Where ERP meets the clinical and billing front line: intelligent features that remove repetitive data entry, surface denial risk before submission, and explain patient responsibility in plain language—always with clinician or biller confirmation where regulations require it.
Patient or front desk photographs the card; OCR plus structured extraction fills payer name, member ID, group, plan type, copays, and effective dates. Staff confirm in seconds, then eligibility can run automatically—replacing five minutes of error-prone typing.
As physicians document encounters, the system proposes likely ICD-10 and CPT codes with confidence scores. One tap to accept or adjust—reducing under-coding drift and query volume while keeping the provider in control.
Before a claim goes out, models flag probable denial drivers from historical payer behaviour—missing modifiers, code pairs, prior auth gaps—with concrete fixes (for example: “Aetna: add modifier 25 when billing 99214 with this add-on”).
After eligibility (e.g. 271 responses), rules combine fee schedules and planned procedures to estimate out-of-pocket cost and generate a patient-friendly explanation—supporting transparency and No Surprises Act-style expectations.
Open balances are ranked by dollar at risk, filing deadlines, likelihood of collection, and typical payer response times—each line gets a recommended next action so billers attack the highest-impact work first.
Pre-837 checks catch missing fields, invalid combinations, outdated codes, modifier conflicts, missing authorisations, and duplicate claims—mixing deterministic edits (CCI, age/gender) with model-assisted edge cases.
Turns billing from reactive clean-up into proactive revenue optimisation—patterns no single practice sees alone.
Continuous analysis of denial history surfaces systemic payer quirks and auto-generates “cheat sheets” per payer—alerting teams before the same mistake repeats and cutting re-bill cycles.
When a superbill includes certain CPTs, the system infers whether prior auth is likely required, lists documentation payers usually want, and drafts a first-pass auth request from the clinical note—learning which language speeds approvals.
Before a biller phones the payer, they get a brief: talking points, appeal phrasing that has worked for this denial reason, department routing, expected hold times, and documents to have ready—capturing expertise that usually walks out with senior staff.
Scores likelihood to pay by history, balance, plan type, and context—recommending whether to collect at check-in, text a statement, offer a plan, or flag financial counselling—reducing bad debt and redundant dunning.
30/60/90-day outlooks with confidence bands from pipeline claims, historical adjudication speeds, denial rates, and seasonality—flagging revenue at risk before it becomes a write-off so leaders can staff and plan with CFO-grade visibility.
AI capabilities are staged by autonomy: start with assistive tasks (capture and coding help), add prediction (denials, payments, cash), then support higher-judgement workflows (auth drafting, appeal calls, queue ranking).
Unlike static rule engines, the platform tightens with volume: more claims improve denial prediction and payer fingerprints; more appeals sharpen call-prep language; more payments refine collection recommendations; more forecasts narrow confidence bands. New sites benefit from accumulated network intelligence while retaining appropriate data boundaries and governance.
Releases were sequenced so authentication, appointments, and dashboard stability preceded wider clinical adjacency—reducing the blast radius of API and UX changes while real patients were already in flight.
We mapped search → book → attend → follow up before polishing edge screens. Appointments, identity, and media contracts were settled early so downstream modules did not thrash.
Core booking and dashboard stability landed first; prescriptions, lab, and pharmacy rolled in stages behind shared list/detail patterns—so the product stayed coherent under deadline pressure.
Crash analytics, upgrade testing across OS versions, and store checklist discipline—so live traffic looked like rehearsal, not a surprise.
The same navigation home hosts booking, visits, prescriptions, diagnostics, pharmacy, and documents—so patients learn the product once even as the network adds modules.
These patterns describe how screens chain without forcing patients to re-enter the same data at every hop.
For ERP and operations positioning for healthcare organisations, see ERP for healthcare companies and ERP for hospitals. All shipped narratives live on case studies.
The mobile product was one surface of a broader programme: the provider network also invested in AI-assisted intake, coding, denial prevention, and cost transparency on the revenue-cycle side. That stack feeds APIs the patient app consumes—for example cleaner insurance fields, eligibility-driven cost messaging, and fewer duplicate data-entry steps—so we document both halves in one narrative. See also our healthcare ERP page for the same AI feature set in context.
The team needed one codebase for iOS and Android with predictable async behaviour: sagas isolate login, appointment lists, and other API flows from UI components, so screens stay testable and errors recover gracefully. That pattern scales as modules—lab, pharmacy, documents—ship on staggered timelines.
WebViews are used selectively where embedded journeys or partner content change faster than store release cycles justify rebuilding natively. Core booking, lists, and authenticated API traffic stay in native screens; WebView surfaces are bounded, cookie-aware where needed, and kept out of critical path where stability matters most.
The app uses document picker, image capture, and blob utilities to move files into the provider’s pipeline with explicit user action—no background surprises. Runtime permissions align with current Android and iOS policies for camera, storage, and media access.
They support booking confirmations, reminders, and engagement nudges where users opt in—reducing no-shows and keeping follow-up surfaces visible without spamming generic marketing.
No. This case study is a patient engagement mobile client—scheduling, visits, prescriptions, and adjacencies—integrated with provider services. Hospital ERP typically covers procurement, finance, workforce, and inventory at enterprise scale; see our healthcare ERP pages for that positioning.
Upgrade work included validation against new Android behaviour (for example location and media rules), crash analytics on staging builds, and phased rollout so production matched rehearsal—not a one-day big bang.