Compliance

Overview

MedDocFlow receives inbound clinical documents, reads them, helps a human reviewer match each one to the correct patient, and writes the document into the practice’s Cliniko account. Because those documents contain health information— one of the most sensitive categories of personal information under Australian law — the system is built so that this data stays in Australia, is seen only by authorised staff, and is retained for no longer than necessary.

This page summarises the controls that support that goal. It describes the design of the production service; the local development build behaves differently and is covered under Development mode below.

Regulatory framework

MedDocFlow is designed to align with:

• Privacy Act 1988 (Cth) and the thirteen Australian Privacy Principles (APPs), which govern how health-service providers collect, use, store, disclose and secure personal and health information.
• The Notifiable Data Breaches (NDB) scheme under Part IIIC of the Privacy Act, which requires eligible data breaches to be assessed and, where the threshold is met, reported to affected individuals and the OAIC.
• Applicable state and territory health-records legislation that practices are subject to — for example the Health Records and Information Privacy Act 2002 (NSW) and the Health Records Act 2001 (Vic).
• The Privacy and Other Legislation Amendment Act 2024, which — among other changes — introduces a transparency requirement for substantially automated decisions (commencing 10 December 2026), a statutory tort for serious invasions of privacy, and tiered civil penalties for interferences with privacy. See Automated decision-making.

MedDocFlow acts on the instructions of the practice, which remains the entity responsible for the patient record. But because it handles health information, MedDocFlow is also itself an APP entity directly bound by the Privacy Act and the APPs — the small-business exemption does not extend to handlers of health information — so the controls on this page are our own obligations, not only the practice’s. The design follows the OAIC’s Guide to health privacy (2025) and its guidance on privacy and the use of commercially available AI products (2024).

Australian data residency

Every component that stores or processes document data runs in the AWS Asia Pacific (Sydney) region, ap-southeast-2. This covers application hosting, authentication, the document database, file storage, background processing and encryption-key management. No patient data is stored or processed outside Australia in the normal course of operation. Because patient data is never sent to an overseas recipient, there is no cross-border disclosure to manage under APP 8.

AI processing stays onshore

Documents are read by an AI vision model run through Amazon Bedrock. Inference is pinned to the Australia geographic inference profile, which keeps requests within Australia (Sydney and Melbourne). The broader Asia-Pacific cross-region profile — which can route requests to other countries such as Japan, Korea, India or Singapore — is deliberately not used.

Under the Bedrock data-handling terms, prompts and model outputs are not retained by the model provider and are not used to train or improve any model. Patient data is never entered into a public, consumer generative-AI tool, sent to the public Anthropic API, or routed through any US-based AI gateway — which is the posture the OAIC recommends for handling sensitive information with commercial AI products.

Automated decision-making

The AI model reads each document and produces extracted fields, a document classification and ranked patient-match suggestions. Those outputs inform a decision; they do not make one. A human reviewer confirms every field and every patient match before anything is written to Cliniko, so no decision that significantly affects a patient is made solely by automation. The AI performs steps substantially related to that decision — reading, extracting, classifying and suggesting a match — and the practice’s reviewer remains the decision-maker, which is also the control that keeps AI output accurate (APP 10).

MedDocFlow discloses this on its privacy page, in line with the automated-decision-making transparency requirement added by the Privacy and Other Legislation Amendment Act 2024 (commencing 10 December 2026). We do not train or fine-tune any model on customer or patient data.

Encryption

• In transit: all connections use TLS 1.2 or higher.
• At rest: document files and database records are encrypted with AWS KMS using customer-managed keys (SSE-KMS).

Access control and authentication

• User sign-in is handled by Amazon Cognito with mandatory multi-factor authentication (MFA).
• Access follows two least-privilege roles — Reviewer and Admin— to enforce separation of duties.
• Sessions expire after a period of inactivity (idle timeout).

Data minimisation and retention

MedDocFlow is built to hold the least patient data possible, for the shortest time possible (APP 11):

• Match-only: the system searches for an existing patient and never auto-creates patient records. Ambiguous or unmatched documents go to a human review queue.
• Human review of every document before anything is written to Cliniko.
• Purge on success: once a document is verified as written to Cliniko, the extracted health information and the stored file are deleted from MedDocFlow. Cliniko becomes the single source of truth.
• Time-limited fallback: documents that fail or are rejected carry a 30-day expiry (TTL) after which they are removed.

Longer-term retention of the clinical record — for example the seven-year minimum (or, for a minor, until age 25) required by state health-records laws such as the NSW HRIP Act and the Victorian Health Records Act — rests with the practice as the holder of the record in Cliniko. MedDocFlow purges its working copy only afterthe document is confirmed written into Cliniko, so purging removes a transient copy without touching the practice’s retention obligation — consistent with the destroy-or-de-identify duty in APP 11.2.

Auditability

Every meaningful action — upload, extraction, each reviewer edit, approval, and the write to Cliniko — is recorded in an append-only audit log. The log is deliberately free of patient identifiers: it records the acting user, a timestamp, a content hash and the relevant Cliniko identifiers, but not patient names or dates of birth.

Cliniko as the system of record

The practice’s Cliniko account is the authoritative store for patient information. MedDocFlow connects to the practice’s Australian Cliniko shard (the au1–au4 endpoints), so the practice-management side also stays in-region. API credentials are held in a managed secrets store, not in application code.

Out of scope

This version does not integrate with national health infrastructure. It does not connect to My Health Record, the Healthcare Identifiers (IHI) Service, or exchange data via FHIR/HL7. Documents are matched against the practice’s own Cliniko patient list only.

Shared responsibility

MedDocFlow provides the technical controls described above. The practice remains responsible for: obtaining any necessary patient consent and notice, granting and revoking staff access appropriately, confirming each patient match during review, and meeting its own obligations as a health-service provider under the Privacy Act and applicable state law.

Development mode

The local and demonstration build runs an offline configuration: authentication is disabled, processing uses a local heuristic instead of Bedrock, and the patient list is synthetic. This mode is intended for synthetic, non-patient data only. A fail-closed guardrail prevents the application from starting with authentication disabled against a production environment or a real Cliniko credential, so the unauthenticated build cannot be pointed at real patient data.