BLOGS 
NEWSROOM 
CASE STUDIES 
WEBINARS 
PODCASTS 
ASSET HUB 
EVENT CALENDAR 
TL;DR
USCDI v3 became mandatory January 1, 2026. The enforcement grace period ended March 1. If you’re building a custom EHR, you need 16 data classes, 94 data elements, FHIR US Core 6.1.0, and SMART v2 baked into your architecture – not bolted on. This guide covers every data class, the 9 certification criteria that changed, and the two paths custom EHR builders have: get ONC certified yourself or build on a certified platform. We’ve done both. Here’s what actually matters.
94 data elements. That’s the number your custom EHR needs to support as of January 1, 2026 – and the March enforcement grace period is already behind us. ONC isn’t sending reminders anymore. They’re processing the 1,600 complaints sitting in the HHS OIG portal.
If you’re a CTO or engineering lead building a clinical platform from scratch, you’ve probably scanned a few compliance articles and walked away more confused than when you started. Most USCDI content is written for compliance officers at health systems running Epic or Cerner. Not for people building the EHR itself.
This is the piece I wish existed when we started architecting custom clinical platforms on FHIR. It’s the builder’s guide – specific, technical, and based on what we’ve shipped, not what we’ve read.
I. What is USCDI and Why Does it Exist?
USCDI – United States Core Data for Interoperability – is ONC’s answer to a problem every custom EHR builder has hit: what data does a clinical system absolutely need to exchange?
Before USCDI, the answer was “whatever your EHR vendor decided.” That’s how we ended up with 47 different ways to represent an allergy across certified systems. USCDI standardizes the floor. Not the ceiling. The floor.
The standard evolved through three mandated versions:
- USCDI v1 (~52 data elements): The baseline. Patient demographics, allergies, medications, conditions, labs, vital signs, procedures. Required under the 2015 Edition Cures Update.
- USCDI v2 (~73 data elements): Added clinical notes, health concerns, assessment and plan of treatment.
- USCDI v3 (~94 data elements): Added health insurance information, health status assessments (disability, cognitive, functional, pregnancy status), expanded SDOH, enhanced demographics. Nearly doubles v1’s requirements.
Key regulatory mechanism: The HTI-1 Final Rule (finalized January 2024) replaced USCDI v1 with v3 as the required standard for all certified health IT. Effective date: January 1, 2026. No further extensions.
II. What’s in USCDI v3: All 16 Data Classes
Most compliance articles mention “expanded demographics” and “SDOH” and leave it there. That’s not enough if you’re building the data model. Here’s every data class in USCDI v3, with the new additions that v3 introduced.
Bottom line: Two new data classes. 24 new data elements across six existing classes. If your data model was built to v1 spec, you’re missing roughly half of what’s now required.
III. USCDI v3 vs v1 and v2: What Actually Changed
| Dimension | USCDI v1 | USCDI v2 | USCDI v3 |
|---|---|---|---|
| Data classes | 14 | 14 | 16 |
| Data elements | ~52 | ~73 | ~94 |
| SDOH coverage | None | Limited | Structured SDOH data elements |
| Insurance data | None | None | Full coverage class |
| Health assessments | None | None | Disability, cognitive, functional, pregnancy |
| Demographics | Basic | Added gender identity | Sex parameter for clinical use, tribal affiliation, related persons |
| Required FHIR version | US Core 3.1.1 | US Core 5.0.1 | US Core 6.1.0 |
| C-CDA version | R2.1 | R3.1 | Companion Guide R4.1 |
The jump from v1 to v3 isn’t incremental. It’s structural. v3 assumes your system can model social determinants, insurance relationships, and health status assessments as first-class data objects – not free text buried in clinical notes.
IV. Who Needs to Comply – and Who Doesn’t
This is the question every custom EHR builder asks first, and the answer is more nuanced than most articles admit.
The short version: ONC certification is technically voluntary for software developers. No one is forcing you to certify. But your customers’ reimbursement depends on it.
The longer version:
- CMS requires providers to use ONC-certified EHR technology for Medicare incentive programs, Shared Savings, and value-based payment arrangements
- 96% of non-federal acute care hospitals already use certified EHR technology (ONC, 2025)
- 78% of office-based physicians have certified EHR technology
- If your custom EHR isn’t ONC-certified, your provider clients can’t use it for those programs
- That limits your addressable market to the shrinking minority that doesn’t participate in federal programs
A. The 9 Certification Criteria Updated Under HTI-1
| Criteria | What It Covers | What Changed for v3 |
|---|---|---|
| (b)(1) Transitions of Care | C-CDA document exchange | Must include all v3 data classes in C-CDA |
| (b)(2) Clinical Info Reconciliation | Merge data from external sources | Must reconcile v3 data elements |
| (b)(10) Electronic Health Info Export | Bulk patient data export | Must export all v3 data classes |
| (b)(11) Decision Support Interventions | CDS triggers and actions | New criterion under HTI-1 |
| (e)(1) View, Download, Transmit | Patient access to records | Must expose all v3 data to patients |
| (f)(5) Immunization Registries | Immunization data sharing | Updated to v3 immunization elements |
| (g)(6) Consolidated CDA Creation | Generate C-CDA documents | Must generate v3-compliant C-CDAs |
| (g)(9) Application Access – All Data | API access to all patient data | Must expose ALL v3 data fields per encounter. No missing fields. |
| (g)(10) Standardized API | FHIR-based API access | Must use FHIR US Core 6.1.0, SMART v2 |
(g)(9) is the one that catches custom builders. It requires that every USCDI v3 data element be accessible via API for each patient encounter. If your data model doesn’t capture pregnancy status or disability status, your (g)(9) compliance fails – even if every other criterion passes.
Build Custom EHR
V. What’s the Required Technical Stack?
USCDI v3 compliance isn’t just about which data you store. It’s about how you expose it.
Required specifications under HTI-1:
- FHIR R4 – the base standard
- HL7 FHIR US Core Implementation Guide STU 6.1.0 – the US-specific profile layer
- C-CDA Companion Guide R4.1 – for document exchange
- SMART App Launch v2.0 – replaces v1 with new scopes and granular permissions
If your custom EHR was built against US Core 3.1.1 or 5.0.1, you need to upgrade. The jump to 6.1.0 isn’t trivial – it changes how FHIR resources are profiled for US healthcare use, including new Must Support elements that map directly to USCDI v3 data classes. For the full FHIR standards roadmap and how TEFCA fits in, we covered that in our TEFCA and FHIR interoperability guide.
What we’ve learned from building FHIR-native platforms: FHIR is the bar, not the solution. Having FHIR endpoints doesn’t mean your data is clean. You still need the pipeline work – terminology mapping, validation, and what the interoperability community calls “uplifting” – to make your FHIR data actually usable downstream.
The piece nobody talks about in USCDI articles: Patient matching. You can have all 94 data elements perfectly structured, and none of it matters if your system can’t reliably determine that this John Doe in encounter A is the same John Doe in encounter B. USCDI doesn’t solve patient matching. It assumes you already have.
VI. How Do Custom EHR Builders Get Compliant?
If you’re building a clinical platform today, you have two realistic paths to USCDI v3 compliance.
A. Path A: Get ONC Certified Yourself
ONC certification means submitting your health IT module to an ONC-Authorized Testing Laboratory (ONC-ATL) and then to an ONC-Authorized Certification Body (ONC-ACB). The 2015 Edition Cures Update has approximately 60 certification criteria across 8 categories.
- Realistic timeline: 12-18 months
- Realistic cost: $200K-$500K+ including engineering time, testing fees, and ongoing Conditions of Maintenance
- Best for: Standalone EHR products sold to multiple provider organizations – the certification becomes a competitive asset
B. Path B: Build on an ONC-Certified Platform
This is the path we take for most custom builds. Platforms like Medplum come pre-certified. (We compared Medplum, Healthie, and OpenEMR in our headless EHR comparison – worth reading if you’re evaluating platforms.) For the full scope of what we do with Medplum, see our Medplum integration services.
Medplum’s certification status (verified):
- CHPL listing: #11745
- Product: Medplum, Version 5
- Certified: 12/31/2025
- Criteria: 19, including (g)(9), (g)(10), (b)(10), (b)(11)
- FHIR: US Core STU 5.0.1 via SVAP
- Base standard: 2015 Edition Cures Base EHR compliant
When you build on Medplum, the platform handles the certification infrastructure – FHIR API compliance, audit logging, authentication, and bulk data export. Your custom development focuses on the clinical workflow layer: specialty-specific UIs, clinical logic, integrations, and the user experience.
Real example: We built a FHIR-native national health records system for an entire country’s public healthcare infrastructure – $131K for a country-scale clinical platform covering patient management, clinical documentation, lab integration, pharmacy workflows, and ONC-aligned data models. The reason the cost was $131K instead of $500K: we didn’t build FHIR infrastructure from scratch. We built the clinical layer on top of platform infrastructure that already handled the compliance floor.
That’s the architectural decision: do you want to build the compliance floor yourself, or build your clinical value on top of someone else’s floor? If you want the full technical walkthrough of building an EHR from scratch, our EHR development playbook covers the 7-phase process.
VII. What Happens If You Don’t Comply?
The enforcement isn’t theoretical anymore.
- $1 million per violation for health IT developers found engaging in information blocking or failing to maintain certification
- CMS disincentive payments for providers using non-certified technology
- Public disclosure of violations
- Loss of eligibility for Medicare incentive programs, Shared Savings, and value-based payment models
- 1,600+ complaints submitted to the HHS OIG portal as of February 2026
For custom EHR builders, the risk is indirect but real. If your platform isn’t certified (or built on a certified platform), your provider customers face reimbursement consequences. That’s a sales objection you can’t talk your way around.
Caveat: the $1M per violation figure from OIG refers specifically to information blocking penalties. USCDI non-compliance and information blocking are related but distinct enforcement paths. Don’t conflate them in your compliance planning – but do take both seriously.
VIII. What’s Coming After v3?
USCDI v3 isn’t the finish line. It’s the start of an acceleration.
Draft USCDI v7 proposes 30 new data elements. The public comment period closed yesterday. ONC is publishing new versions at roughly 6-month intervals.
I’ve been going through the 2026 Interoperability Standards Advisory that ONC published recently. It’s their full catalog of recognized interoperability standards – dense, but it signals where certification requirements are heading. If you’re making platform decisions this quarter, bookmark it.
HTI-4 enforcement begins January 2027. We don’t have the full criteria list yet, but Medplum is already pursuing HTI-4 certification.
The architectural implication: Build your data model to expand, not just to comply with today’s version. If adding a new data class requires a schema migration and a deployment cycle, you’ll be chasing compliance every 6 months. If your data model uses extensible FHIR resources with proper profiling, adding v4-v7 elements is configuration, not rebuilding.
IX. How Do You Audit Your Architecture Against USCDI v3?
Use this to audit your current architecture or plan a new build.
Data Model:
- [ ] All 16 data classes represented in your data model
- [ ] All 94 data elements mapped to FHIR R4 resources
- [ ] 2 new data classes (Health Insurance Information, Health Status Assessments) have dedicated FHIR resources
- [ ] Patient demographics include sex parameter for clinical use, tribal affiliation, related persons
- [ ] SDOH data elements are structured (not free text in clinical notes)
APIs:
- [ ] FHIR R4 endpoints live for all USCDI v3 data classes
- [ ] US Core 6.1.0 profiles applied (not older versions)
- [ ] (g)(9) compliance: all v3 data fields accessible per patient encounter via API
- [ ] (g)(10) compliance: SMART App Launch v2.0 implemented
- [ ] Bulk data export covers all v3 data classes (for (b)(10))
Documents:
- [ ] C-CDA generation includes all v3 data classes (for (g)(6))
- [ ] C-CDA Companion Guide R4.1 format used
- [ ] Transitions of Care documents include v3 elements (for (b)(1))
Certification Path:
- [ ] Decision made: self-certify (Path A) or build on certified platform (Path B)
- [ ] If Path A: ONC-ATL selected, testing timeline planned
- [ ] If Path B: Platform ONC certification verified
Patient Matching:
- [ ] Patient matching strategy in place (USCDI assumes this, doesn’t solve it)
- [ ] De-duplication logic tested across encounter types
Future-Proofing:
- [ ] Data model is extensible for v4-v7 elements without schema migration
- [ ] Monitoring ONC Standards Bulletins for upcoming versions
Where Does This Leave You?
USCDI v3 isn’t a checkbox exercise. It’s an architecture decision that shapes how your clinical platform handles data for the next 3-5 years.
If you’re starting a build now, you have an advantage that legacy EHR vendors don’t: you can design your data model around 94 elements from day one instead of retrofitting a system that was built for 52. That’s a real competitive edge – your platform is v3-native while your competitors are patching.
If you’ve already shipped and need to close gaps, the checklist above gives you a clear audit path. Start with (g)(9) – it’s the criterion that exposes the most missing data elements – and work backward from there.
Three things worth remembering:
- The standard is accelerating. v7 is already in draft. Build to expand, not to comply with today’s version.
- Platform choice matters more than engineering effort. Building on an ONC-certified platform saves you 12-18 months and $200K+ of certification work.
- Patient matching is the foundation nobody talks about. Get that right before worrying about data class coverage.
We’ve built FHIR-native clinical platforms from $131K country-scale systems to specialty workflow modules integrated with Epic. The compliance floor is the same for all of them. The clinical value on top is what makes each one worth building.
Need to get USCDI v3 right from the data model up? Let’s talk through your compliance requirements.
USCDI v3 is the third version of the United States Core Data for Interoperability standard, published by ONC (now ASTP). It defines 16 data classes and approximately 94 data elements that certified health IT systems must support for electronic data exchange. v3 added two new data classes – Health Insurance Information and Health Status Assessments – and 24 new data elements across six existing classes, including structured SDOH data and expanded demographics.
Yes. USCDI v3 became mandatory on January 1, 2026, under the HTI-1 Final Rule. ONC issued enforcement discretion extending the deadline to March 1, 2026, due to a federal appropriations lapse that disrupted testing infrastructure. That grace period has expired. All certified health IT modules must now support USCDI v3.
ONC certification is technically voluntary for software developers – no law requires you to certify. However, healthcare providers need certified EHR technology to participate in Medicare incentive programs, the Shared Savings Program, and CMS value-based payment arrangements. If your custom EHR isn’t certified, your provider customers may face reimbursement penalties. The alternative: build on an already-certified platform (like Medplum) so the platform carries the certification and your custom layer focuses on clinical workflows.
USCDI v1 defined ~52 data elements across 14 data classes (the baseline: demographics, allergies, medications, conditions, labs, vitals). v2 expanded to ~73 elements, adding clinical notes and health concerns. v3 expanded to ~94 elements across 16 data classes, adding Health Insurance Information and Health Status Assessments as entirely new data classes, plus structured SDOH data, expanded demographics (sex parameter for clinical use, tribal affiliation), and disability/cognitive/functional/pregnancy status elements. The required FHIR version also changed: v1 used US Core 3.1.1, while v3 requires US Core 6.1.0.
