The Challenge

When a lifesaver performs a rescue or treats an injury, that incident has to be recorded — not just locally, but in Surf Life Saving's national incident database, the system of record used for reporting, research and funding across the whole organisation.

That database is authoritative, long-established, and speaks SOAP. It also enforces a controlled clinical vocabulary: an incident is not free text, it is a structured record referencing more than a dozen reference tables — activity type, body part, contributing factor, nature of injury, referral, resuscitation performed, service provided, treatment given, who treated, incident type, casualty nationality, casualty status.

Volunteers on a beach cannot be asked to know any of that. They need to record what happened, quickly, on a phone, often one-handed and often wet.

The gap between those two realities is the project.

The Solution

The incident layer of the SLSA Operations platform does two jobs at once: it gives the lifesaver a fast, field-appropriate reporting flow, and it translates what they entered into a valid national incident record.

Mirroring the system of record

The national database's schema is mirrored in the application as a dedicated set of remote models — one per reference table — so the controlled vocabulary lives in code where it can be validated, cached and presented as sensible choices rather than as raw codes. Seventeen of these mirror models cover the incident record and its full reference vocabulary.

That means validation happens before submission. A report that would be rejected by the national system fails in the app, where the lifesaver can still fix it, instead of failing silently hours later.

Talking to a SOAP system from a modern app

Integration runs through a dedicated SOAP client, wrapped in its own service so the rest of the application never deals with the transport. Alongside it, an HTTP integration layer handles the organisation's newer REST endpoints — so the platform speaks both generations of API at once, which is the practical reality of integrating with any long-lived institutional system.

Radio room and field, reconciled

Incidents do not only arrive from the beach. The SurfCom radio room logs incidents too, with its own types and its own confirmation workflow. Both paths are modelled, so an incident radioed in and an incident recorded on the sand end up as one coherent record rather than two competing ones.

Built for the audit trail

Every API interaction is logged with its activity recorded, so when a report is queried weeks later — by a researcher, an insurer or a coroner — there is a defensible trail of exactly what was submitted and when.

The Results

Years of continuous national incident reporting through the platform, into the system of record rather than alongside it
Over 11 million audit-trail entries, so any record's history is reconstructable years later
More than 400,000 logged API calls to the national systems, each with sensitive fields masked
Field-appropriate reporting that still produces a fully structured national incident record
A dozen-plus reference vocabularies mirrored, validated and presented as choices instead of codes
Two API generations bridged — SOAP for the system of record, REST for newer services
Radio-room and beach reports reconciled into a single incident model

What that means commercially

Every incident recorded is a chance to produce a document that a coroner, an insurer or a researcher will later rely on. The value of this integration is that a volunteer who has just performed CPR cannot accidentally file something the national database will reject, and that eleven million audit entries stand behind every record if anyone asks how it got there.

This is also the pattern we reuse for any client sitting on an institutional system of record: don't replace it, don't work around it, put a humane interface in front of it and validate before you submit.

Technology

Laravel with remote models mirroring the national incident schema, a purpose-built SOAP client for the system of record, and a Saloon-based HTTP layer for REST services. Incident and reference data cached locally for offline-tolerant field use, with request-level activity logging across every integration. Delivered as part of the wider Operations platform.

See also: SLSA Operations App — the field platform this sits inside, and SLSA API Integration Layer — the reusable client behind the REST half.

Related Nano Solutions services: Systems Integration · App Security · Software Development. WA government agencies can engage us directly through our CUAICTS2021 panel listing.