Patient consent and health records in Senegal: your rights under law 2008-12, and how FHIR Consent, SMART on FHIR and audit logs control who sees your data.
In short
- Under Senegal's law 2008-12, health data is sensitive, and patients have rights to information, access, objection, rectification and complaint to the CDP.
- In FHIR, a Consent resource records who may see what, but enforcement comes from access control such as SMART on FHIR scopes.
- AuditEvent records make every access traceable, including emergency break-the-glass access.
Awa, 34, sees Dr Moussa Ndiaye, a cardiologist in Plateau, about palpitations. He records her blood pressure, orders an ECG (a recording of the heart's electrical activity) and writes a prescription (ordonnance). That evening she fills it at a pharmacy in Medina, and a week later her mutuelle (mutual health fund) asks for proof of the consultation.
Each of them needs a piece of Awa's record, and none of them needs all of it. On paper, the folder in the doctor's cabinet did the filtering. In a connected system, the rules have to be written into the system itself. This article explains Awa's rights under Senegalese law, how the FHIR standard records consent, how an app gets only the access it was granted, and how every access is traced. It is general information, not legal advice.
Why consent changes when records connect
A paper file has a natural barrier: to read it, you must be in the room. A shared digital record has many doors. Without rules, any connected app could read everything, and nobody would know.
Two kinds of consent are often mixed up. Consent to care is Awa agreeing to an examination or a treatment. Consent to share is Awa deciding who else may see her data, for what purpose and for how long. This article is about the second.
What law 2008-12 says
In Senegal, law no. 2008-12 on the protection of personal data defines consent as "any express, unequivocal, free, specific and informed expression of will" (article 4, our translation). Health data is sensitive data. Processing it is prohibited in principle (article 40), unless an exception applies, for example when the person has given written consent, whatever the medium (article 41).
Article 43 adds that processing for health purposes is legitimate only in listed cases. The patient's consent comes first. Others include protecting the patient's vital interests, public health, and preventive medicine, diagnosis and care carried out under the supervision of a health professional bound by professional secrecy.
So consent is not the only legal basis for care itself. Sharing with others, such as a partner app or an insurer, raises separate questions that each organisation must answer for its own processing. Article 44 also states that health data is collected from the person concerned.
As of October 2026, law 2008-12 is still the reference text, and its reform has been awaited for several years. Our article on health data sovereignty covers the legal context in more detail.
Your rights as a patient
The law gives every person a set of rights over their data. In practice, for a patient:
| Right | What it means | Article |
|---|---|---|
| Information | When data is collected, be told the purposes, recipients, retention period and any transfer abroad | 58 |
| Access | Ask in writing whether your data is processed, and get a copy | 62, 63 |
| Access to medical data | Exercised by the patient, or through a doctor the patient designates | 65 |
| Objection | Object, for legitimate reasons, to your data being processed | 68 |
| Rectification and deletion | Have inaccurate, incomplete or out-of-date data corrected, completed, updated or deleted; after a written request, the organisation responsible must show within one month, free of charge, that it has done so | 69 |
| Complaint | Complain to the CDP, the national data protection authority | 16 |
The CDP uses these powers: in the second quarter of 2026, it received 8 complaints and carried out 5 inspections. Processing is also confidential (article 70), and the organisation responsible must protect data against access by unauthorised third parties (article 71).
How FHIR writes consent down
FHIR is the international standard for exchanging health data, published by HL7 (see FHIR, simply). It describes each piece of information as a "resource". One of them, Consent, is a record of a healthcare consumer's choices, which permits or denies identified recipients to perform actions, for specific purposes and periods of time.
The resource is designed for four uses: privacy (who may collect, access, use or share information), medical treatment, research and advance care directives. In FHIR R4, only the privacy use is actually modelled, and the resource is still marked "trial use".
For Awa, a privacy consent could contain three rules (called provisions), each of type "permit" or "deny":
- permit: Dr Ndiaye may read and update her record;
- permit: the pharmacy in Medina may read her prescriptions (the MedicationRequest resource) for 30 days;
- deny: a wellness app may not see her test results (the Observation resource).
One point is often misunderstood: a Consent resource does not enforce itself. The FHIR specification states that enforcement is outside its scope and is done by access control systems, such as OAuth. That is where SMART on FHIR comes in.
SMART on FHIR: each app sees only what it was granted
SMART App Launch is the HL7 standard that lets an app connect to a FHIR server, based on OAuth 2.0 (the authorisation protocol used by many websites). The app asks for "scopes", short codes that describe exactly what it wants. For example, patient/Observation.rs means "read and search the observations of one patient".
Scopes start with patient/ (one patient's data), user/ (the data the signed-in user is allowed to see) or system/ (a server acting without a user). In a patient-facing app, the authorisation server asks the patient to approve, and it may grant fewer scopes than the app requested.
So if a booking app connected to the same record asks for patient/Appointment.rs, it sees Awa's appointments, and nothing else: not her ECG, not her prescriptions.
Audit logs: every access leaves a trace
Rules are only credible if you can check them. FHIR's AuditEvent resource is "a record of an event made for purposes of maintaining a security log", used to detect intrusion attempts and inappropriate use. It records who acted, from which system, on which data, when, and with what result. From these records, a system can produce a patient-centred account of who accessed a file.
Some countries already show this to patients. In Estonia, patients can track who views their records and set access restrictions through the patient portal.
What about emergencies? If Awa arrives unconscious at an emergency unit, nobody can ask her. FHIR's security labels describe "break-the-glass" access: emergency access for treatment, typically when the patient cannot give consent. The specification requires that the procedure be well understood, properly controlled, and that any use be well represented in an AuditEvent.
Key idea Consent says who may see what. SMART on FHIR makes apps respect it. AuditEvent shows, afterwards, who actually looked.
For the technical reader
In a typical design, the three pieces form a chain. The Consent resource stores the patient's decision. The authorisation server checks it when an app requests access and issues a token limited to the granted scopes. The FHIR server validates that token on every request and writes an AuditEvent, including for break-the-glass access, which carries a purpose-of-use code (BTG). Keeping these steps separate makes each one testable, and lets a partner app plug in without ever seeing more than its scopes allow.
How Quralys approaches this
Quralys starts from a simple principle: nothing is shared by default. The patient's choices are to be stored as FHIR Consent resources, partner apps will connect through a SMART on FHIR API that requires the patient's consent, and every access is to be recorded.
The aim is that a patient's record is read only by those she has allowed, and that every reading can be traced. How the patient app and the doctor suite fit together is described on our platform page, and how other Senegalese apps can plug into the same record in interoperability, not competition.
Sources
- Vie-publique.sn: Law no. 2008-12 on the protection of personal data (full text, PDF)
- Osiris: the CDP on video surveillance and biometric data (June 2026)
- Dakaractu: CDP activity report for the second quarter of 2026
- HL7 FHIR R4: Consent resource
- HL7: SMART App Launch 2.2.0, scopes and launch context
- HL7 FHIR R4: AuditEvent resource
- HL7 FHIR R4: security labels and break-the-glass
- e-Estonia: e-health
Written by the Quralys team
Quralys is building a FHIR-native health ecosystem in Senegal: one record that clinics, pharmacies, labs, insurers and the national system can read, with the patient’s consent.
See it in practice
Private doctors in Dakar can join the pilot: online booking, prepaid consultations, digital ordonnances and video, free during the pilot.
