NextGen API and EHR Integration Guide (2026): FHIR, HL7 and Fees

Part of our complete guide to HL7 fundamentals.

NextGen EHR integration runs on two paths. The NextGen API path gives you FHIR R4 and NextGen's own Enterprise APIs through the NextGen developer portal, for reading and writing data on request. The HL7 v2 path carries live events such as admissions, appointments and results, usually through the Mirth Connect interface engine. Many integrations combine the two.

This guide covers which NextGen product you are connecting to, the NextGen API programs and their fees, the FHIR and HL7 options, NextGen Share and TEFCA, and a realistic build plan. Facts about NextGen's programs and fees come from NextGen's own pages, checked in October 2026. If you need a team to build it, see our EHR integration services.

First: which NextGen are you integrating with?

"NextGen" is a brand, not one system, so confirm the product before you write any code. The APIs, onboarding and fees differ between the two main EHRs.

• NextGen Enterprise is the on-premises or hosted EHR and practice management platform for larger ambulatory practices, multi-specialty groups and health systems. Most HL7 interface work and the Enterprise API programs live here. NextGen's API programs require NextGen Enterprise 5.9.0 or later.
• NextGen Office is the cloud EHR and practice management system for smaller and independent practices. It has its own FHIR R4 APIs and its own published fees.

An app built against NextGen Office will not automatically work against NextGen Enterprise. Ask the customer which product and which version they run on day one; "we use NextGen" is not a complete answer.

For context, NextGen Healthcare has been privately owned by Thoma Bravo since November 2023, when it completed a $1.8 billion take-private (Thoma Bravo, November 2023).

The NextGen API programs for Enterprise

NextGen runs three API programs for NextGen Enterprise, and the one you join decides your fees and approval path (NextGen, checked October 2026).

Development happens on the NextGen developer portal, which provides sandbox testing for both the FHIR R4 APIs and the Enterprise APIs. Developer portal registration is required to create production credentials, and sandbox testing resources are available through the portal. Full Enterprise API documentation is released after you submit NextGen's onboarding form.

For NextGen Enterprise user-facing apps serving provider organizations, NextGen describes six steps to production. Patient Access apps follow separate deployment requirements.

1. Submit the onboarding form.
2. Sign the API Terms of Service.
3. Set up your app in the developer portal.
4. Build and test in the sandbox.
5. Run a beta at one client site.
6. Optionally declare General Availability, after NextGen confirms the integration works successfully in production.

Authentication uses OAuth2. Enterprise apps can use a Global Service Account (GSA) or the External Application Launcher, and user-level authentication needs NextGen Enterprise 5.9.2 or later. The GSA supports most Enterprise API routes but excludes some that need provider-level permissions or auditing, so check NextGen's GSA route status list before you choose.

NextGen Enterprise API: JSON routes and read/write access

Alongside FHIR, NextGen Enterprise offers its own Enterprise APIs: REST routes in NextGen's proprietary JSON format that cover clinical and practice management workflows, including write access that the patient-access FHIR APIs do not offer (NextGen API overview). Use them when you need to create or update data, such as appointments or charges, rather than only read USCDI data. Confirm the routes, permissions and supported NextGen version you need in the developer documentation, which NextGen releases after onboarding.

NextGen Office API fees

NextGen Office publishes per-vendor, per-practice fees for its FHIR APIs (NextGen, checked October 2026).

NextGen Office supports USCDI v1 read routes and C-CDA documents. Because the fees apply per practice, model them across your expected customer count before you price your own product.

The NextGen FHIR API

NextGen's FHIR R4 APIs are the clean path for reading standard clinical data. They are certified health IT APIs built to meet the 21st Century Cures Act patient-access and information-blocking rules, and they expose US Core Data for Interoperability (USCDI) data, such as demographics, problems, medications, allergies, results and vitals, as FHIR resources over REST.

• Enterprise R4 base URL: https://fhir.nextgen.com/nge/prod/fhir-api-r4/fhir/r4/. NextGen also publishes a file of practice-specific base URLs (NextGen practice search).
• Older DSTU2 endpoint: still listed for Enterprise. Build new work on R4.
• NextGen Office: FHIR R4 with SMART App Launch and Bulk FHIR as the paid APIs above.

Before you plan around SMART on FHIR or Bulk FHIR on NextGen Enterprise, confirm support for your target version in the R4 documentation; NextGen's Enterprise program page does not list them.

FHIR is best for on-demand reads and apps launched inside the clinical workflow. It is weaker for high-volume, real-time events, which is where HL7 v2 still does the work. For the security model on the FHIR side, see our healthcare API security guide.

NextGen HL7 interfaces: supported feeds and setup

HL7 v2 supports event-driven feeds into and out of NextGen where the practice has them configured. Message families commonly used in NextGen projects:

• ADT (admit, discharge, transfer): patient registration and demographic updates.
• SIU (scheduling): bookings, reschedules and cancellations.
• ORM and ORU (orders and results): lab and diagnostic orders out, results back into the chart.
• DFT (financial transactions): charges sent to billing.
• MDM (documents): clinical documents and notes.

Configured HL7 feeds send supported events as messages, which suits billing systems, patient engagement tools and analytics pipelines that need to stay current. A FHIR read is a pull. Agree delivery timing, acknowledgment modes, retries and application-error handling with the receiving system, and remember that an acknowledgment does not always prove the data reached the chart. For each feed, confirm direction, message types and trigger events, transport, required fields, licensing and the team responsible for setting it up. Our HL7 integration guide explains each message type segment by segment.

NextGen does not publish a price list for HL7 interfaces. Interface costs depend on who builds them (NextGen's interface team, your own team or a partner) and on your contract, so ask for a written quote per interface.

Mirth Connect for NextGen HL7 interfaces

Mirth Connect, the integration engine NextGen owns, is widely used to route and transform NextGen HL7 v2 messages. NextGen also documents its own interface tools, so ask the practice which one runs its feeds. Quality Systems, the company that became NextGen Healthcare, acquired Mirth, and the engine was sold for a time as NextGen Connect. If your team knows Mirth, it already knows how to build NextGen HL7 interfaces: the same channels, transformers, MLLP listeners and JavaScript mappings apply.

One licensing change matters. From version 4.6, announced on 19 March 2025, Mirth Connect is commercial-only, and 4.5.2 is the last open-source release (NextGen, March 2025). Confirm which version a site runs before you scope licensing. Open-source forks such as Open Integration Engine and BridgeLink are options for teams staying on the open-source line.

For channel-by-channel NextGen workflows, such as scheduling, charges and practice management feeds, see our Mirth Connect and NextGen practice management guide. For build help, see our Mirth Connect integration services.

NextGen Share, Carequality and TEFCA

NextGen Share is NextGen's cloud platform for exchanging records with outside organizations. NextGen describes it as supported by Carequality, which connects users to a national exchange network (NextGen). It is how NextGen practices query and send records to hospitals and other providers outside their own system.

For TEFCA, the federal framework for nationwide exchange, NextGen announced a partnership in September 2025 with Kno2, a designated Qualified Health Information Network (QHIN), intended to let NextGen clients take part (Business Wire, September 2025). Confirm availability, enrollment and activation for the target practice.

For a third-party app, NextGen Share is not a substitute for the NextGen API. It moves records between care organizations; your app still reaches a practice's data through the API programs or HL7 interfaces above. See our TEFCA and information blocking guide for how national exchange affects your integration.

A realistic build plan for a NextGen integration

A NextGen integration usually runs as two parallel tracks. Contracting, engineering, practice readiness and beta testing can each affect the timeline, so start onboarding early and confirm dependencies with NextGen and the practice.

• API track: pick the right API program, submit the onboarding form early, build against the sandbox, validate USCDI reads, and line up a beta site.
• HL7 track: agree the ADT, SIU, ORU and DFT specs with the practice's interface team, build and test them as Mirth channels, and agree acknowledgments and error handling.

Three things keep approval moving. Document your security posture before you ask: token storage, access scopes and how you protect patient data at rest and in transit. Decide early whether you need a patient-facing app or a provider or system-level integration, because they use different authorization flows. And involve the practice early, since a beta site and the practice's sign-off are part of NextGen's route to production.

Integrating with several EHRs? Our multi-EHR integration guide shows how the same pattern repeats across Epic, Oracle Health and athenahealth, and our eClinicalWorks integration guide covers another common ambulatory EHR.

Where Nirmitee fits

Nirmitee is a healthcare integration services company. We build NextGen FHIR integrations and HL7 v2 interfaces on Mirth Connect, and we help software vendors plan the API program, sandbox work and beta. We are not part of NextGen and do not resell NextGen products.

Scoping a NextGen integration? Tell us your use case, NextGen product and version, and we will send back which API program and interfaces fit and the likely approval steps. Request a NextGen integration review.

Key takeaways

• Confirm the product and version first: NextGen Enterprise and NextGen Office have different APIs, onboarding and fees.
• NextGen Enterprise has three API programs. Patient Access and Open Access carry no fees; the API Distributor Program has variable fees.
• NextGen Office publishes fees: $2,400 onboarding plus $50 a month for SMART App Launch, and $2,400 plus $100 a month for Bulk FHIR, per practice.
• HL7 v2 (ADT, SIU, ORU, DFT) supports event-driven feeds where configured, often through Mirth Connect, which is commercial-only from 4.6.
• NextGen Share handles record exchange between organizations; NextGen's 2025 Kno2 partnership is intended to enable TEFCA participation.
• Start onboarding early: contracting, the beta site and practice sign-off sit alongside the build on the critical path.