Medicare Data Flow and Subprocessor Disclosure

This page documents the path of Medicare-related personal and clinical information through Praxi. It is written for tenants who need to meet their own obligations under the Privacy Act 1988 — in particular Australian Privacy Principle (APP) 11 (security of personal information) and APP 8 (cross-border disclosure) — and who are completing a Privacy Impact Assessment (PIA) for their practice's regulator or insurer.

The information here is factual and intended to be quoted directly into a PIA, security questionnaire, or assurance review. If you need a signed equivalent on Praxi letterhead, contact your Praxi support team.

Audience and purpose

You are the primary APP entity for your practice. Your clients consent to your collection and use of their information; you are accountable under the Privacy Act for what happens to it. Praxi is your service provider — we hold and process information on your behalf under our SaaS Agreement and Privacy Policy.

When you submit a Medicare claim through Praxi, three categories of data move through the system:

1. Personal information — patient name, date of birth, address, contact details.
2. Government-issued identifiers — Medicare card number, Individual Reference Number (IRN), Individual Healthcare Identifier (IHI) where applicable, DVA file number for veterans.
3. Health information — the MBS item claimed, the service date, the rendering provider, and (indirectly) the clinical condition the item implies. APPs treat all three categories as "sensitive information" requiring heightened protection.

What data is collected and stored

Praxi stores Medicare-related data in the following records:

Data	Where stored	At-rest protection
Patient name, DOB, address	Patient records	AWS KMS encryption at the storage layer
Medicare card number, IRN	Claim submission records, Medicare claim records, Patient records (where present)	AES-256-GCM application-layer encryption + KMS at storage layer
IHI (Individual Healthcare Identifier)	Patient records	KMS encryption at the storage layer
DVA file number	Patient DVA record, claim records	AES-256-GCM application-layer encryption + KMS at storage layer
MBS item, service date, provider	Claim submission records, Invoice records, Appointment records	KMS encryption at storage layer (these fields are not PHI in isolation but become identifying when combined)
SA response payload (verbatim)	Encrypted claim response (JSON)	AES-256-GCM application-layer encryption + KMS at storage layer
DB4 bulk-bill consent record	Bulk-bill consent records	KMS encryption at storage layer
Audit trail of every claim mutation	Audit records	KMS encryption at storage layer; immutable (insert-only)

The application-layer encryption for Medicare card, IRN, and DVA file number uses AES-256-GCM with a 256-bit master key stored in AWS Secrets Manager. Decryption is gated by authenticated, access-controlled API requests with row-level security enforced so that only your own practice's records are decryptable.

Where data resides

All Praxi production data resides in the AWS Sydney region (ap-southeast-2). There is no cross-region replication of production data.

Component	AWS Region	Service
Primary application database	ap-southeast-2	Aurora PostgreSQL
Cache (PRODA token cache, sessions)	ap-southeast-2	Amazon ElastiCache (Redis)
Object storage (attachments)	ap-southeast-2	Amazon S3
Secrets (encryption keys, API keys)	ap-southeast-2	AWS Secrets Manager
Authentication / identity provider	ap-southeast-2	Self-hosted Keycloak on ECS Fargate
Application compute	ap-southeast-2	ECS Fargate
Logs and traces	ap-southeast-2	CloudWatch Logs, X-Ray, Application Signals
Audit log archive	ap-southeast-2	S3 (long-term retention class)

Praxi's production AWS account is owned by House of Praxi Pty Ltd, an Australian entity. The account is subject to Service Control Policies (SCPs) that deny resource creation outside ap-southeast-2. This is enforced at the AWS organisation level — engineers cannot accidentally provision resources in another region.

Path of a typical Medicare claim

1. Practitioner enters the claim in Praxi. The browser sends the request over TLS 1.2+ to Praxi's API at api.praxi.au. The request is authenticated with a session token in an httpOnly cookie.
2. Praxi persists the submission. Aurora PostgreSQL stores the claim submission record. Medicare card, IRN, and DVA file number are encrypted with AES-256-GCM before insertion; the rest of the row is protected at rest by AWS-managed KMS.
3. Praxi authenticates with Services Australia. Praxi fetches a PRODA access token using House of Praxi's platform device by default, or the practice's own encrypted key when it chooses own-PRODA. Tyro is another optional gateway. Practitioners remain responsible for claims. The token is cached in Redis for 55 minutes — Redis itself runs inside the Praxi AWS VPC and is not internet-reachable.
4. Praxi submits to MCOL. The claim payload is sent over TLS to Services Australia's MCOL endpoint (during pre-certification testing this is SA's vendor test environment; the production endpoint is issued by Services Australia once certification completes). The request includes the patient's Medicare details, MBS item, service date, and rendering provider — this is the point at which patient identifying information leaves Praxi's infrastructure.
5. SA returns a response. SA sends back a claimId, an assessment status, an error code (if any), and the verbatim reason text. Praxi stores the response with AES-256-GCM encryption.
6. Praxi notifies the practitioner. The response surfaces in the UI for the practitioner who submitted the claim. Async reports (BPRW/BPYW for bulk bill, DVRW/DVYW for DVA) arrive on a 15-minute polling cron job and update the same row.

Diagrammatically:

[Practitioner browser] --TLS--> [Praxi web + API (ap-southeast-2)]
                                         |
                                         | TLS, session token
                                         v
                                [Praxi API (ap-southeast-2)]
                                         |
                          +--------------+--------------+
                          |              |              |
                          v              v              v
                    [Aurora PG]    [Redis cache]   [Secrets Mgr]
                  (Medicare data,  (PRODA token   (encryption keys,
                   AES-256-GCM      55-min cache)  PRODA private keys)
                   + KMS)
                                         |
                                         | TLS, PRODA-signed JWT
                                         v
                            [Services Australia: PRODA + MCOL]
                                  (Australian govt infrastructure)

[Bedrock AI suggestion path — only when AI MBS suggestion is invoked]
                    [Praxi API] --TLS--> [Bedrock ap-southeast-2]
                                         (no Medicare/IHI/DVA values,
                                          appointment metadata only)

No patient data crosses the boundary of Praxi's AWS account except the SA round-trip, which is the entire point of the integration.

Subprocessors involved in Medicare claiming

Praxi maintains a public subprocessor register at https://praxi.au/trust/sub-processors. The subprocessors involved in Medicare claiming specifically are:

Amazon Web Services Australia

• Role: Cloud hosting (compute, storage, database, secrets, observability).
• Location: ap-southeast-2 (Sydney).
• Data accessed: AWS does not "see" Praxi data in the operational sense — they provide the storage and compute substrate. Data at rest is encrypted under KMS (AWS-managed key material) and, for the most sensitive fields, additionally under AES-256-GCM with key material stored in AWS Secrets Manager.
• Contractual basis: AWS Customer Agreement, AWS Data Processing Addendum, AWS Australia GDPR-equivalent terms.
• Australian presence: AWS Australia operates the Sydney region under Australian law.

Services Australia

• Role: The Medicare and DVA claim recipient. This is the destination of every Medicare claim; SA is not a Praxi subprocessor in the traditional sense — they are the regulator and benefit administrator.
• Location: Australian government infrastructure in Australia.
• Data accessed: Every claim payload (patient identifiers, MBS items, service details).
• Contractual basis: Services Australia's Health Provider Online Services terms of use, the National Health Act 1953, and the Health Insurance Act 1973. Praxi acts as the authorised submitter under the selected claiming arrangement; a practice using Praxi's PRODA does not need its own PRODA account.
• Australian presence: SA is an Australian Commonwealth statutory authority.

Anthropic via AWS Bedrock (Sydney)

• Role: AI-assisted MBS item suggestion only. When a practitioner uses the Suggest MBS Item feature on an invoice, Praxi sends appointment metadata (duration, mode, profession type, service category) to Bedrock's Claude model. The request does not include the patient's Medicare card number, IRN, IHI, DVA file number, or name. Only structural metadata that an MBS coder would use to choose an item.
• Location: ap-southeast-2 (Sydney). Praxi configures Bedrock to route requests within the Sydney region only; cross-region routing is disabled and enforced at the AI model-routing layer.
• Retention: Anthropic, via AWS Bedrock, does not retain prompts for model training. AWS Bedrock's standard data processing terms apply.
• Contractual basis: AWS Bedrock service terms; AWS responsibility extends to the model inference call.

Authentication and email delivery

• Keycloak is self-hosted by Praxi in ap-southeast-2 — not a subprocessor, but listed here for completeness because it sits in the Medicare workflow's authentication path.
• Amazon SES is used for transactional email (e.g. claim payment notifications, support replies). It is configured in ap-southeast-2. SES does not see Medicare card numbers or clinical detail — only practitioner email addresses and notification copy.

No other subprocessors process Medicare data

Praxi does not use any of the following for Medicare data processing:

• Third-party analytics SDKs (no Mixpanel, no Segment, no Google Analytics with PHI fields).
• Cloud-hosted observability services with cross-border data (no Sentry, no Datadog SaaS — Praxi uses self-hosted observability via CloudWatch in ap-southeast-2).
• Foreign-jurisdiction payment processors for Medicare claim data (Medicare payments go directly from SA to your practice's nominated bank account — no Praxi intermediation).

The complete and up-to-date subprocessor register at https://praxi.au/trust/sub-processors is the authoritative source. This page describes the subprocessors involved in Medicare claiming specifically; some general-purpose subprocessors (e.g. for marketing email to your practice) are not in scope here.

Cross-border disclosure (APP 8)

No Medicare claim data is disclosed outside Australia in the ordinary course of Praxi's operation. AWS Australia infrastructure is operated by an Australian AWS subsidiary; Services Australia is an Australian Commonwealth agency; Bedrock requests route to the Sydney region only.

The only theoretical exception is break-glass support access for a critical incident. Praxi's engineering team is currently Australia-based; in the event of an after-hours incident, an Australian engineer assumes the on-call role. If Praxi were to engage non-Australian support staff in future, the subprocessor register would be updated and you would be notified per the SaaS Agreement before any change took effect.

Retention

Record type	Retention	Source
Claim submission records	Indefinite while the parent invoice exists; 7 years otherwise	AHPRA record-keeping requirement, Health Records Act (Victoria, NSW, ACT variants)
Audit records for Medicare events	7 years from creation	Privacy Act 1988 minimum
Bulk-bill consent records (DB4)	2 years from consent date	Services Australia DB4 retention rule
Encrypted PHI fields	Same as the parent record they belong to	Inherits from the record's retention period
Failed-claim diagnostic snapshots	90 days	Operational only; sufficient for triage
PRODA token cache (Redis)	55 minutes (configured), TTL-expired automatically	Praxi operational
OpenTelemetry traces (PHI-redacted)	30 days	CloudWatch retention policy

Note that 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 practitioner request, because doing so would breach your practice's regulatory obligations.

Right to erasure

The Privacy Act 1988 gives clients certain rights to request correction or deletion of their personal information (s. 12B and APP 13 for correction). Praxi implements an erasure request workflow for this — see Privacy Act compliance for the end-to-end flow.

Key constraints for Medicare data specifically:

• The 30-day SLA. Praxi processes erasure requests within 30 days. This is Praxi's own internal commitment; Privacy Act timelines are different and slower, but the 30-day SLA gives your practice headroom to meet APP 12 (access) and APP 13 (correction) deadlines.
• The AHPRA / Health Records Act floor. Until the regulatory retention floor has elapsed, erasure is performed logically rather than physically — the PHI fields are nulled or replaced with non-identifying tokens, but the audit trail and the structural record (claim ID, service date, MBS item, fee, SA response) are preserved. This protects your practice's ability to respond to a future SA debt-recovery determination or AHPRA notification.
• Erasure does not undo a submitted claim. SA holds its own copy of every claim under its claimId. Praxi's erasure flow removes patient identifiers from Praxi's copy after the regulatory floor elapses; SA's copy is governed by SA's own retention policy. If a patient asks SA to delete their copy, they need to contact SA directly — Praxi cannot do this on their behalf.

Don't conflate the two: erasing a client (a patient record) is a different workflow from deleting a user account (a Praxi login). Praxi implements both through separate workflows.

Encryption key management

The application-layer encryption used for Medicare card, IRN, and DVA file number is documented for completeness:

• Algorithm: AES-256-GCM with authenticated encryption (96-bit IV, 128-bit auth tag).
• Key derivation: A 256-bit master key, stored in AWS Secrets Manager and accessible only to the API service, is used with HKDF to derive per-field sub-keys with a per-record salt.
• Key rotation: The master key is rotated annually. Re-encryption is performed lazily — records are re-encrypted under the new key on next write. Old keys are retained for 7 years to permit decryption of historical records.
• Access control: The master key is reachable only by the API task IAM role. Engineers cannot access the master key value directly; debugging operations against encrypted fields go through audit-logged controllers.
• PRODA private keys: Platform keys are held in AWS Secrets Manager after verified migration through rotation, with primary and standby devices. Own-PRODA keys are separately encrypted at rest with AES-256-GCM. Rotation checks run every six hours and rotate eligible keys within 30 days of expiry. Non-production and the designated production Medicare Test Clinic use vendor test. Other production practices cannot use reserved certification Location IDs. Praxi reports credential compromise to SA within 12 hours of awareness.

Producing a PIA for your practice

For your own practice's Privacy Impact Assessment, the practical steps are:

1. Identify what personal and sensitive information your practice collects (Medicare cards, clinical notes, billing data).
2. Identify your collection, use, and disclosure flows (this document covers the Medicare claiming flow specifically).
3. Identify the subprocessors involved (this page lists Praxi's; you also need to list any other services your practice uses directly — e.g. your accountant's software, your insurance broker).
4. Identify retention periods (this page covers Praxi-side retention; you also need to document your practice's own retention for paper records and other systems).
5. Assess the privacy risks and any mitigations.
6. Document the residual risks you accept.

Praxi publishes a tenant PIA template under Privacy Act compliance. Fill it in for your practice and retain a copy with your compliance records.

Cross-references

• Privacy Act compliance — the practice-wide privacy framework.
• Per-claim Audit Trail — what Praxi logs about every Medicare claim.
• Medicare Permissions Matrix — who within your practice can access Medicare data.
• Data Retention — retention policies across all record types.
• Audit Logs — Praxi's general audit-logging architecture.
• Praxi subprocessor register — the authoritative public list.

Was this page helpful?

---

Verified against the current Praxi product surface, Australian Privacy Principle 11 (APP 11) data security obligations, and the Praxi subprocessor register on 2026-06-05.