Five disciplines for systems members rely on

Most of our extras claims are settled while the member is still standing at a dentist's, physiotherapist's or optometrist's counter. That gives the claims engine seconds to confirm membership, check waiting periods, apply annual limits and return a benefit. I design for that moment from the member's side, because an unclear decline at a counter can feel like a lapsed policy. Hospital claims run differently, with eligibility checks before admission and accounts that arrive weeks later. I keep the two paths separate in our architecture so that a fault in one does not silently stop the other. Benefit rules remain the decision of our product and claims executives. My team's responsibility is that the system applies those rules exactly as approved, explains a decline in plain words and leaves a record a claims officer can follow.

I assume that a capable attacker may eventually reach some part of our environment, and I plan for the decisions that would follow. Under the notifiable data breaches scheme, an organisation that suspects an eligible breach must assess it promptly and notify affected people and Australia's Information Commissioner when serious harm is likely. Those decisions belong to the chief executive, with legal and privacy advice, but they depend on facts my team must supply quickly: which systems, which records, which people. Twice a year we rehearse with the executive team, including how we would contact members whose health information had been taken. Our board settled its position on ransom payment in advance, so that a frightening week would not be the first time directors discussed it. I report the gaps each exercise reveals, not merely that it took place.

A record that no longer serves a member or a legal obligation is exposure rather than an asset. I ask every system owner to state what personal information the system holds, why, and when it should be destroyed or de-identified. Health information, Medicare numbers and bank details receive the closest attention because their misuse causes the greatest harm. The difficult cases are rarely technical. Actuaries value long claims histories, and member services needs proof of earlier cover for people who return. We meet those needs with the minimum identifiable data and with de-identified histories where possible, accepting that some analysis becomes harder. Retention is now a design requirement for new systems. Backups, analytical copies and supplier test environments are included, because our 2023 programme found identifiable data in places our main inventory had not listed.

Our critical operations rely on organisations we do not control: the network that carries point-of-service claims, the banks that collect premiums and the provider that hosts our core systems. APRA's operational risk management standard asks us to understand those dependencies and to remain within stated tolerances when one of them fails. I treat a tolerance as a commitment to members that must be tested, not a number chosen to complete a template. For each critical operation we document the degraded service we would offer, how quickly it starts and who may invoke it. Contracts with material service providers now include joint testing and information rights, which some suppliers initially resisted. I would rather show our board a modest tolerance we have met in practice than an ambitious one we have only simulated.

I use machine learning and language models where their errors can be caught before they reach a member. At present that means drafting call summaries, suggesting answers to cover questions that consultants confirm and sorting incoming correspondence. It does not mean deciding a claim, setting a premium or declining a request. A language model can state an incorrect waiting period with complete fluency, and the person who hears it may book treatment before anyone notices. Each use therefore has a named business owner, an error measure reviewed monthly and a way to switch it off within the hour. The Privacy Act's coming transparency requirements for automated decisions reinforce a habit we already keep: describing where software contributes to a decision about a person, in words that person could follow.