Allscripts Integration: Navigating Unity and Sunrise
Last updated: November 2026
Allscripts is not one platform -- it is two, with divergent architectures, APIs, and integration paths. If someone says "we need to integrate with Allscripts," the first question is: Unity or Sunrise? The answer determines everything about your approach.
The corporate context
The Allscripts name covers a complicated history. The EHR business split from the data analytics side (rebranded as Veradigm). The Sunrise acute-care platform was acquired in the Eclipsys merger. Unity (the ambulatory platform, also called Professional) has its own lineage. As of 2026, the market share is declining -- practices and hospitals are migrating to Epic, Oracle Health, or MEDITECH, and new implementations are rare. But there is still a significant installed base, and if you are building a multi-EHR product, you will encounter Allscripts sites.
Two platforms, two integration surfaces
| Dimension | Unity (Professional) | Sunrise |
|---|---|---|
| Market | Ambulatory practices, physician offices | Hospitals, health systems |
| Deployment | Cloud-hosted or on-premise | Primarily on-premise |
| Primary API | Allscripts Open API (REST/JSON) + legacy Unity API (SOAP/XML) | Allscripts Open API (REST/JSON) |
| FHIR R4 | Supported (coverage varies by version) | Supported (coverage varies by version) |
| HL7v2 feeds | Limited -- most practices prefer API | Full ADT/ORU/ORM over MLLP |
| Scheduling | Available via Open API | Less prominent (hospital scheduling is often separate) |
| Typical IT support | Small practice IT or outsourced | Hospital interface team |
The Open API is the common thread between the two platforms, but the data models underneath are different. A Patient resource from Unity and a Patient resource from Sunrise may have different field populations, different identifier systems, and different extension patterns. Do not assume that a working Unity integration transfers to Sunrise without adaptation.
The Open API
Allscripts Open API provides REST access to patients, encounters, clinical summaries, documents, vitals, medications, allergies, and problems. Registration is through the Allscripts Developer Program.
Key characteristics:
- Token-based auth. OAuth 2.0 with client credentials. Token lifetime is longer than Epic's (typically 60 minutes), which makes the auth lifecycle simpler.
- GetClinicalSummary is the workhorse. For many integration use cases, the
GetClinicalSummaryendpoint returns a comprehensive clinical document (similar to a CCD) for a patient. It is often easier to pull this and parse it than to make individual resource-level API calls. - Write support is limited. The Open API supports document upload and some clinical writes, but bidirectional integration depth is narrower than what Epic or Cerner offer through FHIR.
HL7v2: Sunrise only (mostly)
Sunrise installations at hospitals produce standard HL7v2 feeds -- ADT, ORU, ORM -- over MLLP, similar to Epic or Cerner. The messages follow v2.3 or v2.5.1 and are relatively standard, without the heavy Z-segment customization you see at Epic sites.
Unity (ambulatory) sites rarely use HL7v2. The practices are smaller, often lack interface infrastructure, and prefer API-based integration. If a Unity practice does send HL7v2, it is usually for a narrow use case like lab results from a reference lab, and the interface engine is often managed by the lab, not the practice.
For HL7v2 segment-to-FHIR mapping, the patterns in our migration guide apply directly to Sunrise feeds.
FHIR R4
Allscripts FHIR R4 endpoints exist on both platforms as required by the 21st Century Cures Act. Coverage includes Patient, Encounter, Condition, Observation, MedicationRequest, and AllergyIntolerance. In practice, the FHIR surface is thinner than Epic's or Cerner's:
- Fewer search parameters are supported per resource.
- Bulk Export (
$export) may not be available or may be incomplete at older installations. - Some sites still expose DSTU2 alongside R4; confirm the version before you build against it.
If you need broad data access at an Allscripts site, the Open API's GetClinicalSummary plus FHIR for standard-format clinical reads is the pragmatic combination.
What to expect in practice
Declining investment. Because Allscripts' market share is shrinking, the pace of API improvements and new feature development is slower than what you see from Epic or Cerner. The APIs work, but do not expect rapid iteration.
Migration-in-progress sites. Some organizations that were on Allscripts are mid-migration to another EHR. Confirm that the integration you are building will still be relevant after their go-live on the new system. We have seen teams build Allscripts integrations that were obsolete within 18 months.
The Veradigm question. The data analytics side of the old Allscripts (now Veradigm) has its own APIs for de-identified data, clinical trial recruitment, and real-world evidence. If your use case is analytics rather than clinical workflow integration, the Veradigm APIs may be more relevant than the EHR APIs. These are separate products with separate access agreements.
If you are dealing with an Allscripts site and trying to figure out which platform and API path to use, we can help you sort it out quickly.