Eight systems, one lifecycle: an operations platform for medical staffing

Why this one is anonymous

The client's business is placing doctors. Their commercial relationships with hospitals, their rates, their volumes and the identities of the practitioners on their books are all confidential, and none of it is ours to publish. So this case study names no client, no hospital, no practitioner and no numbers. What is described here is the architecture and the reasoning, which is the part that is useful to anyone weighing similar work.

One thing is worth stating plainly, because the sector invites the wrong assumption: this is not a clinical system. It holds no patient records, no clinical information and no medication data, by design. The sensitive material is practitioner identity, professional registration, insurance, tax and banking details. That is a serious obligation, and it is a different obligation to a health record.

The problem: a lifecycle nobody owned end to end

A doctor moves through six stages before the business is paid and they are paid: recruit, credential, contract, schedule, bill the hospital, pay the practitioner. Each stage already had a capable product behind it. Recruitment ran in one system, rosters in another, documents and signatures in a third, accounting in a fourth.

The gap was the joins. No product owned the whole lifecycle, so each boundary was a person exporting from one system and typing into the next, on a deadline, with money and compliance attached. That is the failure mode we see most often in operations work: not a bad tool anywhere, just nothing holding the tools together.

The monthly payment run was the sharpest version of it. One file, hundreds of rows, each needing validation, an accounting entry, a generated invoice, a signature request and a chase if it went quiet. Done by hand it consumed the finance team's month and every error surfaced late, in money.

The constraints that shaped the design

• Confidentiality is the design input, not a review stepPractitioner identity, registration, insurance and banking details sit in the system. That set the authentication model, the separation between test and live environments, and the rule that no more data is held than the process needs.
• Money and compliance have deadlinesA payment run cannot be late and cannot be wrong. Validation happens before an accounting entry is raised, not after, and anything that fails is surfaced for a person rather than skipped quietly.
• The existing systems stayRecruitment, rostering, documents and accounting were all working products. The brief was to connect them, not to replace four systems and absorb the risk of doing so.
• Australian regulation is the logicRegistration, business number validation, GST and superannuation rules are Australia-specific and are encoded in the payment logic, not layered on top of a generic template.

What we built

An API layer that owns the lifecycle, sitting over the CRM the business already ran on rather than replacing it. The CRM stays the source of truth for people, sites and relationships; the platform orchestrates everything that has to happen to those records, and every external system is integrated through it rather than through a person.

Long-running work moved onto a background job engine instead of a request. A payment run is not a button that has to finish before someone can look away: it is queued work that validates, calls each external service in order, retries what fails transiently, and reports what needs a human. The same engine drives the reminders that used to be a diary note.

Eight external services connect through that layer: recruitment, rostering, accounting, document generation and electronic signature, the Microsoft 365 tenant, the national business register for tax validation, inbound web forms, and SMS. Each one is a boundary that used to be a person re-keying, and is now an integration with an audit trail.

The Australian part is not a detail

Practitioner registration, business number validation, GST treatment, superannuation and provider numbers are all Australia-specific, and they are not configuration on top of a generic system. They are the rules the payment logic is made of. An offshore build against a generic template gets this subtly wrong in ways that only surface at the end of a quarter, which is one of the reasons the work was done here.

Where it landed

The lifecycle now runs as one connected process. A file goes in at the start of the payment run and the platform validates it, raises the accounting entries, generates each document, sends it for signature and follows up on what has not come back. The finance team handles the exceptions rather than the whole. Onboarding, credentialing and contracting run through the same spine, so a doctor's status is a fact the system knows rather than something someone reconstructs from four screens.

We have deliberately not published throughput or headcount figures here. They are the client's numbers, they identify the business to anyone in the sector, and a case study that trades a client's confidentiality for our marketing is not a case study we would want a future client to have read.

What generalises

Most businesses at this size do not need their tools replaced. They need the space between the tools to stop being a person. The products in this build were all fit for purpose; the value was in owning the lifecycle that crossed them, putting the slow work on a queue, and making the state of any given case answerable from one place.

If that shape is familiar, the first conversation is about mapping your own lifecycle and finding the joins that are currently staffed rather than automated.

Common questions

Why not replace the existing systems?

Because they worked. Each product was a reasonable choice for its stage, and replacing four capable systems to solve a joining problem is expensive and risky. Where an off-the-shelf product fits, we configure it and connect it. We build the piece that does not exist.

How is confidential data handled?

Least data held, certificate-based authentication between the platform and the CRM rather than shared passwords, and a separate sandbox environment so that testing never runs against live records. The specifics of a client's security posture are not something we publish.

Is this a health or clinical system?

No. It holds no patient records, no clinical information and no medication data. It handles the administrative and financial lifecycle around practitioners and the sites they work at.

How long does something like this take?

It is not one delivery. A platform like this arrives in stages, with the most expensive manual process automated first so it pays for the next stage. The first conversation is about identifying which stage that is for you.

Talk about your own lifecycle