AMA Victoria · briefing note · August 2026

Practitioner
Experience Monitor

A balanced briefing on the third-iteration pilot implementation, its current security and privacy controls, possible AMA-owned hosting models, and indicative development costs.

Executive position. This is not a “Mickey Mouse” version or a finished enterprise platform. It is a technically substantial, security-conscious pilot implementation that is suitable for organisational review and controlled testing. It still requires AMA Victoria to confirm ownership, hosting, access, backup, retention and approval arrangements before it can be treated as the organisation’s production system.

Purpose of the briefing

This note is intended to support an informed discussion with AMA Victoria. It does not ask AMA to approve a particular supplier, cloud provider or final architecture. It separates what the pilot already demonstrates from the governance and assurance decisions that remain outstanding.

What decision is being sought?

At this stage, the immediate decision is whether AMA Victoria is willing to progress a controlled three-month pilot, subject to its normal review process and confirmation of an AMA-owned production environment.

Three iterations

1 · Linux serverOriginal implementation on a standalone Linux virtual server.
2 · Cloudflare migrationFirst move from the Linux server to a Cloudflare Worker/D1 architecture.
3 · Secure pilot setupSeparately configured Cloudflare iteration with stronger privacy, security, governance and messaging controls.
Important status note. The third iteration has been developed and subjected to isolated smoke checks. Deployment into an AMA-controlled environment, browser-based end-to-end testing, formal organisational approval and an independent focused review remain to be completed.
What the pilot validates

A real functional pilot, not a visual mock-up

The implementation contains a working public collection and administration model. It is designed to collect de-identified experiences about AHPRA regulatory processes, identify recurring themes and support evidence-based advocacy. It is not intended to determine the merits of an individual regulatory matter.

Public pathways
  • Notification experience
  • Fees and financial management
  • CPD, digital and responsiveness
  • General and governance feedback
  • Case updates and privacy information
Privacy by default
  • Email is not required.
  • Names, registration numbers, workplaces and addresses are not required.
  • Free-text fields warn against patient or personal identifiers.
  • Common email, phone and Medicare-style patterns are flagged for review.
Important privacy qualification. The Monitor is designed to collect de-identified information and does not request identity details, but free-text narratives or combinations of information can still make a person reasonably identifiable. This reduces privacy risk; it does not by itself determine whether privacy-law obligations apply. AMA should approve the privacy, retention and incident approach before launch.

Implemented controls

Public submission protection

  • Server-side Turnstile validation on public write forms.
  • Request-size and field-length limits.
  • Structured-value validation and parameterised database queries.
  • Security headers, output encoding and generic error handling.
  • Short-lived, HMAC-derived abuse counters without storing raw IP addresses.

Secure communication

  • Secure Messages does not require an email address.
  • Inbox access requires both a case/reference number and a separate long random access code.
  • Reference and access credentials are stored as HMAC-derived values.
  • Resend receives only a generic administrator alert, never message content or identifying details.

Administrative controls

  • Explicit server-side authorisation for views, replies, exports, classifications and configuration changes.
  • Audited data-quality classification and administrator actions.
  • Controlled CSV export and configurable notification recipients.
  • Single pilot administrator role, with stronger named-user MFA recommended before wider use.

Portable implementation

  • One self-contained Worker file plus a separately reviewable SQL schema.
  • No dependence on a developer’s Linux server.
  • Transferable source, schema, export capability and operating documentation.
  • Cloudflare-specific bindings and D1 SQL would need equivalents if moved to Azure.

What it does not yet validate

AreaCurrent position
Organisational approvalTo confirm AMA’s digital-project review and approval pathway is pending COO discussion.
Production ownershipTo confirm The production account, domain, database and recovery access should be AMA-controlled.
Identity managementPilot limitation Named individual accounts, MFA and fuller role separation remain required for broader use.
Recovery assuranceTo complete Backup settings, recovery window and a non-production restore exercise must be documented.
Independent reviewTo arrange The supplied verification matrix should be run against the deployed environment, followed by a focused independent review.
Hosting and ownership

AMA’s infrastructure response

QuestionResponse receivedPractical interpretation
Digital-project approvalCOO to be consulted on return from leave in September.Do not treat the current technical build as organisational approval.
Where data is hosted“Microsoft 365 environment”.Clarify whether this means Microsoft 365 only, a mandatory Azure hosting/data-location requirement, or an Australian database requirement.
External managed hostingAMA would prefer to own the hosting environment.Cloudflare may be acceptable if the Cloudflare environment is owned and controlled by AMA; an AMA-owned Australian database is also a possible separate component.
AMA subdomainYes to an AMA-hosted environment.AMA should control the domain/DNS and approve the final routing arrangement.
Administration and backupBackup and limited administrator access are definitely required.These become pilot go-live conditions, not optional enhancements.
Existing public Cloudflare footprint. A public check on 23 August 2026 found amavic.com.au delegated to Cloudflare nameservers and its public web response served through Cloudflare. The response also included cookies consistent with an Azure App Service origin. This makes an AMA-owned Cloudflare deployment path credible and may reduce setup effort, but it does not prove the existing Cloudflare account, origin, database, backups or logs are owned by AMA or suitable for this Monitor. Those matters require AMA confirmation.

Two credible hosting options

Option A · AMA-owned Cloudflare

AMA creates or controls the Cloudflare account and the amavic.com.au zone. The Worker, domain route, secrets, Turnstile, access controls and recovery arrangements sit inside that AMA-controlled environment.

Database choice: retain D1 for the lowest-disruption pilot path, or connect the Worker through Hyperdrive to an AMA-owned PostgreSQL/MySQL database in an Australian cloud region if country-specific database control is required. Hyperdrive is a separate database migration, not a D1 location setting.

Conditions: AMA account ownership, named administrators with MFA, documented recovery, WAF/rate limiting, and recorded decisions on D1 or external-database location, logs, backups and access.

Option B · AMA-managed Microsoft/Azure

The application is adapted to an Azure-hosted HTTP runtime, with an AMA-managed database and Microsoft identity/access controls where appropriate.

Advantages: closer alignment with existing Microsoft governance and potentially easier integration with AMA’s internal IT arrangements.

Trade-off: the Worker entry point, D1 database access, schema, secrets, rate limiting, backups and deployment process require migration and re-testing.

Recommended sequence. Ask AMA first whether it can use an AMA-controlled Cloudflare account and the existing domain zone for a dedicated Monitor route or subdomain. If Cloudflare is acceptable, decide separately whether D1 is sufficient for the pilot or whether an AMA-owned Australian database is required. Only commission an Azure rewrite if AMA confirms that Azure or Microsoft-managed hosting is required.

Ownership principle

The production environment should not depend on a developer’s personal Cloudflare account, personal domain, personal email account or unmanaged backup. AMA should own the accounts, billing, DNS, secrets, database, backups and administrator recovery path. A developer may be granted limited implementation access, but should not be the sole person able to operate or recover the service.

Indicative cost and market context

What would this work cost commercially?

The figures below are indicative Australian replacement costs for a project of this character. They are not a quote and exclude GST unless stated otherwise. They reflect the application, security controls, documentation, testing and handover—not merely the number of lines of code.

EngagementIndicative costWhat it normally includes
Prototype/basic functional version$10k–$20kCore pages, forms, database and basic administration, with limited operational hardening.
Senior independent developer$20k–$45kCurrent functional scope, security controls, documentation, testing and a practical handover.
Small specialist agency$35k–$70kDelivery management, implementation, QA, documentation and a more formal handover process.
Production hardening and independent review+$10k–$25kNamed access, backup/recovery testing, deployment verification, security review and remediation.
Azure migration, if required+$15k–$35kHTTP-runtime adaptation, D1-to-managed-database migration, Azure configuration, data testing and re-verification.
Ongoing support$4k–$12k/yrSmall support/maintenance allowance; actual cloud, domain, email and review costs are separate.
Practical planning allowance. For an AMA-owned Cloudflare pilot with proper handover and verification, a reasonable discussion range is approximately AUD $30,000–$50,000 excluding GST. If Azure migration and formal independent review are added, a planning range of approximately AUD $50,000–$90,000 excluding GST is more realistic.

Has AI reduced the cost?

AI has reduced the time needed for first drafts, boilerplate, documentation, test scaffolding and exploring alternative implementations. It has not removed the need for professional judgement or accountability.

Where AI helps

  • Rapidly creates and revises interface code.
  • Assists with SQL, validation and documentation.
  • Finds obvious defects and proposes tests.
  • Makes a small team more productive on a bounded pilot.

What AI does not remove

  • Requirements clarification and risk ownership.
  • Security, privacy and permission review.
  • Deployment, backup and recovery responsibility.
  • Independent testing and post-launch support.

For a project like this, AI may reduce raw coding time materially, but the overall professional cost is usually reduced less because testing, governance, deployment and assurance remain. A planning assumption of roughly 10–25% lower total delivery cost is more defensible than assuming a 50–80% reduction. This is an estimate, not a measured result for this project.

Current market direction

AI-assisted development is now normal in the market. Rates have not simply collapsed: specialist cloud, security, governance and integration skills remain valuable. Buyers increasingly seek milestone-based delivery, source-code ownership, documented handover, security testing and a clear support boundary.

Decisions and next steps

Questions for AMA Victoria

The following questions can be taken to the COO or the relevant AMA technology/governance contact. They are intentionally practical and can be answered without committing AMA to an architecture prematurely.

  1. Can AMA own a Cloudflare account for the pilot, or must the application run in an AMA-managed Microsoft/Azure environment?
  2. Does “Microsoft 365 environment” refer to email/collaboration and identity only, or is it a mandatory application hosting and data-storage requirement?
  3. Are there Australian data-residency, privacy, contractual or records-management requirements for the application database, backups and Cloudflare operational logs?
  4. Can the Monitor use a dedicated AMA-controlled Cloudflare route or subdomain, and does AMA require the database to be separately hosted in an Australian provider region?
  5. Who will be the accountable system owner and who can approve public launch?
  6. How many named administrators are required, and must MFA and individual accounts be mandatory from day one?
  7. What retention period, backup frequency, recovery window and restore-testing evidence are expected?
  8. What level of independent security/privacy review is proportionate to a three-month pilot?

Proposed controlled sequence

StageOutcome
1. Organisational clarificationCOO/AMA confirms approval pathway, ownership model, data requirements, administrator limits, backup expectations and retention.
2. Hosting decisionChoose an AMA-controlled Cloudflare route with D1 or an AMA-owned Australian database, or approve an Azure migration if Microsoft hosting is required.
3. Controlled deploymentDeploy into AMA-owned accounts; configure secrets, Turnstile, domain/DNS, access controls, WAF and backups.
4. ValidationRun the security verification matrix, browser end-to-end checks, restore exercise and focused independent review.
5. Pilot approvalRecord residual risks, retention and incident contacts; open the three-month pilot with a defined review point.

Balanced conclusion

The current implementation is credible as a pilot. It demonstrates meaningful functionality and a stronger privacy/security baseline than a simple form or proof of concept.

It is not yet an AMA-approved production service. That status depends on organisational ownership, hosting confirmation, named access, backups, retention, deployed testing and assurance.

The lowest-risk commercial path is to avoid unnecessary rewriting. Public DNS evidence supports exploring an AMA-controlled Cloudflare route, but AMA must confirm ownership and governance. An external AMA-owned Australian database is possible if required; an Azure migration should be a deliberate governance decision, not an automatic response to Cloudflare use.

Reference points

The technical description is based on the current third-iteration Worker, D1 schema, deployment guide, pilot operations procedure and security verification matrix. Public-domain infrastructure observations were checked on 23 August 2026 using DNS delegation and HTTPS response headers. Hosting/privacy context: Cloudflare D1 data location, Hyperdrive architecture and the OAIC’s personal information guidance. Market context was checked against: Hays, FY25/26 IT Contractor Rates Guide; Stack Overflow, 2025 Developer Survey — AI; and METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.

This briefing is an implementation and planning summary, not legal advice, a privacy impact assessment, a penetration-test report or a formal assurance statement.