Encounter forms and phases
How services, forms, and phases work together — and why the encounter workspace looks the way it does.
Services in Light carry forms. Forms are structured records that capture everything that happens during a service delivery — vaccination details for AIR, consent for compliance, adverse reactions for clinical safety, follow-up responses for outcomes tracking.
Understanding how forms are phased, when they materialise, and what submission means makes the encounter workspace feel less mysterious.
Services carry forms; variants inherit them
Forms are attached to a service (not an offering, not a variant). When you create an offering for that service, the offering automatically inherits the form set. Variants can't override their parent's forms — if two variants need different forms, they probably need to be different services.
This is why the encounter workspace looks the same across every flu-vaccine variant: they all share the same service, so they all share the same forms.
Three phases
A service's forms are grouped into three phases, each with a distinct purpose:
- Intake — before the service happens. Consent, pre-screening, eligibility questions. Filled in when the customer arrives, or earlier if they've registered via a link or kiosk.
- Encounter — during the service. The main record of what was done. For vaccinations, this is where product, batch, dose, and route are captured. This is also where data destined for AIR is collected.
- Post-encounter — after the service. Outcomes, follow-up, patient-reported measures. Completed later — often days or weeks after the encounter itself.
The encounter workspace (the full-screen interface at /encounter/$serviceId) only shows Intake and Encounter forms. Post-encounter forms stay on the service detail page — you don't need the full workspace to fill them.
Why forms come to life late
When you open the encounter workspace, Light creates the form instances from the service's definition at that moment. Before that, they're placeholders — listed on the service so you can see what's coming, but not yet fillable.
This matters because the service's definition can change after the booking is made. If an Intake form is updated between the booking and the appointment, the customer gets the newer version — not a stale one baked in at booking time.
Once the form is opened, it's frozen against that version of the definition. Amending the service definition afterwards doesn't change the form instance; it only affects future encounters.
Submission is definitive
A submitted form is the record of what happened. Light treats submission as the point of truth:
- It's read-only afterwards. Changes require explicit amendment.
- It triggers downstream submissions. AIR submissions for vaccinations happen when the encounter form is submitted. Claims become eligible to submit.
- It's preserved in history. The service activity log captures the submission; later amendments are layered on top rather than replacing it.
The flip side: don't tap Complete until you're sure. A saved draft is easy to edit; a submitted form is a record you'll have to amend.
Why drafts exist
The workspace has both Save (draft) and Complete (submit) because encounter work is interrupted. Between customers, during stock checks, when the phone rings — staff need to park a half- filled form and come back later.
Drafts aren't shared across staff in any special way — anyone with access to the customer can pick up a draft. If two staff edit the same draft simultaneously, the last save wins; Light doesn't version drafts or warn about conflicts.
Highlighted fields
A field is highlighted when Light has something to tell you about it. You'll see this on encounter forms, pre-screeners, and anywhere else you fill something in.
| Highlight | What it means |
|---|---|
| Red | Needs your attention before you can finish |
| Blue | Light prefilled this information, please always double check! |
| Grey | Remembered from last time, like a pinned immuniser |
Red always wins – a field that needs attention shows red even if the value was filled in for you. Read-only fields aren't highlighted.
The side panels exist because context matters
Vaccination work needs the customer's immunisation history (did they have this dose already?), their identifiers (is their Medicare current?), and their notes (any relevant clinical context?). Pulling that information up mid-form means navigating away and losing the encounter workspace.
The right-rail panels bring context to the form rather than the other way around. They're a deliberate workflow choice — not decoration.
After submission, two worlds have to agree
For AIR-eligible vaccinations, the encounter form submission is a local event. The AIR submission is a separate event, asynchronous and subject to AIR's identity matching. A form submitted in Light may take a few minutes to appear in AIR, and may fail AIR validation for reasons that weren't visible in the form.
This is why the customer's immunisation history doesn't update instantly after you tap Complete — Light has recorded the encounter, but AIR hasn't yet accepted it.
If AIR rejects the record, the encounter stays in Light as the source of truth; you fix the underlying issue (identity, Medicare) and resubmit rather than recreating the encounter.