What Trenthos IME is
Trenthos IME drafts independent medical examination reports, file reviews and supplementary reports for Australian personal-injury schemes. Behind most of these reports sits an evening of unglamorous work: reading several hundred pages of records, assembling the chronology, and hunting down the page where the MRI report actually said what you remember it saying. Trenthos IME does that assembly, and it shows its working for every line.
The division of labour is strict, and it is enforced in the software rather than promised in marketing: the system reads, organises and drafts; the doctor examines, reasons and opines. The AI is forbidden - at the prompt level and in code - from originating a diagnosis, causation, prognosis or impairment rating. Where an opinion belongs, the draft either restates what the doctor supplied or marks the gap for the doctor to fill. Doctor in, doctor out.
A case is called a matter. A matter moves through a simple lifecycle - intake, processing, ready for review, in review, finalised - and everything the system produces along the way is traceable back to the pages it came from.
How it is built
Trenthos IME is a cloud-style web application: doctors work entirely in the browser, with nothing to install. The front end is a modern single-page application; the back end is a structured API over a PostgreSQL database. The document pipeline runs as background jobs through a work queue, so uploads and drafting never block the interface, and case documents live in dedicated object storage.
Today the product runs on Trenthos-managed infrastructure in Australia, with every component - application, database, document storage and AI inference - onshore. Production hosting is moving to AWS in the Sydney region (ap-southeast-2), carrying the same onshore constraint with it: the deployment design makes cross-border data movement structurally impossible rather than merely against policy. Planned
The pipeline
A matter is processed in six ordered stages - ingest, OCR, extraction, chronology, draft, export - and the state of each stage is visible per matter. Shipping
Ingest
Documents are uploaded as they arrived: PDFs, scans, and photographs of paper (PNG, JPEG, TIFF). Every file is validated, classified by kind - letter of instruction, clinical records, investigation, prior report, correspondence - and assigned a stable document number. That "D3" is what every later citation points back to.
Reading every page
Each page is read individually. Where a PDF carries real embedded text, that text is used directly; scanned or photographed pages are rasterised and read by optical character recognition, and pages where OCR confidence is poor are re-read by a vision model. Every page records which method read it and how confidently, and the reviewer can see those badges later. Documents are indexed page by page precisely so that citations can be checked page by page.
Fact extraction
The system moves a sliding window across each document and proposes typed facts: events, investigations, treatments, prior opinions and claim documents, each with a date, a provider where present, a page number, and a short verbatim quote from the source. Dates are parsed deterministically; a date that cannot be resolved unambiguously is left undated rather than guessed.
Chronology
The chronology itself is assembled by plain code, not by a model: facts are ordered, duplicates across overlapping windows are merged, and the system raises flags a reviewer would want - gaps of more than six months in the records, history predating the date of injury, treatment appearing before the first recorded presentation.
Drafting
Drafting is deterministic-first. Most report sections are assembled in code from the verified facts and the scheme's template; the AI writes prose only where prose is genuinely needed - answering the instructing party's questions and composing the summary - and every sentence it contributes is typed and tracked for review.
Grounding and traceability
The product is built around one rule: no factual sentence without a source page. What makes that more than a slogan is that grounding is verified in code, not asserted by the model. When the AI proposes a fact with a quote and a page, the system checks that the quote actually appears on that page. A citation that cannot be located is never silently accepted: the fact is stored unverified, annotated, and flagged for the reviewer. Shipping
Every drafted sentence carries one of three types: grounded (traceable to cited pages), doctor input (restating the examiner's own findings or opinion), or unsourced (flagged, and blocked from a final export until a human has dealt with it). In the report view the citations render as chips - "D3 p.6" - and each one opens the exact source page.
Honest gaps and refusals
A report that quietly reads as more than it is becomes the easiest kind to take apart, so the system is deliberately conservative about what it claims: Shipping
- Images not sighted. An imaging investigation known only from its report is rendered with "(report only; images not sighted)" unless the doctor confirms the films were reviewed.
- Impairment is refused, not invented. If no examination findings or impairment assessment has been supplied, the draft will not produce a whole-person impairment figure. The section states what is missing instead.
- Unanswerable questions stay unanswered. The instructing party's questions are reproduced verbatim; a question the file cannot support is marked not answerable, with the reason.
- Opinion is fenced off. Every prompt embeds an instruction set forbidding the model from originating diagnosis, causation, prognosis or stability conclusions - and document text is scrubbed for prompt-injection attempts before any model sees it. If the scrubber trips, every model-derived sentence in that draft is force-flagged for review.
Schemes and report types
Trenthos IME understands three engagement types - file review (documentary review only), supplementary report, and full IME - and shapes the report accordingly; a file review, for example, carries no examination or impairment sections at all.
Scheme coverage today spans the Australian workers-compensation jurisdictions: WorkSafe Victoria, SIRA (NSW), WorkCover Queensland, ReturnToWork SA, WorkCover WA, WorkSafe Tasmania, NT WorkSafe, WorkSafe ACT and Comcare. Shipping
Each scheme is a configuration, not a fork: the correct impairment guide edition and modifications, the scheme's terminology (the worker, the claimant), required declarations, and the expected section structure. The drafting engine itself never branches on the scheme - which is what makes adding the next one tractable. Motor-accident and other schemes (TAC, CTP, DVA) are on the roadmap. Planned
The review workflow
The doctor works through a tabbed matter view - details, documents, chronology, report, your findings, export. Shipping
In the report tab, every sentence can be accepted, rejected or edited in place. Clicking any citation chip opens the source drawer: the cited page with the quoted span highlighted, the OCR method and confidence for that page, and one click through to the source PDF itself. The reviewer never has to trust a citation blind.
Exports are gated. A draft export is always available and carries visible review markers; a final export is refused while any flagged sentence is unreviewed, any unsourced sentence unaccepted, any required doctor input missing, or any instruction question unresolved. Reports export as DOCX (with the examiner's signature image), plus PDF where available, and every export is kept as an immutable version. Once a matter is finalised it is locked against further change; it can be reopened, but only deliberately. Shipping
To be precise about signing: the report is signed by the doctor in the ordinary professional sense - reviewed line by line, completed with their opinion, and issued under their signature. The software does not apply cryptographic signatures on the doctor's behalf.
Security and access
Sessions use short-lived access tokens with rotating refresh tokens and reuse detection, so a stolen token dies quickly and a replayed one revokes the whole family. Multi-factor authentication (TOTP) is required for clinical routes, an idle session locks and requires a PIN to resume, and passwords are hashed with argon2id. Authentication endpoints are rate-limited and designed not to leak which accounts exist. Shipping
Access is role-based - admin, examiner, support, reviewer - and all traffic is encrypted in transit with TLS 1.3.
Tenancy and audit
Isolation between practices is enforced in the database itself: PostgreSQL row-level security is enabled and forced on every clinical table, so a query outside the active tenant's context returns nothing - even application bugs cannot cross tenants. Shipping
Every insert, update and delete on clinical data is captured by database triggers with before-and-after snapshots; reads of clinical content are logged at the API layer; and every AI call is logged with model and usage metadata, without storing case content in the log. Clinical records are soft-deleted rather than destroyed mid-engagement, and exported report versions are immutable.
Data residency and AI
Everything is onshore. Processing and storage run in Australia, and - unusually for a product in this category - AI inference currently runs on Trenthos-controlled hardware in Australia: case content is not sent to third-party AI services, and no customer data is ever used to train models. Shipping
As production moves to AWS Sydney, managed onshore AI inference is planned behind the same guardrails, with region constraints that make cross-border inference structurally impossible rather than a matter of configuration discipline. Planned
The data model is built for de-identification: a matter carries a claimant label of the practice's choosing rather than identity fields - there is nowhere to put a Medicare number or home address, and date of birth is optional. Trial cases run fully de-identified. Configurable per-tenant retention and purge controls are on the roadmap. Planned
Getting a case in
A matter starts with the letter of instruction and the records as they arrived - there is no requirement to clean, split or re-scan the file. The pipeline classifies, reads and indexes what it is given, and the chronology and draft follow.
For trials, cases are de-identified before they reach us - names, addresses and identifiers removed - and files are shared over a secure channel we set up together, never as an email attachment. We will show you how; it takes minutes.
Status and roadmap
Trenthos IME is in early access with a small number of Australian practitioners. The full pipeline has passed an end-to-end acceptance run on synthetic matters - grounding verification, gap flags, impairment refusal, the final-export gate and audit trails all exercised - and the API is covered by a substantial automated test suite run in continuous integration against real services. Shipping
In active development and planned, in rough order: production hosting on AWS Sydney; managed onshore AI inference; additional schemes (TAC and CTP first); per-tenant retention and purge controls; and deeper operational monitoring. Security certifications (SOC 2, ISO 27001) are being designed toward, and are not claimed until they are held. In build
Trying it on one case
The honest test of a drafting system is your own case, marked against your own standard. Tell us the specialty and the scheme, and we will set up a secure way to share one de-identified file; you get the drafted report back to compare. The first case is free, and it starts with one email to support@trenthos.com - or start from the product page.