As of January 1, USCDI v3 is the new floor for certified health IT. The federal certification program now recognizes one version of the United States Core Data for Interoperability (USCDI), the national list of data elements that certified systems must be able to exchange, and that version is 3. Version 1, which shaped most of the exchange built since the 21st Century Cures Act, no longer counts for new certification or for keeping an existing one.
The move was set in the HTI-1 final rule, published in January 2024 by the Office of the National Coordinator for Health Information Technology, now part of the Assistant Secretary for Technology Policy (ASTP/ONC). It arrives with 2 complications. After the 43-day federal shutdown that ended in November, ASTP/ONC said it would not start enforcement actions over the January 1 date before March 1, 2026. And since March 2025 the agency has not enforced several demographic elements of v3 itself, including sexual orientation and gender identity.
This analysis covers what v3 adds and what the grace period does and does not change. It also explains why the payer side of the industry should care about a standard written for electronic health records (EHRs). The short answer is that the same data definitions will travel through the payer APIs due in 2027.
Key takeaways
- USCDI v3 is now the only version for certification. HTI-1 retired USCDI v1 for certified health IT at the end of 2025 and moved the standardized API criterion to US Core 6.1.0 and SMART App Launch 2.0 on the same date.
- The new data classes matter to payers. Version 3 adds a Health Insurance Information class and a Health Status Assessments class, which covers functional and disability status among other elements.
- Enforcement starts March 1. After the shutdown, ASTP/ONC gave developers until February 28, 2026, to finish updates and said it would not begin enforcement before March 1.
- Some demographic elements are not enforced. Since March 2025, certified modules may omit several demographic elements, including sexual orientation and gender identity. USCDI v3.1, published in June 2025, removed those 2 elements.
- The standard has moved past the floor. USCDI has reached version 6, and HHS proposed in December to remove more than half of the program’s certification criteria.
USCDI v3 replaced version 1 for certification
The USCDI is a list, not a transport. It names the data classes and elements a certified system must be able to send and receive, and leaves the format to other standards, mainly HL7 FHIR for application programming interfaces (APIs) and the Consolidated Clinical Document Architecture (C-CDA) for documents.
HTI-1 tied several of those standards together on a single date. According to the HTI-1 fact sheet on standards and criteria, USCDI v3 becomes the only version used in certified health IT after December 31, 2025, and v1 is no longer accepted for certification starting January 1, 2026. On the same date, the standardized API criterion moves to the US Core Implementation Guide 6.1.0, which maps USCDI v3 to FHIR, and to the SMART App Launch Framework 2.0. The C-CDA companion guide moves from release 2.1 to release 4.1. The fact sheet lists updated minimum code sets as well, including the Source of Payment Typology version 9.2 for patient insurance.
The same date brings 2 less visible requirements. A new criterion requires certified systems to let patients request restrictions on the use or disclosure of their data through an internet-based method. And API refresh tokens for confidential apps must last at least 3 months, while a patient’s request to revoke an app’s access must take effect within an hour.
ASTP/ONC had first proposed an earlier date. The fact sheet notes that the proposed rule set USCDI v3 implementation for the end of 2024, and the final rule moved it to January 1, 2026, to give developers time. The HTI-1 overview describes v3 as the new baseline for the certification program as of that date, with developers free to move earlier.
What v3 adds that payers and utilization teams can use
The jump from v1 to v3 is larger than a version number suggests, because it skips v2. The USCDI page maintained by ASTP/ONC lists the additions in v3 relative to v2. For an organization that pays for care, 2 new data classes stand out.
Health Insurance Information. Version 3 adds 7 elements that describe a patient’s coverage, from coverage type to the member and payer identifiers. These are the fields a provider needs to route an eligibility check or a prior authorization request to the right plan. They are also the fields that most often break when a member changes plans or when a dependent is covered under someone else’s subscriber number.
Health Status Assessments. This class brings together assessments of the patient’s current state, including functional status and pregnancy status. Several of these are the facts that coverage criteria turn on. A request for inpatient rehabilitation depends on functional status, and behavioral health and home care decisions often depend on cognitive status. When these facts arrive as structured, coded data, a reviewer can find them without reading a 40-page record. Software can also check whether the documentation a criterion requires is present.
Version 3 also adds elements to existing classes.
| Data class | Elements added in v3 | Where they show up in coverage work |
|---|---|---|
| Medications | Dose details and fill status, among others | Step therapy and adherence questions, though drug prior authorization runs on separate pharmacy standards |
| Laboratory | Specimen type, result status | Distinguishing preliminary from final results before a criterion is applied |
| Patient Demographics/Information | Date of death and tribal affiliation, among others | Eligibility and program rules for American Indian and Alaska Native members |
| Procedures | Reason for referral | Matching a referral to the clinical question a reviewer has to answer |
From the ASTP/ONC USCDI version comparison. The right-hand column is this analysis’s reading of where each element is commonly used, not a statement from ASTP/ONC.
None of this guarantees that the data will be populated. Certification tests that a system can capture and exchange an element, not that clinicians record it. Functional status in particular is often documented as narrative in therapy notes rather than as a coded assessment. The value to a utilization management team depends on whether the providers it works with record these elements in structured form and send them.
What a reviewer needs, field by field
Coverage criteria are written as questions about a patient. Most of those questions now have a defined home in USCDI v3. The table below maps common review questions to the v3 data that could answer them, and to where the answer usually sits in a record today.
| Review question | USCDI v3 data that can answer it | Where the answer often sits today |
|---|---|---|
| Whether the patient meets functional criteria for inpatient rehabilitation or home health | Functional status | Narrative in therapy and nursing notes |
| Whether cognitive impairment changes the level of care needed | Mental and cognitive status | Narrative, sometimes a scored instrument |
| Whether the patient is pregnant, which can change coverage rules and safety checks | Pregnancy status | Problem list entries or narrative |
| The plan and member a request belongs to | Member and payer identifiers | Scanned insurance cards and intake forms |
| Whether a required earlier treatment was tried | Medications, including fill status, and procedures | Medication lists without fill data |
| Whether the lab result a criterion relies on is final | Result status | Lab reports attached as documents |
| The clinical question that prompted the referral | Reason for referral | Referral letters |
Our analysis, using the v3 elements listed by ASTP/ONC. Both right-hand columns are interpretations, not ASTP/ONC statements.
The right-hand column is the problem v3 is meant to solve. Most of the facts a criterion turns on already exist in the record, but as prose. A reviewer reading for functional status is extracting data by hand from documents written for a different purpose. Version 3 gives each of those facts a defined slot. It does not fill the slot. The organizations that benefit first will be the ones whose provider partners record these facts as coded data and whose own intake can read them.
The shutdown moved enforcement to March 1
The federal shutdown that began October 1 lasted 43 days. During it, the ASTP/ONC website went down, and with it the testing tools developers use to show that updated products conform. A developer post from October 31 listed the C-CDA validation tool and the clinical quality measure testing tool as down.
On November 24, 2025, ASTP/ONC announced temporary enforcement discretion. According to the American Hospital Association’s summary, the discretion covers certain compliance dates that took effect January 1, 2026, and runs through March 1, 2026. Developers have until February 28, 2026, to complete updates to their health IT modules. Healthcare IT News reported that ASTP/ONC will not use its direct review authority solely because a developer missed the January 1 date. The affected criteria include transitions of care and the patient and population services APIs, among others.
The grace period changes enforcement, not the standard. The certification requirement took effect on January 1 as written. What changes is whether a developer that has not finished faces consequences in January and February.
For providers, the practical risk sits in federal payment programs that require certified technology. Clinicians in the Merit-based Incentive Payment System and in advanced alternative payment models depend on their EHR vendor’s certification status. Healthcare IT News reported that vendors want CMS to clarify how its certified technology requirements apply during the grace period. Until CMS does, a practice whose vendor finishes in late February has less margin than one whose vendor finished in 2025.
Several demographic elements are no longer enforced
The second complication predates the shutdown. In March 2025, citing Executive Order 14168 and guidance from the Office of Personnel Management, ASTP/ONC issued a notice on certain USCDI v3 data elements. According to a summary by the Drummond Group, a certification body, the agency said it would not penalize certification bodies for certifying modules that cannot categorize data by sexual orientation or gender identity, or that support sex only as female or male using 2 SNOMED CT codes. Modules may also omit other patient demographics paragraphs, including sex parameter for clinical use and name to use. The pause was set for 12 months or until a regulatory revision, whichever comes first, and it does not require developers to remove functions they already built.
ASTP/ONC then published USCDI v3.1, dated June 2025, which it describes as consistent with the executive order. Version 3.1 removes sexual orientation and gender identity from the Patient Demographics/Information class and changes the definition and vocabulary for sex to the 2 SNOMED CT codes. It keeps the rest of v3, including the 2 classes that matter most to payers.
The result is a floor with a hole in it. A certified system may send gender identity while another certified system cannot, and both are compliant. For payers, the effect shows up mainly in analytics and quality programs that use demographic fields to stratify results, and in member communications that rely on a recorded name to use. For clinical coverage decisions, the more consequential element is sex parameter for clinical use, which some laboratory reference ranges and clinical criteria rely on. Plans that receive data from many EHRs should expect these fields to be inconsistently present for some time.
Certification tests that a system can carry a fact, not that anyone records it. The coverage value of USCDI v3 depends on what providers actually send.
The standard has moved past the floor
USCDI v3 is the certification floor, but it is not the current version of the standard. The ASTP/ONC version page shows 3 later versions published since v3, the latest being version 6, dated July 2025. Each adds data elements, and developers can adopt newer versions voluntarily. The gap between the floor and the frontier is now 3 versions.
The direction of federal policy may widen that gap or narrow the program itself. On December 22, 2025, HHS proposed the HTI-5 rule, which it says would remove more than 50% of the certification program’s criteria and refocus the program on standards-based APIs like FHIR. The proposal would also make earlier enforcement discretion notices permanent and revise some information blocking exceptions. HHS estimates savings of $1.53 billion. The proposal will be open for comment for 60 days after it is published in the Federal Register. Until a final rule says otherwise, the v3 requirements apply.
For organizations planning integrations this year, that creates an awkward calculation. Building to v3 is required for certified technology now. Building to later versions positions an organization for future requirements, if those requirements arrive. HTI-5 points toward a program that certifies fewer functions but leans harder on FHIR APIs, which would make the US Core profiles that carry USCDI data more important rather than less.
Why the payer side should track an EHR standard
USCDI is written for certified health IT, which mostly means EHRs. Health plans do not certify their systems under the ASTP/ONC program. They should care anyway, for 3 reasons.
First, the clinical data a plan receives from providers comes out of those EHRs. When a provider attaches documentation to a prior authorization request through a FHIR-based workflow, the structure of that documentation will increasingly follow US Core profiles built on USCDI v3. A plan whose intake systems can read the Health Status Assessments class will be able to find functional status without asking for a fax.
Second, the payer APIs that CMS requires by January 1, 2027, are built around the same definitions. The CMS fact sheet for CMS-0057-F describes a Provider Access API that shares USCDI data and claims data with in-network providers, among other categories, and a Payer-to-Payer API that shares the same categories when a member changes plans. A plan’s ability to return USCDI data depends on its ability to receive and store it in the first place.
Third, the decision clocks that took effect on January 1 make missing data more expensive. Under the new federal prior authorization limits, routine requests must be decided within 7 calendar days, as Rounds described in its analysis of the new deadlines. Every request held for documentation that the provider’s EHR could have sent in structured form spends part of that time waiting.
How the data will reach a plan
The 2027 APIs are where USCDI v3 meets utilization management directly. According to the CMS fact sheet, the Prior Authorization API must list the plan’s covered items and services along with their documentation requirements. It must also return a decision, with a specific reason for any denial. The Provider Access API includes an attribution process and lets patients opt out. The Payer-to-Payer API is limited to data with a date of service within 5 years and works through patient opt-in.
Taken as a set, the APIs make documentation requirements machine-readable on the plan side and clinical data machine-readable on the provider side. What connects them is the data definition. A plan that writes its documentation requirements in terms of USCDI elements, asking for a coded functional status assessment rather than “therapy notes,” can request exactly the fact it needs from a provider’s system. A plan that keeps asking for documents will keep receiving documents.
CMS has said it will use enforcement discretion for the HIPAA X12 278 standard, so plans may build their Prior Authorization API on FHIR alone or on FHIR alongside X12. For clinical data, the choice matters less than it sounds. The X12 278 transaction was designed to carry the request and the response, not the clinical record behind them, and it is the record that USCDI v3 describes.
What to watch in 2026
February 28 and March 1. Most developers will finish within the grace period. The ones that do not will face direct review, and their customers may face questions in CMS programs that require certified technology.
CMS guidance for MIPS and advanced APMs. Clarification on how the grace period applies to certified technology requirements in 2026 would settle the main uncertainty for clinicians.
The HTI-5 comment period. The proposal would change what the certification program covers. Payers and providers that depend on specific criteria, including the C-CDA and patient restriction capabilities, have a narrow window to comment once the proposal is published.
Population of the new data classes. The most useful early measure for payers is the share of clinical documents and FHIR resources received that contain coded functional status or health insurance information. That rate, more than any certification date, will decide whether v3 changes the work of reviewing a case.
About this analysis
Basis. This analysis relies on ASTP/ONC’s HTI-1 materials and its USCDI version documents. Secondary summaries supplied the terms of the 2025 enforcement discretion notices. We also used the HHS announcement of the HTI-5 proposed rule and the CMS fact sheet for CMS-0057-F. The full text of the enforcement discretion notices was not reviewed.
Data notes.
- The list of elements added in v3 comes from ASTP/ONC’s comparison of v3 with v2. Organizations moving directly from v1 will see additional changes introduced in v2.
- The interpretive columns in both tables are this analysis’s reading, not ASTP/ONC guidance.
- HTI-5 is a proposed rule. Its savings estimates and scope are HHS’s own and may change in a final rule.
Sources
- ASTP/ONC, HTI-1 final rule fact sheet on new and revised standards and certification criteria
- ASTP/ONC, HTI-1 final rule overview
- ASTP/ONC, United States Core Data for Interoperability, versions and comparisons
- ASTP/ONC, USCDI version 3.1, June 2025
- American Hospital Association, ASTP/ONC to exercise enforcement discretion for health IT developers on certain certification criteria, November 26, 2025
- Healthcare IT News, ASTP/ONC offers updated HTI-1 compliance date discretion
- Drummond Group, What ONC’s 2025 enforcement discretion means for health IT developers
- Dynamic Health IT, Staying on track with HTI-1 and USCDI v3 during the government shutdown, October 31, 2025
- HHS, HHS proposes HTI-5 rule, December 22, 2025
- CMS, CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) fact sheet
Frequently asked questions
When did USCDI v3 become required for certified health IT?
Under the HTI-1 final rule, USCDI v3 became the only USCDI version for the certification program starting January 1, 2026. After the 2025 shutdown, ASTP/ONC said it would not begin enforcement before March 1, 2026.
What does USCDI v3 add for health plans?
It adds a Health Insurance Information class, which carries coverage details and identifiers for the member and payer. It also adds a Health Status Assessments class, which covers functional status and pregnancy status among other assessments.
Are sexual orientation and gender identity still required in USCDI v3?
ASTP/ONC has not enforced those elements for certification since March 2025, and USCDI v3.1 removed them. Certified modules may support sex as female or male only.