What is FHIR? A plain-language guide for doctors in Senegal

Awa leaves Dr Moussa Ndiaye's cardiology practice in Plateau with a handwritten prescription (ordonnance), a request for a blood test and a follow-up date noted in the secretary's paper agenda. At a pharmacy in Medina, the pharmacist deciphers the handwriting. At the lab, someone types her name again. Next year, a new doctor will start her history from zero.

The problem is not a lack of software. It is software that does not share a language. This guide explains FHIR, the international standard built to give health data that shared language: what it is, its four building blocks, who already uses it and what it would change for a clinic in Dakar. No IT background is needed, and a short section at the end is for technical readers.

What FHIR is

FHIR stands for Fast Healthcare Interoperability Resources and is pronounced "fire". It is a standard for exchanging health information between computer systems, created by HL7 International, an organisation that develops health data standards. The specification is free for use with no restrictions: a clinic, a start-up or a public programme can build on it without paying a licence.

The long word in the middle, interoperability, simply means that two systems can exchange information and both understand it the same way. Think of official administrative forms: because everyone fills in the same boxes in the same order, any office can read a form filled in elsewhere. FHIR does the same for health data, using ordinary web technology (HTTP, JSON, XML).

Several versions exist. The one that regulators and national programmes rely on today is R4: it is the version required by US certification rules and the basis of India's national guide.

The four building blocks

Resources: standard forms

Each kind of health information has an agreed structure, called a resource. There is a Patient resource (name, sex, date of birth, contact details), an Appointment, an Encounter (the consultation itself), an Observation (a blood pressure reading or a lab result) and a MedicationRequest (the prescription). The R4 version defines more than 140 resource types, from scheduling to billing.

Resources point to each other. Awa's MedicationRequest refers to her Patient resource and to Dr Ndiaye's Practitioner resource, so the prescription always knows whose it is and who signed it. When a country needs something the base standard does not cover, FHIR lets it adapt resources to local requirements through profiles (local rules on a resource) and extensions (extra, documented fields), published so that others can read them.

Codes: one meaning everywhere

A form is only useful if the boxes are filled in the same way. FHIR therefore relies on international code lists: ICD-11 for diagnoses, LOINC for lab tests, ATC for medicines and SNOMED CT for detailed clinical terms. Whether a doctor writes paludisme, malaria or palu, the record carries the same ICD-11 code, and every system reads it the same way. Our guide to ICD-11, LOINC and ATC explains each list.

The API: one way to ask

An API (application programming interface) is the door through which one program asks another for information. FHIR defines one RESTful API for all its resources, meaning it uses the same kind of web request a browser sends to open a page. "Give me Awa's active prescriptions" is written the same way whatever the software, and the answer comes back in the same format. So a pharmacy system that can talk to one FHIR server can, in principle, talk to any of them, without a custom connection for each clinic.

SMART on FHIR: the patient holds the key

Sharing must not mean exposing. SMART App Launch, usually called SMART on FHIR, is an HL7 guide that adds sign-in and permissions on top of FHIR. It is based on OAuth 2.0, a common web standard for delegating access, and uses "scopes" to define exactly what an app may read or write. Think of a hotel key card: it opens one room for a limited time, not the whole building.

FHIR also has resources for the rules themselves. Consent records what the patient agreed to, and AuditEvent records who accessed which record and when. How this works in practice is the subject of our article on who can see your health record.

Key idea

FHIR is not an app. It is a shared grammar: standard forms (resources), a shared vocabulary (codes), one way to ask (the API) and one set of keys (SMART on FHIR).

Who already speaks FHIR

FHIR is written into regulation, built into widely used software and adopted by global health programmes.

Note that WHO's SMART Guidelines and SMART on FHIR only share a word: the first turns medical recommendations into digital rules, the second controls what apps may access.

The African Union is moving the same way. In 2023, Africa CDC published health information exchange guidelines and standards for the continent, prepared by a task force of 24 experts. Its recommendation leaves little room for doubt:

"…[the task force] recommends all new implementations and digital health system improvements use FHIR as the primary mechanism for data exchange."

— Africa CDC, African Union Health Information Exchange Guidelines and Standards (2023)

What FHIR changes for a clinic in Dakar

Senegal has digitised health in pieces. DHIS2, the open-source platform behind the national health information system, has been in use for more than ten years, from central level down to community health posts. Private clinics, pharmacies, labs and start-ups, meanwhile, each keep their own records in their own formats.

Here is what a shared standard changes, concretely:

• Written once, read where allowed. Dr Ndiaye's prescription reaches the pharmacy in Medina as structured data, not handwriting. Awa's lab result comes back into his software without being retyped.
• Changing software without losing patients. Records kept in FHIR format can move to another FHIR system. A clinic is no longer tied to one vendor's private format.
• New partners connect once. An insurer, a mutuelle (community health insurance scheme) or a lab connects to the standard, not to each clinic through a separate custom project.
• National reporting without double entry. Consultations can feed the anonymised indicators the national system expects, through a translation layer (middleware). In the DHIS2 survey, this mapping most often happens in middleware, as we explain in DHIS2 and FHIR.

For the patient, the change is simple: her history follows her, instead of staying in the clinic where it was first written.

What FHIR does not do

A standard is a foundation, not a finished house.

• It is not software. FHIR is a specification that software implements. A clinic still needs an application that is pleasant to use and works on a weak connection.
• It does not fix poor data. A wrong diagnosis, coded perfectly, is still wrong. Codes must be chosen with care, and screens should make the right code the easy one.
• It does not decide who sees what. FHIR provides the tools (Consent, SMART scopes, audit logs). The rules come from the patient's choices, the law and each organisation's governance.
• It needs national agreements. Each country still has to settle details: which patient identifier, which code lists, which profiles. India did this by publishing its own FHIR guide. Senegal will need the same kind of shared reference.

For the technical reader

Here is a minimal Patient resource for Awa in JSON (a plain-text data format), following FHIR R4:

{
  "resourceType": "Patient",
  "id": "awa-diop",
  "name": [{ "family": "Diop", "given": ["Awa"] }],
  "gender": "female",
  "birthDate": "1990-04-12",
  "telecom": [{ "system": "phone", "value": "+221 77 000 00 00", "use": "mobile" }],
  "address": [{ "city": "Dakar", "country": "SN" }],
  "communication": [{
    "language": {
      "coding": [{ "system": "urn:ietf:bcp:47", "code": "wo", "display": "Wolof" }]
    },
    "preferred": true
  }]
}

The resourceType says which form this is, and the communication element records Wolof (BCP 47 code "wo") as Awa's preferred language. Nothing in the structure is specific to Senegal: only the values are.

Every resource follows the same REST pattern. GET [base]/Patient/awa-diop returns this record, and GET [base]/MedicationRequest?patient=awa-diop returns her prescriptions. With SMART on FHIR, the app first obtains an OAuth 2.0 access token whose scopes limit what the server will return. In production, a national profile would also constrain each resource, and servers should validate against it.

How Quralys approaches this

Quralys is a FHIR-native health platform being built in Dakar, ahead of launch. Its first product is deliberately ordinary: a patient app to find a doctor, book and pay by mobile money, and a practice suite for doctors with an agenda, consultation notes, pre-filled digital ordonnances and video consultation built on Jitsi. A pilot with three to five private doctors in Dakar is planned.

The difference is underneath. Every action writes a standard FHIR R4 resource (Appointment, Encounter, MedicationRequest and others), so a pharmacy, a lab, an insurer or the national system can later read the same record, with the patient's consent. Existing Senegalese apps are invited to plug into that record through a partner API secured with SMART on FHIR, rather than compete with it. You can see how the first version fits together on the platform page.

Sources

1. HL7 International: FHIR R4 summary
2. Healthcare IT News: 5 things to know about HL7 FHIR
3. HL7 International: FHIR R4 resource index
4. HL7 International: SMART App Launch implementation guide
5. ONC (HealthIT.gov): Standardized API for patient and population services
6. Epic: Epic on FHIR
7. Apple Newsroom: Apple announces effortless solution bringing health records to iPhone (2018)
8. NRCeS: FHIR implementation guide for ABDM
9. WHO: SMART Guidelines
10. DHIS2: EMR–DHIS2 integration survey (June 2026)
11. Africa CDC: African Union Health Information Exchange Guidelines and Standards (2023)
12. HISP Rwanda: Digital health in Senegal, more than ten years of DHIS2