Why FHIR Matters When Choosing Practice Management Software
A referral arrives through secure messaging. A team member opens the document, reads the details and types them into the patient record. Pathology results come from a different system, so they’re downloaded, attached and filed by hand. During a consultation, the AI scribe needs context from the record, so someone copies it across.
The information already exists digitally. The work is getting it from one system into another.
For one patient, that takes a few minutes. Across a busy practice, those minutes become hours of admin, with more chances for details to be mistyped or to go out of date. The fix is interoperability: software that can exchange and use each other’s data directly. FHIR is a shared set of rules for how health information is labelled and sent, so different software can understand each other. It’s becoming more common, and it’s worth understanding before you compare software.
This article covers how FHIR works, what it changes for a practice, and what to ask before you commit to a platform.
What is FHIR?
FHIR (Fast Healthcare Interoperability Resources, pronounced “fire”) is a standard from HL7, the international body that sets health data standards. It gives healthcare software a common way to structure and share data.
Think of it as a common language. It doesn’t automatically connect every system to every other, because systems still need to be set up to work together, including security, permissions and day-to-day workflows. But a shared standard reduces custom development and makes new connections more consistent.
Four ideas sit behind it.
Resources
FHIR splits healthcare information into standard types, called resources. Examples include a patient, an appointment, a prescription (MedicationRequest in FHIR), a test result or measurement (Observation) and a referral (ServiceRequest). Each type has a fixed set of fields, so every system knows where to find a date of birth or a medication.
APIs
An API is a set of rules that lets one piece of software ask another for information, or send it some. Think of it as a menu and ordering system: the rules tell one program exactly how to ask another for something. FHIR requests travel over the web, much like loading a web page, and the answer comes back as structured text that software can read easily. When an API is documented, a developer can see exactly how to ask for what they need.
Terminology
Two systems can share the same fields and still describe things differently. FHIR works alongside clinical codes to fix this. SNOMED CT-AU is Australia’s standard list of clinical codes. It gives each diagnosis, symptom or finding its own code, so “type 2 diabetes” recorded in one system is understood as the same condition in another.
Profiles
FHIR leaves room for choices, so each country publishes a local rulebook, called a profile, that says which fields to use and how. In Australia, AU Core is that common baseline. Sparked is the community that develops and tests FHIR for Australian healthcare.
What FHIR changes for a practice
The technical details matter, but the real question is what interoperability changes in day-to-day work. The examples below describe what’s possible when both ends of an exchange support FHIR.
Referrals
A referral bundles the patient’s details, the reason for referral, their history and supporting documents. FHIR gives each a standard label and place, so the receiving software can fill in the right parts of the record instead of relying on manual entry.
Example: Where the sender supports FHIR, a GP's referral arrives and your team opens a record that is already populated, then confirms the details.
Pathology and results
A PDF is like a photo of a page. Software can display it, but can’t reliably read the patient, test or value inside it. Structured formats solve this, and FHIR is one of them. It sends results as data that software can match automatically. (A single value, such as a haemoglobin level, is an Observation. A group of results forms a DiagnosticReport.)
Example: A blood test result arrives as structured data and is matched to the right patient and test. Staff step in only when the system can't make a true match.
Third-party tools
Telehealth, ePrescribing, AI tools and other applications each need some information from the patient record. A standard way for software to connect gives them a consistent, authorised way to request it, and the platform controls what each one can see. Because the connection method is standard, a new tool that supports the same FHIR standards may connect without a custom-built connection. That keeps your options open as your needs change, including for tools that don’t exist yet.
Example: An AI documentation tool requests only the patient context it is authorised to access, with no custom connection to build. Permissions and configuration are still needed, but the custom work shrinks.
Where the sector is today
FHIR is growing in importance in Australian healthcare, but many referrals, results and other exchanges still rely on older but widely used message formats, such as HL7 v2 and CDA. MediRecords connects with the secure messaging services HealthLink and Medical-Objects for these exchanges. Healthcare organisations and vendors work across several standards at once, so the practical position is a platform that works with the systems you rely on now and gives you a foundation for what comes next.
Why not every platform supports FHIR
Supporting FHIR takes more than adding another integration. A platform has to be built to store and share data in a consistent structure, with authentication, access controls and documented APIs behind it. Many established systems were designed around their own way of organising data, with connections added one at a time over the years. That approach works well for specific connections, but adding a shared standard to an older system means reworking how it stores and organises data. That is a large engineering project, and the vendor has to see enough demand to justify it. Platforms built more recently, or rebuilt around open APIs, often find this easier, though a newer platform isn’t automatically a better one.
That is why it is worth checking how a platform is built, not only what it lists.
What to check before you commit
Which FHIR resources are supported?
Can data be both read and written?
Is the API documented and accessible to developers?
Which Australian profiles or implementation guides are supported (for example, AU Core)?
Has the FHIR implementation been tested or conformance-checked, for example at a Sparked connectathon?
How are authentication and permissions handled?
Can third-party applications connect directly?
How much custom development is required for a new integration?
Does it also support HL7 v2 and CDA for the exchanges that still depend on them?
Are there fees for API access or third-party connections?
Can I export my data in a standard format if I leave?
Clear answers let you compare platforms on equal terms, and vague answers tell you something too. MediRecords publishes its API documentation, so you can test it against this list.
Where MediRecords fits
MediRecords is a cloud-based electronic health record (EHR) and practice management platform designed with interoperability in mind. It supports standard web-based connections (REST APIs) and FHIR, along with Australian standards including SNOMED CT-AU, and is a founding member of Sparked. Its connections cover the workflows where practices feel the most friction:
- Telehealth: Coviu
- AI scribing: Heidi Health
- ePrescribing: eRx
- Healthcare information exchange (referrals, results, correspondence): HealthLink and Medical-Objects
- Payments: Stripe
MediRecords use cases
Appointment booking APIs. A patient-first start.
Appointment Booking API
Patients book from your practice’s own website. They choose a service, see an estimated next opening and get a confirmation. Behind the scenes, the booking goes straight into MediRecords, so your team doesn’t have to re-type it.
This is an example of what a developer could build using the MediRecords appointment APIs, not a ready-made product. Times shown are estimates until the booking is confirmed.
Online patient forms that go into the record
Patient Forms API
New patients fill in their details online before their first visit, including an emergency contact. The details go straight into their MediRecords record, so your team doesn’t have to type them in. Referral letters can be uploaded too. They are saved in the patient’s Correspondence In folder, so nobody has to file them by hand.
Referral letters can be uploaded too. They are saved in the patient’s Correspondence In folder, so nobody has to file them by hand.
This is an example of what a developer could build, not a ready-made product. Referral letters are saved as correspondence, not as referral records.
Frequently Asked Questions
What does FHIR stand for?
Fast Healthcare Interoperability Resources. It’s maintained by HL7, the international standards body for health data.
Is FHIR the same as an API?
No. An API is the way one piece of software asks another for information. FHIR is the set of rules for what that information looks like and where each detail goes. FHIR is usually delivered through an API.
If a platform supports FHIR, can anyone access my patient data?
No. FHIR is about how data is structured and shared, not who can see it. Access is controlled by the platform, which verifies who is asking and limits what each application can see.
Does "supports FHIR" mean the same thing for every vendor?
No. Vendors may support different types of information, different Australian rules, and different levels of reading and writing data. The checklist in the article helps you find out exactly what is supported.
Why does FHIR matter to my practice?
It reduces the manual work of moving information between systems, and it makes it easier to add new tools later without custom-built connections.
Considering a move to MediRecords?
Choose your current system and enter your details into the form below. We’ll show your full migration breakdown, and if you’re ready to proceed, our team will be in touch with your timeframe.
Data we move across from
Expand a category to see where it lives in MediRecords →
Coverage reflects standard MediRecords migration scope. Some fields depend on how your current system exports, and in some cases data moves across but is stored in a different place in MediRecords.
