Automating Data Entry into Xestro Without an API

Xestro has no public API, so referrals, device reports and hospital results cannot be pushed into it the way you would connect two cloud apps. They can still get there automatically. The automation either prepares files that Xestro imports, or uses a software robot that works through Xestro's screens like a person. We use the first wherever we can and the second for the gaps.

We are Osher Digital, a Brisbane automation consultancy. We run two of these automations in production medical practices that rely on Xestro, and everything below comes from that work. If someone in your practice spends part of every day retyping letters and results into Xestro, this is for you.

What Xestro connects to, and what it does not

Xestro is cloud practice management software for Australian private specialists. It stores its data in Australia, it is ISO 27001 certified, and it has built-in connections to a short list of services: HealthLink and Medical Objects for clinical messaging, Services Australia, eRx, MIMS, Tyro, and pathology from Sonic Healthcare and Healius.

What it does not publish is an API that lets another system create a patient, attach a document or record a result. Anything that does not arrive through one of those built-in connections gets into Xestro in one of three ways:

1. A person types it in or uploads it by hand.

2. A file is prepared in a form Xestro can import, and staff or a bot drop it in.

3. A software robot works through Xestro's screens the way a person would.

The second and third can be automated. The first is what most practices do today.

Check the free route first

Before you pay anyone to build something, ask whether the sender can use HealthLink or Medical Objects. Many hospitals, pathology labs and referring doctors already do, and those messages reach Xestro with no extra work. We tell every Xestro practice this before we quote, because it costs nothing.

Automation earns its keep where the built-in connections do not reach:

• referrals that arrive as email attachments, scanned faxes or portal uploads

• reports from equipment in your own rooms, which save to a PC, a network drive or an inbox

• hospital PDFs that bundle several patients into one file

• new patient details that someone currently keys in from a referral letter

What practices need to get into Xestro

Source	What it usually produces	How much work it takes
Stress ECG systems, such as the Philips ST80i	A PDF report, plus XML or DICOM	Low. The XML labels every field, so nothing has to be interpreted
Resting ECG, Holter and ambulatory blood pressure monitors	A PDF report. Some models also export XML	Low to moderate
Echocardiography machines	A PDF report and DICOM images	Moderate. The report is usually the part that belongs in Xestro
Spirometry and sleep study systems	A PDF report	Moderate
Referral letters from GPs and specialists	Letters, PDFs, scans and email text, laid out differently by every sender	High. These need OCR and AI to read
Hospital discharge summaries and pathology bundles	Multi-page PDFs, sometimes with several patients in one file	High. The file has to be split before it can be filed

The gap between the top and the bottom of that table is what drives the cost. A device that writes a labelled XML file next to its PDF already tells you the patient's name, date of birth and test date. A referral letter has to be read, and that is where OCR, AI and a human check come in.

Method 1: prepare files for Xestro to import

This is the method we prefer, because it breaks the least.

Xestro can fill in a new patient's details from a structured JSON file dragged into it, and documents can be bulk imported when they follow Xestro's file-naming rules. So the automation does the slow work (reading, matching, naming and formatting) and leaves a tidy batch ready for import.

The patient file is a single JSON object whose keys are Xestro's own patient fields. This is the shape we produce for referrals, shown here with an invented patient:

{
  "FirstName": "Jane",
  "LastName": "Citizen",
  "KnownName": "",
  "DOB": "14-03-1968",
  "Sex": "Female",
  "Address": "12 Example Street, Richmond, VIC, Australia, 3121",
  "Phone": "0400 000 000",
  "Email": "[email protected]",
  "HealthCard[1][CardNumber]": "2123456701",
  "HealthCard[1][NumberOnCard]": "1",
  "Remarks": "Next of kin: John Citizen, 0400 000 001"
}

Each referral gets its own folder, named after the patient and date of birth, holding the JSON file and the original referral. A staff member drags the file into Xestro, checks the details on screen and saves. Fields the AI could not read with confidence are left blank, not guessed.

A typical pipeline, which we build in n8n on an Australian server:

1. Watch the places documents arrive: a referrals inbox in Microsoft 365, a HealthLink feed, or the folder where a device saves its exports.

2. Read each document. Structured device exports are parsed directly. Letters and scans go through Azure Document Intelligence for OCR, then an AI model pulls out the patient details.

3. Split bundled PDFs into one file per patient and per report.

4. Check for an existing patient by name, date of birth, Medicare number or mobile. A confident match goes ahead. A doubtful one goes to a person.

5. Write the JSON patient file, or rename the document to Xestro's naming convention, and place it in the folder staff import from.

6. Log every step, so anyone can trace a record back to the email or file it came from.

The final drop into Xestro can stay with staff, which takes seconds per batch, or a small bot can do it.

Method 2: a software robot that uses Xestro's screens

Robotic process automation (RPA) is a bot that logs into Xestro in a browser, finds the patient, opens the right screen and types or uploads, the same way a person would. It is the answer when a task has no import route at all.

RPA works, but it is the more fragile of the two. When Xestro changes a screen, the bot can stop until someone updates it, so it needs monitoring and quick fixes. We quote that maintenance up front rather than leave it as a surprise. Most Xestro jobs end up as a mix: file import for everything Xestro can take that way, and a bot only for the steps that have no other way in.

Example Xestro automations we run for medical practices

The first handles referrals. Referrals arrived by email and HealthLink, and the practice managers spent more than 30% of their time typing patient details into Xestro and Zoho CRM. An n8n workflow now watches the inbox and HealthLink and reads each referral with Azure Document Intelligence and AI. It checks Zoho CRM for an existing patient and creates or updates the record through Zoho's API. For Xestro, it writes the JSON patient file shown above into a folder with the original referral, and staff check it as they drag it in. Data entry time fell by more than 90%, and referrals are processed in minutes instead of hours. (Read the case study)

The second example handles results. ECGs, echocardiograms, Holter results, pathology and discharge summaries came in by email, HealthLink and OneDrive, often as one PDF with several patients inside. Staff spent 10 to 20 minutes per batch, several times a day, working out where each report started, classifying it, renaming it and filing it. An AI agent now finds the boundaries between reports, classifies each one, extracts the patient name, date of birth and test date, and renames the file to Xestro's naming convention in a OneDrive folder ready for bulk import. Staff check only the unusual ones. (Read the case study)

A device in your own rooms is a simpler job than either of these. When a machine writes structured XML, there is nothing to interpret, so the build is smaller and there is far less for a person to check.

Where a person still checks

We keep a person in the loop for three things: a patient match that is not certain, a document the system cannot classify, and anything password protected. In practice that is a short review queue each day, not a second job.

Clinical judgement is never automated. The system moves documents and details into the right patient record. A doctor still reads the report.

Patient data stays in Australia

Xestro keeps its data in Australia, and the automation around it should too. Under Australian Privacy Principle 8, a practice that sends personal information overseas generally stays accountable for how the overseas provider handles it. We host client workflows on Australian servers and use OCR and AI services that can run in an Australian region. Whoever you talk to, ask where every step runs, including the AI model. Our guide to self-hosting n8n in Australia covers the hosting side in more detail.

What to have ready before the first call

• What the device or sender exports (PDF, XML, DICOM) and where it saves the files

• Whether the PDF report is enough, or whether images also need to reach the patient record

• Who looks after your Xestro account, and whether you have any import or partner access

• Roughly how many documents arrive each week, and from where

• Any rules about where patient data may be stored or processed

Frequently asked questions

Does Xestro have an API?

Xestro does not publish an API for creating patients or adding documents. It connects to selected services, including HealthLink, Medical Objects, Services Australia and Tyro. Everything else reaches Xestro through file import, a person, or a software robot that uses its screens.

Can a medical device send reports straight into Xestro?

Not on its own, unless the device's software can send through a channel Xestro already accepts, such as HealthLink. Most devices save a PDF, often with XML or DICOM, to a folder or an inbox. An automation picks the files up, matches each one to the right patient and prepares it for import into Xestro.

Can referrals be added to Xestro automatically?

Yes. We read referrals from email and HealthLink with OCR and AI, extract the patient details, check for duplicates and prepare the record for Xestro, with a person reviewing anything uncertain. At one Melbourne practice this cut data entry time by more than 90%.

Is RPA safe to use with patient records?

It can be, if the bot has its own Xestro login with only the access it needs, every action is logged, and it runs on a secured server in Australia. The bigger risk with RPA is that it stops when a screen changes, which is why we use file import wherever Xestro supports it.

Do we still need staff to check the data?

For structured device exports, very little. For referral letters and hospital bundles, yes, but only for the cases the system flags as uncertain. That review step is what keeps duplicate and mismatched patient records out of Xestro.

Talk to us about your Xestro workflow

If a device, a referral inbox or a results feed in your practice ends with someone retyping it into Xestro, book a 15-minute call. Send us a sample file if you can, tell us where it lands, and we will tell you which method fits and what it will cost. Our automated data processing page explains how we build these pipelines, and our healthcare page covers the other work we do for practices.