Why the Stage 3 DEX fields you see may differ from the CHSP guide

When we built CHSP Stage 3 DEX reporting into Comm.care, we learned a lot — mostly the hard way. This article is where we've compiled everything: the gotchas, the places where the Department's own guide disagrees with what DEX actually does, the fields that behave differently to how they're described, and the edge cases that aren't documented anywhere except in rejection error messages.

Fair warning: this is a long one. It's CHSP. Of course it's a long one.

We don't expect anyone to read this top to bottom — not even us, and we wrote it. Treat it as a reference. Ctrl+F your way to the section you need, figure out why DEX is rejecting your session, and get on with your day.

If you'd like to talk through how Stage 3 applies to your specific services — or if something here doesn't match what you're seeing in DEX — reach out to us. We're happy to help.

On 11 August 2026, fifteen new session-level fields became mandatory in DEX production for CHSP reporting. There was no optional phase. The Department also expects the data captured for all services delivered from 1 July 2026, so most providers have a backfill gap of several weeks.

The CHSP Data Exchange guide (from 1 July 2026) sets out which fields apply to which activity in Table 2 on page 56. That table is accurate for most rows — but it is a human-readable summary, not the mechanism. DEX itself tells your software which fields apply, per service type, every time your organisation syncs its reference data.

Where the two disagree, DEX wins — because DEX is what accepts or rejects your session.

This article documents what Stage 3 added, how DEX communicates the rules, and every place we found the published guidance and the live DEX data giving different answers.

1. What Stage 3 added

Fifteen fields, all at session level — they attach to the session record, not to individual line items.

The meal fields are counts, not checkboxes. The guide presents "Meal Type Fields" as a list of meal types, which reads like tick-boxes. DEX expects quantities.

2. How DEX tells your software which fields apply

Every service type your organisation is funded for comes back from DEX with a list of service-type specific requirements. Each one is a code from the list above, plus a description stating whether it's mandatory.

In simplified form, one service type looks like this:

Name: "Direct transport"
ServiceTypeSpecificRequirements:
  - Code: SUBCONTRACTORDELIVERED   "…is required and must be supplied…"
  - Code: VOLUNTEERDIRECTSERVICE   "…is required and must be supplied…"
  - Code: ENGAGEMENTTIME           "…is optional and can be supplied…"
  - Code: TRIPTIME                 "…is optional and can be supplied…"
  - Code: TRIPDISTANCE             "…is optional and can be supplied…"
  - Code: ASSISTANCEQUANTITY       "…is required and must be supplied…"

That list is the rule. If a code is present, the field applies. If it isn't, the field doesn't apply and shouldn't be sent. The description says whether it's mandatory.

Two consequences worth understanding as a provider:

Your fields can change without a software update. If DSS adjusts which service types carry which codes, well-built software picks it up on your next reference-data sync. Nothing needs to be rebuilt.

Your fields only update when your reference data syncs. If your organisation hasn't synchronised its DEX reference data since 11 August 2026, your software may still be working from the pre-Stage-3 rules. This is worth checking with your vendor as the first troubleshooting step if your screens don't show the new fields.

3. The terminology trap: "Program Activity" and "Service Type" are swapped

This one causes more confusion than anything else in Stage 3, and it's stated only once in the guide, in section 1.2:

"DEX reporting for CHSP is structured to the equivalent Program Activity (CHSP Service Type) and Service Type (CHSP Service) levels."

In other words:

So when Table 2's second column says "DEX Service Type", it means the CHSP Service — the specific thing you deliver. And when it says "All", it means every CHSP Service sitting under that activity.

If you have been reading Table 2 as "activity, then service type" in CHSP terms, you have been reading it one level off.

4. Where the guide and DEX disagree

We compared Table 2 against the requirement codes DEX actually returns, across 869 service-type records covering 114 program activities for a live organisation. Eighteen of the nineteen rows matched exactly. Here is everything that didn't, plus the structural differences the table can't express.

4.1 Specialised Support Services — the guide names one service, DEX applies it to six

Table 2 lists:

DEX returns those two codes for all six services under that activity:

• Client advocacy
• Continence advisory services
• Dementia advisory services
• Hearing advisory services
• Other clinical advisory support
• Vision advisory services

Why it matters: if your software was built by reading Table 2, it will only prompt for sub-contractor and volunteer on Vision advisory services. Sessions for the other five will be submitted without mandatory fields and rejected by DEX. This is the single most consequential difference we found.

4.2 The same service can need different fields under different activities

Table 2 is organised by activity, which hides the fact that some CHSP Services sit under more than one activity — and get different Stage 3 fields depending on which.

Three services appear under both Group social support and Individual social support:

Session location is mandatory. So the exact same service name needs an extra mandatory field under one activity and not the other. This is consistent with Table 2 — Individual social support has a tick in the Session Location column and Group social support doesn't — but you can only see it if you already know those services sit under both.

The guide's own worked examples confirm it: §4.7 Example 3 records Service type = Cultural support with Session Location = Community, under Individual social support.

Practical effect: software that decides which fields to show based on the service name alone will get these three wrong. It has to know which activity the service was delivered under.

4.3 Meal counts — the guide omits them, DEX requires them

This is a genuine conflict, not a misreading.

The guide's §4.2 worked examples show meal fields disappearing when no meals were provided:

DEX, however, marks all five counts as "required and must be supplied with a valid value", with no stated dependency on the Meals provided answer.

So a provider following the guide would leave the counts blank on a no-meals respite session; DEX's own rules say they must be supplied. Until DSS clarifies, the safe reading is that 0 is a valid answer — "zero main meals" is a complete response, whereas an omitted field may be rejected as missing.

If your software hides the counts when you answer "No", ask your vendor what happens on submission.

4.4 Meals provided and Meals cooked offsite never appear together

Not a disagreement, but a structural fact that surprises people:

Meal delivery never asks "were meals provided" — meals are the service, so the counts apply directly. The three respite services never ask about offsite cooking. Across all 869 records we checked, these two codes never co-occur.

4.5 The specification contradicts itself on field names

Technical, but it explains why different vendors may have shipped different behaviour. The February 2026 Web Services Technical Specification (v6) spells three fields three different ways across its own field tables, XML samples and Appendix B:

These names are case-sensitive on the wire. The published WSDL — the machine-readable contract DEX validates against — settles it: IsOvernightSupportIncluded, ServiceLocationSettingCode, TripTimeMinutes. In each case the field table is the odd one out.

4.6 Optional fields are described differently in the spec and the server

Appendix B calls three fields "a non mandatory field". DEX's own response text says "is optional and can be supplied". Same meaning, different words — which matters only if you built your software by reading the PDF rather than the response.

The three optional fields are the same either way: Engagement time, Trip travel time, Trip distance. The other twelve are required wherever they apply.

5. Why some providers will find these differences much later than others

There are two ways reporting software gets data into DEX, and the difference decides when you find out something is wrong.

Bulk XML file upload. The software builds a file containing your sessions and uploads it to DEX. The rules about which fields belong on which session have to be worked out in advance — in practice, by the vendor reading the specification and the CHSP guide. Errors come back when the file is processed.

Direct connection to the DEX web services. The software talks to DEX over its API. It can ask DEX which requirements apply to a given service type and get the answer back as data, before anyone fills in a session.

For most DEX changes the distinction barely matters. For Stage 3 it matters a great deal, for three reasons.

The rules aren't in the file format — they're in a separate request

A bulk upload file has nowhere to ask a question. The requirement codes described in section 2 come from a web services operation, so a system built purely around file upload has no route to them and no choice but to encode the published table. That's precisely where the differences in section 4 live — a table-driven implementation prompts for sub-contractor and volunteer on Vision advisory services and misses the other five, and there's nothing in the upload process to reveal it until DEX rejects the sessions.

An accepted upload is not proof of compliance

This is DSS's own warning, from §1.1 of the CHSP Data Exchange guide:

"As the Data Exchange is built to accommodate a wide variety of Commonwealth and State government program reporting, functions that are common across programs may 'allow' the reporting of CHSP data outside of program parameters (e.g. a bulk XML upload may be accepted with service types not included in the funded organisation's CHSP funding agreement)."

The same section adds:

"Where outputs have been recorded inappropriately the performance assessment for the funded organisation will be affected."

So a file that uploads cleanly can still contain reporting you weren't funded for — and the consequence lands on your performance assessment, not on the file.

The data can't be reconstructed later

This is the practical difference for your coordinators. When MAC IDs became mandatory, a late error was recoverable: the client's My Aged Care ID still exists and can be looked up next week.

Stage 3 is not like that. If a session on 14 July is rejected in late August for a missing dessert count, someone has to work out how many desserts were served at a respite session six weeks ago. Roster notes and kitchen records may cover it. Often they won't.

The gap between "prompted while writing the progress note" and "flagged after the batch is submitted" is the gap between recording data and reconstructing it. Stage 3 being retrospective to 1 July 2026 makes that gap the main cost of the whole change.

And responsibility sits with you either way

Also from §1.1:

"The use of third party vendors' DEX reporting software does not limit the funded organisation's responsibilities regarding the timeliness and accuracy of DEX data submissions."

Worth reading twice. However your software works, the Department holds the funded organisation accountable for what reaches DEX.

How to tell which you have

Ask your vendor, or check your own experience:

• When you save a progress note with something missing, do you get the error on the screen straight away, or later, in an upload report or an error file?
• Can your system tell you before you deliver a service which Stage 3 fields that service type needs?
• When DSS changes the rules, does your provider need to ship a software update, or does your system pick it up when you sync your DEX reference data?
• Does your system stop you selecting service types your organisation isn't funded for?

None of these are exotic questions. They're reasonable things to expect an answer to, and the answers determine how much of Stage 3 lands on your staff instead of on your software.

6. Table 2 as published

Reproduced for reference. Sub = sub-contractor, Vol = volunteer, Loc = session location, O/N = overnight support, Eng = engagement time, Trip = trip time and distance, Meal = meals provided / cooked offsite / texture / counts.

Note that "Meal" collapses four separate fields, and the fields differ between respite and Meal delivery — see 4.4.

7. What "All" actually expands to

Table 2 says "All" for eleven of nineteen rows without listing the services. Here is what DEX returned for each of those activities in the data we examined. Your organisation's list may differ depending on what you're funded for.

Allied health and therapy services (13): Aboriginal and Torres Strait Islander health practitioner assistance · Aboriginal and Torres Strait Islander health worker assistance · Allied health assistance · Counselling or psychotherapy · Diet or nutrition · Exercise physiology · Music therapy · Occupational therapy · Physiotherapy · Podiatry · Psychology · Social work · Speech pathology

Therapeutic services for independent living (6): Acupuncture · Art therapy · Chiropractics · Diversional therapy · Osteopathy · Remedial massage

Domestic assistance (3): General house cleaning · Laundry services · Shopping assistance

Personal care (3): Assistance with self-care activities of daily living · Assistance with the self-administration of medication · Continence management (non-clinical)

Nursing care (3): Enrolled nurse · Nursing assistant · Registered nurse

Home maintenance and repairs (2): Assistance with home maintenance and repairs · Gardening

Equipment and products (5): Communication and information management products · Domestic life products · Managing body functions · Mobility products · Self-care products

Group social support (4): Accompanied activities · Cultural support · Digital education and support · Group social support

Individual social support (5): Accompanied activities · Assistance to maintain personal affairs · Cultural support · Digital education and support · Individual social support

Specialised Support Services (6): Client advocacy · Continence advisory services · Dementia advisory services · Hearing advisory services · Other clinical advisory support · Vision advisory services

8. Field notes that catch people out

Water is not a beverage. From the guide: "Water being provided throughout the course of the session is not considered provision of a beverage and does not need to be recorded in the meal type fields."

Partial meal provision. If the client provided some meals and you provided the rest, answer Meals provided = Yes and record only what your organisation provided.

Trip travel time is client-in-vehicle time only. Travel to the pick-up point and back from the drop-off doesn't count.

Engagement time is not service time. It's the connectedness and trust-building time additional to the service, and it applies to Direct transport and Meal delivery — not to Indirect transport, where the trip is a taxi or rideshare service.

Trip time is entered as hours and minutes but stored as minutes. DEX's technical documentation describes it both ways; the actual field is a single minutes value.

Session location is a reference-data code, not free text. Home or Community, drawn from DEX's own reference data.

Meal delivery gets engagement time; respite doesn't. And engagement time is optional wherever it appears, including on Meal delivery — a point Table 2 marks with green shading that's easy to miss in a printed copy.

9. Service types have start and end dates

Every service type DEX returns carries an availability window. In one organisation's data we examined, 48 of 62 service types had expired — all on 16 July 2025, and all named with a DNU prefix ("Do Not Use"). They were the pre-2025 CHSP service list, still present in the data but no longer valid.

Two practical points:

• If your software offers you service types that look outdated or are prefixed DNU, they shouldn't be selectable.
• Availability should be judged against the date the service was delivered, not today's date. If you're completing a backfill for July, a service type that expired in August must still be selectable for a July session.

10. What to do now

1. Sync your DEX reference data. Nothing else works until your system holds the post-11-August requirement codes. Check with your vendor how this is triggered in your product — in many systems it's a manual action, not automatic.

2. List the CHSP activities you're funded for. Only some carry Stage 3 fields. If you deliver only, say, Domestic assistance and Personal care, your change is two new questions — not fifteen.

3. Identify sessions delivered on or after 1 July 2026 that were submitted without Stage 3 data, or that failed submission after 11 August. That's your backfill list.

4. Decide how you'll reconstruct the data. Rosters, run sheets and meal records are the usual sources. DSS expected this recorded in your own systems in the interim, so it may already exist outside DEX.

5. Check the six Specialised Support Services if you deliver any of them — see 4.1. This is where a table-driven implementation fails silently.

6. Confirm what your software does with meal counts when you answer Meals provided = No — see 4.3.

Where Comm.care is up to

Comm.care is delivering Stage 3 in September 2026. Affected customers were contacted directly on 17 August with a holding update.

We should be straight about this: DSS flagged Stage 3 in February 2026, opened its staging environment for vendor testing on 23 February, and confirmed the 11 August go-live date on 22 June. The information was available and we did not act on it early enough. That's on us, not on the Department.

What we have changed as a result: Comm.care reads the requirement codes DEX returns for each of your service types and renders exactly those fields. No hardcoded copy of Table 2, no per-activity rules in our code. When DSS changes which service types need which fields — as they have three times now — your screens follow on your next sync rather than waiting for a release.

Sources and verification

• CHSP Data Exchange Guide (from 1 July 2026) — Table 2, p. 56; terminology in §1.2; worked examples in §4.2, §4.4, §4.7; Appendix A chronology. Published 15 July 2026.
• DEX Web Services Technical Specification v6 (3186) — Stage 3 field definitions; requirement codes in Appendix B, pp. 150–152. Published February 2026.
• CHSP Guide to Data Exchange Stage 3 Changes — plain-English field definitions. Published February 2026.
• CHSP DEX Implementation Update (June 2026) — confirmed 11 August go-live; "There will not be an 'optional' phase". Published 22 June 2026.
• Live DEX data — 869 service-type records across 114 program activities for one funded organisation, plus a second organisation's records, retrieved 19 August 2026. All statements about what DEX returns are drawn from these.
• Published DEX WSDL — retrieved 19 August 2026 from the staging and production endpoints.

Where this article says "DEX returns" or "DEX requires", it describes the data we observed for the organisations we examined. Your organisation's requirement codes depend on the activities you're funded for and should be read from your own DEX reference data.

%% REVIEW NOTES — remove before publication

Decisions Juan needs to make:

1. Publish timing. Recommend holding until PX-031 ships (September). Publishing a "DSS documentation has gaps" piece while our own customers are non-compliant reads as deflection, however carefully worded. Section 9 ("Where Comm.care is up to") is an attempt to defuse that — it may not be enough.
2. Report to DSS first. Findings 4.1 and 4.3 are genuine defects the Department would likely want to fix. Sending these through the affected orgs' FAMs before publishing is both more useful and better positioned than publishing first.
3. Audience. This is long and technical. Sections 4.5 and 4.6 are vendor-facing, not provider-facing — consider cutting them or splitting into a second technical post.
4. Section 9 wording. The admission is deliberate per the Digital Authenticity voice guide ("don't hide limitations or challenges"), and because the timeline is falsifiable from public documents and any provider's FAM. Confirm the tone is what you want.

Claims to double-check before publishing:

• "~19 activities / ~56 services" — the 56 figure comes from the SaH reference data analysis, not directly from a CHSP source. Verify against the CHSP Service Catalogue 2025-27 or soften to "around fifty".
• Section 6's service lists come from one organisation's funded activities. Verify they're the complete national lists against the CHSP Service Catalogue before publishing as reference.
• Section 8's "48 of 62 expired" is from a second, smaller organisation — different sample from the 869-record set. Wording is accurate but worth stating plainly if a reader cross-references.
• The CTA assumes the Comm.care behaviour described ships as designed. Don't publish ahead of the release.

Not included, deliberately:

• The DEX service type ID instability across environments (a vendor problem, not a provider one).
• Internal implementation detail — resolution chains, collection names, schema shapes.
• Any claim that the announcement was late, hidden, or changed. It wasn't; see PX-031's communications timeline.

Source project: PX-031 DEX Stage 3 %%