Patient Portal Adoption: Diagnosing the VeriSM Model Stages
Northbridge Health operates seven hospitals and 180,000 eligible patients. Its patient portal launched 14 months ago with features drawn from a clinician wish list: appointment requests, test results, and bill pay. Adoption is 15% of eligible patients; 300 incidents are logged each month; uptime is 99.2%; and 40% of registration attempts fail during identity proofing. Patients still call scheduling because they cannot complete registration. The portal had a product owner during build, but that role ended at go-live. The service desk closes tickets quickly and reports volume, not themes. Clinical leaders say the portal is an IT project, while IT says clinicians did not define patient outcomes. A board member asks why a technically stable service is not creating value. The next step is to diagnose where the VeriSM model stages are misaligned before adding more features.
1. Map the symptoms to the VeriSM model stages (Define, Produce, Provide, Respond) and identify the two most consequential misalignments. Explain your reasoning.
Read the worked answer
Define: the portal was scoped from a clinician wish list, not from patient outcomes or journeys; no one defined success beyond features. Produce: features were built, but value was not validated-identity proofing was a known barrier, yet 40% registration failure was not treated as a design defect. Provide: uptime is 99.2%, so the service is technically available, but availability is not the same as usability or adoption. Respond: the desk closes 300 tickets a month and reports volume, not themes, so it does not feed learning back. The two most consequential misalignments are the broken Define–Respond loop and the Produce stage's lack of value validation. Without a feedback loop, incidents become noise; without value validation, the organization keeps adding features that do not address registration failure. Adoption at 15% is therefore not a marketing problem but a model-stage problem.
2. What actions would you take in Define and Respond over the next 90 days, and what evidence would show the loop is working?
Read the worked answer
In Define, run a patient-journey workshop across registration, results, and bill pay; define outcome metrics such as registration completion, time to first successful login, and call deflection; and set a service blueprint that names identity proofing as a critical moment. Assign a durable product owner with authority over the backlog. In Respond, change ticket categorization to capture patient intent and failure point, review themes weekly with the product owner, and create a feedback path into Define rather than closing tickets at first contact. Publish a simple dashboard. Evidence of a working loop: registration completion rises from 60% to at least 85%; portal adoption increases from 15% to 30%; repeat incidents and password-related calls fall; and the product backlog contains items traceable to Respond themes. Do not add features until the registration barrier is fixed, because more features would increase complexity without addressing the value gap.