HomeNSW

Reporting Worklist

Mandatory funding reports for Global Health Demo. Click any report to generate, validate, and submit it.

!
Overdue
0
action required
⏰
Due this week
0
across reports
↻
In progress
0
started, not submitted
✓
Submitted (last 30 days)
0
accepted by authority

Reporting Calendar — FY 2026-27

Submission windows for every mandatory report.

ℹ︎
Green cells indicate submitted periods, amber cells are upcoming due dates, red cells indicate the current submission window. Teal cells indicate continuous (real-time) feeds.

Submission History

Past extracts and submissions.

Reference Materials

Source documentation and contact details for each funding authority.

Specification Changes

Upcoming and in-force changes to funding reporting specifications. Filter by jurisdiction, severity, or effective date.

Data Sources & Integrations

A site has one active source EMR at a time. Mastercare Reporting normalises that source's data through the Allied Health canonical model and generates compliant submissions for every state, territory and national MDS — no matter which EMR you run. Switch the active source below to see what the demo looks like for each option.

Live ingestion architecture

The active source feeds into the Allied Health canonical model, which is then transformed by jurisdiction-specific generators. Switching the source EMR doesn't change the canonical model or the MDS generators — only the leftmost stage. That's the architectural reason compliance keeps working when an EMR changes underneath.

Active source EMR
Mastercare EMR
Global Health · Native
→
Ingestion
FHIR / Adapter / Native
Pull, push, subscription
→
Canonical model
Allied Health Core
158 normalised fields
→
MDS generators
30+ collections
Per spec version
⌖
Active source
1
connected at this site
↓
Records ingested today
0
live as of now
◐
Mapping coverage
0%
canonical fields populated
!
Mapping warnings
0
unresolved (last 24h)
▷

Live sync activity

Real-time stream of records flowing from source EMRs into the canonical model
ℹ︎
How this is sold: A site has one source EMR active at a time. Mastercare customers connect via the native source (free, real-time). Non-Mastercare sites license a certified adapter or use the FHIR R4 endpoint. Switching EMRs later only swaps the source — the canonical model and all 30+ MDS generators stay the same, so your entire compliance setup carries over.

Mapping Studio

Configure how source EMR data normalises to the Allied Health canonical model and onto state, territory and national MDS targets. The studio is where new source fields are wired up, code translations are managed, and gaps are surfaced — without writing code.

Source values are translated to canonical values using lookup tables, which then map to the official AIHW / state code sets. New source values are surfaced as pending until reviewed.
Derivation rules compute canonical fields from other fields rather than mapping them directly — for example, age at admission from DOB and admission date, or episode-of-care boundaries from grouped service contacts.
For each MDS in scope, this view shows whether the active source's mappings cover all required fields. Anything below 100% indicates fields that need attention before a clean submission is possible.
ℹ︎
What this means for the demo: ~85–90% of canonical fields auto-map for any well-known source. The remaining 10–15% are typically codes that need translation tables or fields that need a default. Onboarding a new site usually takes 2–5 days of mapping review, not weeks of integration work.

Allied Health Canonical Model

The central data model that every source EMR feeds into and every MDS submission generates from. By keeping sources and targets independent of each other — both sides only ever know about the canonical model — we can support a new EMR by writing one source adapter, and a new state MDS by writing one generator, without touching anything else in the platform.

Source-agnostic by design

This model is the architectural moat. It absorbs the regulatory complexity of 30+ MDS submissions across 8 jurisdictions spanning allied health, community health, mental health, AOD, rehab, family services and disability — the eight code systems they reference (METeOR, SNOMED CT-AU, AS 1269, SACC, ICD-10-AM, ANZSCO, ABS-SEIFA, AHPRA) — and the variable shapes of every source EMR. Sources change. State specs change. The canonical model is what makes that survivable.

⌖
Canonical entities
0
core domain objects
⊞
Canonical fields
0
across all entities
⚭
Code systems
0
referenced
↑
MDS targets generated
0
national + state + territory
Browse the canonical model entity by entity. Each field declares its type, whether it's required, the code system it draws from, and which MDS submissions consume it. Click any field for full detail.
The inverse view — pick an MDS submission, see exactly which canonical fields it draws from, in what order, with what format, and any per-MDS transformation notes. This is the spec-by-spec view that compliance teams want when they ask "what would a clean submission look like?"
Code systems and value sets referenced by the canonical model. Most submissions use METeOR (the AIHW metadata registry), but several pull in SNOMED CT-AU for clinical terminology, AS 1269 for languages, and SACC for countries.
ℹ︎
Why this is the moat: a competitor adding allied health reporting would need to redefine this entire model from scratch — including the parts that aren't visible on the surface (derivation rules, code system mappings, episode boundary logic, profession code translations, jurisdictional variants). That's years of regulatory work, not a feature build.

Site Configuration — Reports in Scope

Configure which statutory reports apply to this site based on the programs delivered, funding sources, and patient populations served. Disabled reports are hidden from the worklist, calendar, history and spec-change views.

Report name

Authority · frequency · due window
1
Reporting period
2
Generate extract
3
Validate
4
Submit

Set reporting period

Confirm the period this submission covers. The system auto-suggests the next outstanding period for this collection.

Generate extract

Run the extraction process to pull all eligible records from Mastercare for the selected period.

Validate against specification

Run all validation rules required by the receiving authority. Errors must be resolved before submission.

Review and submit

Final review before transmission to the receiving authority.

Notifications
View worklist →