How integrations work

Light integrates with three Commonwealth systems that, together, make clinical services claimable and compliant. They're related but separately configured — and understanding the dependencies helps avoid situations where things should work but don't.

Three systems, two configurations

• PRODA — Provider Digital Access, run by Services Australia. The authentication layer. PRODA doesn't itself receive clinical data; it issues and manages the digital credentials other systems require.
• AIR — Australian Immunisation Register, the clinical record system. Receives vaccination data. Depends on PRODA for authentication.
• PPA — Pharmacy Programs Administrator, the claims system. Receives claims for funded programs (CVCP, NIPVIP, MedsCheck). Separate from PRODA/AIR.

In Light, PRODA and AIR appear as one card (AIR via PRODA) because PRODA is configured in service of AIR. PPA is a separate card with its own credentials.

The setup chain

The order matters:

1. PRODA device activation — Activates credentials that AIR uses. At this point the device is registered but AIR access is still pending.
2. HW027 submission — The Online Claiming Provider Agreement. Once Services Australia processes it, AIR access becomes live.
3. PPA connection — Independent of PRODA. User ID + API Key from the PPA Portal.

Until step 2 is complete, AIR submissions queue and fail with authorisation errors. Until step 3, PPA claims can be prepared but not submitted.

Who gets data

Every action in Light touches a subset of these systems:

PRODA never sees clinical data directly — it authenticates the request, then AIR handles it.

Why PPA is separate

A claim to PPA can fail even when AIR is working fine. PPA has its own eligibility rules (cohort, program, date window) separate from AIR's clinical recording. Having them as separate integrations makes that clear:

• An AIR rejection means the record wasn't accepted clinically
• A PPA rejection means the claim wasn't accepted financially

Both can happen independently. Fixing one doesn't automatically fix the other.

The role of the API Key

PPA's API Key is shared at the site level, not per-user. If your pharmacy runs two systems that both claim through PPA — say, Light and a dispensing system — they share the same key. Regenerating the key in the PPA Portal invalidates it everywhere until the new key is entered in every system that uses it.

This is why the PPA setup sheet warns you to update the key in all platforms at the same time. It's the most common cause of silently broken PPA integration.

State and other integrations

Some jurisdictions have their own integrations (e.g. QLD Free Flu is administered as a PPA program, not a separate state integration). No direct state-health-authority integrations exist in Light today — everything flows through the federal systems or through a PPA program that targets a state scheme.

Disconnection is rarely the right fix

When things go wrong, the temptation is to disconnect and reconnect. This almost never helps — most issues are authentication (update credentials), not structural (reregister from scratch). Disconnection loses your configuration history; reconnection requires redoing the whole setup chain.

Prefer:

• Update API Key on PPA
• Reactivate Device on PRODA
• Edit Credentials on PRODA (for provider-number or org-ID changes)

These preserve the existing relationship while refreshing the part that's broken.

Compliance implications

Integrations aren't optional for clinical work. Recording a vaccination without AIR submission is non-compliant; submitting a funded-program claim without valid PPA connection simply fails. Keeping integrations healthy is a pharmacy-owner obligation — the Integrations page is where you watch for warnings and act on them before they disrupt operations.