Implementation Note — August 2026
A person approaching Medicare rarely begins with the vocabulary of the Medicare data system.
They ask questions such as:
What are my Medicare options?
That sounds like a simple information request.
It is not.
“Medicare options” is not a single CMS product category, plan type, dataset, or enrollment pathway. Depending on the person and location, the answer may involve Original Medicare, Medicare Advantage, Medicare Part D, Medicare Supplement insurance, Special Needs Plans, employer or retiree coverage, VA benefits, Medicaid, or other forms of assistance.
Before a publishing system can answer the question well, it must first determine what the question resolves to.
MedicarePlans.com created the Medicare Options resolver to address that problem.
Consumer Language Does Not Always Match Medicare Structure
Medicare information is organized around programs, plan types, contracts, geographic service areas, eligibility rules, benefits, and datasets.
Consumers do not necessarily think that way.
Someone asking about “Medicare plans” may mean Medicare Advantage plans. Or they may be trying to understand every coverage path available to them.
Someone asking about “Medicare options” may not yet know enough about Medicare to formulate a more specific question.
That creates a publishing problem.
A system that interprets the phrase too narrowly may answer a different question than the consumer intended.
A system that treats every possible Medicare subject as equally relevant may produce an answer that is technically comprehensive but difficult to use.
The first task is resolution.
What the Medicare Options Resolver Does
The Medicare Options resolver treats the consumer concept of “Medicare options” as an entry point into a larger Medicare knowledge system.
For the human reader, the county page brings together explanations of the major Medicare coverage pathways and local market information relevant to that geography.
For machines, MedicarePlans.com publishes a second representation of that same subject.
Using WebMEM®, the machine-facing publication decomposes the broad concept of Medicare options into separately identified knowledge objects representing different parts of the local Medicare market.
The human publication explains the options. The machine publication identifies and describes the knowledge domains that make up those options.
Resolution Before Recommendation
This distinction becomes increasingly important as AI systems participate in Medicare information discovery.
Consider the question:
What Medicare options do I have in Mohave County, Arizona?
Before an AI system can meaningfully compare or recommend anything, several questions must be resolved.
Does the consumer mean Original Medicare or private Medicare coverage?
Are standard Medicare Advantage plans available?
Are Special Needs Plans available, and what types?
What standalone Part D choices exist?
What does the local Medigap market look like?
What plan populations and enrollment patterns characterize the local market?
These are not yet recommendation questions.
They are domain-resolution questions.
The Medicare Options resolver provides a publishing surface where those distinctions can be established before the consumer or machine continues into increasingly specific Medicare knowledge.
From an Ambiguous Concept to Explicit Knowledge Domains
Conceptually, the resolver performs a transformation:
“Medicare options” → geography → coverage domains → local markets → plan populations → individual plans → plan facts
Each step reduces ambiguity.
The phrase “Medicare options” begins as a broad consumer concept.
The resolver places that concept within a defined geography and separates it into recognizable Medicare knowledge domains.
Those domains can then resolve into increasingly specific market, population, and plan-level knowledge.
Resolution is progressive.
The system does not need to jump from an ambiguous consumer phrase directly to a plan recommendation.
How MedicarePlans.com Implements the Machine Tier
The Medicare Options county resolver does not publish one undifferentiated machine summary.
Its WebMEM implementation separates the county-level Medicare landscape into distinct knowledge objects.
The current implementation publishes six complementary machine-facing objects:
- County Options Summary — a county-level view of the major Medicare plan and coverage populations represented by the resolver
- Medicare Advantage Summary — local Medicare Advantage availability, plan-type distribution, prescription drug coverage characteristics, cost-sharing ranges, and related market facts
- Part D Summary — local standalone prescription drug plan availability, coverage classifications, premiums, and deductible ranges
- Medigap Summary — local Medicare Supplement carrier availability and sample premium ranges
- Special Needs Plan Summary — local SNP availability separated into D-SNP, C-SNP, and I-SNP populations
- Enrollment Leaders — county-level enrollment leaders across Medicare Advantage, Part D, and Special Needs Plan classifications
These objects do not ask the machine to determine which numbers belong to which Medicare domain by interpreting the surrounding article.
The publisher makes those distinctions explicitly.
What This Looks Like in Practice
The county-level Medicare Options object provides the broad machine-facing representation of the local coverage landscape.
Conceptually, the published knowledge can be represented like this:
Medicare Options — County
- Medicare Advantage → local plan population
- Part D → local standalone prescription drug plan population
- Medigap → local participating carrier population
- Special Needs Plans → local SNP population
- D-SNP → local Dual Eligible SNP population
- C-SNP → local Chronic Condition SNP population
- I-SNP → local Institutional SNP population
- Enrollment → enrollment observations across local plan classifications
Those domains can then be described by their own machine-facing knowledge objects.
For example, the Medicare Advantage object can express the number of available plans, the distribution of HMO, PPO, HMO-POS, and PFFS plans, prescription drug coverage availability, out-of-pocket ranges, and Part B giveback characteristics.
The Part D object can separately express plan counts, basic and enhanced coverage populations, premium ranges, and deductible ranges.
The SNP object can separately identify D-SNP, C-SNP, and I-SNP populations.
The Medigap object can describe carrier availability and sample premium ranges without collapsing Medicare Supplement insurance into the Medicare Advantage or Part D market.
The broad consumer concept remains connected, while the underlying Medicare knowledge remains distinct.
A Resolver Is More Than Navigation
A conventional directory can send a visitor from one webpage to another.
A resolver has a different purpose.
Navigation answers:
Where can I go next?
Resolution answers:
What does this concept mean here, what does it contain, what is it related to, and what can it resolve into next?
The Medicare Options implementation demonstrates that distinction.
The human page provides navigation and explanation.
The machine tier does more than reproduce those links. It identifies Medicare Options as a county-scoped subject and separately publishes knowledge about Medicare Advantage, Part D, Medigap, SNPs, and enrollment within that context.
The resolver is therefore both a navigation surface for people and a resolution surface for machines.
Geography Is Part of the Knowledge
Some Medicare knowledge is national.
Other Medicare knowledge changes according to where the beneficiary lives.
The Medicare Options resolver therefore uses a geographic hierarchy:
United States → state → county → local Medicare options
At the county level, the machine-facing publication explicitly identifies the geographic subject rather than relying solely on a county name appearing in a title or URL.
This matters because plan availability, plan populations, enrollment, carrier participation, and other Medicare characteristics can vary geographically.
Geography becomes part of the knowledge being resolved rather than merely part of the webpage address.
Structured Data Is Not the Same Thing as Resolution
Publishing a collection of machine-readable Medicare facts is useful.
But a list of values alone does not resolve the consumer concept of “Medicare options.”
The values must remain associated with the correct Medicare domain, geographic scope, and knowledge role.
A Medicare Advantage plan count should remain a fact about the Medicare Advantage market.
A D-SNP count should remain a fact about the Special Needs Plan population.
A Medigap carrier count should not become indistinguishable from a Medicare Advantage plan count simply because both appear on the same county page.
Resolution depends on preserving meaning as information becomes more specific.
From Resolver to Resolution Surface
The Medicare Options county page is not intended to contain every fact about every Medicare subject.
Its job is to establish the major knowledge domains relevant to the question and provide continuations into increasingly specific knowledge.
That produces a larger resolution path:
Consumer question → Medicare Options → geography → coverage domain → local market → plan population → Plan ID → plan knowledge
The Medicare Options resolver sits near the beginning of that path.
The Medicare Advantage and Special Needs Plan county publications described in a separate Implementation Note operate farther down it.
Persistent Plan-ID resources can continue the resolution process to individual Medicare plans and their attributes.
Together, these surfaces demonstrate an architectural principle:
A knowledge system does not need one page that answers everything. It needs reliable surfaces that progressively resolve the question.
The Resolver Connects to Two-Tier Publishing
The Medicare Options resolver demonstrates how resolution and two-tier publishing can work together.
The human-facing publication is responsible for explaining Medicare coverage pathways, differences, local context, and consumer considerations.
The machine-facing publication is responsible for making important classifications, populations, geographic scope, facts, and continuations explicit.
MedicarePlans.com uses WebMEM to implement this machine-facing knowledge tier alongside the human-readable publication.
WebMEM is not the resolver itself.
The resolver defines how the question decomposes into knowledge. WebMEM publishes that knowledge for machine resolution.
Why This Matters for Medicare Publishing
Medicare publishing has traditionally been organized primarily around documents and topics.
AI systems introduce another consideration.
The publisher may need to help machines determine not only where information is located, but also what the information describes, what scope it applies to, and how it relates to the question being asked.
A Medicare publisher can identify ambiguous consumer concepts.
It can define the knowledge domains those concepts resolve into.
It can preserve geographic, temporal, eligibility, and product distinctions.
It can publish facts within those domains rather than leaving their meaning to inference.
And it can provide continuations into increasingly specific knowledge.
The publisher already understands the domain. The publishing architecture can express that understanding.
An Ongoing Public Implementation
MedicarePlans.com is currently operating the Medicare Options resolver as part of its public Medicare information architecture.
The implementation should not be interpreted as evidence that a particular search engine or AI system will interpret or use the resolver in a particular way.
That remains an empirical question.
What can be observed is whether systems discover the resolver, how ambiguous Medicare queries begin resolving to it, which downstream knowledge surfaces they use, and whether the distinctions established by the publishing architecture are preserved in generated answers.
Those observations can be documented separately from the implementation itself.
The important publishing question is no longer simply whether the answer exists somewhere on the website.
The more interesting question is:
Can the publisher help the machine resolve what the question actually means?
ly begins with the vocabulary of the Medicare data system.
They ask questions such as:
What are my Medicare options?
That sounds like a simple information request.
It is not.
“Medicare options” is not a single CMS product category, plan type, dataset, or enrollment pathway. Depending on the person and location, the answer may involve Original Medicare, Medicare Advantage, Medicare Part D, Medicare Supplement insurance, Special Needs Plans, employer or retiree coverage, VA benefits, Medicaid, or other forms of assistance.
Before a publishing system can answer the question well, it must first determine what the question resolves to.
MedicarePlans.com created the Medicare Options resolver to address that problem.
Consumer Language Does Not Always Match Medicare Structure
Medicare information is organized around programs, plan types, contracts, geographic service areas, eligibility rules, benefits, and datasets.
Consumers do not necessarily think that way.
Someone asking about “Medicare plans” may mean Medicare Advantage plans. Or they may be trying to understand every coverage path available to them.
Someone asking about “Medicare options” may not yet know enough about Medicare to formulate a more specific question.
That creates a publishing problem.
A system that interprets the phrase too narrowly may answer a different question than the consumer intended.
A system that treats every possible Medicare subject as equally relevant may produce an answer that is technically comprehensive but difficult to use.
The first task is resolution.
What the Medicare Options Resolver Does
The Medicare Options resolver treats the consumer concept of “Medicare options” as an entry point into a larger Medicare knowledge system.
For the human reader, the county page brings together explanations of the major Medicare coverage pathways and local market information relevant to that geography.
For machines, MedicarePlans.com publishes a second representation of that same subject.
Using WebMEM®, the machine-facing publication decomposes the broad concept of Medicare options into separately identified knowledge objects representing different parts of the local Medicare market.
The human publication explains the options. The machine publication identifies and describes the knowledge domains that make up those options.
Resolution Before Recommendation
This distinction becomes increasingly important as AI systems participate in Medicare information discovery.
Consider the question:
What Medicare options do I have in Mohave County, Arizona?
Before an AI system can meaningfully compare or recommend anything, several questions must be resolved.
Does the consumer mean Original Medicare or private Medicare coverage?
Are standard Medicare Advantage plans available?
Are Special Needs Plans available, and what types?
What standalone Part D choices exist?
What does the local Medigap market look like?
What plan populations and enrollment patterns characterize the local market?
These are not yet recommendation questions.
They are domain-resolution questions.
The Medicare Options resolver provides a publishing surface where those distinctions can be established before the consumer or machine continues into increasingly specific Medicare knowledge.
From an Ambiguous Concept to Explicit Knowledge Domains
Conceptually, the resolver performs a transformation:
“Medicare options” → geography → coverage domains → local markets → plan populations → individual plans → plan facts
Each step reduces ambiguity.
The phrase “Medicare options” begins as a broad consumer concept.
The resolver places that concept within a defined geography and separates it into recognizable Medicare knowledge domains.
Those domains can then resolve into increasingly specific market, population, and plan-level knowledge.
Resolution is progressive.
The system does not need to jump from an ambiguous consumer phrase directly to a plan recommendation.
How MedicarePlans.com Implements the Machine Tier
The Medicare Options county resolver does not publish one undifferentiated machine summary.
Its WebMEM implementation separates the county-level Medicare landscape into distinct knowledge objects.
The current implementation publishes six complementary machine-facing objects:
- County Options Summary — a county-level view of the major Medicare plan and coverage populations represented by the resolver
- Medicare Advantage Summary — local Medicare Advantage availability, plan-type distribution, prescription drug coverage characteristics, cost-sharing ranges, and related market facts
- Part D Summary — local standalone prescription drug plan availability, coverage classifications, premiums, and deductible ranges
- Medigap Summary — local Medicare Supplement carrier availability and sample premium ranges
- Special Needs Plan Summary — local SNP availability separated into D-SNP, C-SNP, and I-SNP populations
- Enrollment Leaders — county-level enrollment leaders across Medicare Advantage, Part D, and Special Needs Plan classifications
These objects do not ask the machine to determine which numbers belong to which Medicare domain by interpreting the surrounding article.
The publisher makes those distinctions explicitly.
What This Looks Like in Practice
The county-level Medicare Options object provides the broad machine-facing representation of the local coverage landscape.
Conceptually, the published knowledge can be represented like this:
Medicare Options — County
- Medicare Advantage → local plan population
- Part D → local standalone prescription drug plan population
- Medigap → local participating carrier population
- Special Needs Plans → local SNP population
- D-SNP → local Dual Eligible SNP population
- C-SNP → local Chronic Condition SNP population
- I-SNP → local Institutional SNP population
- Enrollment → enrollment observations across local plan classifications
Those domains can then be described by their own machine-facing knowledge objects.
For example, the Medicare Advantage object can express the number of available plans, the distribution of HMO, PPO, HMO-POS, and PFFS plans, prescription drug coverage availability, out-of-pocket ranges, and Part B giveback characteristics.
The Part D object can separately express plan counts, basic and enhanced coverage populations, premium ranges, and deductible ranges.
The SNP object can separately identify D-SNP, C-SNP, and I-SNP populations.
The Medigap object can describe carrier availability and sample premium ranges without collapsing Medicare Supplement insurance into the Medicare Advantage or Part D market.
The broad consumer concept remains connected, while the underlying Medicare knowledge remains distinct.
A Resolver Is More Than Navigation
A conventional directory can send a visitor from one webpage to another.
A resolver has a different purpose.
Navigation answers:
Where can I go next?
Resolution answers:
What does this concept mean here, what does it contain, what is it related to, and what can it resolve into next?
The Medicare Options implementation demonstrates that distinction.
The human page provides navigation and explanation.
The machine tier does more than reproduce those links. It identifies Medicare Options as a county-scoped subject and separately publishes knowledge about Medicare Advantage, Part D, Medigap, SNPs, and enrollment within that context.
The resolver is therefore both a navigation surface for people and a resolution surface for machines.
Geography Is Part of the Knowledge
Some Medicare knowledge is national.
Other Medicare knowledge changes according to where the beneficiary lives.
The Medicare Options resolver therefore uses a geographic hierarchy:
United States → state → county → local Medicare options
At the county level, the machine-facing publication explicitly identifies the geographic subject rather than relying solely on a county name appearing in a title or URL.
This matters because plan availability, plan populations, enrollment, carrier participation, and other Medicare characteristics can vary geographically.
Geography becomes part of the knowledge being resolved rather than merely part of the webpage address.
Structured Data Is Not the Same Thing as Resolution
Publishing a collection of machine-readable Medicare facts is useful.
But a list of values alone does not resolve the consumer concept of “Medicare options.”
The values must remain associated with the correct Medicare domain, geographic scope, and knowledge role.
A Medicare Advantage plan count should remain a fact about the Medicare Advantage market.
A D-SNP count should remain a fact about the Special Needs Plan population.
A Medigap carrier count should not become indistinguishable from a Medicare Advantage plan count simply because both appear on the same county page.
Resolution depends on preserving meaning as information becomes more specific.
From Resolver to Resolution Surface
The Medicare Options county page is not intended to contain every fact about every Medicare subject.
Its job is to establish the major knowledge domains relevant to the question and provide continuations into increasingly specific knowledge.
That produces a larger resolution path:
Consumer question → Medicare Options → geography → coverage domain → local market → plan population → Plan ID → plan knowledge
The Medicare Options resolver sits near the beginning of that path.
The Medicare Advantage and Special Needs Plan county publications described in a separate Implementation Note operate farther down it.
Persistent Plan-ID resources can continue the resolution process to individual Medicare plans and their attributes.
Together, these surfaces demonstrate an architectural principle:
A knowledge system does not need one page that answers everything. It needs reliable surfaces that progressively resolve the question.
The Resolver Connects to Two-Tier Publishing
The Medicare Options resolver demonstrates how resolution and two-tier publishing can work together.
The human-facing publication is responsible for explaining Medicare coverage pathways, differences, local context, and consumer considerations.
The machine-facing publication is responsible for making important classifications, populations, geographic scope, facts, and continuations explicit.
MedicarePlans.com uses WebMEM to implement this machine-facing knowledge tier alongside the human-readable publication.
WebMEM is not the resolver itself.
The resolver defines how the question decomposes into knowledge. WebMEM publishes that knowledge for machine resolution.
Why This Matters for Medicare Publishing
Medicare publishing has traditionally been organized primarily around documents and topics.
AI systems introduce another consideration.
The publisher may need to help machines determine not only where information is located, but also what the information describes, what scope it applies to, and how it relates to the question being asked.
A Medicare publisher can identify ambiguous consumer concepts.
It can define the knowledge domains those concepts resolve into.
It can preserve geographic, temporal, eligibility, and product distinctions.
It can publish facts within those domains rather than leaving their meaning to inference.
And it can provide continuations into increasingly specific knowledge.
The publisher already understands the domain. The publishing architecture can express that understanding.
An Ongoing Public Implementation
MedicarePlans.com is currently operating the Medicare Options resolver as part of its public Medicare information architecture.
The implementation should not be interpreted as evidence that a particular search engine or AI system will interpret or use the resolver in a particular way.
That remains an empirical question.
What can be observed is whether systems discover the resolver, how ambiguous Medicare queries begin resolving to it, which downstream knowledge surfaces they use, and whether the distinctions established by the publishing architecture are preserved in generated answers.
Those observations can be documented separately from the implementation itself.
The important publishing question is no longer simply whether the answer exists somewhere on the website.
The more interesting question is: