Medicare Compliance Artefacts (SA Submission Ready)
This section collects the four canonical compliance artefacts Praxi maintains to support Services Australia Notice of Integration (NOI) certification under Interface Agreement 2020 v2.1, ongoing re-certification under SA's Version Control Policy v2.0, and tenant-side Privacy Impact Assessments under Australian Privacy Principle 11.
Each artefact is written to be quoted directly into an SA submission, a tenant security questionnaire, or an internal compliance file. The artefacts are versioned against the Services Australia specification revisions they were last verified against — see versioning footer convention below.
Authentication and assurance scope
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.
Platform keys use Secrets Manager with verified rotation, with primary and standby devices and verified rotation. Own-PRODA keys are encrypted at rest. Non-production and the designated production Medicare Test Clinic use vendor test; other production practices cannot use reserved certification Location IDs. PRODA credential compromise must be reported to SA within 12 hours of awareness. These controls describe the implementation model, not issued certification or proof that production credentials and standby devices are ready.
The four artefacts
| Artefact | Primary audience | Read for |
|---|---|---|
| Software Product Description | SA Developer Liaison (NOI cert) | Product identity, scope, architecture summary, claim channels, wire-level conformance, change-control rules. |
| Security Architecture | SA Developer Liaison + tenant security teams | Data classification, encryption at rest and in transit, authentication, tenant isolation, PRODA key management, audit logging. |
| Privacy Impact Assessment | Tenants (own APP 11 / OAIC obligations) + Praxi internal review | Information collected, purposes, disclosure recipients, retention, cross-border posture, privacy-risk register with mitigations. |
| Incident Response | Praxi on-call, SA Developer Liaison | SLAs (12h cyber / 3BD draft-OAIC / next-business-day outage), escalation chain, notification template, common-incident triage table. |
Who reads which
If you are SA Developer Liaison reviewing a Praxi NOI submission, the primary documents are the Software Product Description (what we are) and the Security Architecture (how we protect what we are). The Incident Response one-pager describes how Praxi will communicate with SA when something goes wrong. The Privacy Impact Assessment is supplied for context but is more directly relevant to tenants.
If you are a tenant completing your own Privacy Impact Assessment for your practice's APP 11 obligations or for an OAIC inquiry, the primary document is the Privacy Impact Assessment, which lists the Praxi-side controls and disclosures you can adapt into your own PIA. The Medicare Data Flow page in the billing section is the canonical subprocessor disclosure that supports the PIA.
If you are a Praxi on-call engineer responding to a Medicare-related incident, the primary document is the Incident Response one-pager, which has the lookup table from symptom to runbook.
If you are a tenant security team completing a security questionnaire for your practice's insurer or peak body, the Security Architecture is the page to quote from.
Related Praxi-internal documentation
The artefacts on this page are the SA-facing and tenant-facing public summaries. The engineering source of truth — the path-by-path, service-by-service, environment-variable detail, the on-call PRODA failure-mode and re-certification runbooks, the Medicare Test Clinic UAT procedure, and the breach-response plan — is maintained in Praxi's internal repository documentation and is deliberately kept out of these public artefacts. When a public artefact disagrees with the internal source of truth, the internal reference is authoritative and the artefact is scheduled for reconciliation.
Versioning footer convention
Every Medicare-related technical page in the Praxi documentation declares, in a footer at the bottom of the page, the Services Australia technical-interface-specification versions it was last verified against and the date of last verification.
The footer takes the form:
---
_SA spec conformance — Verified against TECH.SIS.MEDICARE.XX V<version>
(description) on YYYY-MM-DD._
For pages that touch multiple TECH.SIS specs, the footer lists each — for
example, medicare-claiming.md declares conformance against the Common Rules,
BBSW, PCIW, and OPVW specs in a single footer.
The TECH.SIS version numbers are the source of truth, maintained internally in Praxi's SA Documentation Hub. When a TECH.SIS spec version increments at SA's end, the internal catalogue is updated, and the affected documentation pages are then revised to match.
The convention is going forward: pages created or substantially edited after 2026-05-13 carry the footer. Pre-existing pages are retro-fitted on next revision, not in a sweeping back-fill — the footer is a quality signal, not a retrospective audit checkbox.
Cross-references
- Medicare Data Flow — the canonical subprocessor disclosure for tenant PIAs.
- Per-claim Audit Trail — what Praxi logs about every Medicare claim.
- Medicare Claiming — the end-user claiming workflow these artefacts apply to.
- Privacy Act compliance — the practice-wide privacy framework.
- Audit Logs — Praxi's general audit-logging architecture.