Standard Healthcare Events

Track these events in Ours Privacy and you get one clean, semantic naming convention for the whole patient journey: a new inquiry, a booked appointment, whether the patient showed, the calls in between, and the revenue that follows. We recommend adopting them as your standard event names so every source, team, and destination refers to the same things the same way.

The names are what make reporting work without setup. Attribution and Web Analytics already recognize this schema, so funnels, conversion rates, revenue, and multi-touch attribution compute the moment the events arrive. Use your own naming instead and each report has to be mapped by hand; send appointment_booked and revenue_recognized and the patient-acquisition reports run against them directly.

Already tracking custom events? You can keep your existing event names and use the event renaming feature to normalize them to the standard names before they reach a destination or report. Adopting the schema is recommended, not required.

How to send these events

You send standard events the same way you send any event to Ours Privacy. Pick the path that matches who is doing the work:

• No code: build a tag in the Tag Manager to fire these events from your site.
• Website code: call the Web SDK with ours('track', 'appointment_booked', { ... }).
• Backend, EHR, or PMS: post events from your server with the Server-to-Server API, or connect a managed source.

Before an event reaches a destination, add its name to that destination's event allow list. Use test mode to confirm events arrive correctly before sending real data.

Events

The journey runs through four stages: acquisition, booking, attendance, and revenue. Track the events that apply to you. Event names are lowercase snake_case, read object first (for example appointment_booked).

Every property is optional (events are never rejected for a missing one), but the grade shows how much the standard reports lean on it. Highly recommended links the patient journey or makes the event meaningful; Recommended powers the standard dashboards; Optional enables deeper breakdowns by site or provider.

You never add attribution or identity properties yourself. Ours Privacy captures the full attribution block (UTMs, gclid, fbclid, and more; see Understanding Events) on every event, and patient identity (name, email, phone, date of birth) travels as visitor properties so it stays consistent across the journey. From a server, EHR, or PMS, identify the patient with those same visitor properties and send the time the action occurred, so back-dated records land on the right day. See the Server-to-Server API.

lead_captured

A new inquiry: a phone call, web form, or online booking request. A "Schedule" button click or the start of a booking flow counts here as intent, not as a booked appointment, so your booked count stays clean.

call_tracked

An inbound call logged with its outcome and source. A tracked call is also a lead. When you have call detail, send call_tracked and don't also fire lead_captured for the same call, or it counts twice.

new_patient_created

A first-time patient record is created. This is the standalone version of the is_new_patient flag. Pick one as your new-patient signal so the same patient is not counted twice.

appointment_booked

An appointment is confirmed on the schedule.

appointment_confirmed

The patient confirms an upcoming appointment. An optional funnel step between booked and completed.

appointment_rescheduled

A booked appointment moves to a new time or provider. Send this with the original appointment_id rather than cancelling and rebooking, so the journey stays linked.

appointment_completed

The patient attended (showed). For telehealth, send this when an online intake or video visit is finished.

appointment_no_show

A booked appointment was missed.

appointment_cancelled

A booked appointment was cancelled and not replaced. If it was moved instead, send appointment_rescheduled.

purchase

A payment captured at checkout or point of sale. This is the GA4-aligned conversion ad platforms optimize on; if you only send one revenue event, send this. When forwarding to GA4 or Google Ads, keep the name purchase and rename lead_captured to GA4's generate_lead with event renaming.

revenue_recognized

Revenue attributed to a patient or appointment in your PMS or ledger. It often lands later and in pieces (insurance, balance payments). To keep repeated sends of the same transaction from double-counting, set a stable $distinct_id on the event.

Examples

A new patient books online after arriving from a Google Ads campaign:

ours('track', 'appointment_booked', {
  appointment_id: 'appt_8f21',
  service_line: 'ortho',
  is_new_patient: true,
  booking_channel: 'online',
  provider_id: 'dr_chen',
  location_id: 'austin_north',
});

An inbound call that did not convert:

ours('track', 'call_tracked', {
  call_outcome: 'not_booked',
  call_duration_s: 142,
  service_line: 'cosmetic',
  is_new_patient: true,
  staff_id: 'front_desk_02',
});

Revenue captured at checkout:

ours('track', 'purchase', {
  value: 2400,
  currency: 'USD',
  appointment_id: 'appt_8f21',
  service_line: 'implants',
});

A telehealth intake completion, with no physical location:

ours('track', 'appointment_completed', {
  appointment_id: 'visit_5523',
  service_line: 'primary_care',
  is_new_patient: false,
});

Fits your practice setup

The schema works as-is for the most common setups:

• Multi-location groups (dental and medical groups, hospital systems): set location_id and provider_id on every event to break reporting down by site and provider.
• Single-location practices: omit location_id. Everything else works the same.
• Digital health and telehealth: omit location_id and track visits or intakes through the appointment_* events. Send appointment_completed when an online intake or video visit is finished.

This schema is built for HIPAA-regulated workflows. Keep protected health information out of event names, and send patient identity as visitor properties so it is handled through identity matching rather than embedded in event data.

Next Steps

• Understanding Events: how events, properties, and the dispatch flow work
• Visitor Properties: where patient identity belongs
• Allow Listing Events: add these event names to a destination's allow list
• Sources Overview: connect a website, server, or EHR/PMS source