Learn / Developers
For software vendors and integration teams

Bring your software into the care record

Every route into HealthOS lands in the same Canonical Care Record, under the same tenancy, matching and audit rules. Pick the one that fits how your system already talks, and we’ll set you up with a test organisation to build against.

Ask for a test organisation Get the developer guide
A rostering connector in the admin portal: healthy, with its ingress pipeline into the canonical data model, the filters either side and its recent activity.
True of every route
One person, one record

Data is matched to a person on Medicare, IHI, MRN or DVA numbers first, then name and date of birth. Anything uncertain waits in a review queue.

Scoped to one organisation

A connection belongs to the provider who installed it. Its token, its secret and what it can see stop at that organisation.

Standards where they exist

FHIR R4 with AU Core profiles for clinical data, and HL7 v2 for the feeds that still speak it.

On the record

Each call is logged against the connection that made it, and the audit trail is kept for seven years.

Seven ways in

Start from how your system talks

Most vendors need one of these. A few need two, usually a feed in and an app on top.

RouteSuitsDirectionGuide
FHIR for systemsIntegration engines and clinical systems exchanging records in bulk or as eventsBoth waysFHIR for systems
SMART on FHIR appsAn app a clinician opens from a patient’s chart, or a patient or family member opens on their ownBoth waysSMART on FHIR apps
HL7 v2 over MLLPPathology, radiology, ADT and bedside monitor feedsInto HealthOSHL7 v2
Ready-made contractsRostering systems, remote monitoring platforms and location systemsInto HealthOSReady-made contracts
Signed webhooksAnything that can POST JSON when something happensInto HealthOSWebhooks
HealthOS calls your APISystems with a REST or FHIR API we can poll on a scheduleBoth waysPull, files and replication
Files and replicationBatch extracts, SFTP drops and staging tables in a database you runInto HealthOSPull, files and replication
FHIR, twice

The back end and the front end are different jobs

FHIR is our main route for clinical data, and people mean two quite different things by it. We split them.

FHIR for systems

Your integration engine or clinical system exchanges records with HealthOS directly. Bundles can come in through a signed endpoint on the integration engine (the ESB), which maps them, matches the person and writes the record, or go straight to the FHIR API when no mapping is needed. Reads and bulk exports use a backend service credential.

  • No person signs in; the connection itself is authorised
  • Sees what its scopes allow across the organisation
  • Fits event-by-event exchange, and bulk export for whole populations

Read the FHIR for systems guide →

SMART on FHIR apps

Your app runs in front of a person. A clinician opens it from the Apps menu on a person’s chart, or a patient or family member signs in through HealthOS Connections, and the app gets a token for that person and nothing wider.

  • The user signs in and approves the app, and an ID token tells your app who they are
  • Limited to one patient, or to what a clinician may already see
  • Fits decision support, specialist views and apps for families

Read the SMART on FHIR guide →

Getting connected

Every provider runs their own HealthOS, so you never get one key that opens everyone. You build once, and each provider installs your connection in their own organisation.

  1. Tell us what you’re connecting, and who is asking for it. We’ll agree the route and the data with you.
  2. We set up a test organisation with invented people and give you its credentials.
  3. You build against it. Signatures, idempotency keys and error responses behave there exactly as they do in production.
  4. A provider installs your connection from the connector marketplace in their own HealthOS. Their administrator approves it, and the credentials issued belong to that install alone.
The developer guide

Every guide in one PDF

All the routes, examples and error codes in one document, to read offline or hand to your team. Tell us where to reach you and the download starts straight away.

We collect your email so we can follow up about building on HealthOS, and to send API updates only if you tick the box. We don’t sell or share it. To see or remove what we hold, email aaronl@healthos.net.au.

The guides

FHIR for systemsIntegration engines into the ESB, and reads with a backend credential. SMART on FHIR appsRegistration, launch, scopes and what a token can see. HL7 v2MLLP listeners, results, vital signs and TLS. Webhooks and contractsSigning, replay protection and the formats we already read. Pull, files and replicationWhen HealthOS goes and fetches the data itself. In the server roomHosting, identity and security for the IT team.

Step by step

Each setup walked through on a real HealthOS, screen by screen, with who does each step.

Send FHIR Bundles through the ESBA flow with a FHIR webhook source, a signed Bundle, the record it writes. Connect a backend systemKeys, a token, a read, a write and a bulk export. Launch a SMART app from the chartRegister, show it in the Apps menu, launch with the patient. Connect a patient or family appSign in through HealthOS Connections and choose whose records. Send HL7 v2 over MLLPThe listener, a lab result, vital signs and the ACKs. Post JSON to a signed webhookMap your payload, sign it, retry safely, rotate the secret. Use a ready-made contractWorked shifts and device readings in our formats. Let HealthOS read from youYour REST or FHIR API, a file, or your database.

Building for Australian care?

Tell us what your system does and which providers want it connected. We’ll suggest a route and get you a test organisation.

Contact us