Greenway Health Integration Guide: Intergy, FHIR, HL7 v2 & APIs

Greenway Health is one of the established names in US ambulatory EHR, serving independent primary-care practices, multi-specialty groups, and community health centers. Most Greenway customers today run Intergy, Greenway’s strategic platform, with a shrinking legacy base still on Prime Suite. Integration engineers working in the ambulatory segment meet Greenway regularly, especially in primary-care networks and regional specialty groups.

This guide is the practical reference we use when scoping and building Greenway integrations. It covers the platform landscape, the Greenway API set, FHIR R4 access, HL7 v2 interface patterns, typical ambulatory use cases, and how Mirth Connect acts as a translation and monitoring layer between Greenway and downstream systems.

For broader starting points, see our EHR integration guide, HL7 integration guide, and FHIR integration guide.

1. Greenway Health in the Ambulatory EHR Landscape

Greenway Health was formed from the 2013 merger of Greenway Medical Technologies and Vitera Healthcare Solutions (itself formed from earlier Sage Software and Emdeon-provider-Services assets). The merger combined three ambulatory EHR platforms — Intergy, Prime Suite, and PrimeCLINICAL — under one company. In the years since, Greenway consolidated around Intergy as the strategic go-forward platform and began migrating customers away from the legacy products.

Greenway customers typically match the ambulatory market profile:

Independent primary-care practices (1–20 providers).
Multi-specialty ambulatory groups (20–200 providers).
Community health centers and FQHCs (varies widely in size).
Specialty-group networks (orthopedics, cardiology, women’s health).
Independent physician associations (IPAs) aggregating small practices.

Competitively, Greenway runs alongside eClinicalWorks, athenahealth, NextGen, and Allscripts / Veradigm TouchWorks. See our eClinicalWorks integration guide, athenahealth integration guide, NextGen integration guide, and Allscripts / Veradigm integration guide for head-to-head comparisons.

2. Intergy — The Current Platform

Intergy is Greenway’s strategic EHR and practice-management platform. It covers the full ambulatory workflow:

Clinical charting, documentation, orders, results.
E-prescribing and medication management.
Scheduling and registration.
Practice management, billing, and revenue cycle.
Patient portal and engagement tools.
Population-health reporting and quality measures.
Telehealth (integrated and via partners).

2.1 Hosting options

Intergy is available both as a Greenway-hosted cloud service and as an on-premise deployment. Cloud is the default for new customers, with Greenway managing infrastructure, upgrades, and some operational responsibilities. On-premise is still common in larger groups with established infrastructure and integration teams.

2.2 Integration readiness

Intergy was designed from the start with integration in mind: ONC-certified for Meaningful Use successors, FHIR R4 support, mature HL7 v2 interface capabilities, and a Greenway API program for developers. Integrations are first-class citizens in the platform, not bolted on.

3. Prime Suite — The Retired Product

Prime Suite was Greenway’s other ambulatory EHR, inherited from the Vitera / Sage lineage. It had substantial deployments in small and mid-sized practices across the US, especially primary care and some specialty groups.

Greenway announced end-of-development for Prime Suite and has been actively migrating customers to Intergy for several years. Key facts to keep in mind:

Prime Suite is retired for new sales.
Active customer base continues to shrink year over year.
Greenway’s migration services move customers to Intergy; third-party migration services also exist.
Integrations built against Prime Suite require rework to move to Intergy — endpoint URLs, API shapes, and some semantics change.

If you’re starting a new integration in 2026, target Intergy. If you have an existing Prime Suite integration, plan for Intergy migration as part of your roadmap rather than building new functionality on Prime Suite.

4. Integration Surface — APIs and Interfaces

Intergy’s integration surface covers the full modern stack:

FHIR R4 REST APIs — US Core profile reads with OAuth 2.0 and SMART on FHIR.
Greenway APIs (REST) — practice-specific endpoints for scheduling, patient data, documents.
HL7 v2 MLLP — the workhorse for near-real-time clinical message flow.
CCDA — for care-summary exchange and DirectTrust messaging.
X12 837/835 — claim submission and remittance via clearinghouse.
SFTP batch exports — for registry reporting and analytics.

Surface         | Latency      | Auth                | Use case
----------------|--------------|---------------------|---------------------
FHIR R4 REST    | Sync (ms)    | OAuth 2.0 / SMART   | App integration
Greenway REST   | Sync (ms)    | API key / OAuth     | Practice workflows
HL7 v2 MLLP(S)  | Near-RT      | Network / TLS       | ADT, orders, results
CCDA / Direct   | Minutes      | DirectTrust cert    | Care summary
X12 837/835     | Batch / RT   | Clearinghouse acct  | Claims, remittance
SFTP            | Daily/Hourly | SSH keys            | Registry, analytics

5. Greenway APIs

The Greenway APIs are the REST interface for application developers building on top of Intergy. They cover practice workflows that don’t fit neatly into the FHIR R4 standard but are important to ambulatory apps:

Appointment booking, rescheduling, cancellation workflows.
Patient demographics, insurance, and contact updates.
Document upload and retrieval (clinical notes, forms, images).
Task and message routing.
Provider and location metadata.
Patient portal coordination.

5.1 Authorization

API access is provisioned through the Greenway developer program. OAuth 2.0 is the primary authorization mechanism for user-scoped calls; API keys or client-credential flows cover system-level access for backend integrations.

# Sample API call sketch
GET https://api.greenway.example/v1/practice/PRAC_ID/appointments?date=2026-04-22
Authorization: Bearer eyJhbGciOi...
Accept: application/json

# Response: JSON array of appointment objects

5.2 Rate limits

Plan for per-application and per-practice rate limits. Implement exponential backoff on 429 responses, and for high-volume use cases, coordinate with Greenway for appropriately sized quotas. For very high-volume extracts, HL7 v2 batch patterns or SFTP exports are often a better fit than API polling.

6. FHIR R4 Access

Greenway’s FHIR R4 endpoints cover the US Core profile set required for ONC certification. Typical resource coverage:

Patient, Practitioner, Organization, Location
Encounter, Appointment, Schedule, Slot
Observation (labs, vitals), DiagnosticReport
Condition, AllergyIntolerance, Immunization, Procedure
MedicationRequest, MedicationStatement
DocumentReference (for CCDA and clinical documents)
CarePlan, Goal, CareTeam
Coverage (insurance data)

6.1 SMART on FHIR launch

# Provider-facing EHR launch (SMART on FHIR)
1. Provider launches your app from within Intergy
2. Your app receives launch + iss parameters
3. Fetch /.well-known/smart-configuration
4. Redirect to authorize endpoint with scopes
5. Receive authorization code, exchange for token
6. Call FHIR APIs with Bearer token

# Patient-facing standalone launch
1. Patient logs into your app
2. App redirects to Greenway’s OAuth authorize endpoint
3. Patient approves access
4. App receives code, exchanges for token
5. Calls FHIR with patient-scoped token

6.2 Write support

FHIR reads are broadly supported. Writes (POST/PUT) have narrower scope and vary by resource and per-practice configuration. For write-back needs that aren’t cleanly served by FHIR, HL7 v2 messages (ORM, MDM) remain a practical option.

7. HL7 v2 Interfaces on Greenway

HL7 v2 remains the backbone for clinical message flow. Standard ambulatory message types are well supported:

ADT — patient demographics, encounter events.
SIU — scheduling (appointments booked, rescheduled, canceled).
ORM — outbound lab and imaging orders.
ORU — inbound lab and imaging results.
MDM — clinical document events.
VXU — immunization records (common for state registries).
DFT — charge capture.

7.1 Transport

MLLP over TCP, with TLS (MLLPS) the recommended posture for HIPAA-safe transmission. For troubleshooting MLLP failures, see our MLLP connection refused troubleshooting guide.

7.2 Sample ADT^A04 from Intergy

MSH|^~\&|INTERGY|GREENWAY_PRAC|DOWNSTREAM|VENDOR|20260421113000||ADT^A04|MSG44556|P|2.5
EVN|A04|20260421113000
PID|1||MRN778899^^^PRAC^MR||GARCIA^MARIA^L||19780910|F||2106-3|789 PINE ST^^AUSTIN^TX^78701||(512)555-0199|||S||ACCT112233
PV1|1|O|||||PRV022^LEE^MICHAEL^S^^DR|||MED||||ROU|||V3|||SC||||||||||||||||||PRAC|||||20260421113000
GT1|1|1|GARCIA^MARIA^L^^^^^^^SELF||789 PINE ST^^AUSTIN^TX^78701|(512)555-0199||19780910|F||SELF|123-45-6789
IN1|1|AETNA|AETN001|AETNA HEALTH PLANS||||||POLICY556677|||||19780910|F|GARCIA^MARIA^L||SELF|||||||||||||||||||||POLICY556677

8. Typical Ambulatory Use Cases

The integration scenarios we see most often on Greenway projects:

8.1 Reference lab integration

Intergy sends ORM orders to Quest, LabCorp, or a regional reference lab; the lab returns ORU results. Often routed through a Mirth channel that translates formats if the lab uses a non-standard flavor of HL7 v2 and enforces business rules (retry, archive, alert on delivery failure).

8.2 State immunization registry

VXU messages to the state’s Immunization Information System (IIS) are common. Each state has its own format preferences, retry rules, and response handling. Mirth Connect channels wrap the state’s quirks around Intergy’s standard VXU output.

8.3 Specialty registry reporting

Cardiology registries (ACC), orthopedic registries (AJRR), quality registries (QPP, MIPS successors), and condition-specific registries all have their own formats — sometimes HL7 v2, sometimes FHIR, sometimes CSV-over-SFTP. Mirth Connect normalizes Intergy data into the registry’s preferred format.

8.4 Population-health platform feeds

ACOs and IPAs aggregate data across multiple practices into platforms like Arcadia, Innovaccer, Epic HealthyPlanet (where Epic is separately deployed), or custom data warehouses. Typical pattern: nightly extracts from Intergy via FHIR bulk export or SFTP, landed into a staging area, normalized by Mirth or a downstream ETL tool.

8.5 Health Information Exchange (HIE)

State and regional HIEs expect CCDA on Direct, or FHIR R4 queries. Intergy generates CCDAs from encounters; Mirth or Greenway’s own connectors route them to the HIE. Inbound HIE data comes back via similar channels for care coordination.

8.6 Telehealth and patient engagement

Digital-health vendors building patient-facing apps typically launch via SMART on FHIR for provider-side workflows and consume FHIR R4 resources for clinical data. Mirth isn’t always in this path — often the integration is direct app-to-FHIR — but it appears when the practice has additional integration requirements beyond the standard vendor template.

9. Mirth Connect as the Integration Layer

Greenway’s native integrations cover common ambulatory patterns well. The case for adding Mirth Connect in front of Greenway strengthens when you have any of:

Edge-case registries that don’t fit Greenway’s stock connectors.
Multi-practice aggregation for an ACO or IPA.
Cross-format translation — partners expecting FHIR while Greenway emits HL7 v2, or vice versa.
Non-standard clearinghouse arrangements in 837/835 flows.
Centralized audit and monitoring beyond Greenway’s native logs.
Retry, queuing, and store-and-forward for unreliable downstream endpoints.
Staging a migration from Prime Suite to Intergy by maintaining stable downstream contracts during transition.

9.1 Typical channel layout

Inbound from Intergy (MLLP listener on Mirth)
      → Preprocessor (normalize, strip BOM)
      → Filter (only route configured message types)
      → Transformer (HL7 v2 → registry-specific format)
      → Router
          ├─ Destination A: State IIS (VXU)
          ├─ Destination B: ACO data warehouse (JSON)
          └─ Destination C: Specialty registry (CSV SFTP)

See our Mirth Connect guide for deployment patterns, clustering, and operational hardening.

10. Project Plan and Timeline

A realistic 10-week timeline for a typical Greenway integration (ADT outbound, ORU inbound, plus FHIR R4 patient lookups):

Week 1     Discovery
           • Confirm Intergy version, hosting model
           • Inventory existing interfaces, volumes
           • Apply to developer program, sandbox access
           • Security review kickoff

Week 2–3   Design
           • Architecture and Mirth placement
           • Message specs, transformations, mappings
           • Error handling, alerting, monitoring
           • Identifier strategy sign-off

Week 4–6   Build
           • Mirth channels and code templates
           • FHIR client with OAuth handling
           • Unit tests with synthetic messages

Week 7     UAT
           • Clinical SME test cases
           • Error injection & recovery drill
           • Runbook drafted

Week 8     Pre-prod
           • Production-like environment
           • Go/no-go checklist walkthrough

Week 9     Go-live
           • Cutover weekend
           • Hypercare standby

Week 10    Closeout
           • Fine-tune alerts
           • Knowledge transfer
           • Document operational runbook

See our EHR integration project timeline and EHR integration cost guide for broader benchmarks.

11. Common Pitfalls

11.1 Targeting Prime Suite for new projects

Prime Suite is retired. New integrations should target Intergy. If an existing Prime Suite customer asks for a new integration, raise the migration question early — building something new on Prime Suite is short-lived work.

11.2 Assuming FHIR write coverage

FHIR reads are broadly available; writes are narrower. If your integration needs to create observations, record documents, or update conditions, validate FHIR write coverage per resource in the sandbox before scoping around FHIR-only write-back.

11.3 Under-planning per-practice enablement

Sandbox approval doesn’t equal production access. Every practice enables integration separately, with its own security review and acceptance. Build this step into your go-to-market and timeline.

11.4 Identifier sprawl across practices

In ACO and IPA scenarios, each Greenway practice uses local MRNs. Cross-practice patient matching needs a strategy — enterprise MPI, probabilistic matching, or externally assigned global identifier. Decide early.

11.5 Weak monitoring in lean-IT practices

Smaller ambulatory practices rarely have 24/7 ops teams. Your integration must be self-monitoring: listener health, queue depth, message error rate, certificate expiry (90/60/30/7/1 day warnings), downstream SLA violations. If you don’t alert proactively, you discover failures through angry clinicians.

12. Frequently Asked Questions

What is Greenway Health?

Greenway Health is a US ambulatory EHR and practice management vendor headquartered in Tampa, Florida. The company formed through the 2013 merger of Greenway Medical Technologies and Vitera Healthcare Solutions, bringing together the Intergy, Prime Suite, and PrimeCLINICAL product lines. Greenway serves independent primary-care practices, multi-specialty groups, and community health centers — typically in the 1–200 provider range.

What is Greenway Intergy?

Intergy is Greenway’s current flagship ambulatory EHR and practice-management platform. It supports charting, orders, e-prescribing, scheduling, billing, and revenue cycle, with a cloud-hosted deployment option and on-premise configurations for larger practices. Modern integrations go through Intergy’s published APIs and HL7 v2 interfaces.

What happened to Prime Suite?

Prime Suite was Greenway’s legacy ambulatory EHR before Intergy became the strategic platform. Greenway announced end-of-development for Prime Suite and has been migrating customers to Intergy over several years. As of 2026, Prime Suite is retired for new sales and the active customer base is small and continues to shrink. Integration planning for new projects should target Intergy; for existing Prime Suite integrations, plan for Intergy migration alongside.

Does Greenway support FHIR?

Yes. Greenway Intergy provides FHIR R4 endpoints that cover the US Core profile set required by ONC certification — Patient, Encounter, Observation, Condition, AllergyIntolerance, Immunization, MedicationRequest, Procedure, DocumentReference, and others. Access is provisioned through Greenway’s developer program with OAuth 2.0 and SMART on FHIR launch support.

Can I integrate via HL7 v2 with Greenway?

Yes — HL7 v2 is still the workhorse for near-real-time clinical message flow. Intergy supports the standard ambulatory message types (ADT, SIU, ORM, ORU, MDM, VXU, DFT) over MLLP, typically MLLPS (over TLS). Interfaces are configured on a per-customer basis with coordination between the practice’s IT team, Greenway’s implementation team, and the third-party system.

What are Greenway APIs?

Greenway APIs is the umbrella term for the REST and FHIR API surfaces exposed by Intergy. The API set includes FHIR R4 for clinical data, practice-specific APIs for scheduling and patient data, and developer-program tooling for application registration. Integrations that need near-real-time data for an app typically use the APIs, while high-volume clinical feeds use HL7 v2 interfaces.

What’s the typical Greenway integration footprint for an ambulatory practice?

A mid-sized Intergy practice (30–100 providers) typically has 10–25 active interfaces: local lab (inbound orders and results), one or two reference labs (Quest, LabCorp), imaging centers, state immunization registry, health information exchange, specialty registry, patient portal, and clearinghouse for claims. Larger multi-specialty groups and FQHCs run broader footprints; smaller practices have 3–8 active feeds.

How do I get a Greenway sandbox?

Greenway operates a developer program with documentation and a sandbox for application development. Access typically starts with an application to the developer program, followed by sandbox credential provisioning and FHIR endpoint details. Per-practice production access is enabled individually, after each customer practice agrees to the integration.

Does Greenway support 837/835 flows?

Yes. Intergy includes an integrated revenue-cycle module that generates 837 professional claims and consumes 835 electronic remittance advice. Most practices use clearinghouses (Change Healthcare, Trizetto, Waystar, Availity) as intermediaries. Integration engines like Mirth Connect can augment the flow when a specialty payer or custom clearinghouse arrangement doesn’t fit the standard setup.

Why use Mirth Connect with Greenway?

Greenway’s native integrations handle common ambulatory patterns, but edge cases — a specialty registry feed, a non-standard clearinghouse, multi-practice aggregation for an ACO, HL7 v2 ↔ FHIR translation for a partner that expects a different format — benefit from a neutral integration engine. Mirth Connect sits between Greenway and the outside world as the translation, routing, and monitoring layer, with the added benefit of centralized HIPAA-grade audit logging and alerting.

Greenway Health Integration Guide:Intergy, FHIR R4, HL7 v2 & Mirth Connect

Table of Contents