HL7 CRD separates coverage discovery from authorization submission

Discovery answers a different question from submission

Coverage Requirements Discovery is an upstream interaction. Its useful question is what the payer communicates about coverage requirements for a patient and contemplated service while the provider is still planning or ordering. Prior Authorization Support, by contrast, addresses submission and response. Keeping those stages separate prevents a returned requirement from being presented as an authorization, a denial, or proof that the eventual claim will be paid.

The distinction should remain visible in product architecture. A provider-side workflow may invoke CRD, display guidance, gather documentation through Documentation Templates and Rules, and later submit through PAS or another channel. Each step has different inputs, statuses, accountable parties, exceptions, and evidence. A single completed automation badge cannot explain which interaction actually occurred.

The request context determines whether the answer is useful

A CRD interaction depends on patient, payer, coverage, practitioner, service, clinical, and workflow context represented under the guide and its FHIR R4 foundation. A technically successful response may still be unusable if identity is mismatched, coverage is stale, the planned service is underspecified, the wrong endpoint or guide version is called, or locally configured rules do not preserve the payer's source and effective context.

Buyers should require a trace from the workflow trigger to the request context, endpoint discovery, guide version, payer response, user presentation, decision or next action, and retained evidence. The record should show which content came from the payer, which interpretation came from customer configuration, whether information was incomplete, and when a human changed or declined the recommended next step.

Requirements must stay bounded to plan and service scope

Prior-authorization requirements can vary by benefit, line of business, member coverage, service, diagnosis context, location, network arrangement, effective date, and delegated utilization-management role. A response for one context should not silently become a universal payer rule. Systems need version, scope, source, and expiration controls so users can distinguish current guidance from cached or generalized content.

Medical-service CRD also should not be projected onto pharmacy electronic prior authorization without an evidenced pathway. The transaction standards, participants, benefit logic, and networks can differ. A mature implementation makes those boundaries explicit and routes unsupported or contradictory responses to qualified operational review rather than creating patient-specific certainty from an incomplete exchange.

What a buyer should ask providers to demonstrate

Test one ordinary service and one ambiguous case across two plan contexts. Ask the provider to show trigger timing, patient and coverage matching, endpoint selection, version negotiation, returned coverage requirements, source display, documentation handoff, exception handling, user override, downstream submission, status, and audit export. Then change a payer requirement and inspect how open and historical work is treated.

Publication of an HL7 implementation guide does not establish payer availability, product conformance, endpoint reach, data quality, clinical appropriateness, or CMS compliance. Official provider documentation can establish claimed support for a named version. Production evidence requires representative testing with the buyer's payers, systems, populations, policies, and human-review responsibilities.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Prior Auth Monitor will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.