Mapping the Territory: Why Official Roads Need Community Knowledge

Waze did not build a better base map than Google Maps. It added the community-sourced overlay: accidents, speed traps, police, road closures, the pothole on Route 9 that the official map has never acknowledged. The official map is correct. The official map does not know what happened on your route this morning.

Waze added the missing layer on top of existing infrastructure and produced navigation that neither layer alone could provide. The architectural insight was that community overlay and official base map are not competitors. They are composable layers that produce a better outcome together than either produces alone.

Anthropic's CMS Connector is the official road map for prior authorization: authoritative, maintained, covering the federal baseline accurately. But the prior authorization request in front of a reviewer this morning is not a federal question. It is a Blue Cross Blue Shield of Texas question, or a UnitedHealthcare Community Plan question, or a Humana Medicare Advantage question. Each of those payers has added their own criteria, documentation requirements, and decision turnaround rules on top of the CMS baseline. The CMS Connector does not know those rules. This server does.

Anthropic launched Claude for Healthcare at JPM 2026 with a CMS Coverage Connector that gives agents direct access to Medicare National and Local Coverage Determinations. That is the official map. The clinical-rules-mcp-server is the community overlay.

The Federal Floor and the Coverage Reality

Anthropic's CMS Coverage Connector, part of the Claude for Healthcare toolkit launched in January 2026, gives agents structured access to Medicare National Coverage Determinations and Local Coverage Determinations. It enables an agent to pull coverage requirements from the CMS database, check clinical criteria against patient records, and propose determinations with supporting documentation for human review. For Medicare fee-for-service prior authorization, it is the right tool.

The prior authorization landscape is not primarily Medicare fee-for-service. Commercial insurers cover approximately 156 million Americans. Medicare Advantage, which now represents the majority of Medicare beneficiaries, operates under plan-specific criteria that individual payers set within the federal framework. Medicaid programs vary by state. Each of these payers layers their own authorization criteria, documentation requirements, and decision turnaround expectations on top of the CMS baseline.

A prior authorization agent armed only with NCD and LCD data will correctly identify whether a procedure is covered under Medicare. It will not know whether PAYER_COMMERCIAL_A requires pre-certification for CPT 27447 with a specific clinical notes template, or whether that payer's Medicare Advantage plan requires additional documentation that the fee-for-service standard does not. The CMS Connector supplies the federal floor. This server supplies what the floor does not cover.

The math reveals the scope of the gap. Medicare Advantage enrollment reached 31 million beneficiaries in 2024, representing 51% of all Medicare beneficiaries. Commercial coverage accounts for another 156 million Americans. Together, these managed care programs operate under authorization rules that extend beyond federal determinations. Prior authorization affects 35% of physicians daily, with 88% reporting care delays due to the process. Those delays happen when the authorization process cannot resolve the gap between federal coverage standards and plan-specific requirements.

Four Tools and One Design Principle

The server exposes four tools. Three are deterministic database queries. One calls Claude.

list_payers returns the payer catalog from the knowledge store: no model, no inference cost, sub-millisecond response. get_coverage_policy returns coverage status, the payer-specific overlay, and the federal NCD/LCD baseline for a given CPT code and payer identifier: no model, a structured query against a normalized schema. check_auth_requirements returns the authorization-required flag, the criteria list, and the payer's decision turnaround time for a given procedure, diagnosis, and plan type: no model, the same pattern.

flag_documentation_gaps is the tool that justifies a model call. It receives the clinical notes and the criteria result from the coverage check and returns a 0-to-100 completeness score with each identified gap classified as blocking or advisory. Gap analysis requires clinical language understanding: matching the language in free-text clinical notes against the structured criteria of an authorization requirement is a task where an LLM adds genuine value. The other three tools are lookup operations. Lookup operations do not need an LLM.

The design principle is the same one the readmission-risk-scorer demonstrated at the model level: use AI where language understanding adds value, use deterministic computation everywhere else. Three of the four tools execute in microseconds without touching the Anthropic API. The fourth earns its inference cost.

Every tool returns a typed structuredContent object. A consuming pipeline reads it directly with no parsing or normalization layer. This is specification precision applied at the tool boundary: the caller knows exactly what to send, and the server knows exactly what to return. The Zod schema for flag_documentation_gaps defines severity as an enum and the scoring rubric before a single token is generated, so the model is constrained by the contract, not free to invent its own output format.

Composition at the Pipeline Level

The Track 2 LangGraph pipeline is where the composition architecture becomes visible. Four nodes process a prior authorization request: AuthRequestNode validates and structures the input, CoverageCheckNode queries both knowledge layers, DocumentationAuditNode evaluates clinical note completeness, and DeterminationNode produces the final assessment.

CoverageCheckNode is the architectural pivot. It queries the Anthropic CMS Connector and this server's get_coverage_policy in parallel, then merges both results before passing them downstream. The parallel execution is intentional: the two knowledge sources are independent. Neither depends on the other's result. Running them concurrently halves the latency of the coverage check step. The merge happens at the application layer, not inside either knowledge source.

This is what the composition pattern looks like in practice. The Anthropic CMS Connector returns the federal coverage determination. The clinical-rules-mcp-server returns the payer-specific overlay. DocumentationAuditNode receives both, calls flag_documentation_gaps with the combined criteria, and produces a completeness score against the full authorization requirement rather than the federal portion alone. DeterminationNode then has the complete picture: federal coverage status, payer-specific requirements, and documentation gap analysis classified by severity.

Neither knowledge layer produced that complete picture alone. The composition did.

Context Windows Have Boundaries

Every get_coverage_policy query is targeted: it returns the criteria relevant to the specific procedure and payer in the request. The full knowledge store never enters the context window. A prior authorization for CPT 27447 under PAYER_COMMERCIAL_A returns the commercial payer's criteria for total knee arthroplasty plus the relevant federal NCD, not the entire payer catalog or the complete NCD/LCD database.

This is not an optimization. It is an architectural requirement. Context windows have limits. More importantly, an agent that receives the full knowledge base for every request must spend inference capacity deciding what is relevant before it can act on what is relevant. Targeted queries resolve that problem at the database layer, before the token is spent.

The database schema reflects this design: federal NCD/LCD documents and payer-specific overlay rules are stored in separate tables with a query layer that joins them only for the specific procedure and payer in scope. The schema is the context architecture. The query is the context selection. The tool boundary is where the selection happens, so the agent receives a curated, relevant knowledge package rather than a raw data dump it must navigate.

Token usage becomes proportional to the request complexity, not the knowledge store size. A straightforward authorization request for a routine procedure under a commercial plan consumes fewer than 500 tokens in the flag_documentation_gaps call. Complex cases involving multiple criteria and incomplete documentation might reach 2,000 tokens. The difference correlates with the clinical language analysis required, not with the size of the underlying knowledge base.

When Machines Know Their Limits

DeterminationNode produces a confidence score with every authorization assessment. When confidence is 0.8 or above, the determination is returned inline. When confidence falls below 0.8, HumanReviewNode fires. The clinical-rules-ui polls for the review state and routes the reviewer to the /review/[requestId] panel, which presents the structured determination, the confidence score, the documentation gap list with blocking and advisory classifications, and approve/override controls.

The confidence threshold is a governed parameter, not a hardcoded constant. The design principle is the same as payer-auth-intelligence's interrupt-before pattern: the system knows its own uncertainty and routes to human review rather than producing a low-confidence automated determination. In clinical authorization, the cost of a wrong automated determination is not a user experience problem. It is a coverage denial that delays patient care or a wrongful approval that creates liability. The threshold parameter acknowledges that the right value depends on the payer, the procedure, and the risk tolerance of the organization deploying the system.

Extension, Not Replacement

The clinical-rules-mcp-server makes a case that enterprise AI architects need to internalize: the right response to a well-designed foundation tool is to extend it, not replace it.

Anthropic shipped the CMS Connector to give agents access to federal coverage ground truth. They described their prior authorization skill as a starting point for organizations to customize. This server is that customization, implemented as a composable MCP layer that adds payer-specific knowledge without modifying, duplicating, or competing with what Anthropic already ships. The composition produces capabilities that neither layer alone provides.

The four-tool surface, the structuredContent contracts, the targeted query design, and the confidence-gated human review are each individually defensible architecture decisions. Together they represent a coherent design philosophy: every component in an agentic pipeline should do exactly one thing well, define its boundaries explicitly, and compose cleanly with the components around it. The MCP protocol makes that composition possible. The architecture choices make it trustworthy.

The potential for administrative cost savings justifies the architectural precision. Healthcare automation could save the industry $18 billion annually, with prior authorization representing a significant portion of potential savings. CMS requirements for electronic prior authorization by 2026 create a compliance timeline that makes the composition architecture more than an elegant solution. It becomes a practical necessity for organizations that need to bridge federal requirements with payer-specific implementations.

The Community Layer Wins

Waze did not win by building a better road map. It won by adding the community knowledge that the official map could not contain, and by making that knowledge composable with the infrastructure that already existed. The value emerged from the combination.

The clinical-rules-mcp-server is built on the same insight. Anthropic's CMS Connector is the official map. Commercial payer criteria, Medicare Advantage plan-specific rules, and Medicaid program overlays are the community knowledge the official map does not carry. Together, queried in parallel and merged at the application layer, they produce a prior authorization determination that neither source alone could produce.

The server code is at github.com/paullopez-ai/clinical-rules-mcp-server. The UI is at github.com/paullopez-ai/clinical-rules-ui. Track 1 runs in Claude Desktop with zero API keys. Track 2 runs the full LangGraph pipeline. The composition works at either level.

References

[1] U.S. Census Bureau. "Health Insurance Coverage in the United States: 2023." Current Population Reports, 2024.

[2] Centers for Medicare & Medicaid Services. "Medicare Advantage Enrollment Dashboard." CMS.gov, 2024.

[3] American Medical Association. "Prior Authorization and Utilization Management Reform." AMA-assn.org, 2024.

[4] McKinsey & Company. "The Economic Impact of AI in Healthcare Administration." McKinsey Global Institute, 2024.

[5] Centers for Medicare & Medicaid Services. "Advancing Interoperability and Improving Prior Authorization Processes." Federal Register, 2024.