Praxi Medicare Incident Response (SA-facing one-pager)
This is the one-page reference Praxi uses to operate within Services Australia's Interface Agreement 2020 v2.1 incident-notification SLAs. It accompanies the Software Product Description, the Security Architecture, and the Privacy Impact Assessment for inclusion in Praxi's Notice of Integration (NOI) submission and as ongoing compliance evidence.
It is also the canonical document a Praxi on-call engineer should open when a Medicare-relevant incident is detected, with runbook pointers for the common failure modes.
Scope
This document covers Medicare-related incidents — incidents that affect the integrity, availability, or confidentiality of Praxi's Services Australia integration. Examples in scope:
- PRODA credential compromise or suspected compromise.
- MCOL claim-data leak (Medicare card numbers, IRN, IHI, DVA file numbers, claim payloads).
- Praxi outage that prevents tenants from submitting claims.
- Data-quality issue that causes incorrect claims to be submitted to Services Australia.
- Failure of the audit trail, the claim-submission pipeline, or the SA-report polling cron.
Out of scope (handled by adjacent runbooks):
- Praxi-wide outage affecting non-Medicare features only — handled by general incident response in Praxi's general incident-response policy.
- Own-PRODA account issues caused by the practice’s conduct are handled with the practice and SA. Shared platform credential incidents remain Praxi’s responsibility and may affect several practices.
- Service Australia upstream outage with no Praxi-side cause — handled by status page monitoring and tenant communication.
Notification SLAs
Under Interface Agreement 2020 v2.1 and the Privacy Act 1988 / OAIC Notifiable Data Breach scheme:
| Trigger | Notification deadline | Recipient |
|---|---|---|
| Cyber incident affecting Services Australia data | 12 hours from detection | SA Developer Liaison (developerliaison@servicesaustralia.gov.au) |
| Data breach involving Services Australia programme data | 2 business days from detection (deadline skips weekends and public holidays) | SA Developer Liaison (developerliaison@servicesaustralia.gov.au) |
| Notifiable Data Breach (OAIC scheme) — likely to result in serious harm | 3 business days for draft notification; 30 days final | OAIC + affected individuals (via the practice as primary APP entity) |
| Service outage affecting claim submission | Before close of next business day; as soon as practicable | SA Developer Liaison + affected tenants |
| Material change to security posture (e.g. new subprocessor, region change, auth-mechanism change) | Before the change takes effect | SA Developer Liaison + tenants per SaaS Agreement |
| Privacy incident affecting a tenant's clients | As soon as practicable; within 24 hours for actual breach | Affected tenant; the tenant then notifies their clients per APP |
| AHPRA-related professional conduct issue surfaced via Medicare audit trail | Per tenant policy (Praxi notifies the tenant; tenant decides on AHPRA notification) | Tenant practice owner |
The clock starts on detection, not on incident occurrence. Detection is when a Praxi-side signal (auth-failure monitor, claim-reconciliation cron, audit alert, internal report) or an external signal (tenant report, SA Developer Liaison communication, OAIC inquiry) makes Praxi aware of the incident.
Internal escalation chain
The escalation chain for a Medicare incident is, in order:
- First responder — whoever detected the incident. Could be a tenant, a Praxi engineer, an automated alert, or an SA-side communication. The first responder pages Praxi support.
- Praxi support agent — triages the incident, opens an internal incident ticket, gathers initial evidence, escalates to ops engineer on call.
- Praxi ops engineer on call — confirms whether the incident is in scope of this runbook, begins containment, opens an incident channel, drafts the SA notification if the 12-hour trigger applies, and tags in the founder.
- Founder / Privacy Officer — signs off on the SA-facing notification, oversees the OAIC notifiable-breach assessment, makes the final call on tenant communication.
Praxi's on-call rotation is currently solo-founder during the pre-first-hire phase. The escalation chain above reflects the target topology; during the solo phase the founder fills every role and the 12-hour SLA is met by direct action.
External escalation contacts
| Contact | Channel | SLA |
|---|---|---|
| SA Developer Liaison | developerliaison@servicesaustralia.gov.au | 2 business days (Interface Agreement 2020 v2.1) |
| OTS Helpdesk (Online Technical Support) | 1300 550 115 | Business hours |
| OAIC (Notifiable Data Breach) | https://www.oaic.gov.au/notify | Statutory — 30 days final, 3 business days draft |
| AHPRA (professional conduct angle) | https://www.ahpra.gov.au/notifications | Per AHPRA policy |
| AWS Trust & Safety | https://aws.amazon.com/forms/abuse-report | Per AWS terms |
| Australian Cyber Security Centre (ACSC) | https://www.cyber.gov.au/report | Voluntary report; recommended for material cyber incidents |
Notification template
SA Developer Liaison expects the following fields in an incident notification. Praxi pre-fills as much as possible from the audit trail.
SUBJECT: [Praxi - {SEVERITY}] {Brief one-line summary} - {Incident reference}
To: developerliaison@servicesaustralia.gov.au
CC: itest@servicesaustralia.gov.au, (Praxi internal incident channel)
1. Incident reference: PRX-INC-{YYYY}{MM}{DD}-{seq}
2. Severity: (Critical / High / Medium / Low)
3. Detection date/time: YYYY-MM-DD HH:MM AEST - (system or party that detected)
4. Incident date/time: YYYY-MM-DD HH:MM AEST - (or "unknown, suspected since...")
5. Affected tenants: (count; do not list practice names unless SA requests)
6. Affected patients: (count; never patient identifiers in the initial notification)
7. Affected Medicare claims: (count; SA claimId reference list available on request)
8. Brief description: (3-5 sentences. What happened, what data was affected, the
integration channel involved, and the current status.)
9. Root cause: (One paragraph; "under investigation" is acceptable at notification
time if root cause has not yet been determined.)
10. Containment steps taken: (Bullet list. Specific actions, with timestamps.)
11. Remediation in progress: (Bullet list. What Praxi is doing now and the next step's ETA.)
12. Preventive measures: (To be completed at PIR; can be "to be determined at PIR" at
initial notification.)
13. Praxi contact: Peter Hanley, Founder & CTO (Privacy Officer)
hey@praxi.au
14. Next update: (Specific time, never "as soon as we know more".)
A worked example template lives in Annex A of Praxi's data-breach-response plan. The template is filled in real-time during the incident and sent in plain text — not as an attachment — so SA Developer Liaison can paste it directly into their incident-tracking tool.
Common incident types and runbook pointers
The following lookup table is the on-call engineer's first-pass triage. Each row links to the runbook with the step-by-step procedure.
Platform PRODA is the default; own-PRODA and Tyro are optional. A shared platform credential incident may affect several practices. Platform keys use Secrets Manager with verified rotation, with primary and standby devices; own-PRODA keys are encrypted at rest. Non-production and the designated production Medicare Test Clinic use vendor test. Report any PRODA credential compromise to Services Australia within 12 hours of awareness, while containment and recovery proceed. A standby must be independently assessed as safe before use.
1. PRODA 401 storm — auth failures across all submissions
| Field | Detail |
|---|---|
| Symptom | Multiple tenants seeing 401 from PRODA; the PRODA health monitor alerts. Submissions failing. |
| Possible cause | PRODA token cache poisoned; vendor key expired; SA-side PRODA outage; auth-failure lockout cascaded. |
| Runbook | Praxi's internal PRODA key-recovery runbook |
| First action | Check the PRODA health monitor for per-tenant failure counts; check the SA status page; clear the token cache via Praxi's internal token-cache reset procedure. |
| SLA trigger | If SA data confidentiality is at risk, 12-hour notification. If only availability, next business day. |
2. Mass claim rejections — error spike on assessment reports
| Field | Detail |
|---|---|
| Symptom | The bulk-bill report poller returns a large batch of rejected claims; the failed-claims dashboard spikes. |
| Possible cause | MBS schedule update with breaking change; data-quality regression in Praxi; SA-side validation rule change. |
| Runbook | Praxi operations reviews the failed-claim feed; cross-reference error codes against Medicare Error Codes. |
| First action | Pause auto-submit at the affected tenant. Spot-check 3-5 rejected claims to find the common factor. Open a fix branch if Praxi-side; advise tenants if data-quality. |
| SLA trigger | If rejections are due to a Praxi-side regression that submitted invalid claims, next business day notification to SA — Praxi submitted bad data, even though SA caught it. |
3. SA upstream outage — MCOL endpoints unreachable
| Field | Detail |
|---|---|
| Symptom | TLS or 5xx errors against MCOL endpoints; SA status page confirms outage. |
| Possible cause | SA-side maintenance or unplanned outage. Not a Praxi incident. |
| Runbook | Check SA status page; suspend auto-submit at the circuit-breaker layer; notify tenants via in-app banner. |
| First action | Open circuit breaker via the ops portal Command Centre; resume on SA all-clear. |
| SLA trigger | No SA-facing notification required (SA already knows). Tenant communication is recommended for outages >1 hour. |
4. Data leak suspected — Medicare card number or IHI exposure
| Field | Detail |
|---|---|
| Symptom | Audit-log review surfaces unexpected access; tenant reports patient data visible to wrong user; security scan flags exposed PHI. |
| Possible cause | RLS bypass; logging regression that wrote cleartext PHI to CloudWatch; export bundle delivered to wrong recipient. |
| Runbook | Praxi's data-breach-response plan |
| First action | Preserve evidence — do not modify the audit trail or destroy logs. Open incident ticket. Identify scope of affected records. Begin containment (revoke session, rotate credentials, restrict access). |
| SLA trigger | 12-hour SA notification + 3-business-day draft OAIC notification + tenant notification within 24 hours. The breach-response plan is the authoritative procedure; this row is the on-call summary. |
5. Key compromise — PRODA private key or application master encryption key suspected compromised
| Field | Detail |
|---|---|
| Symptom | Unauthorised PRODA submission detected; AWS Secrets Manager access anomaly in CloudTrail; security scan or threat-intel report flags credential. |
| Possible cause | Engineer device compromise; malicious insider; AWS account compromise. |
| Runbook | Praxi's internal PRODA key-recovery runbook for PRODA-key compromise. For master-key compromise: rotate the application master encryption key and re-encrypt all dependent records via the lazy re-encrypt-on-write path. |
| First action | Revoke the compromised credential. Audit all access since suspected compromise window. Begin containment. |
| SLA trigger | 12-hour SA notification. If patient data was decrypted by the compromise, 3-business-day OAIC draft notification + tenant notification. |
6. Audit-trail failure — audit interceptor not writing
| Field | Detail |
|---|---|
| Symptom | Audit-log row count drops; specific mutations not appearing; archive copy-to-S3 lagging. |
| Possible cause | Interceptor regression; AuditLog table write failure; S3 archive cron failure. |
| Runbook | Praxi's internal audit-trail recovery procedure. |
| First action | Confirm scope and time window. Pause non-essential mutations if the audit gap is widening. Restore audit pipeline before resuming. |
| SLA trigger | Next business day notification to SA — audit-trail availability is part of the IA 2020 v2.1 control set. |
7. Migration data quality — claim records corrupted by a database migration
| Field | Detail |
|---|---|
| Symptom | Post-deploy claim-reconciliation cron reports drift; tenant reports missing or wrong claim data. |
| Possible cause | A non-expand migration (RENAME, DROP, NOT NULL on existing) applied incorrectly. ADR-008 phasing was meant to prevent this. |
| Runbook | docs/deployment/DEPLOYMENT_RUNBOOK.md rollback procedure. |
| First action | Halt production deploy pipeline. Restore Aurora from most recent point-in-time snapshot for the affected tables. Verify with claim-reconciliation cron. |
| SLA trigger | Next business day notification to SA for data-integrity impact + tenant communication. |
Post-incident review
Every incident triggers a written Post-Incident Review (PIR) within 5 business
days of resolution. The PIR is filed under
docs/audits/incidents/PRX-INC-YYYY-NN-pir.md and includes:
- Timeline of the incident with timestamps in AEST.
- Root cause analysis (5-whys recommended).
- The decisions made during the incident, who made them, and what alternatives were considered.
- The metrics that mattered (detection-to-acknowledgement, acknowledgement-to-containment, containment-to-resolution).
- Preventive measures, owner, and target date.
- Tenant communication record.
- SA Developer Liaison communication record.
- OAIC communication record (where applicable).
PIRs are reviewed at the next monthly compliance review and the preventive
measures tracked in the services-australia-compliance module's
complianceActions table.
Compliance audit trail
Every incident notification is itself written as a compliance-event record in Praxi's Services Australia compliance system, with the same 7-year retention as the main audit log. A compliance-event timeline is available to Praxi operators for SA review purposes.
The audit trail of what Praxi did during an incident is therefore a first-class, preserved record alongside the audit trail of the mutations that triggered or resolved the incident.
Cross-references
- Software Product Description — product identity and scope of what is being protected.
- Security Architecture — the controls that prevent and detect incidents.
- Privacy Impact Assessment — the privacy-risk register the incident-response process responds to.
- Medicare Data Flow — what data is at risk in a Medicare incident.
- Per-claim Audit Trail — the audit evidence available during incident triage.
- Praxi's internal PRODA key-recovery runbook — PRODA recovery decision tree.
- Praxi's internal re-certification runbook — re-certification workflow if
dhs-productIdchanges. - Praxi's internal data-breach-response plan — the authoritative breach-response procedure.
SA spec conformance — Verified against Interface Agreement 2020 v2.1, Privacy Act 1988 Part IIIC (Notifiable Data Breaches scheme), Third Party Security Policy v2.1 on 2026-05-13; re-verified against the implementation on 2026-08-12.