Send EHR Data From Your Data Warehouse

Use this page when your appointment, attendance, and revenue data already lands in a data warehouse or data lake and you want to use that as the source of record instead of building a separate EHR integration.

If your reaction to an EHR integration is "we already have all of this in Snowflake or Databricks, can you just pull it from there?", this is the page for you. The answer is yes, and this explains how the data moves. Snowflake, Databricks, BigQuery, Redshift, and data lake tables all work the same way here.

If your team has already modeled this data, this is usually the fastest path to measurement. The joins, deduplication, and business logic are done, and you are sending a clean result rather than raw clinical messages.

---

When This Is the Right Path

Choose the warehouse when:

• Appointment and revenue data already flows into Snowflake, Databricks, BigQuery, Redshift, or a data lake.
• Your analytics team already maintains models for visits, attendance, or recognized revenue.
• The outcomes you care about settle late, such as no-shows, insurance payments, and adjusted revenue.
• Direct EHR interface access would take months to obtain, but warehouse access already exists.

Choose a FHIR or HL7 connection instead when you need booking data in near real time, for example to optimize ad campaigns on appointment_booked. Warehouse pipelines usually run on a schedule, so they add latency that direct interfaces do not.

Many organizations use both: direct interfaces for fast booking signals, and the warehouse for settled attendance and revenue.

---

How the Connection Works

The warehouse is where your query runs and Ours Privacy is where the events land, so the flow is outbound from your side. Ours Privacy does not reach into your warehouse and query it.

1. Write a query that returns one row per outcome. Select the appointment, attendance, or revenue records you want to measure, along with the patient identifiers you authorize and the timestamp of the original action.
2. Schedule it. Use whatever already runs your pipelines: a warehouse task or scheduled query, a dbt job, an orchestrator such as Airflow or Dagster, or a reverse-ETL tool.
3. Send each row to the Ingest API as a standard healthcare event.
4. Track what you have already sent. Keep a watermark column or a sent-events table so a re-run does not resend the same rows.

Important: Send the timestamp of the original action, not the time your job ran. Back-dated records then land on the correct day, so a Tuesday appointment reported on Friday still shows up on Tuesday in your reports.

---

Handle Late and Repeated Data

Warehouse data changes after it first appears. Recognized revenue arrives in pieces as insurance and patient balances settle, and attendance can be corrected days later.

• Set a stable identifier on revenue events. Use a consistent $distinct_id so repeated sends of the same transaction do not double-count.
• Reuse one appointment_id from booking through completion and revenue so the lifecycle stays connected as a single journey.
• Prefer revenue_recognized over purchase for ledger revenue that settles over time. Use purchase for a payment captured at checkout.
• Send corrections as the current state. When a visit is reclassified from completed to no-show, send the corrected event rather than trying to retract the original.

---

What to Send From the Warehouse

Warehouse tables usually hold the full lifecycle, which makes them a good fit for the later stages of the patient journey:

• Completed visits: appointment_completed for attendance and show-rate analysis.
• Missed and cancelled appointments: appointment_no_show and appointment_cancelled for leakage analysis.
• Recognized revenue: revenue_recognized with value, currency, and revenue_type.
• Bookings, when the warehouse is your only source for them: appointment_booked.

Identify the patient with visitor properties rather than embedding identity in event properties, so warehouse outcomes match the same person's website activity. Keep protected health information out of event names and properties.

See Standard Healthcare Events for the full property list on each event.

---

Your Warehouse Can Also Be a Destination

These directions are independent. Ours Privacy can deliver processed event, dispatch, and visitor data back out to Snowflake, Databricks, and Google BigQuery.

Sending outcomes in and receiving joined data back gives your analytics team the marketing journey next to the clinical outcome in the same warehouse, which is the join that is normally missing between the two systems.

---

Next Steps

• Ingest API Integration: the endpoint your scheduled job calls.
• Standard Healthcare Events: event names and properties to send.
• Choose an EHR or PMS Connection Path: compare this against direct interface options.
• Visitor Identity and Matching: connect warehouse outcomes to website activity.
• Snowflake and Databricks: receive processed data back in your warehouse.