The customer record

The customer record is the centre of clinical and booking history in Light. Understanding how identity, identifiers, and multi-site context work helps you avoid duplicates and interpret what you see on the profile.

One customer, one record (per site)

A customer record lives at your site. If the same person visits a different pharmacy running Light, they have a separate record there. The two records aren't linked by Light – they're linked by the person's real-world identifiers (Medicare, IHI, date of birth), which is what AIR uses to unify their immunisation history.

This is intentional: your customer data is yours, and a pharmacy across town can't see your notes on a shared customer.

Identity vs identifiers

Two different things:

• Identity – what the person is called and contacted by: name, date of birth, email, mobile. Identity fields are editable at any time and used for search and day-to-day interaction.
• Identifiers – system numbers that tie the person to external registries: Medicare, IHI, DVA. These are what AIR, PPA, and PRODA use to find the person.

A record needs identity to be useful at your site. It needs identifiers to work with external systems. A customer without a Medicare number can still book and receive services – but their vaccinations can't be claimed under programs that require Medicare.

Why "last accessed" exists

The customer list shows when each record was last opened. This is a usage signal, not a clinical one – someone you opened yesterday is more likely to be the person you're looking for now than someone whose record hasn't been touched in three years.

It's also how duplicates reveal themselves: two similar records where one has recent activity and one doesn't suggests the dormant one is the duplicate.

No merge yet

Light doesn't have a customer-merge flow. If you discover a duplicate the recommendation is:

1. Pick the older record – it has more history attached
2. Transfer anything on the newer record that needs keeping (files, recent bookings)
3. Delete the newer record

AIR isn't affected – a person's immunisation history is unified by AIR's own identity matching, not by Light's records.

A proper merge flow is on the roadmap. Until it ships, the guidance above is the safest approach.

What Light doesn't hold

• The full medical record. Light holds immunisation encounters and customer-facing files, not a general medical history.
• AIR data itself. Immunisation history shown on the Immunisations tab is fetched from AIR; it isn't stored on the customer record. The record holds the customer's identity and identifiers that let AIR find them.
• A dispensing record of its own. Light doesn't keep native prescription data. Where your site connects a dispense system such as Minfos, a linked customer's dispense history is surfaced on the Dispense tab and kept up to date from that system. See Connecting your dispense system.

Deletion is permanent, but preserves external state

Deleting a customer removes the record at your site. It doesn't:

• Delete their AIR record
• Withdraw any submitted PPA or AIR claim
• Remove encounter records – those live on independently; if you later recreate the customer, the history re-appears via AIR

See Deleting a customer for the mechanics.