The Deadline Is Boring, The Architecture Is Not

The January 2027 API requirement forces payers to make a thirty-year-old unstructured process machine-readable. That representation gets built once, and how it is scoped decides what else it can carry.

Before midnight on December 31, 1999, the most important work had already been done. The part people remember is the rollover: champagne, news anchors counting down, anxious IT staff watching dashboards. The part that actually mattered happened in 1997 and 1998, in rooms nobody filmed, when organizations made inventories of every system that touched a date field and then had to decide what to do with what they found. The inventory was the project. The remediation was downstream of the inventory.

Two kinds of organizations came out of that period. The first patched date fields and moved on. The second used the mandatory archaeology as an occasion to understand, for the first time, what their systems actually did and how those systems related to each other. They were never going to fund that investigation independently. The regulatory deadline funded it for them. The difference in their positions five years later was not explained by budget. It was explained by how the work was scoped in 1997.

A payer organization today has a January 2027 date on a compliance slide, a budget approved against that date, and a scope document written to make an endpoint conformant. That is the correct response to the situation as stated. The scoping decision has a second consequence that nobody costed, and that second consequence is what this article is about.

The Constraint Set

Start with what the rule actually forces. A payer must expose prior authorization capability through an API, which means the request, the applicable criteria, the documentation required, the decision, and the reason for that decision all have to exist in a structured, machine-readable form. Not in a policy document. Not in a reviewer's judgment. In a representation a system on the other side can consume without a human reading it.

That is a larger change than the integration work implies, and the reason is thirty years old. The electronic standard for this transaction has existed since the 1990s and its existence did not produce structured prior authorization, because the criteria being applied were never structured. The transaction carried a request and a response around a decision process that stayed in documents, in reviewer expertise, and in phone calls.

The rule closes that gap by requiring the criteria and the reasons to be expressible, not just the request and the answer. Building that representation is the project. The API is the part that gets demonstrated.

The pressures around it are the ordinary ones and they are decisive. A fixed date that cannot move, a budget approved against a compliance scope, a delivery organization already committed, and a clinical policy function that owns the criteria and has never been asked to make them machine-readable before.

The 278 transaction has been available since the Clinton administration, which tells you something about the relationship between a standard existing and a standard being used.

In practice, the criteria do not live in one place. They are distributed across national vendor criteria sets, internal clinical policy documents, local rules that vary by line of business, and the working judgment of medical directors who have spent years developing expertise that was never intended to be expressed as logic. Making them expressible requires a clinical policy exercise that precedes the engineering work. Most payer organizations are not staffed for that exercise in clinical policy, and the delivery timeline does not accommodate discovering that late. The organizations that are moving fastest right now are the ones that recognized this constraint early and staffed accordingly, rather than treating the criteria representation as an output of the technical work.

Where the federal baseline ends and the payer-specific rule set begins matters enormously here, and the distinction the author makes in this piece on official roads and community knowledge is exactly the gap a criteria representation has to bridge.

What Gets Scoped First, and Where the Fork Happens

Two teams can satisfy the same requirement and produce assets with entirely different futures, and the difference is set in four decisions that cost nothing extra at the time.

The first is whether the criteria are represented as evaluable rules with identity and version, or embedded in the code path that answers the API call. Both pass conformance. Only one of them can be reasoned over by anything else, ever.

The second is whether the decision record captures the reason in a structured form, meaning which criterion was applied, what evidence satisfied it, and what was missing, or whether it captures a reason code and a free-text string. The rule requires a specific reason. A reason code satisfies that sentence and carries no reusable information.

The third is whether the documentation requirements are modeled as a queryable relationship between a service, a plan, and the evidence that supports it, or as a static list returned per request. The fourth is whether the transaction is designed with a persistent identity across its full lifecycle, so a request, its documentation exchange, and its outcome are one durable thing rather than a series of unrelated calls.

None of those four decisions expands the compliance scope. All four decide whether the organization ends 2027 with a conformant endpoint or with a structured representation of its own coverage logic.

The criteria embedded in a code path are not the wrong choice because the engineers made a mistake. They are the natural choice when the framing is "pass the conformance test" rather than "build a representation." Embedding is faster to implement, easier to test in isolation, and entirely defensible given the stated scope. It fails eighteen months later, when a clinical operations team asks whether they can evaluate a new service type against the same criteria a reviewer uses, or when a vendor integration requires exposing criteria logic without rebuilding the decision engine. At that point, the criteria do not exist anywhere a second system can read, and the answer to every question is a rebuild.

The fork between those two futures is not visible in a conformance test. It is visible only in the scoping document, and only to someone who is reading for it.

The architecture that treats the exchange between provider and payer as a typed, auditable protocol rather than a bespoke negotiation is described in more detail here, and the reasoning applies directly to how the criteria layer gets bounded.

The Architecture That Fits, and What It Refuses to Do

Given that substrate, the agentic capability on top of it is a small addition rather than a second program, and it has a specific shape. A staged pipeline: intake and validation, benefit and eligibility check, criteria evaluation against the structured rules, routing, and human review. Deterministic at both ends, model reasoning only in the middle where reasoning genuinely helps, and a confidence gate between the reasoning and the routing.

The gate carries one rule that is not negotiable and is set before implementation rather than tuned afterward. The system never issues an automated denial on model uncertainty. Below the threshold, the request routes to a human reviewer, and human review is a named node in the design with its own state, its own audit record, and its own service expectations. It is not an exception path and it is not a fallback.

The value this creates is latency, completeness, and consistency. It gets a complete, well-documented request in front of the right reviewer faster, with the applicable criteria and the supporting evidence already assembled and the gaps already named. It is not a mechanism for deciding more cases without people, and an architecture that presents it that way should not be built.

A system designed well enough to surface what is missing from a request is the same system that makes explicit, on the record, why documentation that does not connect clinical facts to stated criteria is a structural failure rather than an administrative one. The argument the author makes here on justification quality applies directly to what the criteria evaluation layer is being asked to assess.

The criteria evaluation function belongs behind its own interface rather than inside the API service. The reason is operational: the criteria change on clinical policy cycles, which are not the same as software deployment cycles, and mixing them into a single release path creates dependency that neither team will enjoy. State for these transactions persists across days, sometimes weeks, and the right persistence layer is determined by the organization's existing footprint as much as by architectural preference. Pretending otherwise is where most implementation guidance fails. The audit obligation implies immutability for the decision record: once a determination is made and communicated, the record of what criteria were applied, what evidence was present, and what was missing cannot be modified, only annotated with a new action.

The organizational design point that matters most here is separation of function. The team that authors the criteria and the team that operates the system applying those criteria should not be the same team. This is not a technical constraint. It is a controls design point, and it protects both functions.

Where This Goes Wrong

The objection from a payer CIO is the correct one, and I would make it in their position. Scope creep against a regulatory deadline is how organizations miss regulatory deadlines. The budget was approved for compliance, the date does not move, and "while we are in here" has ended more programs than any technical failure ever has. Anything beyond the requirement belongs in a separate initiative with its own business case and its own funding.

I am not arguing for more scope. I am arguing that four scoping decisions inside the existing scope cost nothing at the time and cost a rebuild later, and that they are being made by default right now by people who do not know they are making them. If a decision cannot be made to fit inside the compliance scope, it should not be attempted, and I would rather an organization ship a conformant endpoint on time than miss the date reaching for something better.

There is a second failure mode that deserves naming, and it is more serious than the first. A structured criteria representation makes automated decisioning easier, and easier is not the same as appropriate. The organization that builds this substrate acquires an obligation along with a capability, which is to decide deliberately, and in writing, what the system is permitted to do without a person, before anyone is in a position to ask why it cannot do more.

That decision belongs in a governance document that exists before the system is deployed, not in a retrospective review after volume scales. The architecture makes certain things possible that were not possible before. Which of those things the organization chooses to enable is a clinical, legal, and ethical determination, and it should be made by the people accountable for those domains rather than inherited from a software default.

The Close

Pull the current scoping document this week. Find where the criteria are being represented, and check whether they are being modeled as evaluable rules with version identity or embedded in the code path that answers the API call.

That single line tells you which organization you are building.

Y2K is remembered as the disaster that did not happen, which is the worst possible performance review for the largest successful remediation project in the history of the industry. The organizations that spent the following decade in a materially better position were not the ones who avoided the disaster. They were the ones who used the mandatory work to understand what they had built, and scoped accordingly.

The difference between the two kinds of organizations coming out of January 2027 will be decided in the scoping meeting, not in the go-live review.