The 2027 trend nobody in healthcare leadership is talking about loudly enough: the AI health navigator is arriving, and most organizations are not ready to lead it
A note on perspective: I write most of my UX content from the practitioner’s chair. This one is written from a seat above. The CEO framing changes the argument in a specific way: design trends become organizational decisions, experience failures become strategic liabilities, and the question shifts from how do we design this to whether the organization is structured to lead it at all. Both chairs matter. This one is the one most healthcare organizations are missing.
Nearly every health plan and health system in the country has built, maintained, and optimized a product for the last fifteen years. People who use it universally dislike it. Its completion rate for complex tasks is what a consumer product would consider catastrophic. It is the first place a member goes when something goes wrong with their health, and it is designed in a way that makes that already-bad moment worse.
It is the member portal.
By 2027, organizations that understand what is happening will start replacing it, not updating or redesigning it. Replacing the architectural concept of it with something that works the way people actually need healthcare to work.
The replacement is the AI health navigator. A persistent, personalized, conversational AI layer that knows who you are across every dimension of your healthcare relationship, answers questions in plain language, takes action on your behalf with your authorization, and surfaces what you need before you know to ask for it.
The infrastructure for this exists today. The organizational will to build it correctly is what is missing. And the CEO or Chief Design Officer who understands this change as a design and organizational leadership problem, not a technology procurement problem, is going to build something that actually changes what healthcare feels like to the people living inside it.
Why the Portal Failed and Why That Failure Was Predictable
The member portal was built to reduce call center volume. That was its original strategic purpose, and it has never fully changed, no matter how many features were added on top.
A product built to reduce call center volume is designed around what the organization needs from the interaction, not what the member needs from it. The member needs to understand their benefits, manage a claim dispute, find a doctor, get a prior authorization, understand their explanation of benefits, manage a chronic condition, coordinate care across multiple providers. The portal is designed to let members self-serve those tasks with minimal organizational resources.
Those are not the same design brief, and the difference shows up in every portal on the market.
The navigation structures reflect administrative categories, not human mental models. A person who wants to know why their prescription was denied doesn’t think of that problem as a pharmacy benefit management task that necessitates navigating a claims history filtered by service type. They think of it as: my medication is not covered and I do not understand why. The portal makes them learn the organization’s internal taxonomy to get an answer. A well-designed system would simply answer the question.
The information architecture represents the organization’s data siloes, not the member’s integrated experience. Benefits information lives separately from claims, claims live separately from care gaps, care gaps live separately from provider directories, provider directories live separately from appointment scheduling. The member’s actual need crosses all of these categories simultaneously. The portal makes them cross each boundary manually.
The interaction model assumes literacy, digital comfort, and available time. A substantial part of the population that most needs to use these systems has limited literacy, limited digital comfort, limited time, and limited tolerance for friction when they are already dealing with a health situation that is producing anxiety. The portal was not designed for them. It was designed for the healthy, engaged, digitally literate member who represents a minority of the people who actually need it most.
These are not design mistakes that better UX teams could have fixed. They are structural failures produced by a strategic brief that was never centered on the person. A redesign can’t fix that structural failure. It requires a rearchitecting.
What the AI Health Navigator Actually Is
The AI health navigator is not a chatbot. The distinction is important because the healthcare industry’s prior experience with chatbots produced products that destroyed trust faster than the portals they were meant to augment.
A chatbot answers scripted questions from a decision tree. It fails when the question does not fit the script, which is most of the time when someone has a real healthcare problem. It produces deflection responses that are technically accurate and practically useless. It makes the person feel handled, not helped.
The AI health navigator is something structurally different. It is a persistent, context-aware AI agent that retains a longitudinal relationship with a specific person across their entire healthcare experience. It knows their benefits, their claims history, their care gaps, their medication list, their care team, their stated preferences, and their interaction history with the organization. It can answer questions that require reasoning across all of those data sources simultaneously. It can take action, with clear authorization, within defined parameters. And it gets more useful over time because it is accumulating a model of this specific person’s healthcare situation, not just responding to isolated queries.
The TEFCA framework, the Trusted Exchange Framework and Common Agreement that went into operational phase in 2024 and is scaling in 2026, is the data infrastructure layer that makes this possible. For the first time, a national framework for healthcare data exchange allows a single system to pull authorized health information from multiple sources: the payer, the provider network, the pharmacy benefit manager, the lab, and the specialist. The data fragmentation that made longitudinal AI health navigation impossible is being technically resolved.
The AI capability layer is also arriving. Multimodal models that can process clinical documentation, claims data, benefits language, and member queries in natural language are commercially deployable at the quality level required for healthcare contexts. The combination of capable AI and improving data access creates the first genuine opportunity to build the member portal replacement that every health plan executive has said they wanted for a decade.
The question is no longer can we build this. The question is whether the organizations that should be leading it understand what leading it actually requires.
Why This Is a CEO-Level Decision, Not a Product Decision
This is where the framing shifts from practitioner to organizational leader, and the shift matters.
A product team can redesign a member portal. They do not have the authority to replace it.
Replacing the member portal with an AI health navigator requires decisions that sit above the product function in every organization that has tried to make them without executive alignment. It needs resolving data governance questions that span multiple business units with separate P&L accountability. It requires a trust and liability framework for an AI system making recommendations about healthcare decisions that the legal and compliance functions have not yet built the vocabulary to evaluate. It requires a change management strategy for an organization whose customer service, clinical, and administrative workflows are all built around the portal’s current architecture.
These are not design decisions. They are organizational decisions that have design implications. And the CEO or senior executive who does not understand the design implications will make the organizational decisions in a way that produces the wrong product, even with the right technology.
The specific failure mode I have watched play out in healthcare organizations is what I would call the procurement trap. The organization identifies the trend, gets excited about the technology, issues an RFP for an AI health navigation platform, selects a vendor with strong AI infrastructure, deploys it as a layer on top of the existing portal architecture, and produces a product that is technically impressive and experientially incoherent.
The incoherence comes from trying to add an interactive AI layer to a system that was architecturally designed around the opposite interaction model. A portal built on administrative taxonomy cannot support an interactive AI designed to answer human mental models because the underlying data architecture doesn’t map between the two. The AI is fluent but wrong, or accurate but bureaucratic, which is the same problem the portal already had.
Avoiding the procurement trap requires someone at the organizational decision level who understands that the AI health navigator is not a feature addition to the existing portal. It replaces the interaction architecture, which means it requires replacing significant portions of the underlying data architecture, and that is a three- to five-year organizational investment, not a twelve- to eighteen-month vendor deployment.
A CEO with a design background, or one who has a design leader they trust and listen to, will understand this before signing the contract. Most others will not.
The Three Design Decisions That Determine Whether This Works
If I am leading the organization building this, these are the decisions I make before any vendor conversation, any technology selection, any product roadmap.
The first decision is who the primary user is.
The AI health navigator can be designed for the engaged, health-literate member who wants a more efficient method to manage their healthcare relationship. Or it can be designed for the anxious, overwhelmed member who has a problem they do not understand and needs the system to help them figure out what is happening and what to do about it.
These produce completely different products. The first user desires speed, efficiency, and integration. The second user desires reassurance, plain language, and patience with questions that feel stupid to ask but are not. Most organizations, when they say they are designing for their members, are actually designing for the first user because that user is easier to build for and produces better early engagement metrics.
I design for the second user and measure success by whether the first crisis interaction a member has with the health system is less frightening than it would have been otherwise. That is the bar. Not engagement rate. Not sessions per month. Whether the system is actually useful when something is actually wrong.
The second decision is how trust builds over time, not at launch.
The AI health navigator asks a person to trust an AI system with their medical decisions at a moment as trust in both AI systems and healthcare organizations is under active pressure. You cannot design around that. You have to design with it.
The trust architecture I would build is incremental and transparent. Over time, the system earns the right to act on a member’s behalf through a series of smaller interactions where it demonstrates accuracy, privacy protection, and correspondence with what the member actually wanted. It does not start with full agentic capability. It starts by answering questions well and consistently, in a way that makes the person’s situation clearer rather than more complicated. The agentic features unlock progressively as the relationship builds.
This is a longer path to the full product vision than most product roadmaps will tolerate. It is also the only path that produces a product the target population will actually use.
The third decision is what the handoff to a human looks like.
The AI health navigator will fail some percentage of interactions. The member will ask something the system cannot answer accurately. The situation will be complex enough that AI guidance is insufficient. The member will be in a state of distress that requires human response rather than information delivery.
How the system recognizes these instances, communicates to the member that it is handing off and why, and prepares the human on the receiving end at the context needed to pick up without starting over is a design problem most AI health product roadmaps treat as an edge case. It is not an edge case. The interaction determines whether the member trusts the system enough to use it again.
I design the handoff as carefully as I design the primary interaction. The seam between AI and human holds the most important trust signals, and I have never seen it designed well in a healthcare AI deployment built on a vendor platform rather than a first-principles architecture.
What the Organizations That Get This Right Will Have That Others Will Not
By 2028, the market will clearly separate healthcare organizations with a well-designed AI health navigator front door from those still maintaining a portal with an AI chatbot bolted on top.
The organizations that get it right will have higher member engagement scores not because they optimized for engagement yet because they built something that is genuinely useful in difficult moments. They will have lower unnecessary care utilization not because they restricted access but because a member who understands what is happening to them and what their options are makes different decisions than a member navigating an opaque system alone. They will have better health outcomes in specific populations because proactive, personalized outreach through a trusted conversational layer reaches people that a quarterly mailer and a portal notification never did.
These are the outcomes healthcare organizations have been trying to produce through digital engagement for fifteen years. The technology to actually produce them is arriving in 2026 and 2027. The organizational will and design leadership to build them correctly remain unresolved.
I believe the organizations that resolve it will build a genuine competitive advantage that is extremely difficult to replicate, because the trust a well-designed AI health navigator builds with a member over multiple years of accurate, helpful interactions isn’t transferable to a competitor product. You cannot migrate trust. You build it, interaction by interaction, over time.
That is the 2027 healthcare UX trend worth paying attention to. Not the technology. The organizational decision about whether to lead it or let it happen to you.
Sources: TEFCA Recognized Coordinating Entity (RCE), “TEFCA Operational State and Expansion Report,” 2026; KLAS Research, “Member Portal Experience Survey: Health Plan Digital Engagement,” 2025; Accenture, “Healthcare Digital Experience Consumer Survey,” 2026; McKinsey Center for U.S. Health System Reform, “The Next Age of Healthcare Navigation,” 2025; American Journal of Managed Care, “AI-Enabled Member Engagement in Value-Based Care Organizations,” 2026; Gartner, “Emerging Technology Trends in Healthcare IT,” 2026.