The problem
The client is a regional healthcare network operating twelve outpatient clinics, with a leadership team under real pressure to "do something with AI" after a board presentation from a competitor. They came to us with fourteen ideas gathered from department heads (an AI scheduling assistant, an ambient clinical documentation tool, a patient chatbot, automated prior-authorization drafting, and ten others), no way to compare them, and a budget that could fund maybe three.
This is the most common version of the problem we see: not a lack of ideas, but no defensible way to rank them. Every department head believed their idea was the priority. Without a structured evaluation, the default is picking whichever idea the most senior person in the room likes best, which is a poor filter for what's actually buildable, valuable, and safe in a HIPAA-regulated environment.
What we actually did
We ran a three-week structured discovery engagement, not a slide-deck exercise. The output was a ranked, scored list of all fourteen ideas against four criteria we defined with the client upfront: technical feasibility given their existing systems, expected value (measured in clinician hours saved or revenue impact, not vague "efficiency"), regulatory and compliance risk, and time to a first working prototype.
Week 1: mapping constraints, not brainstorming
We spent the first week almost entirely on infrastructure and data reality, not on the ideas themselves. That mattered because several ideas were dead on arrival for reasons that had nothing to do with AI. The client's EHR API access tier didn't support the write operations an automated documentation tool would need, and their patient messaging system had no API at all, which killed the chatbot idea as originally scoped. Finding this in week one, rather than week eight of a build, is most of the value of doing discovery properly.
Week 2: scoring against real criteria
Our engineers scored each surviving idea together with the client's clinical and compliance leads, in the same room rather than separately. This was deliberate: engineers scoring feasibility without a compliance lead present tend to underweight regulatory risk, and clinical leads scoring value without engineers present tend to overestimate what's technically easy. Scoring together surfaced disagreements early rather than after a build had already started.
Week 3: a build plan for exactly three ideas
We narrowed to three recommended builds, each with a defined scope, a rough cost and timeline range, and an explicit statement of what would make each one fail (the risk we'd be watching for). Every other idea on the list was documented with a specific reason it didn't make the cut, rather than dropped silently, so the client could explain the decision to the department heads whose ideas weren't picked.
Challenges and tradeoffs
- Getting honest EHR API access details took longer than expected. The client's own IT team didn't have a full picture of what their EHR vendor contract actually permitted programmatically. We had to get the vendor on a call directly, which added four days to week one but avoided scoping a build against capabilities that didn't exist.
- Scoring disagreements were the most valuable part of the process, not friction to route around. The clinical lead and our engineers disagreed sharply on the feasibility score for two ideas. Rather than averaging the scores, we documented both positions and let the client's leadership make the final call with full context, which beats us silently picking a number.
- Saying no to eleven ideas is a change-management problem, not just a scoring problem. We built a one-page rationale for each dropped idea specifically so the client's leadership had something concrete to hand to the department heads whose ideas didn't get picked, rather than a vague "we decided not to."
Results
The client moved forward with the prior-authorization drafting tool first (built by us in a follow-on engagement). It shipped in nine weeks and now handles roughly 40% of draft volume for their billing team. The ambient documentation tool is scoped for a second phase once vendor tooling matures; the client credits the discovery process with avoiding a premature start that would have hit vendor limitations mid-project.
The most concrete measure of value: nothing was spent building any of the eleven ideas discovery ruled out, several of which the client's leadership said they would otherwise have greenlit.
What we'd do differently
We'd bring the EHR vendor into a call in the first two days of discovery by default now, rather than waiting until we hit a specific technical question that needed their input. That's become standard practice on healthcare engagements since this one.