ADHA Conformance Testing: A Preparation Checklist

How ADHA conformance is structured

The Australian Digital Health Agency runs conformance under its published Conformance Framework, service by service. For each national capability — My Health Record, the HI Service, electronic prescribing — there's a Conformance Assessment Scheme (CAS) describing how software is assessed, conformance profiles stating the requirements, and test specifications translating them into executable test cases. Since 2015 the model has been industry self-declaration backed by observed testing: you execute the tests, the Agency's testing partner observes the formal runs, and you sign a declaration that carries legal weight.

Two structural facts drive all planning. Conformance attaches to a specific product version, for a specific set of use cases — not to your company. And the scope is set early, by what you nominate: the use cases on your Vendor Product Details form determine your test data pack, your test cases, and your obligations. Scope is the single biggest lever you control.

Which schemes apply to which products

Scope follows product type. Rough mapping, to be confirmed against the current schemes:

• A clinical information system uploading to or reading the national record → My Health Record CAS plus HI Service requirements, and the security conformance profile — the path covered in the My Health Record integration guide.
• Prescribing, dispensing or medication chart software → the electronic prescribing scheme's profile for that product class, plus HI Service, plus exchange onboarding.
• A hosted/multi-tenant platform → the same schemes under the Contracted Service Provider model, which changes registration and certificate arrangements more than it changes the tests.
• A consumer or mobile app reading My Health Record → the FHIR Gateway's own registration and assessment pathway, materially different from B2B conformance.

The artefacts you'll produce

Expect the paper trail to be a workstream of its own. Across the schemes, the recurring artefacts:

• Vendor Product Details (VPD) form — registers the product and nominates use cases. Everything downstream is derived from it; treat it as a scoping decision, not paperwork.
• Test data pack and test specifications — issued to match your nominated scope; your team executes these in the vendor test environment (SVT for My Health Record and HI Service work).
• Self-assessment evidence — documented results of the self-paced test runs, which precede and gate the observed sessions.
• Notice of Connection (NoC) — the outcome of the observed web-service testing for the product version; described in detail in the My Health Record integration guide.
• Conformance / clinical-usage evidence (CCD) — for requirements observation of web services can't verify: how the software presents record content, manages consent workflows, and meets clinical safety requirements.
• Security conformance evidence — the Security Requirements for My Health Record Connecting Systems profile involves evidence verification, not just declaration. Expect to substantiate claims about your software's security posture.
• The declaration — the Conformance Vendor Declaration Form (or scheme equivalent, such as electronic prescribing's Declaration of Conformance), signed for the product version, which authorises production connection.

Where the calendar time actually goes

Teams budget for build time and underestimate everything around it. The recurring consumers of weeks:

• Sequencing dependencies. HI Service capability underpins everything else, NASH credentials underpin connectivity, and test environment access has its own onboarding. These serialize ahead of any formal testing.
• Scheduling observed sessions. Formal NoC runs are booked with the Agency's testing partner; lead times exist and re-runs after a failed session go to the back of the queue. Enter observed testing only when self-assessment is genuinely clean.
• Unhappy-path rework. The test specifications exercise error handling — mismatches, statuses, access denial, superseded identifiers. Teams that built happy-path-first fail here and rework under schedule pressure.
• The evidence workstreams. Security evidence and clinical-usage requirements involve people outside the integration team — security engineers, clinical governance, UX. Start those threads when development starts, not when testing ends.
• Change control afterwards. Conformance is per version. Changes to conformance-relevant functionality trigger re-assessment of affected scope, so the release process needs a 'does this touch conformance?' gate permanently.

The ADHA conformance preparation checklist

Common failure modes

• Over-scoping release one. Nominating every document type and use case you might ever support multiplies test scope now for capability you won't ship for years. Conform narrow, extend later — extension testing on a conformant product is a far better position.
• Treating conformance as a testing phase. Teams that first read the test specifications after build discover requirements that live in their data model. Conformance is a design input.
• Booking observed sessions optimistically. A failed observed run costs a re-booking queue, not an afternoon. The self-assessment gate exists to protect you; respect it.
• Losing the version thread. Hotfixes and refactors ship, and a year later nobody can say whether production still matches the declared version's conformance-relevant behaviour. The version-to-declaration mapping needs an owner.
• Forgetting the customer's paperwork. The software is conformant, the pilot site has no HPI-O and no NASH certificate, and go-live slips a month on registration lead times that were knowable on day one.