A Software Company in Indianapolis Counting Down to the Payer API Deadline

Updated November 2026 · Written and maintained by the Progression Agency strategy team

January 1, 2027 is the date in the CMS interoperability rule by which a health plan’s patients, in-network doctors, other plans and prior authorization system have to be able to reach its data through four named APIs. For a software company in Indianapolis, where Elevance Health lists its address, that date is the work. This page gives each of the four APIs its own clock, the data it has to carry and the build list, then the cost. Progression is based in New York, builds for Indiana companies remotely, and offers on-site sessions on request.

One date, four doors

A health plan’s project board has one date on it and four columns under it. Each column is an API, each API has its own owner, and each one opens a different door onto the same patient records.

The board is made up, and the shape is real. The same date sits on all four columns, but the work, the people and the patients behind each one are different. This page takes them one at a time.

What a software company in Indianapolis is being asked to build

The CMS fact sheet on the Interoperability and Prior Authorization final rule, CMS-0057-F, says Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities and Qualified Health Plan issuers on the Federally Facilitated Exchanges, collectively called impacted payers, must implement and maintain certain FHIR application programming interfaces.

Impacted payers must also implement certain operational provisions, generally beginning January 1, 2026, and have until compliance dates, generally beginning January 1, 2027, to meet the API development and enhancement requirements. CMS says the exact dates vary by the type of payer. Whether a plan is covered, and which date applies, are questions for the plan’s counsel.

An Indianapolis software company asked to help is asked to build four interfaces to the plan’s data, and the surrounding screens and logs. It does not decide whether the plan is covered, and it does not make the plan compliant.

What does impacted payer mean?

It is the rule’s collective name for the plan types listed above. If you are unsure whether your plan is one, ask counsel before you scope any work.

A search for an Indianapolis software company usually comes from a plan or a vendor that already knows the date. The sections below are written for that reader.

Clock 1: Patient Access API

The earlier CMS rule already required a Patient Access API. The new rule adds information about prior authorizations, excluding those for drugs, to the data available through it, by January 1, 2027. CMS says this helps patients understand their plan’s prior authorization process and its effect on their care.

Annual reporting is a separate clock. Beginning January 1, 2026, impacted payers must report annual metrics to CMS about Patient Access API usage, so the API has to count its own use.

• Add prior authorization records to the Patient Access API data set.
• Exclude drug prior authorizations, as the rule says.
• Test with the apps patients actually use.
• Count usage in a way that can be reported each year.
• Keep a record of changes to the data model.

Clock 2: Provider Access API

The rule requires a Provider Access API that shares patient data with in-network providers who have a treatment relationship with the patient. The data are individual claims and encounter data (without provider remittances and enrollee cost-sharing information), USCDI data classes and data elements, and specified prior authorization information excluding drugs.

Payers must also keep an attribution process that associates patients with the in-network or enrolled providers they have a treatment relationship with, allow patients to opt out, and give plain language information about the benefits of data exchange and the right to opt out. The date is January 1, 2027.

• Build the attribution process that links patients to treating providers.
• Expose claims, encounter, USCDI and prior authorization data through the API.
• Honor each patient’s opt-out before any data leaves.
• Show the plain language information where patients will see it.
• Log each request, response and opt-out change.

Clock 3: Payer-to-Payer API

The Payer-to-Payer API makes claims and encounter data (excluding provider remittances and enrollee cost-sharing information), USCDI data and information about certain prior authorizations available when a patient changes plans. Payers share only data with a date of service within five years of the request.

CMS describes an opt-in process for patients to give permission, with plain language educational resources that explain the benefits of the exchange and the right to opt in. These requirements must be implemented by January 1, 2027.

• Capture the patient’s permission before any data moves.
• Limit the data to dates of service within five years of the request.
• Exchange data in both directions with other plans.
• Show the educational resources in plain language.
• Keep a record of each permission and each transfer.

Clock 4: Prior Authorization API

The Prior Authorization API must be populated with the plan’s list of covered items and services, be able to identify documentation requirements for approval, and support a prior authorization request and response. It must also communicate whether the plan approves the request, with the date or circumstance on which the authorization ends, denies it with a specific reason, or asks for more information. The date is January 1, 2027.

CMS also says HHS will announce enforcement discretion for the HIPAA X12 278 transaction standard for covered entities that implement an all-FHIR Prior Authorization API, so a FHIR-only or combined approach can be used. Ask counsel what applies to your plan.

• Load the covered items and services list and keep it current.
• Return the documentation requirements for each item.
• Accept a request and return approval, denial or a request for more information.
• Return a specific reason with every denial.
• Return the end date or circumstance of every approval.

The cards collect the data and patient choice lines that run through the Provider Access and Payer-to-Payer APIs. Build them once in a shared layer and reuse them.

What the four clocks cost to build

The cost depends on what already exists. A plan with a working Patient Access API and a strong data layer adds less than one starting from files and batch jobs. The Prior Authorization API often touches the most systems, because it reaches into utilization management.

Hosting, licenses and security testing are on top of these figures. Progression quotes after a written scope, with no price for any one API. Our software development company page explains how a scope is written, and HIPAA compliant software development covers health data handling.

Does the rule tell a plan which software to buy?

No. The fact sheet describes what the APIs must do and by when. Whether a plan builds, buys or splits the work is its own decision.

What drives the price up?

How many source systems feed the data, how clean the data are, how many apps and providers must be tested, and how much of the work needs a vendor.

• Number of source systems behind each API.
• Quality of member, claims and provider data.
• Consent and logging screens.
• Testing with outside apps and providers.

The opt-in and the opt-out are product work

The rule asks for plain language information to patients about the benefits of exchange and their choice. That is a screen, a paragraph and a button, written by someone who knows the plan’s members. A software company builds the screen; the plan, with counsel, writes the words.

• One screen for the Provider Access opt-out and one for the Payer-to-Payer opt-in.
• A short paragraph in everyday words, tested with real members.
• A record of every choice, with the date.
• A way to change the choice later.

Can a patient change the choice later?

The rule describes the choice and the information that comes with it. Build a way to change it, and record each change with its date.

Who writes the patient language?

The plan’s member communications team, reviewed by counsel. Ask counsel what the rule requires, and keep the approved text under version control.

What started on January 1, 2026?

The fact sheet says impacted payers must send prior authorization decisions within 72 hours for expedited requests and seven calendar days for standard requests, excluding QHP issuers on the Federally Facilitated Exchanges. Beginning in 2026 they must give a specific reason for a denied prior authorization decision, whatever method is used to send the request.

Payers must also publicly report certain prior authorization metrics annually by posting them on their website, and the initial set was due by March 31, 2026. These provisions do not apply to drug prior authorization decisions. Check the rule for your plan.

Who owns each API inside a plan?

Usually four different people, which is why the board has four columns. The Patient Access API often sits with member services and digital, Provider Access with provider relations, Payer-to-Payer with enrollment and Prior Authorization with utilization management.

Name the owners on the readiness card before the first meeting.

A readiness card for your plan

Use the card as a first page for the project folder. It forces the choices that decide the scope.

The cards list the six questions to settle first. Our SEO in Indiana page covers search for Indiana companies, and app development agency covers the member apps that sit in front of these APIs.

Related services and guides

Pages that sit beside this countdown:

• Software development company
• App development agency
• SEO in Indiana
• HIPAA compliant software development

Frequently asked questions