The CMS Interoperability and Prior Authorization Final Rule Timelines, HIPAA Transaction Standards, State Turnaround and Gold Carding Laws and ERISA Appeal Rights: Compliance for US Prior Authorization Software

This article is part of our series on Custom Prior Authorization Automation Platform Development for US Payers and Provider Groups: Building a Rules Engine, Attachment and Status Tracking System

Requirements With Dates Attached

Most compliance in this series describes a steady state. Prior authorization compliance software describes a transition.

Federal requirements adopted for impacted payer programs carry staged compliance dates, which means organizations in scope are building toward obligations that are published rather than speculative, and organizations serving them are building for a market that will change on a schedule.

That is unusual and it changes how a build should be planned, since designing to current practice means designing to something that is being superseded.

Three further surfaces sit alongside in any prior authorization compliance software scope: the long-standing transaction standards, state laws that have moved considerably on turnaround and exemptions, and the appeal frameworks that depend on plan type.

Dates and scope have been subject to change and this guide publishes none of them, which makes current published guidance and counsel the right sources.

This is educational content, not legal advice. Compliance is the regulatory layer of the full custom software development guide to custom authorization platform development, expressed through web application development in the consoles where determinations are recorded.

The CMS Interoperability and Prior Authorization Final Rule

What It Addresses

Requirements adopted for impacted payer programs address implementing an interface supporting prior authorization alongside other access interfaces, communicating decisions within specified timeframes with separate handling for expedited requests, providing specific reasons when a request is denied, and publicly reporting metrics about authorization activity.

Scope, applicability by program and the specific obligations belong in current published guidance.

Staged Dates and What They Mean

Compliance dates are staged across coming years and have been subject to change, including enforcement discretion in some areas.

For a payer in scope this is an engineering program with deadlines rather than a roadmap item. For a provider or vendor it changes what payers will be able to receive and what they must publish.

The Metrics Obligation Is Underrated

Public reporting of authorization metrics changes the incentive landscape, since approval rates, turnaround times and denial patterns become visible.

An organization whose platform cannot produce those figures reliably has a problem that is operational before it is regulatory, and building the measurement properly is worth doing regardless of the date.

HIPAA Transaction Standards

The long-standing layer that explains why this process looks the way it does.

The administrative simplification provisions require covered entities conducting certain transactions electronically to use adopted standards, with a standard adopted for health care services review covering authorization requests and responses, maintained by the designated standards body and updated through regulatory adoption of versions.

Which produces a constraint worth understanding: the standard in force is the one adopted by regulation, not the latest the standards body has published, and version transitions happen through rulemaking.

Attachment standards addressing the transmission of supporting clinical documentation have been the subject of proposed rulemaking over an extended period, and the absence of a settled adopted standard is a substantial part of why clinical documentation still moves by fax.

Operating rules adopted alongside the standards address infrastructure and response expectations.

Privacy and security obligations apply throughout, since authorization requests carry clinical information and the platform holds it across both parties.

For the build: use the adopted version, handle the variation implementers introduce within it, and plan for version transitions as regulatory events rather than vendor upgrades.

Work from the current adopted standards and the implementation specifications, and never publish them. Establishing which of these apply to you is what a sprint does, covered in The Discovery Phase Explained.

State Turnaround and Gold Carding Laws

The layer that varies most and that has been the most active area of legislation in this space.

States have enacted laws addressing authorization turnaround times including shorter windows for urgent requests, requirements for electronic submission capability, transparency about clinical criteria and the qualifications of reviewers, continuity of approved authorizations when coverage changes, and limits on retrospective denial of approved services.

Exemption or gold carding programs have spread, generally exempting providers whose requests are approved at a high rate over a measurement period from authorization requirements for specified services, with the mechanics of measurement, notification, duration and revocation differing by state.

These apply to the plans a state regulates, which means a payer’s obligations differ by line of business and self-funded employer plans sit under a different framework.

For a provider operating across states, the requirements that apply depend on the plan rather than on where the practice sits, which is counterintuitive and frequently misunderstood.

For the platform: turnaround configured by plan and jurisdiction rather than globally, exemption status held and applied at intake, and the measurement a gold carding program requires produced as a standing capability.

Verify per state and per line of business, and never publish provisions.

ERISA Appeal Rights

The framework that determines what happens after a denial for a large share of covered people, and the one most often handled generically.

Employer-sponsored group health plans subject to the federal employee benefits framework operate under requirements governing claims and appeals, addressing what constitutes an adverse benefit determination, the timeframes within which decisions and appeal determinations must be made including expedited handling for urgent care claims, the content a determination notice must include, the right to the documents relied upon, the requirement that an appeal be reviewed by somebody other than the original decision maker, and in many cases access to external review.

A prior authorization denial is generally a pre-service claim determination under that framework, which attaches these obligations to it.

Other plan types operate under their own frameworks, with program-specific appeal structures.

Which means the appeal path depends on the plan, and a platform that offers one generic appeal workflow has got it wrong for most of its volume.

For the build: plan type held on the member record, the applicable framework driving timeframes and notice content, the independent reviewer requirement enforced structurally, and external review supported where it applies.

Obtain counsel, and never publish requirements or timeframes.

Other Obligations

Privacy and security obligations across a platform holding clinical information on both sides. Clinical reviewer qualification requirements, which address who may issue certain determinations and in some regimes require same-specialty review.

Mental health parity requirements, which reach authorization practices applied to behavioral health relative to medical benefits.

Utilization review accreditation where an organization holds or seeks it, and state utilization review licensure, which several states require.

Surprise billing and related protections where authorization interacts with them. Medicare Advantage and Medicaid managed care program requirements, which carry their own authorization provisions.

Record retention across requests, determinations, documentation and appeals. Language access and accessibility for member-facing communications. Those obligations apply equally to custom mobile app development where a member-facing application exists. And delegation agreements where utilization management is delegated.

What This Means for the Build

Five positions follow and belong in the architecture of any prior authorization compliance software.

Turnaround configured by plan, line of business and jurisdiction rather than globally, with expedited handling identified at intake.

Determination records carrying the reviewer, their qualification, the policy version applied and the specific basis, since every downstream obligation depends on them.

Denial communication constructed to the applicable framework’s content requirements, with appeal rights and the correct path included.

Appeal workflow driven by plan type, with the independent reviewer requirement enforced structurally rather than by policy.

And metrics measurement built as a standing capability rather than a reporting project, since public reporting obligations and gold carding measurement both depend on it.

Because requirements are moving on published dates, the structures encoding them should be configurable while the determination and outcome positions remain fixed. Which obligations become concrete product features is mapped in Prior Authorization Software Features.

Conclusion

Design to where the federal requirements are going rather than to current practice, since the dates are published.

Configure turnaround by plan and jurisdiction rather than globally. Drive appeal workflow from plan type, because one generic path is wrong for most volume. Build metrics measurement as a standing capability.

And keep the determination with a qualified reviewer whose qualification the record carries. This is educational content, not legal advice. Obtain counsel and work from current published guidance, then brief the software companies in the United States quoting you on where the platform’s job stops.

If you are scoping a platform, establishing which of your lines of business sit under which appeal framework is the question most likely to change your workflow design.

FAQ