Privacy notice

How patient data is handled

• Operative-report text pasted into Itemate is de-identified server-side before any external API call. The de-identifier strips names, dates of birth, Medicare numbers, MRN/UR numbers, addresses, and phone numbers, replacing each with an opaque token ([NAME-1], [MEDICARE-1], etc.).
• The raw report text, the de-identification token-to-original map, and the redacted text are all request-scoped: held in memory for the duration of one HTTP request and discarded when the response returns. None of these is written to a database.
• When the de-identifier finds an ambiguous shape it cannot confidently classify, it flags the request for human review rather than guessing and proceeding.
• Patient age in whole years is computed locally from DOB plus operation date before de-identification runs. The DOB itself is then discarded; only the integer age reaches the matcher, the logs, and any doctor rule that age-gates on paediatric vs adult MBS variants.
• Server-side logs are PHI-free by design. They record counts, model names, MBS item numbers, timings, patient age (years), and the CF Access email of the clinician who ran the request. They never contain raw report text or any patient identifier.

What Itemate does persist (PHI-free)

Itemate is a workflow tool, not a record system, and never persists patient data. The following non-patient state is kept in Cloudflare D1:

• Doctor-curated correction rules (doctor_rules). Each row holds the procedure-name text the matcher should fire on, the MBS items the surgeon mapped it to, an optional age condition, and the CF Access email of the clinician who created the rule. Procedure-name text comes from the extractor's structured output, never from a patient identifier.
• Per-report confirmation hashes (report_confirmations). When a clinician confirms a row inside a specific report, Itemate stores a SHA-256 hash of the normalised report text along with the confirmed item number, the procedure name, and the clinician's CF Access email. The hash lets a re-validation of the same report rehydrate the prior decisions without re-asking. It does not contain the report text and is not reversible to it, but a hash of clinical text is arguably a pseudonymous identifier under OAIC guidance, so we disclose it explicitly here.
• Aggregate usage telemetry (usage_events). One row per validate call and one row per doctor-acceptance click. Each row carries the event type, date (AEST), counts (validations / flags / acceptances), confidence-tier distribution, dollar uplift, doctor-rule hit count, and (optionally) the clinician's CF Access email. PHI-impossible-by-construction (no procedure names, no item descriptions tied to a case, no report text, no patient age tied to a case).
• Daily Anthropic spend counters (token_budget), keyed by AEST date. Token totals only, no per-case attribution.
• MBS schedule catalogue, ortho relevance tags, and rule version metadata. Public reference data, sourced from mbsonline.gov.au.

Itemate stores no passwords or session cookies of its own. Authentication is handled by Cloudflare Access (Google OAuth + One-Time PIN), and only authenticated clinicians on the allowlist can use the tool.

What leaves the server, and where it goes

Only de-identified report text is sent to Anthropic's Claude API for prose-to-structure extraction. No identifiers and no D1 records are included in that call.

Anthropic processes requests in the United States, so de-identified report text leaves Australian jurisdiction during extraction. Under Australian Privacy Principle 8 (cross-border disclosure of personal information), we disclose this sub-processor explicitly. Anthropic is contracted not to train models on API inputs by default; the redacted text we send carries no Australian-resident identifiers.

Nothing is transmitted to Medicare or any other third party. Itemate does not bill, claim, or submit on anyone's behalf.

Marketing pages (analytics)

Itemate uses PostHog on the public marketing and sign-up pages only (/about, /pricing, /sign-up). PostHog records page views and a small set of named funnel events (e.g. "pricing_viewed", "checkout_intent") so we can tell which parts of the message convert. Autocapture is disabled and session recording is disabled; we never collect form-field content, document text, or keystrokes. The validator, admin board, and Word add-in do not load PostHog at all, so no analytics event ever fires from a page that has touched de-identified report text.

After you complete checkout, PostHog identifies you by the email you provided to Stripe, so the funnel can be linked to a real account. Before checkout you remain anonymous. PostHog Cloud (US) is the sub-processor; this is a second cross-border disclosure under APP 8 and is scoped to billing identifiers (email, plan tier) and page-view metadata only.

You can opt out of analytics in your browser at any time using a DNT-style extension (uBlock Origin, Brave Shield, etc.) or by emailing the contact below for an account-level opt-out flag.

Retention

• doctor_rules, report_confirmations, and usage_events are retained indefinitely while the service is live, to keep the matcher's learning history and audit trail intact. Tables are append-only; nothing is silently overwritten.
• The token_budget table is keyed by AEST date and retained indefinitely for cost-attribution audit.
• Clinicians may request deletion of any rule they authored or any report_confirmations row tied to their CF Access email by contacting the address below.

Contact

Built by Nicholas W. Fraser. Privacy questions, data requests, or takedown requests: nickwfraser@gmail.com.