Monitor an outsourced claims service between formal reviews

A provider's monthly dashboard is green, but your claims team keeps chasing the same delayed cases. The dashboard may be accurate and still miss the problem: it might measure completed work while excluding cases that have never reached the completion queue.

Ongoing monitoring should help explain that difference. Its purpose is to connect signals with the service the insurer relies on, decide what needs attention and establish whether action worked.

CPS 230 requires monitoring and senior-management reporting on material arrangements, proportionate to the service. This article offers an original monitoring design for an outsourced claims service. It does not prescribe a universal review frequency or replace the insurer's risk framework.

Begin with the service promise

For a fictional private health insurer, Fern Health, an external provider performs part of claims processing. The insurer retains customer contact and oversight. All names, facts and events below are invented to illustrate the method.

Start with the service definition and agreed measures. Which claims enter the provider's workflow? When does the service clock begin? What pauses it? Which exceptions are excluded? Who validates the data supplied for reporting?

These details matter because two teams can use the same phrase, such as processing time, to describe different intervals. A supplier may measure the time after a case becomes complete, while customers experience the delay from first submission.

Keep both views if they answer different questions. Do not change the contract measure informally; add an operational measure where needed and make its purpose clear.

Choose a small set of connected signals

A lean team benefits from signals it can investigate. A long list that nobody understands creates work without improving decisions.

For Fern Health, a suggested starting set is:

• Agreed service performance, including exceptions and how the figures were calculated.
• Age and volume of unresolved work, separated by meaningful case type.
• Incidents and near misses affecting the supplied service.
• Changes to systems, people, controls or subcontractors that could alter service delivery.
• Remediation actions that are overdue or have not been independently checked.
• Customer-contact themes that may reveal failures outside the supplier's dashboard.

This is an editorial selection, not an APRA reporting template. Adapt it to the actual allocation of work and the consequences of delay.

APRA's CPG 230 guidance discusses periodic reviews that consider operational issues, control effectiveness, security, continuity and strategic changes. A practical monitoring design uses those areas to ask service-specific questions, rather than treating each as a document to collect once.

Separate an alert from a finding

Fern Health receives several internal escalations about claims waiting for missing information. The supplier report still shows performance within the agreed measure.

The first step is verification. The service owner checks whether the escalations concern the same provider workflow, whether the cases are still open and whether the delay was caused by the supplier, the insurer, missing customer information or a combination.

Use approved access to the records needed for that check. Keep personal claims details out of broad monitoring reports when an aggregated or de-identified explanation will do.

The review finds a specific pattern: requests for further information were generated, but a subset did not reach the insurer's customer-contact queue. The supplier's completion metric excludes those cases because they remain incomplete. This is an invented control failure, not a claim about any real provider.

Now the signal supports a finding. The dashboard was answering a narrower question than the insurer needed, and a handoff failure was leaving work unowned.

Set triggers with actions attached

A trigger is useful when the team knows what happens next. Choose thresholds and escalation timing according to the insurer's approved tolerances, service obligations and risk appetite. Do not copy numerical limits from another organisation's example.

A simple working matrix can use these categories:

Unverified concern: a credible alert lacks enough service detail. The service owner checks scope and current status, records unknowns and sets a time for the next update.

Recurring service exception: verified cases show a pattern. Operations and the provider investigate the cause, identify affected work and agree containment.

Control failure or widening impact: the pattern suggests a control is ineffective or customer consequences are increasing. Risk and incident owners assess escalation, senior-management reporting and any notification obligations.

Overdue or ineffective remediation: the promised fix is late or fails its acceptance test. The decision-maker reviews residual exposure, interim measures and the next contractual or operational step.

These categories do not replace urgent escalation. If facts indicate serious impact, the team should use its incident process immediately rather than wait for the next monitoring meeting.

Ask for a fix that reaches the affected work

In Fern Health's example, the supplier proposes changing the interface that sends information requests. That addresses future messages but leaves historical cases unresolved.

The insurer asks for two linked workstreams. The technical owner corrects and tests the interface. Operations identifies the affected cases, confirms which requests were delivered and assigns outstanding work to the right queue.

A useful action record contains the failure, the affected scope, the immediate containment, the proposed fix, the accountable owners and the evidence required for closure. It also identifies any dependency on the insurer's own staff or systems.

Avoid writing “supplier to resolve” where the insurer must change its receiving process. An outsourced service can have a shared failure, and monitoring should make both parties' actions visible.

Verify closure over the relevant workflow

The supplier reports that the interface change is deployed. Fern Health does not close the issue solely on that statement.

First, the team checks that synthetic information requests reach the expected queue and carry usable references. Next, it verifies the treatment of affected historical cases. Finally, it observes the relevant live process through approved monitoring to see whether the recurring exception returns.

The observation period should match the frequency and risk of the workflow. A process that runs monthly cannot be meaningfully assessed using only a quiet afternoon after deployment. Record the limits of the check and any residual uncertainty.

If the result fails, reopen or retain the action with a clear explanation. A status change should follow evidence, not the date promised in a meeting.

Report the decision, not every alert

Senior management needs to understand what changed, what it means for the service, what remains unresolved and what decision is required. A report containing every incoming signal can hide those points.

For Fern Health, the concise report explains the missed handoff, the affected workflow, containment, the status of historical cases and the evidence still needed for closure. It also shows the revised monitoring measure that will expose incomplete cases waiting without an owner.

Keep the supporting evidence accessible for challenge. The CPS 230 evidence checklist provides a related way to organise sources, gaps and decisions.

Take unresolved findings into remediation closure and use the board-report guide when a service concern requires a decision above the operating team.

Start with one green metric that operational staff distrust. Ask what it includes, what it excludes and which customer work could remain invisible. That conversation is often more useful than adding another dashboard.