Offerings, variants, and services

The Services area uses three related words: service, offering, variant. They look interchangeable and often get used loosely in conversation, but in Light they're distinct. Getting them straight makes the rest of the area easier to navigate.

The three layers

• Service — the type of thing being delivered. "Flu vaccine." "COVID-19 vaccine." "Medication review." Services are the underlying catalogue; you don't create them day-to-day. They carry the data that's true regardless of who delivers it: AIR antigen codes, claimable programs, forms.

• Offering — the operationalised version — how your pharmacy delivers the service. An offering says: this is a flu vaccine, it's 15 minutes long, costs $25, takes place in Consultation Room A, between 9am and 12pm on weekdays. The offering is what customers book and what appears in your Services list.

• Variant — an offering that inherits from another offering. Same service, different rules. Flu vaccine — CVCP (funded) and Flu vaccine — private pay are two variants of the same service.

Why the distinction matters

Keeping services, offerings, and variants separate lets the platform do three things that would otherwise be painful:

1. Share service-level metadata

AIR antigen codes, form definitions, claim eligibility live on the service. They're the same for every offering that delivers it. When AIR updates a code, every offering using that service picks up the change automatically.

2. Let your pharmacy configure its own delivery

Two pharmacies running Light both offer flu vaccines, but one runs a drop-in clinic (15-minute slots, any room) and the other does appointment-only (20-minute slots, specific pharmacist). Both are "Flu vaccine" services with different offerings.

3. Keep variants in sync without duplication

A pharmacy might run ten flu-vaccine variants: adult, child, pregnant, Indigenous, over-65, aged-care resident, funded, private, and so on. All share the same duration and resource; they differ on price and claim program. Variants let you change the shared configuration in one place (the parent) and have it propagate.

Offering groups

An offering group is an offering that exists purely to hold its variants. The parent isn't directly bookable — its only purpose is to give the variants a common parent for inheritance and display.

This is useful when the "plain" version of a service doesn't really exist at your site. You offer CVCP-funded flu vaccines and private- pay flu vaccines but not an unqualified "flu vaccine" — so the parent is a group and the variants are the only bookable things.

The rule of thumb

• Same service + same delivery → one offering
• Same service + different delivery → parent offering + variants
• Different services → different offerings (even if they share resources and staff)

If you find yourself creating two offerings that share everything except a price, those should be variants. If you find yourself creating a variant whose configuration is entirely different from its parent, that's probably a separate offering.

Why variants aren't just tags

A tag on a booking could in principle mark "this one is CVCP" — but tags can't carry their own price, duration, or availability rules. The variant-and-parent model lets the configuration diverge cleanly when it needs to, and stay in sync when it doesn't.

What this means for the rest of the app

• Bookings are always against offerings (or variants). You never book a service directly.
• Claims know which program applies because the variant carries that information.
• AIR submissions know which antigen code to send because the service carries that.
• Forms attached to the service appear on every offering that delivers it, without per-offering configuration.

That's the shape of the model. In practice, most day-to-day work happens at the offering level — services and variants are there when you need them, invisible when you don't.