Prior Authorization API

Skip key takeaways

Updated October 8, 2026

• Required versus recommended CMS-0057-F requires FHIR R4, US Core, SMART App Launch and a HIPAA-compliant request and response, while CMS only recommends the Da Vinci CRD, DTR and PAS guides for payers.
• Payers and certified modules use different versions CMS still lists 2.0.1 and 2.1.0 for payers and flags 2.0.1 as derived from expired standards, while since October 1, 2026 certification to 45 CFR 170.315(g)(31)-(33) has required CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1, so payers should target the newer versions.
• Pended decisions need subscriptions HTI-4 requires certified modules to receive pended responses through subscriptions, and PAS says the inquire response omits requests for more information, so payer notifications have to work before the decision clock runs out.
• X12 278 is unenforced, not repealed HIPAA still names the X12N 278 and CMS has not enforced it against all-FHIR prior authorization since February 28, 2024, while the proposal to replace it with FHIR is not final.
• Operational rules came first Since January 1, 2026 impacted payers owe a specific denial reason regardless of the method used to send the request. All of them except FFE QHP issuers owe 72-hour and 7-day decisions, and the first public metrics were due March 31, 2026, a year before the API deadline.

Copy takeaways

In short: a prior authorization API is the FHIR interface through which a provider's system learns whether an item or service needs prior authorization, collects the documentation the payer wants, submits the request and receives the decision. CMS-0057-F requires impacted payers to run one, built on FHIR R4, US Core and SMART App Launch and supporting a HIPAA-compliant request and response, starting January 1, 2027 for Medicare Advantage organizations and state Medicaid and CHIP fee-for-service programs. For payers the Da Vinci CRD, DTR and PAS implementation guides are recommended rather than required. The obligation to support them falls on health IT modules certified to 45 CFR 170.315(g)(31)-(33), and since October 1, 2026 the versions those criteria reference are CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1. Certification is voluntary for developers; hospitals and clinicians are drawn in through the Electronic Prior Authorization measure. That split and an X12 278 standard that HIPAA still names drive the decisions below for architects at payers, EHR developers and provider-facing app teams.

What Does CMS-0057-F Require of a Prior Authorization API?

CMS-0057-F, the Interoperability and Prior Authorization final rule published at 89 FR 8758 and effective April 8, 2024, binds impacted payers: Medicare Advantage (MA) organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities and qualified health plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs). Commercial group plans and Exchange plans outside the FFEs are not in scope. For MA, 42 CFR 422.122 states the obligation directly: "Beginning January 1, 2027, an MA organization must implement and maintain an API conformant with" a list of cross-references to other API requirements in 422.119 and to three standards at 45 CFR 170.215(a)(1), (b)(1)(i) and (c)(1): FHIR R4, US Core 3.1.1 and SMART App Launch 1.0.0. Under 45 CFR 170.215 the adoption of the last two expired on January 1, 2026, a year before the API date, so payers should build to US Core 6.1.0 and SMART App Launch 2.0.0 or a later approved version, which CMS names among the updated versions ONC has approved and payers may use.

The same section gives the API four functions. It lists the covered items and services, excluding drugs, that need prior authorization, and it identifies the documentation each one requires. It also carries the request and the response, the function that keeps older transaction standards in play: under 42 CFR 422.122(b)(3) the API "Supports a Health Insurance Portability and Accountability Act (HIPAA)-compliant prior authorization request and response, as described in 45 CFR part 162". Finally, it communicates an approval with the date or circumstance on which it ends, a denial with a specific reason or a request for more information.

Other payer types carry parallel text with their own dates. For Exchange plans, 45 CFR 156.223(b) applies "for plan years beginning on or after January 1, 2027, a QHP issuer on a Federally-facilitated Exchange must implement and maintain an API". Paragraph (d) holds the exception. The issuer files a narrative justification with its QHP application stating why it cannot reasonably comply, the impact on providers and enrollees, its current or proposed means of giving providers the information and its solutions and timeline to comply. Approval by the FFE requires that making the issuer's QHPs available serves qualified individuals in the state and that an exception is warranted to let the issuer offer QHPs through the FFE. The final rule's summary sets the managed care date "by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities". State Medicaid and CHIP fee-for-service programs have their own relief: a one-time extension of one year, requested through the state's Advance Planning Document, or an exemption when at least 90 percent of their beneficiaries are enrolled in managed care. MA organizations and managed care plans have neither path.

CRD, DTR and PAS are recommended, not required

Nothing in that list names a Da Vinci guide. CMS says so in its enforcement discretion FAQ: the rule "requires the use of certain Health Level 7® (HL7®) standards and recommends certain HL7 implementation guides". A payer could meet the four functions without them, though few certified modules could then talk to it.

Key dates across these rules and the actions covered below:

Date	Rule	Who it binds	Status
February 28, 2024	No HIPAA enforcement against all-FHIR prior authorization that skips X12 278 (GL-2024-02)	HIPAA covered entities	In force, no end date
October 1, 2025	HTI-4 criteria (g)(31)-(33), (j)(20) and (j)(21) available	Health IT developers seeking certification	Final
January 1, 2026	Adoption of US Core 3.1.1 and SMART App Launch 1.0.0 in 45 CFR 170.215 expires; CMS flags the 2.0.1 Da Vinci guides as derived from them	Payers building the APIs, ONC Health IT Certification Program	Final
January 1, 2026 (Medicaid and CHIP managed care: rating periods starting on or after that date)	Specific denial reason on any channel, 72-hour and 7-day decisions	Impacted payers (timeframes exclude FFE QHP issuers)	Final
March 31, 2026, then yearly	Public prior authorization metrics for the prior calendar year	Impacted payers	Final
October 1, 2026	CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1 replace 2.0.1 in 45 CFR 170.215(j)	ONC Health IT Certification Program	Final
January 1, 2027	Prior Authorization API	MA organizations, state Medicaid and CHIP fee-for-service programs (states may seek a one-year extension or an exemption)	Final
Rating period or plan year beginning on or after January 1, 2027	Prior Authorization API	Medicaid and CHIP managed care, FFE QHP issuers	Final
October 1, 2027	Conformance to CRD, DTR and PAS; drug prior authorization (API for medical-benefit drugs, NCPDP for pharmacy-benefit drugs outside MA)	Impacted payers	Proposed in CMS-0062-P, not final as of October 2026

Which CRD, DTR and PAS Versions Should You Build To?

The two sides of the transaction point at different versions. CMS's page of relevant standards and implementation guides lists CRD, DTR and PAS at STU 2.0.1 and 2.1.0 for the Prior Authorization API, and it marks the 2.0.1 entries as "Implementation guides derived from adopted standards that expired on January 1, 2026", the expired standards being US Core 3.1.1 and SMART App Launch 1.0.0. The same page lets payers use updated versions, provided other law does not prohibit them, ONC has approved them for the certification program and they do not disrupt API access, and it names US Core 6.1.0 and SMART App Launch 2.0.0 among the updated versions ONC has approved.

Certification moved on October 1, 2026. ONC's part of the CMS-0062 rulemaking was finalized inside the FY 2027 inpatient prospective payment system (IPPS) final rule (CMS-1849-F and CMS-0062-F). That rule replaced the versions previously adopted in 45 CFR 170.215(j) "with the finalized updated versions upon the effective date of this final rule", and its dates section reads: "These regulations are effective on October 1, 2026." The current text of 45 CFR 170.215(j) lists CRD 2.2.1, DTR 2.2.0 and "Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide, Version 2.2.1-STU 2.2" and nothing older. There is no dual-version window for certification: from that date "these versions of the IGs will be the only versions health IT developers may use to meet the electronic prior authorization certification criteria as of the effective date of this final rule". Fielded EHRs did not flip on the same day, because the rule describes developers as having, if the remaining proposals are finalized, until the CY 2028 performance periods to deploy certified health IT meeting the updated standards, so 2027 traffic can still come from 2.0.1 builds or uncertified clients. The same final rule recounts that ONC had proposed "a January 1, 2028 expiration date for versions of the standards and specifications currently in 45 CFR 170.215(j)(1) through (3)", but what it finalized was replacement on the effective date. HL7 published all three 2.2 releases in March 2026, and a version pin should cite the readable /en/ pages: CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1.

How payers should handle the version gap

A certified module built to 170.215(j) speaks CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1, while a payer that read the CMS page literally may have shipped 2.0.1 or 2.1.0. Because ONC adoption is what makes 2.2.x an ONC-approved version, a payer can move to it under CMS's updated-version allowance. The FY 2027 IPPS final rule is also explicit that prior to the proposed October 1, 2027 payer compliance date, "APIs established by impacted payers are not required to conform to any version of these standards". The practical rule is to target 2.2.x and keep older versions only as a transition layer for clients that have not moved. CMS's own list ties the 2.0.1 guides to standards that expired on January 1, 2026, so a 2.0.1 path is a transition aid, not a target. In the matrix, the last column is our recommendation, not regulatory text.

Specification	Version CMS lists for payers	Version in 45 CFR 170.215 for certified modules from October 1, 2026	What a payer endpoint should accept
CRD	STU 2.0.1 (flagged as derived from expired standards) and 2.1.0	2.2.1, in 170.215(j)	2.2.1 as the target, 2.1.0 and 2.0.1 only as a transition layer for older clients
DTR	STU 2.0.1 (flagged as derived from expired standards) and 2.1.0	2.2.0, in 170.215(j)	2.2.0 as the target, 2.1.0 and 2.0.1 only as a transition layer for older clients
PAS	STU 2.0.1 (flagged as derived from expired standards) and 2.1.0	2.2.1, in 170.215(j)	2.2.1 as the target, 2.1.0 and 2.0.1 only as a transition layer for older clients
CDS Hooks	Not listed	2.0.1, in 170.215(f), for the (j)(20) client	Hook requests from 2.0.1 clients, with payload handling that also tolerates CDS Hooks 3.0.0, which CRD 2.2.1 lists among its base specifications

What Does HTI-4 Require of EHR Developers?

HTI-4 is the ONC rule, published inside the FY 2026 IPPS final rule, that created the electronic prior authorization certification criteria alongside updates for e-prescribing and real-time prescription benefit checks. The ASTP/ONC key dates sheet states: "The HTI-4 Final Rule is effective October 1, 2025." Five of its six new criteria serve prior authorization: three workflow criteria, (g)(31)-(33), and two client criteria they depend on, (j)(20) and (j)(21). The sixth, (b)(4), covers real-time prescription benefit. Unlike the payer rule, these criteria reference the Da Vinci guides directly, so a module certified to them is a fixed point payers have to meet. Certification itself is a developer's choice: section 3001(c)(5) of the Public Health Service Act sets up the program for "the voluntary certification of health IT", as ONC's December 2025 deregulatory proposal recounts.

In 45 CFR 170.315, criterion (g)(31) makes the module a CRD client that supports the workflow triggers of (j)(20) and the order-sign CDS Hook. Criterion (g)(32) requires it to "Support the capability for users to request and populate prior authorization documentation using templates and rules as a" Full DTR EHR, authenticating with SMART Backend Services. Criterion (g)(33) opens with "Support the following capabilities to enable users to submit prior authorization requests." and makes the module a PAS client that consumes and processes the payer's ClaimResponse.

The two client criteria carry the transport. Criterion (j)(20) is the CDS Hooks client, bound to CDS Hooks 2.0.1 in 170.215(f). Criterion (j)(21) is the Subscriptions client, bound to the Subscriptions R5 Backport guide 1.1.0 in 170.215(h) over a REST-hook channel, and (g)(33) relies on it to receive pended authorization responses. The (g)(33) criterion does not name the PAS $inquire operation, so a payer cannot assume a certified module will poll for status and notification has to work.

Teams already running FHIR R4 and SMART launch, covered in our EHR integration guide, start (g)(31)-(33) further along.

Prior Authorization API Components, Owners and Failure Modes

Six components make up a working prior authorization exchange. The last column names the failure mode that follows from each component's requirements.

Component	Who builds it	Governing text	Typical failure mode
CRD service (CDS Hooks server)	Payer or its delegate; EHR developer builds the client	42 CFR 422.122(b)(1)-(2) functions, CRD 2.2.1 (recommended), 45 CFR 170.315(g)(31) and (j)(20) for the EHR	The hook fires but no card comes back for the patient's plan, because endpoint discovery or payer routing is wrong
DTR questionnaire package (Questionnaire with CQL)	Payer authors the content, EHR or a SMART app renders it	42 CFR 422.122(b)(2), DTR 2.2.0 (recommended), 45 CFR 170.315(g)(32)	CQL written against a US Core version the EHR does not expose, so pre-population comes back empty and clinicians retype
PAS endpoint (Claim/$submit, Claim/$inquire)	Payer or an intermediary	42 CFR 422.122(b)(3)-(4), PAS 2.2.1 (recommended), 45 CFR 170.315(g)(33)	A denial returned without a specific reason, which breaches 422.122(a) even though the API call succeeds
X12 278 bridge	Intermediary or payer	45 CFR 162.1302, 42 CFR 422.122(b)(3), GL-2024-02 enforcement discretion (covered below)	Double translation drops situational fields; the mapping is published by X12, not in the guide
Pended-decision notification	Payer server; EHR developer builds the subscription client	PAS 2.2.1 subscription requirement, 45 CFR 170.315(j)(21)	The pend is sent, the notification never arrives and the 72-hour or 7-day clock runs out unseen
Decision-time and metrics pipeline	Payer	42 CFR 422.568, 422.572 and 422.122(c)	The clock starts at an event other than receipt of the request, so decisions run late and published decision times are wrong

Build Order for Payers and EHR Developers

Payer build order

Start with the operational layer, which already applies: denial reasons, decision clocks and metrics. Build the PAS endpoint next, pended handling included, since pends carry the clock risk. Per the PAS 2.2.1 technical specification, "The Claim submit operation is executed by POSTing a FHIR Bundle to the [base url]/Claim/$submit endpoint." Per item, "Whether a response is considered 'pended', 'denied', or 'successful' depends on the review action code returned in the response." For pends the guide is strict: "A subscription-based mechanism SHALL be used by the client to be informed of updates to the authorization." The payer therefore publishes a SubscriptionTopic and delivers notifications when a pended item is decided. While a request is pended, the same Claim submit operation can be used to modify or cancel it.

A pend can also turn into the request for more information that 422.122(b)(4) lists as one of the outcomes. Polling misses it; the PAS specification warns: "The Claim Inquiry response does not include all of the information that can be returned in a request response, such as any request for additional information, so the inquire operation SHOULD NOT be used by the client while waiting for final results." The client learns of it through the subscription notification. The documentation itself is gathered through DTR. Per the PAS background page, the PAS Task profile uses a DTR launch to give the provider the URL of a data-request Questionnaire, with the Questionnaire package named in Task.input. The DTR specification lists that Task among its launch contexts, next to an incomplete QuestionnaireResponse for re-launching DTR to continue an earlier session.

The CRD service follows, on the order-sign hook at minimum because that is the hook HTI-4 names, then order-select and appointment-book. CRD 2.2.1 defines six hooks, and the EHR must route each request to the right payer's CRD server, but connectivity comes first. The CRD foundation page says "Initial setup of connectivity between client and payer will have a manual component to establish security credentials and a trust relationship (unless both parties are part of a shared trust network)." A CRD server that supports endpoint discovery SHALL keep at most one endpoint per coverage, and once a connection runs on automated configuration, clients SHOULD repeat discovery at least once a day. Credential exchange and endpoint discovery therefore need as much testing as card content.

DTR packages follow. The DTR 2.2.0 guide describes the approach: "DTR leverages FHIR Questionnaires combined with embedded CQL logic and associated value sets to retrieve existing information". The payer exposes a single endpoint for all DTR calls, $questionnaire-package among them. Its CQL should target the US Core versions certified modules actually expose.

EHR developer build order

An EHR developer builds the transport first: the (j)(20) CDS Hooks client and the (j)(21) Subscriptions client. On top of the hooks client sits the (g)(31) CRD client. Next, the (g)(32) Full DTR EHR adds questionnaire rendering, CQL execution and SMART Backend Services. Last comes the (g)(33) PAS client, because it depends on the earlier pieces and on the subscription client for pended responses.

How to Test Conformance to CRD, DTR and PAS

ONC's Inferno platform hosts a kit per guide, the CRD, DTR and PAS test kits, each with suites for both sides of the exchange at 2.0.1 and at the 2.2 release and none at 2.1.0. The DTR and PAS kits let the client under test authenticate with SMART Backend Services or UDAP B2B client credentials. All three pages, updated September 8, 2026, call the tests drafts for preliminary checks and rate maturity as low.

Passing a suite shows that an implementation behaves as the guide at that version requires. It does not show that the payer's coverage rules are right, that a denial carries the specific reason 422.122 requires or that decisions meet the 72-hour and 7-day clocks, because those obligations sit outside the guides. Whether a kit run counts toward certification under (g)(31)-(33) is a question for ONC's test procedure for each criterion, not for the kit page. A payer that accepts several versions should run the server suites for each version the kits cover, 2.0.1 and the 2.2 release. The kits have no 2.1.0 suite, so a 2.1.0 path needs its own tests.

Does the X12 278 Transaction Still Apply?

Yes, in regulation. HIPAA's transaction standard for referral certification and authorization at 45 CFR 162.1302 still names the X12N 278 (version 005010X217), and 422.122(b)(3) points the Prior Authorization API at that part of the HIPAA rules. Enforcement is what changed, through guidance letter GL-2024-02 of February 28, 2024. The letter states that "HIPAA Administrative Simplification enforcement action will not be taken against HIPAA covered entities that choose not to use the X12 278 standard as part of an electronic FHIR prior authorization process." It gives no end date.

That leaves a payer two legitimate designs: an all-FHIR API under the discretion, or FHIR at the edge with X12 behind it. The PAS 2.2.1 home page anticipates the second: "these FHIR interfaces will communicate with an intermediary who, when necessary, can convert the FHIR requests to the corresponding X12 instances prior to passing the requests to the payer". That mapping is not in the guide: "To respect X12 intellectual property, all mapping and X12-specific terminology information will be solely published by X12". PAS supports the 278 request and response (005010X217) and the 278 inquiry (005010X215), so a bridge has to be tested on both.

What CMS-0062-P proposes for X12 278

HHS has proposed to end the dual track. The CMS-0062-P proposed rule, published April 14, 2026, would adopt the "CRD, DTR, and PAS IGs in place of the adopted versions of the X12N 278 Health Care Services Review" under HIPAA. Its scope is narrower: "The proposals to adopt the FHIR standards would only apply to dental, professional, and institutional transactions". The same proposal would require impacted payers to conform to the guides and would bring drugs covered under a medical benefit into the Prior Authorization API, with drugs covered under a pharmacy benefit moving to proposed NCPDP standards for impacted payers other than MA organizations, for which such requirements already exist, both from October 1, 2027. The FY 2027 IPPS final rule restates the proposed payer date: "We proposed an October 1, 2027 compliance date for impacted payers to conform to the proposed standards and IGs". Those payer-side proposals were not final as of October 2026; only ONC's version update from the same rulemaking is.

Decision Timeframes, Denial Reasons and Public Metrics

The operational requirements of CMS-0057-F took effect a year before the APIs. Per the CMS fact sheet, impacted payers other than QHP issuers on the FFEs have "to send prior authorization decisions within 72 hours for expedited (i.e., urgent) requests and seven calendar days for standard (i.e., non-urgent) requests", and "impacted payers must provide a specific reason for denied prior authorization decisions, regardless of the method used to send the prior authorization request". For MA, under 42 CFR 422.568(b)(1)(ii), from January 1, 2026 the standard decision is due "7 calendar days after receiving the request for the standard organization determination", with extensions of up to 14 calendar days in listed circumstances, while 422.572 keeps 72 hours for expedited determinations. For Medicaid and CHIP managed care the new limits apply to rating periods that start on or after January 1, 2026. 42 CFR 422.122(c) adds public reporting: "Beginning in 2026, following each calendar year that it offers an MA plan, an MA organization must report prior authorization data".

Public prior authorization metrics

The metrics go on the payer's website each March 31 for the previous year, and the fact sheet notes that "the initial set of metrics must be reported by March 31, 2026". For MA they are reported at contract level and exclude drugs. They cover the list of items needing prior authorization, standard and expedited approval and denial shares, approvals after appeal or extension and the average and median decision time.

Where Does the Electronic Prior Authorization Measure Stand?

CMS-0057-F added an Electronic Prior Authorization measure to the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability category. For hospitals and CAHs the FY 2027 IPPS final rule makes it optional with 10 bonus points in CY 2027 and required and unscored from CY 2028, tied to certified technology "which will be required to use version 2.2 of the Da Vinci IGs as part of ONC Health IT Certification Program requirements".

For MIPS clinicians CMS-0057-F made the measure required and unscored from CY 2027; the CY 2027 physician fee schedule proposed rule would make it a bonus measure for that year and add a prescription drug measure from CY 2028. Until a final rule adopts that, the CMS-0057-F position stands. None of this changes what a certified module must support.

How Pharos Production Helps

Our healthcare IT team builds software for provider and payer organizations, and our EHR integration services include HL7 and FHIR interfaces where the target system makes them available. We help payers and EHR developers separate required work from recommended and settle the version and X12 decisions before the build starts.

Sources: Centers for Medicare & Medicaid Services, CMS-0057-F fact sheet, CMS-0057-F rule page, HIPAA transaction enforcement discretion FAQ, guidance letter GL-2024-02 and APIs and relevant standards and implementation guides; Federal Register, CMS-0057-F final rule (89 FR 8758), CMS-0062-P proposed rule (91 FR 19890), FY 2027 IPPS final rule with CMS-0062-F (91 FR 49570), CY 2027 physician fee schedule proposed rule (91 FR 43842) and ASTP/ONC deregulatory actions proposed rule; eCFR, 42 CFR 422.122, 42 CFR 422.568, 45 CFR 156.223, 45 CFR 170.215 and 45 CFR 170.315; ASTP/ONC, HTI-4 final rule page, HTI-4 overview and key dates and Inferno test kits for CRD, DTR and PAS; HL7 International, Da Vinci CRD 2.2.1 home and foundation, Da Vinci DTR 2.2.0 home and specification and Da Vinci PAS 2.2.1 home, background and specification. Engineering guidance, not legal advice.

FAQ

Last updated: October 8, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• Does a provider-facing app vendor need ONC certification?

  Featured question. Copy link Copies a direct link to this answer to your clipboard.

  Not by law. Section 3001(c)(5) of the Public Health Service Act sets up the ONC program for the voluntary certification of health IT, and an app that is not a certified module can still take part in prior authorization, for example by running DTR as a SMART app.

  The pull toward certification comes from customers: the FY 2027 IPPS final rule ties the hospital Electronic Prior Authorization measure to certified technology that will be required to use version 2.2 of the Da Vinci guides.

• Does a payer need ONC certification for its Prior Authorization API?

  Copy link Copies a direct link to this answer to your clipboard.

  No. The ONC Health IT Certification Program certifies health IT modules such as EHRs, not payer APIs. A payer conforms to the CMS rule instead.

  Certification still matters to the payer indirectly, because ONC's adoption of a guide version is one of the conditions under which CMS lets payers use an updated version of the recommended guides. The FY 2027 IPPS final rule adds that, prior to the proposed October 1, 2027 compliance date, payer APIs are not required to conform to any version of these guides.

• Can a provider-facing app run DTR without being a certified EHR?

  Copy link Copies a direct link to this answer to your clipboard.

  Yes. The DTR guide allows the questionnaire logic to run as a SMART on FHIR app launched from the EHR or natively inside the EHR.

  An app vendor can implement DTR without certifying a module, but the provider organization's certified EHR still has to supply launch context and the US Core data the questionnaire's CQL reads.

• What does passing the Inferno tests prove?

  Copy link Copies a direct link to this answer to your clipboard.

  That the implementation conforms to the tested version of the CRD, DTR or PAS guide, within what each suite checks. The kits call themselves drafts for preliminary checks.

  Passing does not show that coverage rules are correct, that denials carry the specific reason 42 CFR 422.122 requires or that decisions meet the regulatory clocks, because those requirements sit outside the guides.

• Can an intermediary sit between the EHR and the payer?

  Copy link Copies a direct link to this answer to your clipboard.

  Yes, on either side. The CRD guide lets an intermediary take responsibility for the FHIR interface on the provider side, including deciding which payer should receive a coverage request.

  The PAS guide expects FHIR interfaces that talk to an intermediary which, when necessary, converts the requests to X12 before passing them to the payer.

• How should a payer handle requests from EHRs on different IG versions?

  Copy link Copies a direct link to this answer to your clipboard.

  Target CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1, the versions certification has required since October 1, 2026, which CMS allows because ONC adopted them. Keep 2.1.0 or 2.0.1 only as a transition layer for clients that have not moved: CMS's own list flags the 2.0.1 guides as derived from standards that expired on January 1, 2026.

  Run the Inferno server suites for 2.0.1 and the 2.2 release. The kits have no 2.1.0 suite, so test a 2.1.0 path separately.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.