Why FHIR Matters When Choosing Practice Management Software

Why FHIR Matters When Choosing Practice Management Software

October 21, 2026

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:

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.

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.

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.

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.

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.

Can't see your system? It can usually still move across. Reach out to our team to organise a sample data review.

By submitting, you agree to MediRecords contacting you about your migration. See our privacy policy.

More from the Blog

What Happens To Your Data When Switching EHR Systems?

What Happens To Your Data When Switching EHR Systems?

September 23, 2026

You’ve decided it might be time for a software change. Then comes the question that stops most practice managers in their tracks: “what happens to all the data we’ve built up?” 

Patient demographics. Clinical notes going back a decade or more. Medication histories, allergies, referral letters, scanned documents: the accumulated record of every patient who has ever walked through your door.

For many practices, this is where the search for new software stalls. Not because the new system isn’t better, but because the data feels too risky to move.

Changing software doesn’t mean leaving your data behind, and it doesn’t mean starting again from a blank patient list. With the right preparation, the information your practice depends on can be assessed, prepared and carried across into a new system.

Data migration is a process, not a copy and paste

Data migration is the process of moving information out of your current software and into a new system. Depending on what your existing system holds, that can include patient demographics, clinical records, medications, allergies, immunisations, investigation results, correspondence, documents and referrals, along with other everyday practice data.

The complexity comes from something most practices never have a reason to think about: no two systems store information the same way. Practice software isn’t built to a single shared standard, so a field that’s a simple text entry in one system might be a structured, coded value in another. Even something as basic as an allergy list can be organised in completely different ways behind the scenes.

That’s not a flaw in any particular system. It’s the reality of an industry where different vendors have built things independently over many years. In practice, this means every field falls into one of three categories during a migration:

Fields that move straight across.

The data type exists in both systems in a comparable form, so it transfers with little to no restructuring.

Fields that move across but land somewhere different.

The information carries over, but because the two systems model it differently, it may sit in a different part of the patient record than you're used to.

Fields that need a closer look.

Some data types are specific enough to a vendor's system that they need a sample of your real data checked before anyone can confirm exactly how, or whether, they'll convert.

Knowing which of your data falls into which category before you commit is one of the most useful things a practice can ask for early on.

What can you expect at each stage of a data migration?

No two software providers run migration exactly the same way, but at MediRecords, it comes down to four stages: scope, authorise, transfer and test, then go live. A typical process may look something like:

Scope the migration

A good plan starts with the practical questions: what does your current system hold, what can it export, and are there oddities, like old scanned documents or unusual custom fields, that need special handling? Scoping is shaped around your practice, not treated as one size fits all.

Authorise the migration

Once requirements are understood, formal authorisation is typically required before anyone accesses your existing system or data. This is usually a consent style agreement that sets out exactly what's being moved and gives permission to access the source system. It's a short, straightforward step, but an important one, since it ensures everyone is clear about what's happening before it happens.

Transfer and prepare the data

Your data is exported and prepared in a test environment first, never straight into your live account. This is where the real differences between systems get sorted out, and where you get a clear picture of what's included and any limitations that apply.

Test, review and go live

Your data is checked against your source system, and any issues that come up are fixed before you see the results. Duplicate records can occur since new data is added alongside what's already there, which is why they're flagged in a clean up report for your team to work through. Once the test is clean, your team reviews it against a supplied checklist, and once you're happy, your records move into your live account and a start date is set.

Common data migration myths

“We’ll lose years of history.” Structured records, and often scanned documents and notes, are designed to carry across, not be left behind. Testing in a separate environment before going live is precisely to catch anything that hasn’t come through properly, so it can be fixed before your team ever relies on it.

“It’ll take months and disrupt everything.” Most migrations are measured in weeks, not months, and one handled properly shouldn’t require your practice to pause normal operations while it happens. New information is inserted alongside what’s already in your current system, rather than overwriting it, so there’s little risk to the records you’re actively using day to day. Your team can generally keep working in the old system right up until going live.

“Our team needs to understand databases to get through this.” None of the technical mapping is work your team needs to do. What’s asked of your practice is far more practical: confirming what data you want brought across, providing access to an export of your current system, and reviewing the results once they’re ready. The database level work sits with the migration team, not with practice staff.

What this means for your practice

No practice needs to manually move records or understand how databases work to get through a migration. What’s expected of you is straightforward: help define what matters, provide access to your data, answer a few questions about your current system, and review the results once they’re ready. Handled properly, the record you’ve built over years of patient care arrives intact in the system you’re moving to.

Curious what a move to MediRecords would actually look like for your practice? Check your system with our free interactive migration tool to see exactly what data can move across, where it will land, and which fields might need a closer look.

Check your system

Frequently Asked Questions

How does data migration work with MediRecords specifically?

MediRecords migrates data from many of the major practice management systems used across Australia. If your current system isn’t a common one, a sample of your data can usually still be reviewed to confirm what’s possible. The process follows the same shape outlined above: scoping what needs to move, signing a short consent agreement, testing your data in a separate environment, and reviewing the results before anything goes live in your MediRecords account.

A few checks happen before anything reaches your live account. Your data is first moved into a test environment and reviewed against your existing system. Where a patient’s history exists in multiple records, the version with the longest, most complete history is the one brought across. Where the migration creates duplicates, a clean up report is shared with your team so you know exactly what to review.

Most migrations are measured in weeks, not months. The exact timeline depends on which system you’re moving from, how much data you have, and how complex your records are.

Not every field converts the same way between systems, since no two platforms store information identically. Some data moves straight across, some lands in a different part of the record, and some needs a closer look at a sample of your actual data before anyone can confirm how it’ll convert.

Any reputable migration process takes steps to keep your data secure throughout, including during testing. Ask your provider directly how they handle this if it’s not covered in what they’ve shared with you upfront.

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.

Can't see your system? It can usually still move across. Reach out to our team to organise a sample data review.

By submitting, you agree to MediRecords contacting you about your migration. See our privacy policy.

More from the Blog