EHR and PMS Support Matrix
Find how your EHR or practice-management system connects to Ours Privacy, including Epic, Cerner, athenahealth, eClinicalWorks, Curve Dental, CareCloud, Raintree, and how to request a system that is not listed.
Use this page to find how your EHR or practice-management system connects to Ours Privacy, and what to do if it is not listed.
The short answer for almost every system: if it exposes FHIR, HL7, an API, or a reporting feed, it can connect. The mechanism varies, and so does the effort, so the tables below give you the realistic path and timeline rather than a yes or no.
How to Read This Page
Connection mechanisms, from least to most effort:
- Dedicated source. A prebuilt source you configure in the dashboard. No engineering work.
- Webhook. The system posts activity to a webhook source URL. Configuration, not development.
- FHIR or HL7 interface. The standard healthcare interoperability route, and the primary path for clinical systems. Requires interface access from your EHR environment, which your EHR team or vendor grants.
- API or backend integration. Your team calls the system's API and sends outcomes through the Ingest API.
- Warehouse or reporting feed. The data already lands somewhere you can query. See Send EHR Data From Your Data Warehouse.
- Automation layer. A HIPAA-compliant automation platform such as Keragon bridges systems with no direct outbound path.
Important: The EHR name alone does not determine the mechanism. Two organizations on the same EHR can expose different interfaces, fields, event types, and permissions depending on their deployment, version, and vendor agreement. Treat this page as the starting point for a scoping conversation, not a guarantee about your specific environment.
Systems You Can Connect Today
These have documented setup you can follow now. The mechanism differs, and it is worth knowing which you are getting: a dedicated source receives data server-side from the platform, so it keeps working whether or not the patient's browser is involved. Web SDK or Tag Manager tracking runs in the patient's browser on pages that platform serves, which is the right tool for booking flows you host but will not capture activity that happens entirely inside the platform's backend.
| System | Category | How it connects |
|---|---|---|
| Healthie | Virtual care practice management | Dedicated source, server-side webhooks. Healthie |
| NexHealth | Patient scheduling and engagement | Webhook for appointment outcomes, plus Web SDK or Tag Manager for the booking funnel. NexHealth |
| Yosi | Patient intake and scheduling | Web SDK or Tag Manager. Yosi |
| Loyal Health | Patient engagement and scheduling | Web SDK or Tag Manager. Loyal Health |
| Tellescope | Patient engagement and CRM | Web SDK or Tag Manager. Tellescope |
For any system on this page that is not in this table, the connection is built per organization. That is normal for EHR work and is what the rest of this page covers.
Enterprise and Ambulatory EHRs
These connect through standard healthcare interoperability interfaces. Access is granted from your EHR environment, so involve your EHR or IT team early and plan for a longer timeline than a webhook.
| System | Typical mechanism | What to know |
|---|---|---|
| Epic | FHIR or HL7 interface | Broad FHIR support. Which resources you can read depends on what your organization enables, so confirm appointment and encounter access with your Epic team. See Choose an EHR or PMS Connection Path. |
| Epic MyChart | Warehouse or reporting feed | MyChart bookings happen outside your website and are not generally pushed outbound for marketing use. The practical route is the appointment record once it reaches a reportable system. Expect batch timing. |
| Epic open scheduling | FHIR interface, or automation layer | Conversion capture for open scheduling depends on interface access in your Epic environment. Scope this with your Epic team before committing to a launch date. |
| Oracle Health (Cerner) | FHIR or HL7 interface | Oracle Health, formerly Cerner and often called Cerner Millennium, supports standards-based interoperability. Available resources and authorization vary by deployment and vendor agreement. |
| athenahealth | FHIR, HL7, or API | Commonly exposes appointment and billing activity. Confirm which endpoints your agreement includes. Worth knowing before you scope: athenahealth's built-in webhooks are deliberately minimal and generally carry an event name and ID without patient identifiers, so they alone will not connect an appointment back to the ad click that produced it. Plan on the FHIR or API route when attribution is the goal. |
| eClinicalWorks / Healow | HL7 interface or API | Interface availability varies by hosting and contract. Confirm with your eClinicalWorks representative what outbound access exists. |
| Veradigm (Allscripts) / MyEvolve | HL7 interface or API | Long-tail deployments differ substantially. A warehouse or reporting feed is often the faster route if one already exists. |
| CareCloud | API or HL7 interface | Confirm appointment and revenue endpoint access for your plan. |
Specialty and Vertical Systems
Specialty platforms are more likely to require a partner program, an API agreement, or a reporting feed. The path is usually available; the gating factor is typically the vendor's access process rather than the technology.
| System | Typical mechanism | What to know |
|---|---|---|
| Curve Dental | API, subject to vendor partner program | Integration access typically runs through the vendor's partner program, which affects timeline. A warehouse or reporting feed is often faster if one exists. |
| NexTech | API or reporting feed | Common in aesthetics and ophthalmology. Confirm appointment and revenue access. |
| Raintree | API or reporting feed | Common in therapy and rehab. Interface access is deployment-specific. |
| IntakeQ / PracticeQ | Webhook or API | Supports outbound notifications, which usually makes this a configuration task. |
| Zenoti | Webhook | Frequently the system of record for both bookings and payments, so it can send booking and revenue outcomes. See Connect Any Patient Scheduling Platform. |
| OpenLoop | API or Ingest API | Telehealth enablement. Connect through your backend or an automation layer. |
| SmartCare | API or reporting feed | Behavioral health EHR. Interface access is deployment-specific. |
| CarePortals | API or webhook | Confirm which outbound options your deployment offers. |
| Relatient | Webhook | Self-scheduling activity is webhook-based. See Connect Any Patient Scheduling Platform. |
Other systems by vertical
Asked about often enough to list. The mechanism depends on your specific deployment and agreement, so the middle column is where to look first rather than a commitment. Your account representative can confirm before you plan a timeline.
| System | Usual starting point | Vertical |
|---|---|---|
| NextGen Healthcare | FHIR, HL7, or reporting feed | Ambulatory and specialty |
| AdvancedMD | API or reporting feed | Ambulatory and specialty |
| Practice Fusion | API or reporting feed | Small ambulatory practice |
| Tebra (Kareo) | API or warehouse feed | Independent practice management |
| DrChrono | API or automation layer | Ambulatory and specialty |
| ModMed (Modernizing Medicine) | API, subject to vendor partner program | Dermatology, ophthalmology, orthopedics |
| Elation Health | API or automation layer | Primary care |
| Canvas Medical | FHIR interface or webhook | Primary and virtual care |
| Denticon | API or reporting feed | Dental, multi-location |
| Dentrix | Reporting feed or warehouse | Dental |
| Eaglesoft | Reporting feed or warehouse | Dental |
| Open Dental | Database or reporting feed | Dental |
| Dolphin | Reporting feed or warehouse | Orthodontics |
| Sycle | Scheduled export to the Ingest API | Audiology |
| SimplePractice | Automation layer or Ingest API | Behavioral health |
| Athelas / Commure | API or reporting feed | Revenue cycle and virtual care |
Note: Dental systems are frequently on-premise, which makes a warehouse or reporting feed the realistic path rather than a live interface. If your data already lands somewhere queryable, Send EHR Data From Your Data Warehouse is usually the fastest route.
If Your System Is Not Listed
Not being listed says nothing about whether you can connect. It usually means no customer has asked yet.
Work through these in order:
- Check whether it exposes FHIR or HL7. Most clinical systems do, and that is the primary path. See Choose an EHR or PMS Connection Path.
- Check whether it can send webhooks. If it can post a notification anywhere, it can post to a webhook source. This is the fastest route when available.
- Check where the data already lands. If appointments and revenue already flow to a warehouse or data lake, that is often the fastest path of all, because the modeling work is done. See Send EHR Data From Your Data Warehouse.
- Check whether your team can call its API. If so, your backend can send outcomes through the Ingest API.
- Request it. If none of the above applies, submit an integration request below.
Request an Integration
Contact your account representative, or email support@oursprivacy.com, with the following. Requests are tracked, and the details below are what make a request actionable rather than a name on a list.
- The system name, vendor, and deployment. Cloud or self-hosted, and the version if you know it.
- The integration methods it exposes. FHIR, HL7, API, webhooks, scheduled exports, or none that you know of. A link to the vendor's developer or API documentation helps most.
- The outcomes you want to measure. Bookings, attendance, no-shows, revenue, or others.
- The identifier available on those records. Email, phone, or your own patient or lead ID. This is what connects backend outcomes to website activity.
- Whether you already have interface access, or would need to request it from the vendor.
- Whether the data already lands in a warehouse or data lake.
- Whether you need write-back into the EHR. This is a separate use case from bringing EHR data in for measurement, and is scoped with its own data flow and permissions.
What happens next: the request is assessed against the methods your system exposes and the outcomes you need. In many cases an existing path already covers it, and the answer is a configuration plan rather than a build. When a new connection is genuinely required, the request is tracked and scoped with a timeline.
What You Get Once Connected
Regardless of mechanism, connected activity maps to Standard Healthcare Events, so the same reporting works across every system:
One setup step worth knowing about: the mapping to standard event names is something you configure, not something that happens by itself. A source sends its own payload shape, and you map it to
appointment_booked,appointment_no_show, and the rest through Data Mapping or event renaming. It is worth doing during setup, because the standard patient-acquisition reports run against those names directly.
- Attribution connects appointments and revenue to campaigns and channels.
- Conversions and Funnels shows booking and attendance drop-off.
- Visitor Identity and Matching links backend outcomes to the patient's web journey.
- Allow Listing Events and Data Mapping control what reaches each destination.
Next Steps
- Choose an EHR or PMS Connection Path: compare the available routes in detail.
- EHR and PMS Integrations: how the measurement flow works end to end.
- Send EHR Data From Your Data Warehouse: use an existing warehouse as the source.
- Connect Any Patient Scheduling Platform: connect the booking surface patients actually touch.
- Standard Healthcare Events: the event contract every path maps to.
How is this guide?