Allscripts / Veradigm Integration: Sunrise, TouchWorks, FHIR, HL7 v2

The Allscripts / Veradigm portfolio is a set of EHR products that share a brand lineage but have distinct architectures, integration surfaces, and customer bases. The 2022 rebrand of Allscripts Healthcare Solutions to Veradigm — with the concurrent sale of the hospital business (Sunrise Acute Care) to Constellation Software / N. Harris Computer — has created some confusion in the market. Integration engineers need a clear map of which products live where, what APIs they expose, and how to work with them consistently.

This guide is the practical reference we use in the field. It covers the product portfolio as it stands in 2026, the Veradigm Developer Program, the Allscripts Open FHIR + HL7 v2 APIs, typical multi-product integration patterns, and the role Mirth Connect plays as a neutral integration layer across the portfolio.

For adjacent context, see our EHR integration guide, HL7 integration guide, and FHIR integration guide.

1. Allscripts, Veradigm, and the 2022 Rebrand

Allscripts Healthcare Solutions was, through the 2000s and 2010s, one of the major US EHR vendors, with a portfolio covering hospital (Sunrise), ambulatory (TouchWorks, Professional EHR), data analytics (dbMotion, Payerpath), and related services. In 2022, the company:

Sold the hospital business — Sunrise Acute Care and related hospital products — to Constellation Software / N. Harris Computer Corporation.
Rebranded the remaining parent company as Veradigm, focusing on ambulatory EHR, data and analytics, and the provider-facing and payer-facing businesses.
Retained TouchWorks, Professional EHR, dbMotion, and related products under the Veradigm name.

In practice, the market still uses “Allscripts” interchangeably with the product names. You’ll hear “Allscripts Sunrise” and “Sunrise” referring to the same product; “Allscripts TouchWorks” and “Veradigm TouchWorks” referring to the same ambulatory EHR. Integration teams should be precise when documenting a project: specify the product name and version, not just the parent brand.

What the rebrand did not change: the FHIR and HL7 v2 integration programs continue, developer documentation remains accessible, and existing customer integrations continue to operate. Expect brand changes in UI and documentation, but not architectural changes to the integration surface.

2. Product Map — Which Platform Are You Integrating With?

The integration approach depends entirely on which product the target customer runs. Ask first.

Product              | Segment              | Ownership (2026)    | Notes
---------------------|----------------------|---------------------|----------------------
Sunrise Acute Care   | Hospital / inpatient | Constellation/Harris| Formerly Allscripts
TouchWorks           | Ambulatory mid-large | Veradigm            | Largest ambulatory
Professional EHR     | Ambulatory small-mid | Veradigm            | Smaller practices
dbMotion             | Interoperability/HIE | Veradigm            | Data aggregation
Payerpath / RCM      | Revenue cycle        | Veradigm            | Claim & billing

A single health system may have multiple products deployed — Sunrise in the hospital, TouchWorks in affiliated ambulatory clinics, dbMotion as the community record aggregator. Your integration scope should map to each product explicitly.

3. Sunrise Acute Care — The Hospital EHR

Sunrise Acute Care is a full hospital EHR: CPOE, clinical documentation, pharmacy, laboratory, radiology, and financials for inpatient, ED, and some ambulatory departments. It’s deployed across US hospitals, especially mid-sized and regional systems, and continues to be marketed post-2022 under its new ownership.

3.1 Integration surfaces

HL7 v2 MLLP — ADT, ORM, ORU, MDM, SIU, DFT, BAR (billing account). Near-real-time via MLLP (typically MLLPS in modern deployments).
FHIR R4 APIs — US Core profiles under Allscripts Open, with OAuth 2.0 and SMART on FHIR.
Sunrise-specific integration modules — device integration (monitors, infusion pumps), lab analyzer interfaces, pharmacy robot integration.
CCDA — for DirectTrust messaging and HIE participation.
Batch extracts — for data warehouse hydration, typically via custom reports or database views.

3.2 Typical hospital integration footprint

A Sunrise hospital of 200–500 beds typically runs 50–150 active HL7 v2 interfaces across clinical systems, ancillary departments, and external partners. A growing share of new integrations go through FHIR, especially for care-coordination and patient-facing apps.

4. TouchWorks — Ambulatory Mid-to-Large Practices

TouchWorks is the Veradigm ambulatory EHR positioned for mid-sized and larger multi-specialty groups. Deployment scale typically ranges from 50 to 500+ providers at a single organization, often spanning multiple specialties.

4.1 Integration surfaces

FHIR R4 under Allscripts Open — US Core resources, OAuth 2.0 / SMART on FHIR launch.
HL7 v2 MLLP — ambulatory message types (ADT, SIU, ORM, ORU, VXU, MDM).
TouchWorks-specific REST APIs — for documents, tasks, problem lists, and specialty workflows.
CCDA and Direct messaging.
X12 837/835 — claim submission and remittance (often through Payerpath or third-party clearinghouses).

4.2 Typical integration scope

A large TouchWorks group runs 20–60 active interfaces: labs, imaging centers, specialty-referral partners, registries, population-health platforms, patient portal, telehealth, and payer connections. FHIR is increasingly the path for new third-party app integrations.

5. Professional EHR — Smaller Ambulatory Practices

Professional EHR targets smaller practices (1–50 providers) with simpler workflow needs. It has a narrower integration surface than TouchWorks but covers the core use cases.

FHIR R4 (with a subset of US Core resource coverage vs TouchWorks in some configurations).
HL7 v2 MLLP for core message types.
CCDA for care-summary exchange.
X12 for claims.
Direct messaging for clinical document exchange.

Integrations for Professional EHR tend to be simpler and faster to build than TouchWorks or Sunrise, but plan for per-customer variation — smaller practices often have idiosyncratic configurations.

6. Veradigm Developer Program

The Veradigm Developer Program is the entry point for app developers building on the Allscripts / Veradigm portfolio:

Application registration and OAuth client provisioning.
Sandbox environment with synthetic patient data.
Documentation for FHIR endpoints and product-specific APIs.
Marketplace for distributing approved apps.
Per-customer production enablement workflow.

Typical onboarding flow

1. Sign up for Veradigm Developer Program
2. Register application with redirect URIs and scopes
3. Receive sandbox credentials
4. Build and test against the FHIR sandbox
5. Submit for review (app certification / listing)
6. Per-customer production enablement (client credentials
   issued for each target practice/hospital)
7. Go-live with each customer as they authorize access

Budget adequate time for the per-customer enablement step. Each hospital or practice has its own security and procurement review. Do not assume production access follows automatically from sandbox approval.

7. Allscripts Open — FHIR + HL7 v2 in One Program

Allscripts Open is the umbrella for open-standards integration across the EHR portfolio. Core components:

7.1 FHIR R4

US Core profile coverage across Patient, Encounter, Observation, Condition, MedicationRequest, AllergyIntolerance, Immunization, Procedure, DocumentReference, DiagnosticReport, and the usual SMART on FHIR launch patterns.

# Example: patient search with OAuth
GET /fhir/r4/Patient?identifier=MRN|987654
Host: fhir.allscripts-open.com
Authorization: Bearer eyJhbGciOi...
Accept: application/fhir+json

# Returns a Bundle of matching Patient resources

7.2 HL7 v2

HL7 v2 remains the high-volume transport. Allscripts Open publishes interface specifications for ADT, ORM, ORU, MDM, SIU, and others, per product. Versioning varies — validate during discovery.

7.3 SMART on FHIR apps

Both provider-facing (EHR-launched) and patient-facing (standalone) SMART on FHIR apps are supported across the portfolio. Launch context and scopes follow the standard SMART specification.

7.4 Bulk FHIR / flat FHIR

For population-health and analytics use cases, bulk FHIR export is available in increasing coverage. Plan for asynchronous export workflows and NDJSON parsing.

8. Multi-Product Integration Scenarios

The distinctive challenge with this portfolio is that many customers deploy multiple products. Three common scenarios:

8.1 Sunrise + TouchWorks (health system with affiliated clinics)

A hospital runs Sunrise inpatient; affiliated ambulatory clinics run TouchWorks. Patient demographics and encounters need to flow between them, with unified MRN handling and care-coordination across settings. Typical integration: a Mirth hub receives ADT from both products, normalizes identifiers via an enterprise MPI, and distributes to downstream systems.

8.2 TouchWorks + Professional EHR (acquired practices)

A physician group using TouchWorks acquires smaller practices running Professional EHR. Consolidating reporting, quality measures, and population-health feeds across the two ambulatory EHRs is the integration project. Mirth Connect channels normalize data from both into a unified analytics pipeline.

8.3 Any-product + dbMotion

When dbMotion is the community record aggregator, integrations feed data into dbMotion from the EHRs and retrieve consolidated views. FHIR APIs and CCDA exchange are the primary surfaces. Plan for data-stewardship conversations about what data goes where and how conflicts are reconciled.

9. Mirth Connect as the Integration Layer

In a mixed Allscripts / Veradigm environment, a standalone integration engine pays for itself on the first multi-product project. Why Mirth Connect specifically:

Vendor neutrality — Mirth talks to Sunrise, TouchWorks, and Professional EHR simultaneously without product bias.
Transformation engine — JavaScript transformers for HL7 v2 ↔ FHIR translation, identifier normalization, and custom business rules.
Operational visibility — single pane of glass across all product feeds.
Cost — avoid per-interface licensing fees from proprietary engines.
Decoupling — Allscripts product upgrades don’t force changes to Mirth, and vice versa.

See our Mirth Connect guide for a deeper look at deployment patterns, clustering, and channel design.

10. Project Plan and Timeline

A realistic timeline for a typical Allscripts / Veradigm integration (single product, ADT + ORU + FHIR read):

Week 1–2   Discovery
           • Confirm product(s) and version(s)
           • Inventory interfaces, volumes, existing gaps
           • Developer program application
           • Security review kickoff

Week 3–4   Design
           • Architecture and Mirth placement
           • Message specs, FHIR scopes, mappings
           • Sandbox access validated
           • Error handling & alerting defined

Week 5–7   Build
           • Mirth channels, transformers
           • FHIR client with OAuth
           • Unit tests, integration tests

Week 8–9   UAT
           • Synthetic production-like test
           • Clinical SME sign-off
           • Runbook drafted

Week 10    Pre-prod / staging
           • Production-like environment
           • Go/no-go checklist
           • Per-customer enablement kickoff

Week 11    Go-live
           • Cutover (weekend or planned window)
           • Dual-run if feasible
           • Hypercare standby

Week 12    Hypercare & closeout
           • Daily standups
           • Incident response
           • Fine-tune alerts, knowledge transfer

For multi-product integrations, plan each product as a separate build stream with a consolidated integration-and-test phase. For cost planning, see our EHR integration cost guide.

11. Common Pitfalls

11.1 Conflating the rebrand with architecture change

The 2022 Veradigm rebrand is a corporate change, not a technology reset. Integration surfaces and behaviors remain substantially the same. Don’t assume you need to rewrite — but do verify documentation URLs and endpoint URLs have moved correctly in your config.

11.2 Under-testing across products

A FHIR integration that works beautifully against TouchWorks may behave differently against Professional EHR. Test against every product you target, not just one. Plan for test time per product in your project schedule.

11.3 Forgetting the per-customer enablement step

Sandbox approval does not equal production access. Every customer hospital or practice has its own security review. Build this step into your go-to-market and track it per account.

11.4 Ignoring dbMotion in community records

If your target organization uses dbMotion as a community record, an integration that only touches the EHR product misses half the picture. Scope dbMotion as a first-class integration target where it’s in play.

11.5 Version drift in HL7 v2 interfaces

Older Sunrise installs often carry HL7 v2.3 interfaces. Modern TouchWorks deployments use 2.5.1. Integrations that assume one version will break against the other. Document version per-interface in discovery and test with real messages.

12. Frequently Asked Questions

What happened with Allscripts and Veradigm?

In 2022, Allscripts Healthcare Solutions rebranded the parent company as Veradigm, after selling its hospital EHR business (Sunrise and related products) to Constellation Software / N. Harris Computer Corporation. The Veradigm name now covers the ambulatory EHR portfolio (TouchWorks, Professional EHR), the data and analytics business, and the provider- and payer-facing platforms. The hospital products (Sunrise Acute Care) continue operating under a separate ownership but are commonly still referred to as “Allscripts Sunrise” in the market.

What is Allscripts Sunrise?

Sunrise Acute Care is the hospital EHR product historically marketed by Allscripts — a full inpatient platform including CPOE, documentation, pharmacy, and financials. After the 2022 transaction, Sunrise is owned outside the Veradigm corporate umbrella but remains a major hospital EHR in mid-sized and larger US health systems. Integration patterns are similar to other tier-1 hospital EHRs: HL7 v2 interfaces for near-real-time feeds, FHIR R4 APIs under the Allscripts Open program, and a separate developer portal.

What is TouchWorks?

TouchWorks is Allscripts’ ambulatory EHR for mid-sized to large multi-specialty groups and Independent Physician Associations (IPAs). It’s widely deployed in practices of 50–500 providers. TouchWorks has mature HL7 v2 interface capabilities, FHIR R4 endpoints via Allscripts Open, and a long history of third-party integrations through the Developer Program.

What is Professional EHR?

Professional EHR is Allscripts’ ambulatory product for smaller practices (typically 1–50 providers). It’s simpler than TouchWorks with a more prescribed workflow. Integration surfaces include HL7 v2, FHIR R4 (with some resource coverage differences vs TouchWorks), and CCDA document exchange.

What is Allscripts Open?

Allscripts Open is the umbrella for the FHIR + HL7 v2 API program across the Allscripts / Veradigm EHR products. It includes OAuth 2.0 authorization, SMART on FHIR launch support, and US Core FHIR profiles. Access is provisioned through the Veradigm Developer Program with sandbox credentials and per-customer production enablement.

Is there a single API that works across Sunrise, TouchWorks, and Professional EHR?

Not exactly. The FHIR R4 surface under Allscripts Open follows the same US Core profiles, so a well-designed FHIR integration can reuse code across products — but endpoints, configurations, scopes, and resource coverage vary product by product. Any multi-product integration should plan for per-product testing and configuration differences.

How does the Developer Program work?

Veradigm runs a Developer Program with application registration, sandbox access, documentation, and a marketplace for apps. Developers sign up, register applications, receive sandbox credentials, build and test against synthetic data, then negotiate per-customer production enablement with each hospital or practice that wants to use the integration.

Can I use the same integration engine across all Allscripts products?

Yes. An integration engine like Mirth Connect sits outside any specific EHR product and can talk to Sunrise, TouchWorks, and Professional EHR simultaneously. This is the most common approach in health systems with a mixed Allscripts / Veradigm footprint — one Mirth cluster, multiple channels per product, unified monitoring and alerting.

What HL7 v2 versions do Allscripts products use?

Across the portfolio, expect HL7 v2.3, 2.4, 2.5, and 2.5.1. Sunrise interfaces in older installs may still use v2.3 for legacy reasons; newer TouchWorks and Professional deployments commonly use v2.5 or 2.5.1. Confirm the version per-interface during discovery — mismatches in field population and segment usage are the single most common source of rework.

What about dbMotion?

dbMotion is Allscripts’ (now Veradigm’s) interoperability and data-aggregation platform. It acts as a community clinical record, pulling data from multiple EHRs into a unified view. If your integration target is dbMotion rather than a specific EHR, the patterns differ — FHIR APIs, CCDA consolidation, and data-subscription models. Treat dbMotion integration as a separate discipline from EHR-product integration.

Allscripts / Veradigm Integration:Sunrise, TouchWorks, Professional EHR & FHIR

Table of Contents