NextGen Integration: Specialty Practices and the Bundled Mirth Question
Last updated: November 2026
NextGen Healthcare occupies a specific niche: ambulatory specialty practices. Orthopedics, cardiology, dermatology, behavioral health, gastroenterology, community health centers (FQHCs). The EHR is template-driven, with specialty-specific workflows that go deeper than what a general-purpose ambulatory platform like athenahealth offers.
Two things make NextGen integration different from other EHRs: the specialty-specific data model, and the fact that NextGen bundles Mirth Connect as its default integration engine. Both shape how you approach the work.
The bundled Mirth question
NextGen acquired Mirth Corporation in 2015 and rebranded the product as NextGen Connect Integration Engine. Many NextGen sites have Mirth running out of the box. This creates a question you will hit immediately: does the site already have a working integration engine, and if so, do you need another one?
When the bundled Mirth is enough:
- Standard HL7v2 routing. If the integration is point-to-point HL7v2 (lab orders out, results back, ADT to a downstream system), the bundled Mirth handles this well. The channels are often already configured or easy to add.
- Simple transformations. Mirth's JavaScript-based transformer can handle segment mapping, field extraction, and basic filtering without external tools.
- The practice has Mirth expertise. Some NextGen sites have interface analysts who know Mirth well. Leveraging their existing skill set is faster than introducing a new tool.
When you need something else:
- FHIR-native requirements. Mirth's FHIR support has improved but is not its strength. If you need native FHIR resource construction, Bulk Export handling, or SMART on FHIR authentication, a purpose-built FHIR layer may be cleaner.
- Multi-EHR aggregation. If you are building a product that connects to NextGen plus Epic plus Cerner plus athenahealth, running a separate Mirth instance per EHR does not scale well. A centralized integration layer makes more sense.
- The practice's Mirth is old or unmanaged. The bundled Mirth version may be years behind the current NextGen Connect release. Some sites have Mirth running but nobody on staff who understands the channel configurations. Adding channels to a Mirth instance nobody maintains is risky.
- Complex orchestration. If your integration requires multi-step workflows (receive a result, enrich it with data from another source, validate it, route it conditionally), Mirth can do this but it gets complex fast. Purpose-built orchestration tools or a custom pipeline may be more maintainable.
The pragmatic approach: ask the site what Mirth version they are running, who manages it, and what channels already exist. If the answer is "current version, managed by our interface analyst, and we have channels for all our lab interfaces," build on what is there. If the answer is "we think Mirth is running but nobody touches it," treat it as absent and plan your own infrastructure.
For a broader comparison of integration engine options, see our alternatives to Mirth Connect.
Specialty-specific integration patterns
NextGen's value proposition is specialty depth. The templates contain fields and workflows that general-purpose EHRs do not have. This surfaces in integration work as custom data elements that do not map cleanly to standard FHIR resources.
Orthopedics and surgical specialties
NextGen's orthopedic templates track body site detail (left knee, right shoulder, specific joint surface), implant information, range-of-motion measurements, and surgical history at a granularity that standard FHIR Condition and Procedure resources do not capture. If your integration needs this data:
- The proprietary NextGen API exposes specialty-specific fields that the FHIR API may not.
- Implant data often lives in custom fields or document-attached structured data, not in standard clinical segments.
- Pre-op and post-op protocols are template-driven and may need to be extracted as documents rather than discrete data.
Behavioral health
Behavioral health practices on NextGen use templates for treatment plans, screening instruments (PHQ-9, GAD-7, AUDIT-C), and session notes with structured assessment fields. Integration considerations:
- 42 CFR Part 2 governs substance use disorder records and requires explicit consent for disclosure. Your integration must respect segmentation rules. This is not a FHIR or HL7v2 problem -- it is a consent architecture problem. See our HIPAA consent engineering guide for the technical details.
- Screening instrument scores are often stored as Observations with LOINC codes, which map cleanly to FHIR. But the full screening instrument responses may be in custom template fields.
Community health centers (FQHCs)
FQHCs on NextGen have UDS (Uniform Data System) reporting requirements. Integration for quality reporting typically involves extracting clinical data (diagnoses, procedures, vitals, lab results) and computing quality measures. The data is standard clinical data -- the complexity is in the measure logic, not the extraction. NextGen's reporting tools handle some UDS measures internally, but custom measures or external reporting platforms need data extraction.
Cardiology
Cardiology templates include structured ECG data, echocardiogram measurements, cardiac catheterization results, and device interrogation data. Much of this is stored as documents or in specialty-specific fields. Standard HL7v2 ORU carries some results, but detailed cardiac data often requires the proprietary API or document-level extraction.
API surface
NextGen exposes three integration paths:
| Path | Protocol | Coverage | Notes |
|---|---|---|---|
| NextGen proprietary API | REST/JSON | Patients, appointments, encounters, clinical data, documents, practice management | Broadest coverage, developer portal registration required |
| FHIR R4 | REST/JSON | Standard clinical resources (Patient, Encounter, Condition, Observation, etc.) | Required by Cures Act; coverage is adequate for core clinical data |
| HL7v2 | MLLP | Lab orders/results, referrals, some ADT | Typically managed through bundled Mirth |
For most specialty practice integrations, the proprietary API provides access to the specialty-specific data that FHIR does not cover. Use FHIR for standard clinical data exchange and the proprietary API for everything else.
Referral networks
Specialty practices live on referrals. A primary care physician sends a referral; the specialist sees the patient; the specialist sends a consultation note back. NextGen handles both sides:
Inbound referrals arrive as CCDA documents (via Direct messaging or API) or as HL7v2 SIU scheduling messages (if the referring organization sends them). The CCDA contains the reason for referral, relevant clinical history, and insurance information. NextGen can ingest these into the patient chart.
Outbound consultation notes are generated by NextGen after the specialist encounter. These go back to the referring provider as CCDAs. If you are building a referral management platform, the document exchange pattern is the most universal -- it works regardless of what EHR the other side runs.
Multi-location considerations
Specialty groups often operate across multiple locations. NextGen organizes data by practice and location. For integrations that need to aggregate data across locations (e.g., a central analytics dashboard for a 10-location orthopedic group), you need to query each location separately and aggregate client-side. There is no cross-location API query.
Provider schedules may span locations (a surgeon operates at Hospital A on Mondays and Clinic B on Wednesdays), which complicates scheduling integrations. The provider is one entity in NextGen; the schedule is location-bound.
If you are building an integration for specialty practices on NextGen and trying to figure out whether to work with the bundled Mirth or bring your own infrastructure, we can help you assess what makes sense for your specific case.