A structured, anonymous practitioner-feedback and continuous-quality-improvement platform for recording doctors’ experiences with AHPRA regulatory processes, identifying recurring themes, and supporting evidence-based advocacy.
The Monitor is not a complaints portal and does not determine the merits of an individual regulatory matter. It is a structured data-collection tool. Practitioners can record de-identified experiences and later provide limited progress information, allowing authorised reviewers to analyse aggregate patterns, emerging signals, practitioner wellbeing impacts, communication problems, proportionality concerns, fees, digital services, governance and accountability.
The public experience is designed for de-identified submission. The application does not require a practitioner’s name, email address, telephone number, registration number, exact workplace or address. Free-text fields display privacy guidance asking contributors not to include patient identifiers, unnecessary names or other identifying material. This reduces identification risk, but cannot guarantee that every narrative or combination of responses is anonymous.
The main 24-question pathway covers notification context, communication, support, wellbeing, fairness, proportionality, outcome and contact preference.
Collects structured feedback on fee levels, transparency, impact, comparisons and practitioner expectations.
Examines CPD appropriateness, portal usability, digital improvements, contact with AHPRA and responsiveness.
Records broader confidence, regulatory culture, board representation, accountability and reform priorities.
Additional routes support case updates, the project explanation and privacy information, secure practitioner-to-administration messaging, a pseudonymous inbox, and a protected administrative panel.
The implementation follows the original Replit project brief’s deliberately simple deployment model: one ES-module Worker file contains the HTML, CSS, browser JavaScript and SVG assets as embedded string constants. There is no framework, build step, Node.js runtime, uploaded static-asset dependency or conventional public Linux server required. The Worker is pasted into the Cloudflare dashboard and connected to a D1 database through a binding named DB.
This structure makes the application straightforward to understand, back up and transfer. It also keeps the public browser separate from the database: browser code calls Worker endpoints, and only server-side Worker code performs database operations.
amavic.com.au delegated to Cloudflare nameservers and served through Cloudflare response infrastructure. Response cookies were also consistent with an Azure App Service origin. This supports the practicality of an AMA-controlled Cloudflare route or subdomain, but does not prove who owns the current Cloudflare account, where the origin/database is hosted, or whether the current website configuration can be reused for this application.
Security is provided through a combination of Cloudflare-managed controls and application-level controls in the Worker. The design follows data minimisation, de-identification by default, defence in depth, separation of public and administrative functions, least-privilege intentions, and graceful failure if one layer is compromised.
The Worker does not persist raw IP addresses in D1. Cloudflare operational, security or observability logs may nevertheless contain request metadata such as IP-related data, user-agent and timing information depending on the account configuration. Log retention, access, exports and incident handling therefore require the same governance attention as the application database.
Practitioners do not need an email address to submit information, return to the platform or communicate with the Monitor team. A notification submission produces an opaque case reference for finding that submission. The case reference is a pseudonymous identifier, not a name or email address, and should be kept private.
For private two-way communication, the Secure Messages route issues a separate, long, random secure access code. The reference and access code are required together to open the practitioner’s inbox. The message table stores only HMAC-derived verifiers for those credentials; it does not store the plaintext message reference or access code. The access code is shown once and cannot be recovered by the system.
A practitioner may optionally associate a secure message with an earlier case reference, or send a standalone message. The practitioner’s message remains in the platform and an authorised administrator can provide one reply. The email channel is notification-only: Resend receives a generic alert that a message is awaiting review, never the message content, case reference, access code, practitioner details or other identifying material.
/update route uses the case reference to find an existing submission and record a progress update; it does not require an email address. It is not the authentication mechanism for private two-way communication. Secure Messages, with the separate access code, is the route intended for private conversation.
The pilot currently uses a single Worker administrator role with an eight-hour signed session and an initial password stored as a Cloudflare Secret. After first login, the administrator can change the password; the replacement is stored in D1 as a salted PBKDF2 hash. The panel supports controlled browsing, data-quality classification, notes, message review and reply, notification-recipient management, password changes and audited CSV export.
Before use beyond a tightly governed pilot, the administrative route should be placed behind Cloudflare Access with named individual accounts and MFA. The application has explicit per-action checks, but the pilot password should not be treated as a substitute for organisational identity management or role separation.
Cloudflare D1 stores structured SQLite data. The schema is supplied separately so it can be reviewed, migrated and retained as part of the deployment record. The current third Cloudflare iteration contains the original survey tables plus security and messaging tables:
submissions — notification experience responses, opaque case reference, contact preference, verification fields and privacy flags.updates — progress and outcome updates linked to a submission reference.feedback_fees, feedback_cpd_digital, feedback_general, feedback_governance — the four additional structured feedback pathways.admin_config — hashed replacement administrator password and notification settings.messages — secure-message threads, HMAC credential verifiers, message/reply status and privacy flags; no plaintext reference or access code.audit_log — event metadata for important administrative actions without narratives, secrets or credentials.request_throttle — short-lived HMAC-derived abuse counters, removed after the defined retention window.The full creation schema includes all current tables and privacy flags; a separate migration script adds privacy flags to an existing database. D1 can use an Oceania location hint, but that is not a country-level Australia-versus-New Zealand assurance. D1 recovery/Time Travel and any additional encrypted backup process should be enabled and documented according to the selected Cloudflare plan and the pilot governance decision. Cloudflare’s global infrastructure means the primary database location, replicas, logs, backups and administrator/support access should be explicitly recorded rather than inferred from the domain name.
The current infrastructure objective is very low-cost operation. The present estimate is approximately US$7 per year for the Cloudflare domain registration, with Worker and D1 usage intended to remain within the selected Cloudflare plan’s included or low-volume allowances. Actual charges and limits should be checked in the Cloudflare account before launch. Resend, if enabled, is a separate third-party transactional email service and should be reviewed against its own limits or pricing. Turnstile is used for bot protection rather than as an email service.
This cost profile is possible because there is no dedicated virtual server, operating-system patching burden, conventional database server, R2 asset store or separate application host. The trade-off is that Cloudflare account governance, D1 recovery capability, data residency, service limits and administrative Access configuration must be documented as part of the pilot rather than assumed.
The platform is not locked into a personal server. The Worker source, embedded page content, SQL schema, CSV export capability and documented data model provide a practical transfer package. A future move could target another Worker/edge platform, a managed serverless runtime, or a conventional application server with SQLite/PostgreSQL-compatible storage.
One intermediate option is to retain the Worker while replacing D1 with an AMA-owned PostgreSQL or MySQL database in an Australian cloud region, connected through Cloudflare Hyperdrive. This is a separate database migration: it requires query-code changes, secure database connectivity, backup/recovery and access controls, and a review of Hyperdrive caching and Worker/log processing. It is not a D1 country-location setting or an end-to-end residency guarantee.
A transfer would not be a one-click migration: Cloudflare-specific bindings, D1 SQL details, Turnstile, Secrets, DNS, Access rules and Resend domain verification would need equivalents or reconfiguration. However, the application has no large framework, build pipeline or proprietary front-end bundle to reconstruct. Secrets would be recreated in the destination’s protected secret store, data would be exported and validated under governance approval, and the domain could be repointed after testing.
This third iteration is proportionate to a three-month AMA-VIC pilot. It provides de-identified-by-design collection, secure pseudonymous messaging, abuse protection, auditability, controlled exports and documented recovery/incident procedures. It should not be described as enterprise-grade, as a conclusion that privacy law cannot apply, or as fully independent security assurance without the remaining governance controls.