If you have ever looked for an app to keep your medical record, you have met the acronym FHIR. It shows up in descriptions, on “security and compliance” pages, in announcements from hospitals and ministries. It is rarely explained. This guide does that without turning you into a programmer: what FHIR is, which problem it solves, what it means for you concretely, and how to tell whether an app really uses it or just writes it on the website.
The problem: every system speaks a different language
A blood test done at a laboratory reaches you as a PDF. The same test, in the hospital's system, is a row in a database with its own format. At your family doctor it is, perhaps, a free-text note. Three places, three formats, no link between them. When you want to put them together, the only tool is a human who reads and retypes.
For decades, medical systems were built exactly like that: each with its own format, exchanging data with others only through “bridges” written specially, expensively and fragilely. Older standards (HL7 version 2, from the 1980s, or CDA) partly solved the problem for hospitals, but they are hard for modern apps to use and almost impossible for a person to read.
What FHIR is
FHIR (pronounced “fire”) stands for Fast Healthcare Interoperability Resources. It is a standard published by HL7 International, the organisation that has defined how medical data moves between systems for over 35 years. The version in wide use today is R4 (4.0.1), published in 2019; a newer version, R5, has existed since 2023, but most systems in the world, including the legal requirements in the EU and the US, are based on R4.
The central idea is simple: any piece of medical information is described as a resource with a known structure. There is a resource for the patient (Patient), one for a test or a measurement (Observation), one for a diagnosis (Condition), one for a prescribed medication (MedicationRequest), one for an allergy (AllergyIntolerance), one for a vaccination (Immunization), one for a document (DocumentReference) and so on, around 150 in total. Each resource has defined fields: an Observation has a code for what was measured, a value, a unit, a date, who measured it, for whom.
Resources are written in JSON or XML, formats every programming language reads, and travel over the internet exactly like web pages, through addresses and HTTP requests. That is the difference from the old standards: FHIR uses the tools every programmer already knows, so it is cheap to implement and hard to implement wrongly.
Codes: so everyone understands the same thing
Structure is not enough. If one system writes “blood sugar” and another “serum glucose”, they still do not understand each other. FHIR solves this by requiring standard codes for content:
- LOINC for tests and measurements: fasting glucose is code 1558-6, anywhere in the world.
- SNOMED CT and ICD-10 for diagnoses and procedures.
- ATC (the WHO classification) for medications, by active substance.
- UCUM for units: mg/dL and mmol/L are written identically everywhere, and conversion is automatic.
With structure and codes, a FHIR resource produced by a laboratory in Sibiu is read correctly by a hospital in Vienna or an app in California, without anyone having written a “bridge” between them.
What it means for you, concretely
Four things, from the most visible to the most important.
Your data can be moved. If your record is stored as FHIR, it can be exported completely and imported into any other compatible system. You do not depend on a single app and you are not hostage to a format only it understands. “Yours” means, in practice, “exportable in a standard format”.
Your data can be understood by doctors. A new doctor, a hospital in another country, an emergency service: all of them can receive a FHIR summary (usually as an International Patient Summary) and read it in their own system, with their codes, in their language. Not a 40-page PDF, but data they can search, filter and compare.
Your data can be brought together. Tests from different laboratories, measurements from your watch, medications from prescriptions, scanned documents: when all are FHIR resources with LOINC codes and dates, they fit on the same timeline and can be compared. A good app does this automatically.
Your data is protected by a standard, not a promise. FHIR also describes how access to data is granted: through SMART on FHIR, a framework based on OAuth 2, in which you explicitly approve which app sees which part of the record, for how long, and you can withdraw access. It is the same mechanism you use when you “sign in with Google” on a website, applied to medical data, with fine-grained permissions (only the tests, only the medications, read-only).
Where FHIR is already used
FHIR is not a standard “for the future”. It is already mandatory or in use in places you know:
- The United States requires by law (the 21st Century Cures Act and the 2020 ONC rules) that any certified medical system expose the patient's data through a FHIR R4 API, and that patients can take their data with an app of their choice.
- Apple Health Records brings records from hundreds of hospitals into the Health app on iPhone, via FHIR.
- The European Union chose FHIR for the European electronic health record exchange format (EEHRxF) that the EHDS regulation imposes on member states; patient summaries exchanged between countries through MyHealth@EU are built on it.
- The United Kingdom, the Netherlands, Germany and the Nordic countries use FHIR in their national infrastructures, from the German electronic prescription to the Dutch record.
- The World Health Organization chose the FHIR-based International Patient Summary for its global network of digital health certificates.
For you, this means an app that keeps your record as FHIR R4 is not an island: it speaks the language hospitals and authorities already speak, now and for the next decade.
How to recognise an app that really uses FHIR
Anyone can write “FHIR” on a website. The questions below separate the word from the reality.
- Can I export my whole record as FHIR? Not “a PDF report”, but a file with the resources (a Bundle) another system can import. If the answer is “no” or “only on request, by e-mail”, the data is not really yours.
- Do lab results have LOINC codes and UCUM units? An app that only stores “Cholesterol: 210” as text cannot compare it with last year's value from another lab. One that stores the code and the unit can.
- Can I give someone else access, limited and revocable? A doctor, a clinic, another app: with SMART on FHIR, you choose what they see and for how long, and you see who read what.
- Can I generate an IPS summary? This is the practical test of “interoperability”: if the app can produce the standard summary any European hospital reads, the structure behind it is real.
- Is there public developer documentation? A documented FHIR API with a public capability statement (
CapabilityStatement) means other systems can actually connect. If there is none, “interoperable” is just an adjective.
What FHIR does not solve
It is fair to state the limits too. FHIR describes the format and transport of data, not its quality: a wrongly entered result stays wrong, just in a nice format. FHIR does not guarantee your privacy; that comes from who hosts the data, in which country and under which access rules. And FHIR does not make systems want to exchange data: many hospitals have a FHIR API and open it to no one, which is exactly why legislation (in the US, and in the EU through the EHDS) exists to oblige them.
How Anpheros uses FHIR
Anpheros stores each person's record as HL7 FHIR R4 resources (26 resource types, from Patient and Observation to DocumentReference and Consent), with LOINC, ICD-10, ATC and UCUM codes, in the European Union. The Anpheros Daily app is a client of the same public API clinics and developers use; there is no separate “internal” format. You can export the full record or an IPS summary at any time, validated with the official HL7 validator. Access for other apps is granted through SMART on FHIR, with consent for a limited period, revocable, and with a log you can see. The API documentation and the capability statement are public at developers.anpheros.com.
Frequently asked questions
Do I need to know FHIR to use my record?
No. FHIR is under the bonnet. You see tests, medications and documents; the standard makes them movable, comparable and readable by doctors. It is worth knowing it exists only so you choose well where you keep your data.
Is FHIR the same as the national electronic record?
No. FHIR is a format and a way of transport; the national record is a system. Many national systems use or are adopting FHIR, but the fact that a country has an electronic record does not mean you can take your data out of it as FHIR. In the EU, the EHDS will require exactly that.
What is the difference between FHIR R4 and R5?
R5 (2023) brings refinements, but it is not yet required by legislation and few systems use it. R4 (2019) is the basis of the US and EU requirements and of existing implementations. An app on R4 is the safe choice today; the move to R5 will happen gradually, with compatibility.
If my export is FHIR, can I really import it into another app?
If the other app accepts FHIR import, yes, on one condition: standard codes. Resources with LOINC, ICD-10 and UCUM map cleanly; those with free text end up as notes. That is why it matters that the source app coded the data from the start.
Is FHIR secure?
FHIR by itself is neither secure nor insecure; it is a format. Security comes from the implementation: encryption, hosting, authentication, consent. SMART on FHIR provides a good framework for controlled access, but you still have to look at who holds the data and where.
Keep your medical record with you
Anpheros Daily keeps symptoms, lab results, medications and documents in one place, in a standard format, under your control. The Basic plan is free.