Product and intended use
Define the configuration, people, information and tasks being assessed.
Product and deliverables covered
Public claim only
The vendor publishes four named deliverables: Medical Chronology ('Structured, date-ordered timeline of all medical events, diagnoses, treatments, medications, and providers. Every entry hyperlinked to its source page in the original records'), Medical Summary ('tailored to case type: workers' compensation, personal injury, TPD, or public liability'), De-Identification ('Automated removal and redaction of identifying information') and Audit & Provenance ('Confidence scores per extraction, source page citations, model provenance logs, and flagged items requiring human review'). Outputs are delivered 'in Word, Excel, and PDF'. The pilot page adds a fifth item, a 'Pilot Evaluation Report'. All of this is on the vendor's own marketing pages; no specification document is published.
Ask: Which of the four deliverables are included in the price we are quoted per case, and is the de-identification output an extra?
Release stage of the product
Public claim only
The vendor describes the offering in pilot terms on every page read, checked 2026-09-27: '100+ Page bundles supported in pilots', 'Pilot Turnaround scoped per file and urgency', 'Pilot outputs can include reviewer checks where your workflow requires them', 'We offer fixed-scope paid pilots with clear success metrics' and 'Live customer pilots are scoped around Australian-hosted processing and storage'. The pilot page states 'Every pilot delivery is identical to what you'd receive as a customer.' No generally available product with published specifications, service levels or turnaround commitments is published.
Ask: Is there a generally available service behind the pilot, with published turnaround and volume commitments, or is every engagement scoped individually?
How the service is delivered
Public claim only
The published model is a delivered service rather than software the firm operates: records are sent through 'our secure, encrypted transfer', 'Our AI pipeline reads every page', and outputs are returned as Word, Excel and PDF files. No tenancy, login, browser application, mobile client, API or on-premises option is published. No cloud provider or region is named. The deployment value recorded here is the closest available in the controlled list and should be read with this finding.
Ask: Do we get a tenancy and logins of our own, or do we send records and receive files, and where does the processing physically run?
How the extraction pipeline is described
Public claim only
The home page states 'Not a single-model black box. Different document types route to specialised models - vision models for scanned layouts, language models for clinical extraction, purpose-built OCR for handwritten notes', and that the pipeline 'handles scanned PDFs, digital records, handwritten clinical notes, and mixed-format documents' at 'Up to thousands of pages per case'. Audit output is said to carry 'Confidence scores per extraction, source page citations, model provenance logs'. No model, provider, version, confidence-scoring method or provenance format is published, checked 2026-09-27.
Ask: How is the confidence score calculated, what does a model provenance log contain, and can we see a worked example on one of our own bundles?
Australian law addressed
Public claim only
The compliance page maps the service against named Australian Privacy Principles - APP 1, 6, 8, 11, 12 and 13 - and against the Health Records Act 2001 (Vic), the Health Records and Information Privacy Act 2002 (NSW) and the Health Records (Privacy and Access) Act 1997 (ACT), stating that handling practices 'are designed to comply with the most stringent requirements across all jurisdictions'. De-identification is said to follow 'the OAIC's De-identification Decision-Making Framework', including a 'motivated intruder' test. The page carries no version, no effective date and no governing-law or jurisdiction clause, and no contract is published.
Ask: Which entity gives these compliance undertakings, under which State's law would our agreement be governed, and are the compliance page statements warranted in the agreement?
Check for vendor content directing how AI describes the product
Not confirmed
A deliberate check for content telling AI models, assistants or crawlers how to describe the product found none on this vendor's site as at 2026-09-27. Checked: a site map run that returned nine URLs, none of which is /llms.txt, /ai-info, /ai or /for-ai; the link sets and footers of the three pages read (home, compliance and pilot), which contain no such path; and the text of those pages, which contains no block addressed to AI models, assistants or LLMs. No file at /llms.txt was fetched directly, so this is an absence in what was indexed and read rather than a proven absence. The site does carry comparative marketing about unnamed other products - 'Many tools in this space are built for US or Canadian workflows' - which is not carried into this profile.
Ask: Does MedExtract publish any file or page addressed to AI models or crawlers, such as /llms.txt, describing how the product should be presented?
Data, controls and requirements
Compare the actual configuration with firm, client and jurisdiction requirements, supported by evidence.
Authority to send client health information
Not confirmed
Nothing published addresses the customer's authority, consents or notices. The compliance page says records are processed 'consistent with APP 6 primary purpose limitations' and that the vendor provides a 'Data Processing Agreement' before the pilot begins, but that agreement is not published, so who warrants what about consent and authority is unverified as at 2026-09-27. There is no controller and processor characterisation, and no customer warranty, on any page read.
Ask: In the data processing agreement, who is the APP entity responsible for the collection, and what does MedExtract require us to warrant about consent before we send a claimant's records?
Which models and providers process the records
Public claim only
No model, model family or model provider is named on any page read. The compliance page and the pilot page state that the 'model-provider path' is 'confirmed in writing' before live records are processed, and the APP 8 row states the same. The home page describes 'vision models for scanned layouts, language models for clinical extraction, purpose-built OCR for handwritten notes' without naming any of them. The model provider is therefore something settled per engagement rather than published.
Ask: Which models and providers will process our records, in which country does each of them run inference, and will that be named in the pilot scope document?
Sub-processors and onward disclosure
Not confirmed
No sub-processor list is published and no sub-processor, cloud provider, OCR provider or reviewer supplier is named anywhere on the pages read. The compliance page states that reviewer checks can be added 'where your workflow requires clinical QA, procurement assurance, or sign-off', which implies people other than the extraction pipeline may see records, but who they are and whether they are employees or contractors is not published. No change-notification right over sub-processors is published.
Ask: Please list every sub-processor and reviewer, employee or contractor, who could access our clients' records, with the country each one operates in, and how we are notified of a change.
Whether records are used to train models
Public claim only
The compliance page states 'Client medical records are never used to train, fine-tune, or improve AI models. Records are processed solely for producing requested outputs, consistent with APP 6 primary purpose limitations', checked 2026-09-27. The APP 6 row repeats 'No secondary use. No model training on client data.' This is a statement on the vendor's own compliance page; no contract, data processing agreement or model-provider term is published to support it, and no model provider is named whose terms could be checked.
Ask: Will the data processing agreement carry the no-training undertaking, and does it bind the model providers as well as MedExtract?
Use of corrections and reviewer feedback
Not confirmed
Nothing published addresses what happens to feedback. The pilot page says 'We walk through the outputs together and gather your feedback' and the compliance page says 'corrections handled promptly post-delivery' under APP 13, but neither states whether corrections, reviewer annotations or evaluation results are retained, reused or excluded from the no-training undertaking.
Ask: Are the corrections we make to a delivered chronology retained, and are they excluded from the no-training undertaking in the same terms as the source records?
How long records are kept
Public claim only
The compliance page states 'Records are retained only for the period required to deliver outputs and fulfil contractual obligations. Secure deletion on request or at the end of the retention period, in accordance with APP 11.2', checked 2026-09-27. No period is given. The same page says retention periods are covered in the Data Processing Agreement, which is 'Available before the pilot begins' and is not published.
Ask: What is the default retention period in days for records, outputs, backups and audit logs, and can we require deletion within a shorter period?
Deletion on request
Public claim only
The compliance page states 'Secure deletion on request or at the end of the retention period, in accordance with APP 11.2' and lists 'Secure deletion at end of retention period' under APP 11, checked 2026-09-27. No deletion timeframe, no certificate of destruction, no treatment of backups and no treatment of de-identified derivatives is published. Deletion procedures are said to be in the unpublished data processing agreement.
Ask: Within how many days of a deletion request are records, outputs, backups and any de-identified derivatives destroyed, and will MedExtract certify it?
Which people can read the records
Public claim only
The compliance page states 'Access controls enforce least-privilege principles. Audit logs track every access event' and lists 'Least-privilege access controls. Audit logging on all access events' under APP 11. Separately it states that 'A qualified reviewer checks all de-identified outputs before delivery' in the de-identification workflow, and that reviewer checks can be added for clinical quality assurance or sign-off. The number of people involved, whether they are employees or contractors, which country they work in and whether the firm can obtain the access log are not published.
Ask: Who are the reviewers who read our clients' records, are they employees, in which country do they work, and can we obtain the access log for a given case?
Authentication and account controls
Not confirmed
No login, tenancy, single sign-on, multi-factor authentication, role model or session control is published, because the published delivery model is a transfer of records and a return of files rather than an application the firm logs into. The pilot page refers only to 'Secure encrypted record upload' and 'our secure, encrypted transfer'. What that transfer is - a portal, a secure link or email - is not stated.
Ask: What is the secure transfer mechanism, who at our firm can authorise an upload or a download, and is multi-factor authentication available on it?
Encryption at rest and in transit
Public claim only
The compliance page states 'All data is encrypted using AES-256 at rest and TLS 1.3 in transit' and repeats 'AES-256 encryption at rest, TLS 1.3 in transit' in the APP 11 row, checked 2026-09-27. Key management, key custody and backup encryption are not addressed, and no security page or technical documentation is published; the compliance page says security documentation is 'Available on request for your IT and compliance review'.
Ask: Who holds the encryption keys, where are they held, and can we see the security documentation before the pilot rather than after?
Independent assurance
Not confirmed
No certification, attestation, audit report or independent test is claimed anywhere on the three pages read - there is no ISO 27001, SOC 2, IRAP or HIPAA claim, no penetration test statement and no trust centre. The compliance page offers 'Security Documentation' described as 'Technical documentation covering encryption standards, access controls, infrastructure architecture, and incident response procedures', 'Available on request'. The absence of any published assurance document is itself the finding, checked 2026-09-27.
Ask: Has any part of the service been independently audited or penetration tested, and if so by whom, when, and can we see the report?
What we would be contracting to, and with whom
Not confirmed
No terms of service, master agreement or data processing agreement is published. The compliance page states a 'Data Processing Agreement' covering 'data handling, security standards, retention periods, deletion procedures, breach notification obligations, and permitted uses' is 'Available before the pilot begins'. The counterparty is not identified: the footer of every page read names an individual and states 'ABN on request', with no company, trust or partnership name, checked 2026-09-27. The pilot converts to an annual contract with the pilot fee credited to the first invoice.
Ask: Which legal entity contracts with us, what is its ACN or ABN, and can we see the data processing agreement and the annual contract before the scoping call?
Cross-border disclosure
Public claim only
The compliance page addresses APP 8 in conditional terms: 'Live customer pilots are scoped around Australian-hosted processing and storage, with cross-border disclosure requirements and model-provider path confirmed before live records are processed.' The home page headline and a statistic tile state 'Australian data sovereignty by design' and 'AU Data sovereignty by design'. No provider, region or data-centre location is named, and there is no statement that no data leaves Australia. The vendor also states of others that 'Offshore BPO and US-based AI tools process sensitive health information outside Australian jurisdiction' - a comparative claim about unnamed products that is not carried into this profile.
Ask: Will MedExtract warrant in writing that no record, prompt, output or log leaves Australia, and if any component sits offshore which one is it and under what APP 8 mechanism?
Data breach notification
Not confirmed
No breach notification commitment is published. The compliance page lists 'breach notification obligations' among the matters covered in the Data Processing Agreement, which is not published, and lists 'incident response procedures' among the contents of the security documentation available on request. There is no reference on any page read to the Notifiable Data Breaches scheme or to notifying the Office of the Australian Information Commissioner, notwithstanding that the pages otherwise engage closely with the Privacy Act 1988.
Ask: What notification period and content will the data processing agreement commit to for an eligible data breach involving our clients' health information, and who notifies the OAIC?
How changes are notified
Not confirmed
No version number, effective date, change log or change-notification commitment appears on any page read, including the compliance page that carries the privacy and security statements, checked 2026-09-27. Because the pipeline is described as routing document types to different models, a model change would alter how records are processed, and no notice right over that is published.
Ask: Will we be told before the models, the reviewer arrangements or the hosting location change, and will the compliance statements be versioned so we can see what we relied on?
Ending the engagement and getting data out
Not confirmed
Nothing published addresses termination, transition or export. Outputs are delivered as Word, Excel and PDF files, which the firm keeps, but there is no statement about access to audit and provenance records after delivery, no post-termination deletion timetable and no run-off or transition assistance. The pilot page states there is 'No obligation beyond the pilot'.
Ask: After a pilot or an annual contract ends, what happens to the records, the audit and provenance logs and any de-identified derivatives, and over what period?
Integration with firm systems
Not confirmed
No integration, API, connector or practice management or document management link is published. Intake is described as 'Securely upload your medical records - any format, any volume' through 'our secure, encrypted transfer', and delivery as files 'in Word, Excel, and PDF'. Whether records can be pulled from, or outputs written back to, a matter file is not addressed on any page read.
Ask: Is there any way to send records from our document management system and return the chronology to the matter file, or is manual transfer the only path?
Whether the pipeline reaches outside the supplied records
Not confirmed
Nothing published states whether the models consult anything beyond the records supplied for the case. The vendor states that every entry is 'hyperlinked to its source page in the original records' and that 'Every extraction traces to a source page', which describes provenance of the output rather than a restriction on what the models may read. No statement excludes external retrieval or web access.
Ask: During extraction, does any model retrieve clinical reference material or other content from outside the bundle we supplied?
Whether the service takes actions of its own
Not confirmed
The published workflow is four steps - Upload, Extract, Review, Deliver - and describes no action beyond producing and delivering documents. No agent, workflow automation, outbound messaging or write-back to another system is published, and no statement sets a boundary on what the service may do without instruction.
Ask: Does any part of the service act outside producing the requested documents, for example contacting providers, requesting further records, or writing to another system?
Whether a human checks the output before delivery
Not confirmed
The vendor's statements differ across the same site, checked 2026-09-27. Optional: 'Reviewer checks can be included where your workflow requires added clinical QA, risk review, or sign-off. AI performs extraction; humans can be added where the use case calls for it' (compliance page); 'AI does the heavy lifting. Reviewer checks can be included where accuracy, risk, or client requirements call for human sign-off' (home page); 'AI extraction + scoped review ... Reviewer checks can be included where your workflow requires them' (pilot page). Mandatory: 'Human verification. A qualified reviewer checks all de-identified outputs before delivery. Automated de-identification is effective but not infallible - the human layer catches edge cases' (compliance page, de-identification framework) and, in the APP 13 row, 'Human review layer ensures errors are caught before delivery'. The audit deliverable also lists 'reviewer sign-off' and 'flagged items requiring human review' as though review is part of every delivery.
Ask: Is a human reviewer included in the price for chronologies and summaries, or only for de-identification, and who signs off the audit report if we do not buy reviewer checks?
