Two teams had already started designing their own AI summaries. It was a small example of a bigger problem: without shared patterns, every feature would introduce another way for users to understand, review, and interact with AI.
I worked across the UX team to establish common interaction patterns while designing the practice management features myself.
A little context
Healthcare software isn’t particularly forgiving of mistakes. Billers need to account for every dollar, and clinicians need to know exactly what ends up in a patient’s chart.
Our AI work ranged from relatively simple summaries to agents capable of taking action on financial records. Some features were there to help people understand information faster. Others could actually do the work.
That meant we couldn’t treat every AI interaction the same way. A summary needs to be easy to review. A suggested chart update needs an explicit decision. An automated payment needs a status, a record of what happened, and a way to handle exceptions.
The challenge was to make those behaviors familiar across the product without forcing every feature into an identical interface.
The projects
My work covered seven features at different stages of development.
| Feature | What it does | My involvement |
|---|---|---|
| Collections summary | Summarizes collections activity, including previous and next actions | DesignedLive |
| Transaction History summary | Reuses the summary pattern in the redesigned transaction experience | DesignedBeta |
| Pre-visit summary | Prepares clinicians with relevant information before an appointment | Mentored |
| Clinical assistant | Suggests chart updates from visit transcripts | MentoredLive |
| AI assistant | Answers practice management questions using cited Knowledge Base articles | Mentored |
| Payment posting | Matches insurance payments to claims and supports recommended or automatic posting | DesignedIn design |
| Billing agents | Run scheduled checks for denials, underpayments, and filing deadlines | Designed |
I designed the collections, payment-posting, and billing-agent experiences. I also mentored the designers who built the clinical features and the AI assistant.
Working across those projects gave me a view of decisions that individual feature teams wouldn’t necessarily encounter.
Starting with summaries
The collections and pre-visit summaries were an obvious place to establish a shared pattern.
They serve different users and contain completely different information, but the basic interaction is the same. Someone needs a useful summary, needs to know when it was generated, and needs a way to tell us when something isn’t right.
We standardized the AI identification, review guidance, update controls, timestamps, and feedback behavior. A negative rating opens a short set of reasons, giving the product team something more useful than a thumbs-down count.
Insurance paid most claims on this visit. One needed a code correction and rebill before payment.
Summary generated: Nov 17, 11:38 AM
Chief complaint: Recurring headaches, follow-up visit.
Summary generated: Nov 17, 8:02 AM
We also made updates deliberate rather than automatic. The user can see when the information was generated and request a new summary when needed.
It’s a small interaction decision, but an important one when someone may be making a clinical or financial decision based on the information.
What happens when AI starts doing the work?
Payment posting introduced a different set of problems.
A summary can be reviewed and ignored. An automatically posted insurance payment changes the account. The interface needs to make that distinction clear.
We designed posting controls that let practices choose, by payer, whether the AI should recommend matches or post them automatically. Each payment line shows its current status, including exceptions and work still in progress.
The same thinking carried into the billing agents. We distinguished agents that only report information from those that can make changes, and designed run histories so staff can review what happened.
Clinical suggestions required another variation. Rather than applying a group of changes to a chart, clinicians can accept or reject individual suggestions.
These aren’t identical interactions, and they shouldn’t be. What they share is a clear distinction between what the AI suggests, what it does, and what the person can control.
Making feedback useful
I wanted feedback to work consistently, regardless of where someone encountered AI.
Summaries and assistant responses use the same positive and negative feedback controls. When someone reports a problem, we ask whether the response was inaccurate, outdated, incomplete, off-topic, or cited the wrong source.
Sources
What went wrong?
For features that take action, the more useful signals may be different: accepted suggestions, rejected changes, overrides, posting exceptions, and agent histories.
The point wasn’t to collect feedback for its own sake. It was to give Product a consistent way to see where AI was helping and where people still needed to correct it.
Where things stand
The collections summary is live, and the same pattern is being carried into Transaction History. The clinical assistant is also live, while payment posting and billing agents are at earlier stages of development.
The product team’s early assessment of the collections summary estimates a 75% reduction in manual note-review time per claim. That’s an encouraging result for the feature, although it isn’t a measure of the shared UX patterns themselves.
For the broader AI experience, there’s still more to learn. I’m particularly interested in how often people override AI actions, what kinds of feedback they submit, and whether practices become comfortable moving from recommendations to automatic posting.
Looking back
One of the interesting things about this work was how quickly reasonable, independent design decisions could turn into product-wide inconsistency.
Nobody was deliberately creating a fragmented experience. Each team was focused on getting its own feature right.
My contribution was working across those projects, recognizing where decisions should be shared, and helping the team establish patterns we could reuse as AI became part of more workflows.
And as AI moves beyond summarizing information into actually doing things, I expect those patterns will need to keep evolving.