By the time we began working seriously with individual Medicare Plan IDs, we thought we understood the basic publishing problem.
Medicare Options had shown us that a relatively small body of coherent knowledge could support many different questions. We were learning to think less about manufacturing individual answers and more about making the knowledge beneath them explicit.
A Plan-ID query looked easier.
Instead of asking a broad question about Medicare coverage in a county, the user could provide a specific identifier and ask for a specific fact.
The source data was authoritative. The identity appeared precise. The requested attribute was discrete.
What could go wrong?
Quite a lot, as it turned out.
17.1 This Should Have Been Easy
Consider the question:
What is the monthly premium for H5216-043?
From a publishing perspective, this looked like an unusually favorable information problem.
The user had supplied a structured Medicare identifier. We were not trying to infer which plan someone remembered from an advertisement or determine what they meant by “a cheap Medicare Advantage plan.”
They had given us:
H5216-043
and asked for:
the monthly premium.
CMS supplied authoritative plan data. We could identify the plan. We could publish a resource associated with that identifier. Premium was a factual attribute represented in the source data.
This was exactly the kind of problem that explicit machine-consumable knowledge seemed well suited to solve.
The difficulty was hidden inside the identifier.
H5216-043 correctly identified a Medicare plan at the contract-and-plan level. But the underlying entity structure could continue one level deeper.
The plan had segments.
Conceptually:
H5216-043
├── H5216-043-1 → $0
├── H5216-043-2 → $18
└── H5216-043-3 → $27Now the apparently simple question looked different.
The user had correctly identified the parent plan.
We had correctly identified its children.
We had the premium for each one.
And the premiums were different.
The identifier had not failed. It had done exactly what it was supposed to do: identify H5216-043.
What it had not done was identify the plan deeply enough to determine which segment-specific premium applied.
That distinction was easy to miss because the parent identifier looked so precise.
We had the right plan.
We still did not have the answer.
17.2 All the Facts Were True
The next realization was more important.
There was nothing wrong with the premium data.
Assume that the appropriate authoritative CMS source establishes:
H5216-043-1 has a $0 monthly premium.
H5216-043-2 has an $18 monthly premium.
H5216-043-3 has a $27 monthly premium.
There is no hallucinated value.
No stale source.
No transcription error.
No conflict that requires us to decide which premium is “really” correct.
All three are true.
That created a kind of failure we had not been thinking about clearly enough.
Suppose a system retrieves the $18 premium and answers:
The monthly premium for H5216-043 is $18.
The source fact may be completely accurate.
The application of that fact is not justified.
The system could instead retrieve all three values and attempt to be more careful:
Premiums for H5216-043 range from $0 to $27.
That statement accurately summarizes the candidate values.
But it still does not necessarily answer the question.
If one segment applies to a beneficiary, that beneficiary does not have a monthly premium ranging from $0 to $27. The beneficiary has one applicable segment with one applicable premium.
The range describes the candidates.
It does not resolve which candidate governs the case.
This was where our understanding of the publishing problem changed.
We had been concentrating on whether the right knowledge could be found.
In this case, it could.
The identifier had been recognized. The parent plan had been identified. Its child segments were known. The premiums were available. The source was authoritative. The individual facts were valid.
Retrieval had succeeded.
Resolution had not.
That was a different failure.
The machine did not necessarily need another fact about the premium.
It needed to know which of the facts it already possessed applied.
17.3 The Missing Fact Wasn’t a Fact
The next question was obvious.
What distinguished the segments?
In the Plan-ID cases we were examining, geography supplied the missing discriminator.
The publisher could know the parent plan.
It could know every segment beneath the parent.
It could know the premium associated with each segment.
It could know the geographic service area associated with each segment.
And it could know that geography was what determined which segment applied.
The state of the publisher’s knowledge was therefore fairly complete.
What was missing was the beneficiary’s geography.
That distinction turned out to matter enormously.
The publisher did not need another premium.
It did not need a better source.
It did not need another page explaining H5216-043.
It needed another piece of context from the person asking the question.
More importantly, the publisher already knew which piece of context was missing.
That meant we knew something beyond the three premium values.
We knew:
Geography must be resolved before a segment-specific premium can be presented as the definitive premium for H5216-043.
Until then, we had tended to think of that kind of rule as application logic.
A Medicare application might ask the beneficiary for a county, map that geography to the appropriate segment, retrieve the corresponding premium, and display it.
The software knows what to do:
Geography
↓
Applicable Segment
↓
Applicable PremiumThe public content might expose only the result.
But the rule connecting those steps was not merely a software implementation detail.
It described the domain.
The publisher knew that the parent identifier alone was insufficient for this attribute. It knew that child variants existed. It knew that the attribute varied among them. It knew which discriminator selected the applicable child.
That was knowledge too.
This was the part we had been leaving behind.
We were publishing facts while some of the knowledge required to use those facts correctly remained inside applications, database relationships, and business logic.
Once we saw that distinction, the publishing question changed again.
If the publisher knows the values and knows the condition governing their applicability, why publish only the values?
We did not need to publish the application’s code or tell an external answer engine what algorithm to execute.
We needed to preserve something more fundamental:
This is what must be known before this assertion can be applied safely.
That was the beginning of treating resolution requirements as part of the publisher’s knowledge.
17.4 Lee’s Pack of Cigarettes
The realization took me back to a programming class years earlier.
The class used PDP-11 Macro assembly language. Our instructor, Lee, was trying to teach us something more fundamental than syntax.
He asked for a volunteer.
Lee had a pack of cigarettes in his shirt pocket. The student’s task was to give him exact, step-by-step instructions for removing a cigarette from the pack and lighting it. The student could not simply perform the task or rely on Lee to fill in the obvious parts. Lee would follow the instructions as they were given.
To the student, the instructions sounded perfectly reasonable.
Lee followed them literally.
He reached incorrectly and pinched his shirt instead of properly grasping the pack. He pulled at the fabric. He mishandled the pack. The foil became another problem. Cigarettes were dropped. The filter and smoking end had not been distinguished precisely enough. Even the orientation of the lighter introduced assumptions the instructions had never stated.
Everyone in the room knew how to take out a cigarette and light it.
That was exactly the point.
The student knew what he meant.
Lee demonstrated how much of that meaning had never actually been communicated.
The instructions were not false. They were incomplete in ways that human common sense normally repaired without anyone noticing.
A machine does not owe us that repair.
Lee’s lesson was simple:
If you want the machine to do what you mean—not just what you say—you’d better be precise.
Years later, H5216-043 was the same lesson in a much more consequential domain.
We knew the parent plan had child segments.
We knew their premiums differed.
We knew geography determined which child applied.
If we published the identifiers and premiums but failed to preserve those conditions, we had not actually published everything we knew that was necessary to use the facts correctly.
The machine could retrieve exactly what we gave it.
The source could be authoritative.
Every fact could be true.
And the answer could still be wrong.
We had begun the Plan-ID work believing the challenge was to make the correct facts available.
The correct facts were already available.
What we had failed to publish was the knowledge governing their use.