Praxi Medicare Privacy Impact Assessment

This is Praxi's Privacy Impact Assessment (PIA) for the Medicare-claiming pathway. It documents the personal and health information Praxi processes when a practitioner submits a Medicare or DVA claim, the purposes of that processing, the safeguards Praxi applies, and the residual risks Praxi has accepted with their mitigations.

The PIA is written for two audiences:

1. Praxi-internal review — annual revision and ad-hoc revision on any architecture change, captured in docs/audits/ and signed by the Privacy Officer.
2. Tenant adaptation — practices completing their own PIAs under Australian Privacy Principle 11 (security of personal information) and APP 1.2 (open and transparent management) can quote this document directly or adapt it as the Praxi-service portion of their own PIA.

The complete and authoritative version of Praxi's Privacy Policy and SaaS Agreement live at praxi.au/legal/privacy-policy and praxi.au/legal/saas-agreement. This PIA is a working document; the Privacy Policy is the contractual instrument.

Audience and scope

Each Praxi tenant is the primary APP entity for its practice. Tenant clients give consent to the practice for collection and use of their personal and health information; the practice is accountable under the Privacy Act 1988 for what happens to that information. Praxi is the service provider that holds and processes information on the practice's behalf under contract.

This PIA covers Medicare and DVA claiming specifically — the flow that begins when a practitioner enters a claim in Praxi and ends when Services Australia returns an assessment outcome and payment. It does not cover the broader scope of Praxi's processing (clinical notes, telehealth, assessments, etc.); those are documented in adjacent feature pages and in the practice-wide Privacy Act compliance framework.

Medicare Online claims use House of Praxi's PRODA organisation by default, under the vendor model described in MCOL Q&A 5. A practice may choose its own PRODA organisation or Tyro instead. Practitioners remain responsible for their claims regardless of the authentication choice.

For the default service, Praxi links each practice Location ID (Minor ID) to House of Praxi's PRODA organisation. A signed HW027 is required for each provider number at each location. The practitioner signs it; question 3 is left blank when using Praxi's PRODA. Practices choosing their own PRODA manage their own linking and enter their own PRODA registration authority number in question 3. The Services Australia API client identifier is one platform value across practices; it is separate from the PRODA organisation and device identity.

Information collected and stored

Praxi processes the following categories of information when handling a Medicare claim. The full data inventory, including storage locations and at-rest protections, is in Medicare Data Flow; this PIA summarises it.

Category	Examples	APP classification
Personal information	Patient name, date of birth, address, contact details	Personal information (APP 6)
Government-issued identifiers	Medicare card number, Individual Reference Number (IRN), IHI, DVA file number	Personal information; sensitive in combination
Health information	MBS item code, service date, rendering provider, indirect indication of clinical condition	Sensitive information / health information (APP 6.2(a))
Clinical context (supporting the claim)	Clinical note linked to the appointment, treatment plan reference, GP referral details	Sensitive information
Bulk-bill assignment of benefit consent (DB4)	Patient consent record, consent method (typed_name / tick_box / i_accept), timestamp	Personal + record-keeping (Health Insurance Act 1973 s.20A)
Wire-protocol metadata	dhs-correlationId, dhs-messageId, claimId, SA response payload	Personal information (echoes the above)
Audit trail	Who submitted the claim, when, from where (IP, user-agent)	Personal information (about the practitioner)

The Australian Privacy Principles treat the combination of health information with a government identifier as sensitive information requiring heightened protection. Praxi applies AES-256-GCM application-layer encryption to the government identifiers (Medicare card, IRN, IHI, DVA file number) and AWS KMS encryption at the storage layer to every other category — see Security Architecture for the cryptographic profile.

Purpose of collection and use

Praxi processes Medicare-related information for three purposes:

1. Claim submission to Services Australia — the primary purpose, agreed by the patient at the point of bulk-bill assignment or patient-claim authorisation. Information is submitted via MCOL endpoints to SA and SA's response is stored against the claim.
2. Claim reconciliation and benefit payment tracking — receiving the SA processing and payment reports (BPRW/BPYW/DVRW/DVYW) on the 15-minute polling cadence and surfacing benefit outcomes to the practitioner.
3. Regulatory and audit compliance — preserving the full audit trail of every claim for the 7-year minimum required by AHPRA, Health Records Acts, and the Privacy Act 1988. The audit trail is what protects the practice from spurious debt-recovery claims at the AAT or AHPRA notifications.

Praxi does not process Medicare information for:

• Marketing to the patient or anyone else.
• Profiling or behavioural analytics.
• Re-selling, syndicating, or aggregating across tenants.
• Training Anthropic's foundation models — Bedrock's standard data processing terms preclude Praxi's prompts being used for training, and Praxi does not enrol in any Bedrock data-sharing programme.

Disclosure

Praxi discloses Medicare-related information only to:

Recipient	What is disclosed	Lawful basis
Services Australia	Every claim payload	Health Insurance Act 1973, National Health Act 1953, patient's bulk-bill assignment or patient-claim consent
Department of Veterans Affairs (via SA channel)	Every VAAW claim payload	Veterans' Entitlements Act 1986, Military Rehabilitation and Compensation Act 2004
The practitioner who submitted the claim	The SA response, assessment status, benefit paid	Service provider relationship; the practitioner authored the claim
Other Praxi users at the tenant	Subject to RBAC and consent for sharing	The practice's own consent management

Praxi does not disclose Medicare information to:

• Other Praxi tenants (RLS enforces strict isolation).
• Anthropic — the AI MBS-suggestion path uses Bedrock-Sydney and never includes Medicare card number, IRN, IHI, or DVA file number. Only structural appointment metadata.
• Third-party analytics, advertising, or marketing services.
• Any party outside Australia (see Cross-border disclosure below).

Data quality (APP 10)

Praxi protects data quality at three points:

1. Patient verification (OPVW) before claim submission. Praxi requires patient verification via the OPVW channel before any claim is submitted. The verification confirms the Medicare card number, IRN, and patient name match SA's records. Verification failures are surfaced to the practitioner before claim submission, never silently passed through.
2. Validators at the controller boundary. Praxi validates the Medicare card weighted-mod-10 check digit, the provider number weighted-mod-11 check letter, the DVA file number format, the MBS item against the published schedule for the service date, and the Australian timezone offset on every service-date timestamp. Validation failures return a 422 response with the specific field at fault — they never submit malformed data to SA.
3. Verbatim error surfacing. SA's ServiceMessagesType.reason text is displayed to the practitioner verbatim, never truncated, never rewritten. The practitioner sees exactly what SA said and can correct the input or escalate as appropriate.

Data security (APP 11)

The detailed security control set is in Security Architecture. The summary:

• AES-256-GCM application-layer encryption for Medicare card, IRN, IHI, DVA file number, own-PRODA private keys, and SA response payloads. Platform PRODA keys are held in AWS Secrets Manager with verified rotation.
• AWS KMS storage-layer encryption for all data at rest.
• TLS 1.2+ for all transport, with TLS 1.3 preferred internally and PRODA + MCOL transport at the Services Australia-published profile.
• PostgreSQL row-level security on every tenant table.
• Authentication via Keycloak with JWT in httpOnly cookies (never localStorage).
• Role-based access control with 12 roles and a permission catalogue audited against the seed by CI gate.
• Audit logging of every mutation and every decryption operation, 7-year retention.
• Trivy + Cosign + Semgrep + tfsec/Checkov in the CI pipeline.

Retention

Retention follows the schedule on Medicare Data Flow. In summary:

Record type	Retention	Basis
Claim submission records	Indefinite while parent invoice exists; else 7 years	AHPRA / Health Records Acts
Audit records for Medicare events	7 years	Privacy Act 1988 minimum
Bulk-bill consent records (DB4)	2 years	Services Australia DB4 retention
Failed-claim diagnostic snapshots	90 days	Operational
PRODA token cache (Redis)	55 minutes	Operational (token TTL is 60 minutes; cache TTL is 55)
OpenTelemetry traces (PHI-redacted)	30 days	CloudWatch retention policy

The 7-year AHPRA / Health Records Act floor is minimum retention. Praxi does not delete Medicare claim records before that floor is reached, even on patient erasure request, because doing so would breach the practice's regulatory obligations. Erasure within the floor is handled logically (PHI fields nulled, structural record preserved) rather than physically — see Right to erasure below.

Cross-border disclosure (APP 8)

No Medicare claim data is disclosed outside Australia in the ordinary course of Praxi's operation. The relevant facts:

• Hosting. All Praxi production infrastructure runs in AWS ap-southeast-2 (Sydney). Service Control Policies at the AWS organisation level deny resource creation in any other region; engineers cannot accidentally provision in a US or European region.
• Subprocessors. AWS Australia is the substrate. Services Australia is Australian Commonwealth infrastructure. Anthropic-via-Bedrock is constrained to the au.anthropic.* inference profile, which routes processing inside the Sydney region only — the global.anthropic.* profile (which can route cross-region) is forbidden in Praxi's central model registry and blocked at the application layer.
• Personnel. Praxi's engineering team is currently Australian-resident. After-hours incident response is rotated among Australian engineers.

The only theoretical exception is break-glass support access for a critical after-hours incident in a future state where Praxi has expanded its engineering team beyond Australia. If non-Australian support staff are engaged, the subprocessor register is updated and tenants are notified per the SaaS Agreement before any change takes effect. No such expansion is currently planned.

For tenants completing their own PIA: this means Praxi-side processing presents no APP 8 cross-border disclosure. The patient's information stays in Australia.

Right to erasure (APP 12, 13, and s. 12B)

The Privacy Act 1988 gives patients certain rights to request access (APP 12), correction (APP 13), and erasure (s. 12B) of their personal information held by an APP entity. Praxi implements an erasure-request workflow for patient-erasure requests routed through the practice.

Key constraints for Medicare data:

• 30-day internal SLA. Praxi processes erasure requests within 30 days (ERASURE_SLA_DAYS = 30). This is internal practice; statutory Privacy Act timelines are different (and slower) and the 30-day SLA gives the practice headroom to meet APP 12 (access) and APP 13 (correction) deadlines.
• Regulatory retention floor. Until the 7-year AHPRA / Health Records Act floor has elapsed, erasure is logical: PHI fields are nulled or replaced with non-identifying tokens, but the structural record (claim ID, service date, MBS item, fee, SA response, audit trail) is preserved. This protects the practice's ability to respond to a future SA debt-recovery determination or AHPRA notification.
• SA-side records. Services Australia holds its own copy of every claim under SA's claimId. Praxi's erasure removes patient identifiers from Praxi's copy after the regulatory floor elapses; SA's copy is governed by SA's own retention policy. A patient requesting SA-side erasure must contact SA directly.
• Erasure does not undo a submitted claim. Refund or claim reversal is a separate operational workflow (SA's Same Day Delete SDDW channel or SA's debt-recovery process).

Two services implement deletion, and they are distinct:

• Patient erasure workflow — Privacy Act §12B patient erasure (the workflow described above).
• Account deletion workflow — Apple-required user-account deletion path for Praxi accounts. Different scope, different lawful basis, different retention rules.

Privacy impacts identified and mitigated

The privacy-risk register for Medicare claiming. Each risk has a Praxi-side mitigation; the residual risk Praxi has accepted is named explicitly.

1. PRODA credential compromise

Aspect	Detail
Risk	A compromised platform credential can affect several practices; a compromised own-PRODA key affects that practice.
Mitigation	Encrypted key custody, verified rotation and a checked standby; see below.
Residual risk	A usable signing credential can enable misuse across affected practices.

Platform private keys are held in AWS Secrets Manager. The platform uses a primary B2B device with a standby for continuity. A recorded standby is not proof of a healthy connection: its activation, key, expiry and authentication history must be checked. Key rotation stages a replacement, verifies acceptance by Services Australia and promotes the verified version. An incomplete or uncertain rotation requires review before the affected device returns to service.

These are key-custody controls, not evidence that production credentials or a standby device are ready. Practices choosing their own PRODA have separate keys, encrypted at rest with AES-256-GCM. Recovery depends on the available verified key or backup and may require a new device activation code.

Non-production environments use vendor-test PRODA and claiming endpoints. Production uses live endpoints except for the explicitly designated Medicare Test Clinic, which uses vendor test. Reserved certification Location IDs are refused for other production practices. Invalid endpoint configuration blocks requests rather than allowing a live/test fallback.

Praxi must report a PRODA credential compromise to Services Australia within 12 hours of awareness. Containment, evidence preservation and recovery run alongside notification; investigation must not delay reporting.

2. Medicare card number leak via log or trace

Aspect	Detail
Risk	A Medicare card number is logged in cleartext to CloudWatch or exported in an OpenTelemetry trace, exposing it to AWS-account-internal observability tooling.
Mitigation	All logging in the API layer goes through a structured logger and is sanitised at the OpenTelemetry request hook before export. The hook redacts UUIDs, Medicare numbers, IHI, and free-text identifiers before export. Plain console logging is blocked at lint. PHI in request bodies is automatically redacted in audit-log diffs.
Residual risk	A new code path that bypasses both the logger and the audit interceptor and writes raw bytes to stdout/stderr would leak to CloudWatch. Mitigation is code review, ESLint rules, and grep-based pre-commit checks.

3. Cross-tenant data leak via RLS bypass

Aspect	Detail
Risk	An isolation defect exposes another practice’s data.
Mitigation	Database row-level security, scoped application access and automated isolation checks.
Residual risk	A policy or application defect may defeat isolation; review and verification remain necessary.

4. SA response interception in transit

Aspect	Detail
Risk	An on-path attacker intercepts the MCOL request/response and reads the patient's Medicare card number, IRN, claimed item, and assessment outcome.
Mitigation	All MCOL transport is TLS 1.2+ to Services Australia. Praxi has no production code path that bypasses TLS. PRODA + MCOL endpoints are anchored to SA's published certificate chain.
Residual risk	A compromised intermediate CA in SA's published chain could enable a state-actor-level MITM. Detection would be through TLS-anomaly monitoring at SA's end; Praxi cannot detect this independently.

5. Improper access by Praxi staff

Aspect	Detail
Risk	A Praxi staff member (engineer, support agent) accesses a tenant's Medicare data outside legitimate support need.
Mitigation	Separate staff authentication, MFA, limited support access and an audit trail.
Residual risk	An authorised operator may misuse access. Restrict duties and review audit records.

Open issues

No open privacy issues identified at the date of last verification. Outstanding hardening items (not privacy issues but adjacent):

• iOS certificate pinning is retired pending a written rotation runbook and real SPKI hashes.
• SOC 2 Type II — controls defined, first observation window underway; certification follows completion of the observation period.

Review cycle

This PIA is reviewed:

• Annually, on the anniversary of last verification. Next scheduled review: 2027-05-13.
• On any architecture change that affects the data flow described in Medicare Data Flow, including new subprocessor, new data category, new disclosure recipient, change of hosting region, change of authentication mechanism.
• On any privacy incident that is formally classified as notifiable under the OAIC scheme.

Reviews are signed by Praxi's Privacy Officer and stored in docs/audits/ with the date in the filename.

Producing a PIA for your practice

For tenants adapting this document into a practice-level PIA:

1. Identify your practice's purposes. Praxi covers Medicare claiming; your practice also collects information for clinical care, billing, reporting, internal supervision, and so on. Document all of them.
2. List your subprocessors. Praxi is one. Your accountant's software, your insurance broker, your tax agent, and any third party that touches patient information are others.
3. Document your collection notice. APP 5 requires you to tell your patient at or before collection who you are, why you're collecting, and how the information will be used. Praxi's claim-submission flow assumes you have done this.
4. Document your consent capture. Bulk-bill assignment of benefit consent is recorded in Praxi and meets SA's DB4 requirement. Your practice should also record general clinical-information-sharing consent separately.
5. Identify the risks you accept. Use the risk register above as a starting point and add risks specific to your practice (paper records, kiosk-mode check-in, branch-office connectivity, etc.).
6. Set a review cadence. Annual is a reasonable default. Praxi reviews on the anniversary of last verification.
7. Retain a copy in your compliance records. The OAIC may request it.

The tenant PIA template lives at Privacy Act compliance.

Cross-references

• Software Product Description — what Praxi is and what claim channels it implements.
• Security Architecture — the security control set this PIA references.
• Incident Response — what Praxi does when a privacy incident is detected.
• Medicare Data Flow — the canonical subprocessor disclosure.
• Per-claim Audit Trail — what Praxi logs about every claim.
• Privacy Act compliance — the practice-wide privacy framework and PIA template.
• Praxi Privacy Policy — the authoritative contractual document.
• Praxi SaaS Agreement — the service-provider contract.
• Praxi subprocessor register — the authoritative public list.

---

SA spec conformance — Verified against Privacy Act 1988 (incl. APPs 5, 6, 8, 10, 11, 12, 13, s. 12B), Interface Agreement 2020 v2.1, Notifiable Data Breach scheme (OAIC) on 2026-05-13; retention, residency and erasure claims re-verified against the implementation on 2026-08-12.

Was this page helpful?