Praxi Medicare Software Product Description
This is the canonical Software Product Description prepared for submission to Services Australia under Interface Agreement 2020 v2.1. It will accompany Praxi's Notice of Integration (NOI) for certification and is the reference document that subsequent re-certification events compare against.
Per Services Australia MCOL Questions and Answers (Q&A 17), the values
declared on this page — in particular dhs-productId — are immutable until SA
processes a re-certification. Any change to product identity, message-payload
structure, authentication mechanism, or claim channel set triggers re-cert. See
Change control at the end of this document for the full
criteria.
Product identity
| Field | Value |
|---|---|
| Software name | Praxi |
| Product version | Praxi1.0 |
dhs-productId | Praxi1.0 (declared on every MCOL request; immutable until SA re-cert per MCOL Q&A 17) |
| Vendor | House of Praxi Pty Ltd |
| Vendor country | Australia |
| SA Developer Portal | Application "Praxi1.0", node/39915 |
| Primary contact | developerliaison@servicesaustralia.gov.au (vendor liaison) |
| Vendor support email | hey@praxi.au |
| Product website | https://praxi.au |
The dhs-productId header value is a single fixed product identifier emitted on
every MCOL request, every PRODA device-activation call, and every PRODA
key-rotation call. It is set platform-wide, with no per-tenant override.
Purpose and scope
Praxi is a multi-tenant SaaS practice-management product for Australian psychology, allied health, and counselling practices. Its scope, in relation to Services Australia, covers:
- Medicare Online Claiming (MCOL) for bulk-bill (
BBSW) and patient-claim (PCIW) workflows under the Better Access initiative, Chronic Disease Management (CDM), Eating Disorder Plan (EDP), Perinatal items, and the broader allied-health MBS schedule. - DVA Allied Health Psychology claiming via the
VAAWchannel, including support for Gold Card and White Card veterans with accepted-disability validation. - Patient and entitlement verification via
OPVW(Medicare card, mandatory before claim submission),OCVW(concession verification), andOVVW(veteran verification). - Same-day deletion via
SDDWfor patient-claim correction within one business day. - Report retrieval via
BPRW/BPYW(bulk-bill processing and payment), andDVRW/DVYW(DVA equivalents). - Bulk Bill Assignment of Benefit (DB4) capture per Services Australia's July 2026 mandate, supporting typed-name, tick-box and explicit acceptance consent modes.
- Safety Net threshold tracking for Original Medicare Safety Net (OMSN) and Extended Medicare Safety Net (EMSN), with per-organisation annual threshold values aligned to SA's January updates.
Praxi is not the patient's general-practice EMR. It is a practice-management
product for allied-health and mental-health providers who claim against MBS
items under the Better Access, CDM, and allied-health framework, or against the
DVA schedule for veteran patients. ECLIPSE in-hospital and private-health
insurance claiming is not implemented and is outside the Praxi1.0 NOI scope.
ECLIPSE has no claim dispatcher.
Architecture summary
Praxi runs as a multi-tenant SaaS on AWS in the Sydney region
(ap-southeast-2). The deployment topology is:
| Layer | Implementation |
|---|---|
| Web frontend (tenant) | Next.js 16 + React 19 |
| Web frontend (Praxi staff) | Next.js 16 |
| Mobile (practitioner) | SwiftUI native iOS (practitioner app) |
| Mobile (client) | SwiftUI native iOS (client portal app) |
| Backend API | NestJS 11 on Node.js 20 on ECS Fargate |
| Primary database | Amazon Aurora PostgreSQL 16 with row-level security (RLS) on every tenant table |
| Cache | Amazon ElastiCache (Redis 7) — PRODA token cache, rate-limit counters |
| Object storage | Amazon S3 (encrypted, ap-southeast-2 only) |
| Identity provider | Self-hosted Keycloak 23 on ECS Fargate (separate RDS instance) |
| Secrets | AWS Secrets Manager (encryption keys, PRODA private-key wrap key, SA API client identifier) |
| Observability | CloudWatch Logs + AWS X-Ray + Application Signals via OpenTelemetry |
| DNS | Route 53 + DNSSEC on praxi.au and subdomains |
Practice data is isolated using database row-level security and application access checks. Praxi's tenant data isolation is described in detail in Security Architecture.
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.
Claim channels implemented
| Channel | Services Australia operation |
|---|---|
| BBSW | Bulk bill submission |
| PCIW | Patient claim submission |
| SDDW | Same-day deletion |
| VAAW | DVA allied health submission |
| OPVW | Patient verification before claiming |
| OVVW | Veteran verification |
| OCVW | Concession verification |
| BPRW / BPYW | Bulk bill processing and payment reports |
| DVRW / DVYW | DVA processing and payment reports |
The full canonical channel inventory is maintained in Praxi's MCOL service layer and audited as part of Praxi's Medicare conformance checks.
EPVW, BIRW, STSW, DVA Medical, and ECLIPSE claim transport are not implemented
or declared for Praxi1.0. The July 2026 changes to TECH.SIS.PHI.01 v1.1.3 and
TECH.SIS.PHI.06 v1.2 concern ECLIPSE outbound and enterprise patient
verification behaviour. They do not alter Praxi's direct OPVW request-response
flow.
Authentication
Praxi authenticates with Services Australia using PRODA B2B Unattended, per B2B Unattended Developers Guide V4.2. Every MCOL request bears a Bearer access token obtained via JWT-bearer grant against the PRODA token endpoint.
Cryptographic profile
- Key type: RSA 2048-bit
- Signing algorithm:
RS256 - JWT format: Compact JWS with header
kid = deviceName - JWT assertion claims:
iss= PRODA org id,sub= device name,aud=https://proda.humanservices.gov.au,token.aud=https://medicareaustralia.gov.au/MCOL,iat,exp = iat + 600. - Token endpoint grant:
urn:ietf:params:oauth:grant-type:jwt-bearer.
Token lifecycle
| Item | Production | Vendor test | Praxi handling |
|---|---|---|---|
| Access token | 60 minutes | 60 minutes | Redis-cached for 55 minutes; refresh on demand |
| JWT assertion | 10 minutes | 10 minutes | 600 seconds |
| RSA key pair | 150 days | 180 days | Auto-rotated within 30 days of expiry |
| Device | 6 months | 62 months | Health monitor warns at 90/30/7 days remaining |
| Device Activation Code | 1 day | 7 days | Stale-DAC warning on activation |
| Auth-failure lockout | 5 failures | 5 failures | Alert at 3, hard-lock at 5 |
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.
Wire-level conformance
Required HTTP headers
Every MCOL request bears the following headers. Their values originate from two source modules in Praxi's MCOL layer — there is no third path that emits MCOL headers.
| Header | Format | Source |
|---|---|---|
Authorization | Bearer <PRODA access token> | Selected platform or practice PRODA identity |
X-IBM-Client-Id | SA-issued API key from SA Developer Portal | One platform API client identifier |
dhs-productId | Praxi1.0 | single fixed product identifier |
dhs-auditId | Location Minor ID, format AAANNNNN (8 characters) | Practice location’s allocated Minor ID |
dhs-auditIdType | Location Id | Constant |
dhs-subjectId | Medicare card number or DVA file number for this claim | Patient identifiers for this claim |
dhs-subjectIdType | Medicare Card or Veteran File Number | Per-claim |
dhs-messageId | urn:uuid:<UUID> — unique per HTTP attempt including retries | Freshly generated UUID per attempt |
dhs-correlationId | urn:uuid:<LocationMinorId><16 hex> — exactly 33 characters, stable across retries of one operation | Derived from the location Minor ID plus 16 random hex characters |
Content-Type | application/json | Constant |
Data format rules
Amounts. All money fields cross the wire as integer cents represented as
strings. chargeAmount is 3–7 characters; benefitPaid is up to 7 characters
and is absent when zero; patientContribAmount is only present on PCIW when
accountPaidInd='N'. Internally Praxi stores both the dollar Decimal column and
the cents Int column to guarantee SA-wire parity. Conversion is performed at the
API boundary by a dedicated amount-conversion utility.
Dates and times. Dates are YYYY-MM-DD. Datetimes are
YYYY-MM-DDThh:mm:ss.sTZD where TZD is an Australian offset between +06:30
and +12:00. Praxi never emits UTC Z on the wire. Conversion is performed
by Praxi's date-time handling, which always resolves Australian wall-clock
semantics regardless of the container's clock.
Medicare card number. Praxi validates the 10-digit Medicare card structure:
positions 1–8 are the card base; position 9 is a weighted-mod-10 check digit
using weights 1,3,7,9,1,3,7,9; position 10 is the card issue number (1–9,
never 0). The Individual Reference Number (IRN) is 1–9, never 0. Praxi does
not use the Luhn algorithm for Medicare; Luhn is for credit cards and gives
different results.
Provider number. Praxi validates the 8-character provider number: positions
1–6 are the numeric stem; position 7 is the practice-location character
(excluding I, O, S); position 8 is the check letter from the
weighted-mod-11 letter-mapping table. Praxi validates every provider number
against this rule before a claim is submitted.
Single-name patients. Praxi distinguishes single-name conventions between
channels: BBSW/PCIW expects familyName=name, givenName="Onlyname"; OPVW
expects familyName=name, givenName="*Onlyname*". The respective DTOs enforce
these conventions.
Sex codes. 1 = Male, 2 = Female, 3 = Other, 9 = Not stated.
Error response handling
SA returns errors in the ServiceMessagesType envelope with severity
Fatal > Error > Warning > Informational. Praxi parses every response through
its response parser and displays the reason text verbatim to the
practitioner — no truncation, no rewording, no localisation. This is a Services
Australia conformance requirement. Reason mapping for end-user remediation
appears alongside the verbatim SA text but never replaces it. The full mapped
error catalogue is published in
Medicare Error Codes and exposed
through the in-product error-detail Sheet.
Validators
Praxi's input-validation guarantees (enforced at the controller boundary via
Zod-derived DTOs in @anatine/zod-nestjs):
- Medicare card number — 10 digits, weighted-mod-10 check on position 9,
position 10 in
[1-9] - IRN — single digit
[1-9] - DVA file number — alphanumeric, length 8–9
- Provider number — 8 characters, position-7 letter exclusion (
I,O,S), weighted-mod-11 letter check at position 8 - Location Minor ID —
AAANNNNN(3 letters + 5 digits), per Correct Use of Minor ID v1.1 - MBS item — present on SA-published schedule for the service date (Praxi syncs the MBS schedule daily at 0800 AEST)
- DVA service-type code —
Kfor allied-health psychology (VAAW); SA spec is explicit thatSis for Medicare specialist claims andKis for DVA allied-health, and Praxi rejects payloads mixing the two
SA spec conformance — versioning footer
Praxi declares conformance against the following Services Australia technical-interface-specification versions as of 2026-08-12:
| TECH.SIS reference | Praxi-implemented version |
|---|---|
| TECH.SIS.MEDICARE.01 — Common Rules | V2.1.9 |
| TECH.SIS.MEDICARE.02 — BBSW (Bulk Bill Store-and-Forward) | V2.1.4 |
| TECH.SIS.MEDICARE.03 — BPRW / BPYW Reports | V2.0.9 |
| TECH.SIS.MEDICARE.04 — PCIW (Patient Claim Interactive) | V2.1.6 |
| TECH.SIS.MEDICARE.05 — SDDW (Same-Day Delete) | V2.0.3 |
| TECH.SIS.MEDICARE.06 — OPVW / EPVW (Patient Verification) | V1.1.0 (OPVW only) |
| TECH.SIS.MEDICARE.07 — OCVW / ECVW (Concession Verification) | V2.0.4 (OCVW only) |
| TECH.SIS.DVA.02 — DVA Allied Health (VAAW) | V1.0.08 |
| TECH.SIS.DVA.03 — DVRW / DVYW Reports | V1.0.05 |
| TECH.SIS.DVA.04 — OVVW / EVVW (Veteran Verification) | V1.0.05 (OVVW only)¹ |
| Medicare Online and ECLIPSE Change Guide | V3.4.9 |
| PRODA B2B Unattended Developers Guide | V4.2 |
| Interface Agreement 2020 | v2.1 |
| Third Party Security Policy | v2.1 |
| Version Control Policy | v2.0 |
| Correct Use of Minor ID | V1.1 |
¹ Implemented against V1.0.05. The V1.0.06 update (current on the SA library,
reviewed 2026-08-11) reinstates the single-name patient convention — family name
carries the name and given name is Onlyname — which Praxi already implements.
Conformance against V1.0.06 will be re-declared once the updated specification
is incorporated into the vendor reference library.
Spec versions are tracked internally in Praxi's SA Documentation Hub, the single index Praxi operators consult when reproducing SA-supplied PDFs verbatim during conformance verification.
Compliance posture
- Australian Privacy Principles — Praxi is the service provider to its tenants, who are the primary APP entities for their practices. Praxi acts under SaaS Agreement and Privacy Policy controls.
- Privacy Act 1988 — 7-year audit retention, AES-256-GCM encryption for
sensitive identifiers,
ErasureRequestworkflow under §12B. - Health Insurance Act 1973 / National Health Act 1953 — DB4 Bulk Bill Assignment of Benefit capture, 2-year retention per SA rule.
- AHPRA / Health Records Acts — minimum 7-year clinical-record retention.
- Interface Agreement 2020 v2.1 — incident notification SLAs are surfaced in Incident Response. Essential Eight Maturity Level 3 alignment is described in Security Architecture.
- ISO/IEC 27001 — alignment, not formally certified.
- SOC 2 Type II — in-progress (controls defined; first observation window underway).
Change control
Per Version Control Policy v2.0 and MCOL Q&A 17, the following changes trigger re-certification with Services Australia. Praxi declares them here so SA reviewers can see the criteria Praxi will hold itself to:
dhs-productIdchange. Any version increment that changes the SA Developer Portal application identity (e.g.Praxi1.0→Praxi2.0) requires re-cert. Cosmetic version increments that retain the samedhs-productIdvalue do not.- Message-payload structural change. Adding/removing fields, changing the cardinality of nested arrays, or altering the semantics of an existing field on any MCOL endpoint that Praxi consumes.
- Authentication mechanism change. Migration off PRODA B2B Unattended, change of JWT assertion claims structure, change of cryptographic profile (e.g. RSA → EC).
- New claim channel. Implementing a previously-uncertified MCOL endpoint
(e.g. adding
IHCWto a today's allied-health profile). - Hosting region change. Migration of production data residency away from
ap-southeast-2.
Internal Praxi changes that do not trigger SA re-cert:
- UI/UX refinements that do not affect submitted payload semantics.
- Refactors that preserve wire-level behaviour and conformance test outcomes.
- Performance, observability, and operational improvements.
- Adding non-Medicare features (clinical notes, telehealth, assessments).
The procedure for an SA-triggering change is documented in Praxi's internal re-certification runbook, which Praxi's Medicare conformance tests reference on the relevant gate.
Cross-references
- Security Architecture — the detailed security and key-management view.
- Privacy Impact Assessment — privacy-risk register and mitigations.
- Incident Response — incident-notification SLAs and runbook entry points.
- Medicare Data Flow — subprocessor disclosure for tenants.
- Medicare Claiming — the end-user workflow this product supports.
- This page restates the SA-facing subset of Praxi's internal engineering source of truth, which carries additional implementation detail kept out of public artefacts.
SA spec conformance — Verified against TECH.SIS.MEDICARE.01 V2.1.9 (Common Rules), TECH.SIS.MEDICARE.02 V2.1.4 (BBSW), TECH.SIS.MEDICARE.04 V2.1.6 (PCIW), TECH.SIS.MEDICARE.06 V1.1.0 (OPVW), TECH.SIS.DVA.02 V1.0.08 (VAAW), PRODA B2B Unattended V4.2, Interface Agreement 2020 v2.1 on 2026-05-13; re-verified against the implementation on 2026-08-12.