Veradigm Unity
Veradigm is a channel through which practices arrive, and its Unity platform is not one API. Drawing it as a single box is the most consequential simplification anyone makes about this integration.
#Two separate APIs
| API | Holds | Example actions |
|---|---|---|
| EHR | The order, the encounter, diagnoses, notes | GetOrders, GetEncounterByApptID, GetPatientDiagnosis, SaveNote, SaveOrder |
| Practice Management | The policy - payer, member id, benefits | GetPatientPolicy, GetSchedule, GetAppointmentById |
#The action envelope
Unity is action-based rather than resource-based. Every call is the same shape, with the operation named in a field.
{
"Action": "GetPatientPolicy",
"Appname": "...", "AppUserID": "...", "PatientID": "...",
"Parameter1": "", "Parameter2": "", "Parameter3": "",
"Parameter4": "", "Parameter5": "", "Parameter6": "",
"Token": "..."
}#Identity must reconcile across the two
reconcileIdentity() runs at the seam, before composition, comparing patient reference, medical record number and date of birth across every contributing source. A disagreement throws. This was found by an eval case written to inject the fault, which discovered there was nothing stopping it.
#Contract status
| What | State |
|---|---|
| Action names | Verified against the published references - 210 actions harvested, 119 EHR and 91 PM. |
| Request and response field shapes | Not verified. The references are action lists, not schemas. |
Every field mapping in the adapter is therefore a placeholder, and the live adapter refuses to run until cassettes are recorded from a sandbox. That is a real blocker, and the console shows it as one rather than as a green checklist.