Challenge
Still calling DSTU2 after the sunset
Agnotic approach
We inventory DSTU2 usage now and migrate to R4 routes, practice by practice, well before December 31, 2026.
NextGen Healthcare FHIR capabilities
NextGen Healthcare FHIR Capabilities
NextGen Enterprise and NextGen Office expose different APIs with different limits, and one of them retires its DSTU2 version at the end of 2026. This reference maps what NextGen's own documentation allows, and Agnotic Technologies builds and tests your integration against it.
FHIR R4NextGen EnterpriseNextGen OfficeDSTU2 sunset plan
Trusted by global innovators
What are NextGen Healthcare FHIR capabilities?
NextGen Healthcare FHIR capabilities are the FHIR R4 and DSTU2 APIs, SMART App Launch and Bulk FHIR endpoints that NextGen Enterprise and NextGen Office expose to outside apps, alongside NextGen's proprietary Enterprise APIs. Agnotic Technologies maps what NextGen's public documentation allows to your use case, then builds and tests the integration for you.
The first question is which NextGen product your customers run. NextGen Enterprise serves larger ambulatory groups and NextGen Office serves smaller practices, and their APIs, documentation and limits are published separately.
This page is the developer reference. Our NextGen Healthcare integration page covers how an engagement runs across HL7 v2, FHIR and the NextGen API.
Capability table
Which NextGen APIs can your app use?
Built only from NextGen's public API pages. What a given practice has installed and configured still has to be confirmed per practice.
| API | Product | Standard and access | Who it serves | Notes from NextGen's docs |
|---|---|---|---|---|
| Patient Access API | NextGen Enterprise 5.9.0+ | FHIR R4 and DSTU2, read only | Patient-facing apps | Public route docs; DSTU2 sunsets December 31, 2026; a Practice Search page shows which practices have it configured |
| FHIR APIs for user-facing apps | NextGen Enterprise | FHIR | Apps used by NextGen Enterprise staff | Full documentation provided after developer onboarding |
| Enterprise APIs | NextGen Enterprise 5.9.0+ | Proprietary JSON REST, 800+ routes, read and write | Provider organization apps | Documentation after onboarding; clients grant access to adopted apps in the NextGen API Client Portal |
| Office Patient Access API | NextGen Office 5.0+ | FHIR R4 with C-CDA, read only | Patient apps | No charge for USCDI v1 reads |
| Office SMART App Launch API | NextGen Office 5.0+ | FHIR R4, read only, one patient | Provider-selected apps | Onboarding and monthly fees per vendor per practice; per-application request limits |
| Office Bulk FHIR API | NextGen Office 5.0+ | FHIR Bulk Data Access, read only, patient groups | Population data for providers | One bulk request per patient per week; onboarding and monthly fees |
NextGen publishes its own API fees on its regulatory information pages. We do not set or quote them; we scope our build separately.
Deadline
What changes for NextGen FHIR apps on December 31, 2026?
NextGen Healthcare will sunset the FHIR DSTU2 API for NextGen Enterprise on December 31, 2026. Any app still calling DSTU2 routes needs to move to the FHIR R4 API before then.
R4 is more than a version swap. NextGen's R4 routes cover USCDI v3 data elements, but elements added after USCDI v1 need the practice to run NextGen Enterprise 8.3.1 or later, so the same app can see different data at different practices.
Failure points
Where do NextGen FHIR integrations break?
Each of these follows from NextGen's published documentation, and each one fails quietly unless the design plans for it.
Challenge
Assuming FHIR can write data back
Agnotic approach
The FHIR APIs NextGen documents are read only. Write-back goes through Enterprise APIs where the use case and the program allow it.
Challenge
Expecting USCDI v3 data everywhere
Agnotic approach
The app handles both USCDI v1 and v3 responses, because practices below NextGen Enterprise 8.3.1 get v1 routes.
Challenge
Hitting NextGen Office rate limits
Agnotic approach
Requests are queued and paced under the published per-IP and per-application limits, with backoff when throttled.
Challenge
Running bulk exports like a sync job
Agnotic approach
NextGen Office allows one bulk request per patient per week, so ongoing changes come from targeted reads instead.
Challenge
An app the practice has not authorized
Agnotic approach
Rollout includes the practice granting access in the NextGen API Client Portal, checked before go-live at each site.
Pre-build checklist
What should you confirm before you build on NextGen?
We work through this list before writing integration code, so the plan rests on facts rather than assumptions.
- Which product each target practice runs: NextGen Enterprise or NextGen Office
- The NextGen Enterprise version at each practice, against the 8.3.1 threshold for USCDI v3 data
- Whether your app is patient-facing, provider-facing or system-to-system, which decides the API family
- Which developer program fits: Patient Access, Open Access Developer or API Distributor
- Whether the use case needs writes, which the documented FHIR APIs do not support
- The rate limits and bulk export limits that apply, and the request pattern that stays under them
- Whether target practices have Patient Access configured, using NextGen's Practice Search page
- That all sandbox and test work uses synthetic patients only
Scope drivers
What drives the cost of a NextGen FHIR integration?
We do not quote a price before scoping. These factors move the effort most.
Enterprise, Office or both
Each product has its own APIs, auth endpoints and limits, so supporting both roughly means two integrations.
FHIR only or Enterprise APIs too
Read-only FHIR is the smaller build. Enterprise API write flows add mapping, validation and more testing.
DSTU2 migration
Apps already on DSTU2 need a migration plan and parallel testing before the sunset date.
Number of practices
Each practice adds authorization, version checks and support, and may return different USCDI versions.
Population data
Bulk FHIR adds long-running jobs and file handling, within NextGen Office's weekly per-patient limit.
Startup or established product
Startups often need the data model built with the integration. Established products mostly need mapping and hardening.
Who builds on NextGen
Who builds on NextGen's APIs
Most demand comes from products that serve ambulatory and specialty practices.
Patient app developers
Apps that let patients of NextGen practices read their own records through Patient Access APIs.
Specialty workflow products
Provider-facing apps for NextGen Enterprise practices built on Enterprise and FHIR APIs.
Small-practice tools
SMART App Launch apps selected by NextGen Office practices.
Analytics and quality platforms
Population data through the NextGen Office Bulk FHIR API, within its limits.
Health tech startups
Products that need NextGen practice data from their first pilots.
Practice IT teams
Internal apps built under the Open Access Developer Program.
How we work
How do we take a NextGen integration live?
Four steps, with a fixed first release agreed before any code is written.
1.
Pick the API family and program
We match your use case to Patient Access, FHIR or Enterprise APIs and the developer program that covers it.
Right surface
2.
Onboard and test
We complete NextGen's onboarding, read the full documentation it opens up, and test with synthetic patients.
Synthetic data
3.
Pilot one practice
The practice authorizes the app, we confirm its version and data, and run the first release there.
Pilot practice
4.
Roll out and monitor
Practices are added one by one, with monitoring of auth errors, throttling and data quality.
Monitored
Compliance as engineering
How do we keep PHI safe on a NextGen integration?
HIPAA applies to your product as well as the practice. These are the safeguards we build in.
Business associate agreements
Agnotic signs a BAA before any PHI is shared, and development uses synthetic patients only.
Least privilege
Each app requests only the data its use case needs, per practice and per user type.
Tokens and keys
OAuth tokens and client secrets live in a secrets manager, rotated and never logged.
Audit logging
Every API call is logged with user, patient, practice and time.
Compliance-First Healthcare App Development Services Backed by Global Standards
01
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
02
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
03
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
04
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
05
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
06
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
07
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
08
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
09
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Standards in scope
Standards on NextGen's API surface
FHIR R4DSTU2SMARTBulk DataUSCDIC-CDA
Facts and sources
Which facts from NextGen's documentation shape this page?
Short facts we design around, each linked to NextGen Healthcare's own API pages.
For NextGen Enterprise 5.9.0 and later, NextGen Healthcare documents read-only Patient Access APIs in FHIR DSTU2 and R4, and Enterprise APIs: more than 800 JSON-based RESTful routes for reading and writing EHR and practice management data in a proprietary NextGen format.
Source: NextGen Healthcare, Public API DocumentationNextGen Healthcare will sunset the FHIR DSTU2 API for NextGen Enterprise on December 31, 2026, and developers using it must migrate to the FHIR R4 API before that date.
Source: NextGen Healthcare, Patient Access API documentationNextGen's FHIR R4 routes include USCDI v3 data elements, but elements that were not part of USCDI v1 need the patient's practice to run NextGen Enterprise 8.3.1 or later; on earlier versions the API defaults to USCDI v1 routes.
Source: NextGen Healthcare, Patient Access API documentationFor NextGen Office, the Patient Access, SMART App Launch and Bulk FHIR APIs support only read (GET) operations for USCDI v1 data, allow up to 20 requests per minute from one IP address, and permit one bulk data request per patient per week.
Source: NextGen Healthcare, NextGen Office API Section 170.404 Regulatory InformationNextGen runs an Open Access Developer Program for clients building apps for internal use and an API Distributor Program, which includes API sandboxes, for apps released to the NextGen community; the Distributor Program may carry fees based on the scope of data needs.
Source: NextGen Healthcare, API Developer Program
Frequently Asked Questions
Yes. NextGen documents FHIR R4 APIs for both NextGen Enterprise and NextGen Office. NextGen Enterprise also has a DSTU2 API, which NextGen will sunset on December 31, 2026.
Not through the FHIR APIs NextGen documents publicly; they are read only. NextGen Enterprise APIs support read and write through a proprietary JSON format, and we use them where your use case and developer program allow.
NextGen says developers must migrate from the NextGen Enterprise DSTU2 API to R4 before December 31, 2026. We map each DSTU2 call to its R4 route, test with synthetic patients and switch practices over one at a time.
Patient-facing apps use the Patient Access path. Clients building internal apps use the Open Access Developer Program, and vendors releasing apps to NextGen clients use the API Distributor Program, which includes API sandboxes.
It depends on scope; we agree a fixed first release on the scoping call. A read-only patient app on NextGen Office is a smaller release than an Enterprise API integration with write-back across many practices.
Yes. Agnotic signs a business associate agreement before any PHI is shared, and sandbox and test work uses synthetic patients only.
Engineers use AI tools for drafts and test generation, then review every change. AI tools never see real patient data, and every mapping is tested against synthetic data before it reaches a practice.