A guide for clinical operations and IT
The EMR ZAP login you are looking for does not exist
If you typed “emr zap login” expecting a username and password page, here is the honest answer: there isn’t one. The ZAP, Zus Health’s Zus Aggregated Profile, was built to live inside the chart, not behind its own front door. This page explains what that means, why some EMRs show the ZAP and others cannot, and what to do when your chart is a legacy Windows desktop app that has nowhere to put the embed.
Direct answer, verified 2026-06-16
There is no standalone EMR ZAP login. The Zus Aggregated Profile launches embedded inside your EMR through a SMART on FHIR app launch, which carries the EMR’s own session so no separate sign-in is prompted, or it is embedded as an iframe inside your application and secured by your app’s SSO. To open the ZAP on its own you sign in to the Zus dashboard. It has no dedicated “EMR ZAP” URL or credentials of its own.
Source: Zus docs, Accessing the ZAP and Zus Aggregated Profile.
What “EMR ZAP login” actually refers to
The phrase trips people up because it sounds like a product with its own portal. It is not. The ZAP is a unified, reconciled view of a patient’s record that Zus assembles from external networks, de-duplicates, normalizes, and converts to FHIR, with 600+ FHIR resources behind each profile. The point of the design is that a clinician never leaves their workflow to see it.
So the “login” you are searching for is really a question about where the ZAP appears and which session it borrows. There are three places it shows up:
- Inside the EMR. Many EHRs support a SMART on FHIR app launcher. The ZAP launches straight from the patient chart and rides the EMR’s existing authentication, so there is nothing extra to log into.
- Inside your own app. You embed the ZAP as an iframe and implement your own access controls, so your users are authenticated and authorized by your application, not by a Zus login screen.
- The Zus dashboard. To open a ZAP directly, you sign in to Zus itself. Zus documents user authentication through Google Workspace, Azure AD, and Okta SSO.
If none of those describe your situation, you are probably staring at the real problem: your EMR has no place to put the ZAP at all.
Why some charts can host the ZAP and others cannot
The whole embedded approach depends on one thing: the EMR shipping a SMART on FHIR app launcher. Modern, web-based EHRs do, which is why the ZAP drops in cleanly there. The trouble starts in the parts of healthcare that still run on Windows desktop charts:
- Epic published through Citrix, where the chart is a remote window with no in-app launcher you can target
- Older Cerner and MEDITECH builds installed as thick desktop clients
- eClinicalWorks and similar systems where the data lives in a desktop UI, not a SMART container
On those systems there is no button to surface the ZAP, and even when a clinician opens the aggregated record in a separate browser tab or the Zus dashboard, the data still has to make it into the chart. That last step is where the time goes: a person reads reconciled medications and problems off one screen and types them into another, one field at a time.
Getting aggregated data into a chart with no launcher
The clinician opens the ZAP in a separate tab or the Zus dashboard, then transcribes the relevant data into the desktop chart by hand.
- Open the ZAP in a browser tab, away from the chart
- Read meds, problems, and care team off the screen
- Type each field back into the desktop EMR
- Reconciliation errors creep in when fields get missed
How the data actually moves
The agent does not call an API and it does not need the EMR to expose one. It operates the screen the way a person does, reading the accessibility tree that the operating system already publishes for assistive technology, then driving the chart’s real input fields.
From aggregated profile to a legacy chart, no API in the loop
The engine is open source, so you can check the claim
Mediar runs on Terminator, an MIT-licensed project written in Rust and described in its README as “playwright for windows computer use.” It uses Windows UI Automation and the accessibility tree to locate elements by their name and role, the same properties screen readers rely on. That is the reason it can operate a chart with no SMART launcher and no FHIR endpoint: it reads what the app already exposes to the operating system, rather than asking the vendor for an integration.
Because the selectors are accessibility roles instead of pixel coordinates or brittle screen positions, the automation self-heals when the chart’s layout shifts. You can read the source, the releases, and the issue history before you trust it with a clinical workflow.
Two ways to reach the patient record
These are not rivals. Where your EMR can host the ZAP, the embed is the cleaner path. The accessibility agent is for the charts that cannot.
| Feature | SMART on FHIR ZAP embed | Mediar accessibility agent |
|---|---|---|
| Where it runs | Modern web EHRs that ship a SMART app launcher | Any Windows desktop EMR: Epic in Citrix, older Cerner, MEDITECH, eClinicalWorks |
| Needs the EMR to expose a launcher or API | Yes, requires SMART on FHIR support in the chart | No, it drives the existing UI through the accessibility tree |
| Writing data back into the chart | The ZAP is a viewer; re-keying into the chart stays manual | Types reconciled fields straight into the chart inputs |
| Login and session | Inherits the EMR SMART session, no separate credentials | Runs inside the clinician's already signed-in Windows session |
| Time to first workflow | Gated on EHR vendor integration approval | Days: watches the workflow once, then repeats it |
If your EMR supports a SMART on FHIR launcher, embedding the ZAP is the right call. Mediar is for the desktop charts that have no launcher and where aggregated data still ends up hand-keyed.
“A regional healthcare provider moved patient intake off manual transcription and onto a desktop agent, the exact kind of re-keying that a workflow ending in a 'ZAP login' tends to leave behind.”
Mediar deployment, regional healthcare
What to do with this
If you came here to find a login, the practical version is short. First, confirm whether your EMR supports a SMART on FHIR app launcher; if it does, ask your Zus contact to launch the ZAP from the chart and you are done, no extra password. If it does not, the ZAP can still be opened from the Zus dashboard, but you will be transcribing by hand unless you automate the last step.
That last step, getting reconciled data into a legacy desktop chart with no API, is the part Mediar handles, on Epic in Citrix, older Cerner and MEDITECH, eClinicalWorks, and similar systems.
Your chart has no ZAP launcher. Now what?
Book a call and we will look at your actual EMR, on Epic in Citrix or a legacy desktop build, and show how aggregated data gets keyed in without an API.
EMR ZAP login FAQ
Is there a standalone EMR ZAP login page or URL?
No. The ZAP (Zus Aggregated Profile) has no separate login screen. It opens embedded inside your EMR through a SMART on FHIR app launch, or as an iframe inside your own application, and to open it on its own you sign into the Zus dashboard. If you are hunting for an 'EMR ZAP' address with its own username and password, it does not exist; the ZAP inherits whatever session it launches from. Source: docs.zushealth.com/docs/accessing-the-zap, verified June 2026.
What does ZAP stand for?
ZAP is the Zus Aggregated Profile, Zus Health's reconciled, up-to-date record of a patient's history assembled from external data networks. Zus de-duplicates and normalizes the inputs into FHIR, with 600+ FHIR resources behind each profile.
How do clinicians authenticate to the ZAP?
Through the host system, not a dedicated ZAP login. A SMART on FHIR launch from the patient chart carries the EMR's session, so no extra sign-in is prompted. When the ZAP is embedded as an iframe in your own app, your application authenticates the user, with Zus documenting SSO through Google Workspace, Azure AD, and Okta.
Why can my colleague's EMR show the ZAP but mine cannot?
The deciding factor is whether your EMR ships a SMART on FHIR app launcher. Modern web EHRs do, so the ZAP drops in. Charts that run as Windows desktop apps, such as Epic published through Citrix, older Cerner builds, MEDITECH, or eClinicalWorks, often have no launcher to host the embed, so there is no in-chart ZAP button to click.
How do you get aggregated data into a chart that has no launcher or API?
A desktop agent reads the aggregated data through the Windows accessibility tree, the same interface a screen reader uses, then types it into the chart's input fields. No SMART launcher, no FHIR endpoint, and no vendor integration request are required, because the agent operates the EMR the way a person would.
Is the automation engine open source?
Yes. Mediar runs on Terminator, an MIT-licensed project written in Rust, published at github.com/mediar-ai/terminator and described as 'playwright for windows computer use.' It uses Windows UI Automation and the accessibility tree to locate elements by name and role, so teams can read the engine and extend it.
Does the agent store our EMR passwords?
No. It runs inside the clinician's existing signed-in Windows and EMR session and acts within that session, rather than holding a separate credential set. Mediar is SOC 2 Type II certified and HIPAA compliant, and can deploy on-prem or in the cloud.
Related reading
How to automate Epic in Citrix without VDA access
Why UI selectors do not cross the Citrix boundary, and how to drive Epic from the client side.
Member enrollment automation: the exception queue
The records that fall out of the 834 feed get hand-keyed. Here is how a desktop agent keys them in.
The legacy desktop apps with no API are the moat
Why the systems without an API are exactly where accessibility-tree automation earns its keep.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.