Client ID
frog-runner
Client Name
FHIRFrog Runner (frog-runner)
Client Type
Backend Service
Target Nodes
Redirect URIs
Not applicable — Backend Service client.
Scopes
system/*.*
Contact Email
Joernguy.Suess@csiro.au
Tenant (optional)
Requesting a new write-capable tenant, e.g. FHIRFROG (happy to take whatever name/convention you'd prefer) — the shared DEFAULT tenant is read-only for participant clients, which is what we're hitting.
Urgency
Medium - Needed within 2 weeks
Business Justification
frog-runner (aehrc/fhir-frog → frog-runner module) is an automated FHIR conformance test runner. It executes AU Core TestScript bundles end-to-end against a target server, which requires autocreating fixture resources (via a transaction Bundle with conditional-create) before each test and autodeleting them afterward.
We just fixed a bug on our side where the fixture autocreate transaction used an invalid urn:uuid: value (the TestScript's local fixture id, not a real UUID) — confirmed fixed against smile.sparked-fhir.com/aucore/fhir/DEFAULT and fhir.hl7.org.au/aucore/fhir/DEFAULT, both of which now correctly reject/accept based on real validation rather than the UUID-format error. But both return 403 Access denied (OperationOutcome, from the server's own auth layer) on any write (POST/PUT/transaction) since the DEFAULT tenant is read-only for participants — confirmed via .well-known/smart-configuration and by comparing an unauthenticated write (403) vs one with a bogus bearer token (401, proving the server is actually validating tokens rather than blocking anonymously).
A write-capable tenant + Backend Service client would let us run the full AU Core test suite end-to-end (create → validate → cleanup) against a real Sparked-managed server instead of only read-only conformance checks.
Additional Context
Resource types the test suite creates as fixtures: AllergyIntolerance, Condition, Encounter, HealthcareService, Immunization, Location, Medication, MedicationRequest, MedicationStatement, Organization, Patient, Practitioner, PractitionerRole, Procedure. Fixtures are created via a single transaction Bundle (conditional create keyed on a http://fhir-frog.test/fixture identifier) and torn down again (autodelete) at the end of each TestScript run — expect low, bursty write volume (≤20 resources per run), not sustained load.
Happy to adjust tenant naming/scopes to whatever fits your conventions best — flagging in case a narrower scope (e.g. per-resource-type) is preferred over system/*.*.
Client ID
frog-runnerClient Name
FHIRFrog Runner (frog-runner)
Client Type
Backend Service
Target Nodes
Redirect URIs
Not applicable — Backend Service client.
Scopes
system/*.*Contact Email
Joernguy.Suess@csiro.au
Tenant (optional)
Requesting a new write-capable tenant, e.g.
FHIRFROG(happy to take whatever name/convention you'd prefer) — the sharedDEFAULTtenant is read-only for participant clients, which is what we're hitting.Urgency
Medium - Needed within 2 weeks
Business Justification
frog-runner (
aehrc/fhir-frog→frog-runnermodule) is an automated FHIR conformance test runner. It executes AU CoreTestScriptbundles end-to-end against a target server, which requires autocreating fixture resources (via a transactionBundlewith conditional-create) before each test and autodeleting them afterward.We just fixed a bug on our side where the fixture autocreate transaction used an invalid
urn:uuid:value (the TestScript's local fixture id, not a real UUID) — confirmed fixed againstsmile.sparked-fhir.com/aucore/fhir/DEFAULTandfhir.hl7.org.au/aucore/fhir/DEFAULT, both of which now correctly reject/accept based on real validation rather than the UUID-format error. But both return403 Access denied(OperationOutcome, from the server's own auth layer) on any write (POST/PUT/transaction) since theDEFAULTtenant is read-only for participants — confirmed via.well-known/smart-configurationand by comparing an unauthenticated write (403) vs one with a bogus bearer token (401, proving the server is actually validating tokens rather than blocking anonymously).A write-capable tenant + Backend Service client would let us run the full AU Core test suite end-to-end (create → validate → cleanup) against a real Sparked-managed server instead of only read-only conformance checks.
Additional Context
Resource types the test suite creates as fixtures:
AllergyIntolerance,Condition,Encounter,HealthcareService,Immunization,Location,Medication,MedicationRequest,MedicationStatement,Organization,Patient,Practitioner,PractitionerRole,Procedure. Fixtures are created via a single transactionBundle(conditional create keyed on ahttp://fhir-frog.test/fixtureidentifier) and torn down again (autodelete) at the end of each TestScript run — expect low, bursty write volume (≤20 resources per run), not sustained load.Happy to adjust tenant naming/scopes to whatever fits your conventions best — flagging in case a narrower scope (e.g. per-resource-type) is preferred over
system/*.*.