Written and maintained by CASRAI Editorial Board
Last updated
NextGen Healthcare is an ambulatory healthcare technology vendor that develops two distinct ONC-certified Electronic Health Record (EHR) and Practice Management (PM) platforms—NextGen Enterprise and NextGen Office—alongside the widely deployed NextGen Connect Integration Engine (formerly Mirth Connect) for health information exchange and clinical data interoperability.
What Is NextGen Healthcare and What Does Its Portfolio Cover?
Headquartered in the United States, NextGen Healthcare serves ambulatory medical groups, specialty practices, tribal health organizations, and Federally Qualified Health Centers (FQHCs). In health informatics and clinical trial site operations, understanding a clinic’s “NextGen EHR” environment requires identifying which of the company’s two separate software architectures the site runs, as well as its middleware layer:
- NextGen Enterprise (EHR and Practice Management): Built for mid-to-large multi-specialty physician groups, academic faculty practices, behavioral health networks, and FQHCs. NextGen Enterprise combines customizable clinical documentation templates (the NextGen Knowledge Base Model, or KBM), dental and behavioral health charting, revenue cycle management, and Uniform Data System (UDS) federal grant reporting on top of a relational Microsoft SQL Server database.
- NextGen Office (formerly MediTouch by HealthFusion): Acquired via HealthFusion, NextGen Office is a multi-tenant, browser-native SaaS EHR and practice management platform built for smaller independent physician practices (typically 1 to 10 providers) with touch-first clinical charting and an integrated clearinghouse.
- NextGen Connect Integration Engine (formerly Mirth Connect): Following the acquisition of Mirth Corporation, NextGen Healthcare stewarded Mirth Connect—an open-architecture healthcare integration engine used across thousands of hospitals, reference laboratories, and Health Information Exchanges (HIEs) to transform and route HL7 v2, HL7 v3, C-CDA, X12, DICOM, and HL7 FHIR messages.
What Is the Difference Between NextGen Enterprise and NextGen Office?
Because both products carry the NextGen brand, health IT architects and clinical research sponsors integrating third-party applications must distinguish their underlying infrastructure, database access, and API endpoints:
| Architectural Dimension | NextGen Enterprise | NextGen Office (formerly MediTouch) |
|---|---|---|
| Target Clinical Organization | Multi-specialty medical groups, FQHCs, community health centers, and multi-site enterprise practices | Small-to-midsize independent ambulatory practices and solo/group specialty clinics |
| Deployment & Hosting Model | Managed cloud hosting (AWS / NextGen Cloud) or customer-managed on-premises Windows/Citrix infrastructure | 100% browser-native, multi-tenant cloud SaaS (no local server or Citrix client required) |
| Underlying Database Access | Dedicated Microsoft SQL Server relational schema; supports direct SQL reporting, SSRS, and data warehouse ETL | Abstracted multi-tenant cloud persistence; no direct customer SQL server access (reporting via built-in analytics and APIs) |
| Clinical Charting Paradigm | Structured Knowledge Base Model (KBM) specialty templates, custom template editor, and ambient/mobile workflows | Touch-oriented browser charting flowsheets, cross-specialty macros, and integrated patient portal |
| FHIR R4 & API Surface | ONC-certified NextGen Enterprise FHIR R4 API + NextGen Enterprise REST API (clinical & PM read/write) | ONC-certified NextGen Office FHIR R4 API (separate base URLs, sandbox, and OAuth 2.0 registration) |
How Do Developers Integrate With NextGen Healthcare APIs and FHIR Endpoints?
Under the ONC 21st Century Cures Act Final Rule (45 CFR § 170.315(g)(10) and § 170.215), both NextGen Enterprise and NextGen Office expose certified standardized APIs. Based on official NextGen Healthcare interoperability documentation, external integration workflows use three primary technical pathways:
- HL7 FHIR Release 4 (4.0.1) & US Core Profiles: NextGen exposes read-only patient and clinical resources mapped to the US Core HL7 FHIR Implementation Guide for USCDI (United States Core Data for Interoperability) data classes, including
Patient,AllergyIntolerance,CarePlan,CareTeam,Condition,Device,DiagnosticReport,DocumentReference,Encounter,Goal,Immunization,Location,MedicationRequest,Observation,Organization,Practitioner,Procedure, andProvenance. - SMART on FHIR App Launch and OAuth 2.0 Authorization: Third-party clinical decision support tools, patient registries, and research apps authenticate via the SMART App Launch Framework using OAuth 2.0 and OpenID Connect (OIDC). NextGen supports standalone patient launch (allowing patients to authorize apps using their NextGen PxP Portal or NextGen Office Portal credentials), EHR clinician launch (launching a SMART app in context inside the NextGen chart), and backend system-to-system services using asymmetric JSON Web Keys (JWKS).
- FHIR Bulk Data Access (
$export): For population health analytics, value-based care cohorts, and clinical trial feasibility screening across an entire patient panel or FHIRGroup, NextGen supports the HL7 FHIR Bulk Data Access specification, returning asynchronous newline-delimited JSON (.ndjson) files. - NextGen Proprietary REST APIs and NextGen Connect (Mirth): Because baseline ONC FHIR R4 certification focuses primarily on clinical data retrieval, bidirectional operational workflows—such as real-time appointment slot booking, patient demographic creation, charge posting, document upload, and ambient scribe note write-back—often pair FHIR R4 queries with NextGen’s expanded RESTful Enterprise APIs or HL7 v2 (
ADT,SIU,ORM,ORU,MDM) channels managed via NextGen Connect.
How Is the NextGen Enterprise SQL Database Structured for Clinical Reporting?
In FQHCs, practice-based research networks (PBRNs), and multi-specialty clinics running NextGen Enterprise, clinical data managers and biostatisticians frequently build SQL Server Reporting Services (SSRS) extracts, Uniform Data System (UDS) tables, or OMOP Common Data Model (CDM) ETL pipelines directly against the NextGen Enterprise Microsoft SQL Server database (commonly named NGProd).
Unlike document-centric EHRs, NextGen Enterprise stores every template checkbox, vital sign, and billing charge in normalized and template-specific SQL tables:
- Identity Hierarchy (
personvs.patient): NextGen separates universal human identity from practice-specific patient status. Thepersontable (keyed by a GUIDperson_id) stores master demographic attributes (name, date of birth, sex, race, ethnicity, address, and contact details) for every individual in the system—including patients, non-patient guarantors, and family members. Thepatienttable links toperson_idand adds practice-bound clinical and financial attributes (such as medical record numbermed_rec_nbrand primary care provider). - Encounter Spine (
patient_encounter): Every billable or clinical visit generates a row inpatient_encounter(keyed byenc_idand linked toperson_idandpractice_id), recording the encounter timestamp (billable_timestamp), rendering provider, service location, and clinical/billing lock status. - Clinical Core and Knowledge Base Model (KBM) Tables: Core clinical lists reside in dedicated tables—such as
patient_problems(SNOMED CT / ICD-10 problem list),patient_medication(active and historical prescriptions),patient_allergy, andlab_nor/lab_results_obx(HL7 v2 orders and LOINC-coded observations). Additionally, data entered into NextGen’s customizable KBM clinical templates are written to template-specific SQL tables (such asmaster_imfor master clinical assessment items andvital_signs_tables) linked back toperson_idandenc_id. - Reporting Governance: To prevent long-running analytical queries from locking transactional tables during clinic hours, health systems replicate the production SQL Server database (via SQL Server Always On availability groups, transactional replication, or nightly backups) to a dedicated reporting server or enterprise data warehouse before running cohort queries.
Strengths, Limitations, and Ambulatory EHR Alternatives
- Strengths in Specialty and FQHC Research: NextGen Enterprise’s granular SQL Server schema and built-in FQHC Uniform Data System (UDS) and Social Determinants of Health (SDOH) templates make it highly adaptable for community health center epidemiology, multispecialty registries, and health services research.
- Integration Complexity Across Two Codebases: For digital health vendors and decentralized clinical trial (DCT) platforms, the primary operational challenge is that NextGen Enterprise and NextGen Office do not share a single backend or API schema; an integration built for NextGen Enterprise REST endpoints requires separate onboarding and FHIR mapping for clinics on NextGen Office.
Comparison With Peer Ambulatory EHR Platforms
| EHR Platform | Primary Market Segment | Core Database & Hosting Model | Interoperability & API Stack |
|---|---|---|---|
| NextGen Healthcare (Enterprise & Office) | Multi-specialty groups, FQHCs (Enterprise) & small practices (Office) | MS SQL Server cloud/on-prem (Enterprise); multi-tenant cloud (Office) | ONC FHIR R4, Enterprise REST APIs, NextGen Connect (Mirth Connect) |
| eClinicalWorks (eCW) | Large and small ambulatory groups, FQHCs, and urgent care | Cloud-centric relational architecture (eCW Cloud on Azure) | FHIR R4 Connect Portal, healow APIs, Carequality / TEFCA |
| athenahealth (athenaOne) | Independent practices, medical groups, and enterprise ambulatory networks | Single-instance, multi-tenant cloud SaaS | athenaOne FHIR R4 APIs, proprietary REST APIs, Marketplace partners |
| Veradigm / Altera Digital Health | Ambulatory practices (Veradigm EHR) and hospital/specialty groups (TouchWorks) | Hosted / cloud SQL and multi-tenant architectures | Veradigm Connect, Unity API, ONC FHIR R4 endpoints |
| ModMed (EMA) | Outpatient medical and surgical subspecialties (dermatology, ortho, ophthalmology) | Cloud-native specialty data model | ModMed synapSYS FHIR R4 APIs and specialty registry pipelines |
Frequently Asked Questions
What is the difference between NextGen Enterprise and NextGen Office?
NextGen Enterprise and NextGen Office are two separate Electronic Health Record (EHR) and Practice Management (PM) architectures maintained by NextGen Healthcare. NextGen Enterprise is a customizable client-server/cloud platform built on a Microsoft SQL Server relational database for mid-to-large multi-specialty medical groups and Federally Qualified Health Centers (FQHCs). NextGen Office (formerly HealthFusion MediTouch) is a browser-native, multi-tenant cloud EHR/PM designed for smaller independent ambulatory practices without direct SQL database access.
How do developers integrate with NextGen Healthcare APIs and FHIR endpoints?
Developers integrate with NextGen EHR platforms through the NextGen Partner Program / Developer Portal using ONC-certified HL7 FHIR R4 (4.0.1) APIs (supporting SMART on FHIR OAuth 2.0 patient/provider launch, US Core profiles, and Bulk Data $export), NextGen’s proprietary RESTful Enterprise/Practice APIs for scheduling and write-back workflows, or HL7 v2 and C-CDA interfaces routed through the NextGen Connect Integration Engine (formerly Mirth Connect).
How is the NextGen Enterprise SQL database structured for clinical reporting?
NextGen Enterprise stores clinical and financial records in a unified Microsoft SQL Server database where core tables include person (master demographic identity keyed by person_id), patient (practice-level clinical attributes), patient_encounter (visit instances, timestamps, rendering providers, and billing statuses keyed by enc_id), and KBM (Knowledge Base Model) template tables (including master_im and specialty template tables) that support Uniform Data System (UDS) and eCQM reporting.
Sources
- NextGen Healthcare — Interoperability, Certified API Documentation, and HL7 FHIR R4 Endpoints (NextGen Enterprise & NextGen Office) (https://www.nextgen.com/interoperability).
- NextGen Healthcare — API Search and ONC Cures Act Real World Testing / Developer Documentation (https://www.nextgen.com/api-search).
- Office of the National Coordinator for Health Information Technology (ONC) / Code of Federal Regulations — 45 CFR § 170.315(g)(10) (Standardized API for patient and population services) and § 170.215 (Application Programming Interface Standards) (https://www.law.cornell.edu/cfr/text/45/170.315).
