FHIR Frog AU Core Conformance Tests
0.1.0 - draft
FHIR Frog AU Core Conformance Tests, published by FHIR Frog. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/jgsuess/au-core-tests/ and changes regularly. See the Directory of published versions
| Official URL: http://fhirfrog.org/fhir/au-core-tests/TestScript/au-core-sexassignedab | Version: 0.1.0 | |||
| Active as of 2026-08-16 | Computable Name: AUCoreSexAssignedAtBirth | |||
Covers the AU Core Sex Assigned at Birth extension (au-core-rsg-sexassignedab, 2.0.0) requirements identified in fhirfrog/au-core-compiler#25 (AUC-026). Correction to the issue's own framing, discovered while authoring this TestScript: au-core-rsg-sexassignedab is a content-level refinement of the generic individual-recordedSexOrGender extension, not a separately-URL'd one - its own snapshot fixes Extension.url to the base extension's canonical URL (http://hl7.org/fhir/StructureDefinition/individual-recordedSexOrGender), not its own. au-core-patient DOES inherit a Patient.extension:recordedSexOrGender slot from its au-patient (AU Base) baseDefinition (visible only in the snapshot, not the differential - which is why the original gap-analysis missed it), typed generically against individual-recordedSexOrGender rather than specifically against au-core-rsg-sexassignedab. So the real, narrower gap is: nothing distinguishes/tests the 'sex assigned at birth' flavour specifically (identified only by the fixed SNOMED 1515311000168102 'Sex assigned at birth' value on its extension:type sub-extension) from other uses of that same generic slot. Covers presence of both must-support sub-extensions (extension:value - biological sex, extensible-bound to the AU THS biological-sex-1 ValueSet; extension:type - fixed to the SNOMED code identifying this specific flavour) via a generic FHIRPath probe against a fetched Patient, exactly as the issue itself suggested was possible without any new engine capability. ProfileValidation runs validateProfileId against au-core-patient to confirm the whole resource - extension included, now correctly url'd to match the inherited slot - remains profile-conformant.
url: TestScript AU Core Sex Assigned at Birth extension — presence & profile conformance
version: 0.1.0
name: AUCoreSexAssignedAtBirth
title: AU Core Sex Assigned at Birth extension — presence & profile conformance
status: Active
date: 2026-08-16 05:55:37+0000
publisher: FHIR Frog
contact: FHIR Frog: https://gitlab.com/fhirfrog
description:
Covers the AU Core Sex Assigned at Birth extension (au-core-rsg-sexassignedab, 2.0.0) requirements identified in fhirfrog/au-core-compiler#25 (AUC-026). Correction to the issue's own framing, discovered while authoring this TestScript: au-core-rsg-sexassignedab is a content-level refinement of the generic individual-recordedSexOrGender extension, not a separately-URL'd one - its own snapshot fixes Extension.url to the base extension's canonical URL (http://hl7.org/fhir/StructureDefinition/individual-recordedSexOrGender), not its own. au-core-patient DOES inherit a Patient.extension:recordedSexOrGender slot from its au-patient (AU Base) baseDefinition (visible only in the snapshot, not the differential - which is why the original gap-analysis missed it), typed generically against individual-recordedSexOrGender rather than specifically against au-core-rsg-sexassignedab. So the real, narrower gap is: nothing distinguishes/tests the 'sex assigned at birth' flavour specifically (identified only by the fixed SNOMED 1515311000168102 'Sex assigned at birth' value on its extension:type sub-extension) from other uses of that same generic slot. Covers presence of both must-support sub-extensions (extension:value - biological sex, extensible-bound to the AU THS biological-sex-1 ValueSet; extension:type - fixed to the SNOMED code identifying this specific flavour) via a generic FHIRPath probe against a fetched Patient, exactly as the issue itself suggested was possible without any new engine capability. ProfileValidation runs validateProfileId against au-core-patient to confirm the whole resource - extension included, now correctly url'd to match the inherited slot - remains profile-conformant.
fixture
id
sexassignedab-patient-fixtureautocreate: true
autodelete: true
resource:
au-core-patient-sexassignedab
| Name | Path | SourceId |
| patientId | Patient.id | sexassignedab-patient-fixture |
test
name: Read
action
Operations
Type Resource EncodeRequestUrl Params Test script operation code: read (Read) Patient true /${patientId} action
Asserts
Response WarningOnly okay false
test
name: ExtensionPresence
action
Operations
Type Resource EncodeRequestUrl Params Test script operation code: read (Read) Patient true /${patientId} action
Asserts
Expression WarningOnly Patient.extension.where(url = 'http://hl7.org/fhir/StructureDefinition/individual-recordedSexOrGender').exists() false action
Asserts
Expression WarningOnly Patient.extension.where(url = 'http://hl7.org/fhir/StructureDefinition/individual-recordedSexOrGender').extension.where(url = 'value').value.exists() false action
Asserts
Expression WarningOnly Patient.extension.where(url = 'http://hl7.org/fhir/StructureDefinition/individual-recordedSexOrGender').extension.where(url = 'type').value.coding.code.where($this = '1515311000168102').exists() false
test
name: ProfileValidation
action
Operations
Type Resource EncodeRequestUrl Params Test script operation code: read (Read) Patient true /${patientId} action
Asserts
ValidateProfileId WarningOnly http://hl7.org.au/fhir/core/StructureDefinition/au-core-patient false