What patient data you can share with a partner

This is an operating guide, not legal advice. It helps a commercial team design the smallest workable data flow and know when to escalate to its privacy or legal adviser — it does not substitute for that adviser. Verify every point below against current guidance: the underlying rules have moved twice in three years, and will move again.

When to use this

Use this when a commercial or partnerships team is designing what data moves between a healthcare business and a channel partner — a pharmacy chain, a distributor, an insurer, a field agent network — and needs a defensible answer to "what does this partner actually need to see." It is for the design conversation before a data-sharing arrangement goes live, not for an active breach or a regulator inquiry, both of which need a lawyer in the room immediately rather than a guide.

Commercial teams need enough information to route demand, fulfil a service, reconcile a payment, and improve a channel. They do not automatically need a patient's full clinical story to do any of that, and the instinct to attach it "just in case" is exactly the habit this guide exists to interrupt.

The current regulatory picture, as of August 2026

Nigeria's data protection regime sits on the Nigeria Data Protection Act, 2023 (NDPA), signed into law on 12 June 2023. The NDPC states the Act applies to an organisation domiciled, resident, or operating in Nigeria; to processing in Nigeria; and to a non-Nigerian organisation processing the data of someone in Nigeria — see the NDPC FAQ. A healthcare business operating only inside Nigeria, with only Nigerian patients, is squarely inside that scope.

One correction worth making explicitly, since older material still circulates it: the Nigeria Data Protection Regulation (NDPR) 2019 is not the current operative regulation. The NDPA superseded it as Nigeria's primary data protection law, and since the Commission's General Application and Implementation Directive (GAID) — NDPC/NDP ACT-GAID/01/2025 — entered into force on 19 September 2025, the GAID is now the authoritative implementing framework, not the 2019 NDPR. If a contract or an old internal document still cites "the NDPR," that's a sign it needs updating. Both are on the NDPC resources page.

Under the NDPA, "sensitive personal data" explicitly includes health status, alongside genetic and biometric data, ethnic origin, religious belief, sex life, political opinion, and trade union membership — processing it needs a stronger lawful basis than ordinary personal data, generally explicit consent. That is the category almost everything in a patient's clinical record falls into, and exactly why it shouldn't travel through a commercial reporting pipeline by default.

Two further points before designing any partner-facing flow. Cross-border transfer of personal data out of Nigeria is restricted by default — it generally needs the destination country to hold an NDPC adequacy designation, an approved mechanism such as standard contractual clauses, or a narrow exception like explicit consent. A partner's vendor sitting outside Nigeria is a question for counsel before data flows. And the Act sets a 72-hour window for a controller to notify the NDPC of a breach likely to risk data subjects' rights, under Section 40 — tight enough that "let's confirm what happened first" is not viable. Confirm current specifics with your adviser; obligations for a "controller of major importance" differ from those for a smaller processor.

The boundary in plain language

Five checks before a data request goes out

1. Purpose: what decision or service does this field enable? Write it in one sentence — if you can't, don't request it yet.
2. Role: who is the data controller here, and who is the processor? Confirm with the privacy lead or counsel, don't assume.
3. Minimum: can an ID, count, band, or status replace a name, phone number, or clinical field, without breaking the purpose?
4. Access: who can view, export, correct, delete, or approve this data — and how is access removed when someone leaves the role?
5. Evidence: where are the notice, lawful basis, permissions, retention rule, and incident route actually written down?

Request design template

Complete this before approving any new field going to a partner or a commercial dashboard.

Safe commercial reporting patterns

Escalate immediately when

• A partner asks for a full patient list "for follow-up" with no documented purpose or approved workflow.
• A spreadsheet combines names, phone numbers, diagnoses, and payment status for convenience.
• Data is sent outside Nigeria, or to a new vendor, without a transfer and security review.
• A lost device, misdirected email, or unauthorised download may have disclosed personal data — the 72-hour NDPC clock starts from awareness, not confirmation, so move it up the chain immediately.
• A team cannot explain how a person would know why their data was collected or how to raise a request about it.

How to read the result, and where this guide breaks

This guide draws a boundary; it doesn't draw the line for you in every case, and treating it as a checklist that removes the need for a privacy review is the most common way it gets misused. A field that looks like ordinary partner-operations data in one workflow — a delivery status, say — can become linked personal data the moment it sits in the same row as a name and a diagnosis. The boundary is about the flow as designed, not any one column read alone.

The second failure mode is treating "minimum data" as a one-time decision rather than something to revisit as a partnership grows. A pilot sharing aggregated counts can drift, six months later, into a spreadsheet with patient names once someone well-meaning adds "just for context." The request design template exists to make each new field a deliberate decision again, not an accretion nobody signed off on.

Worked walkthrough

A generic scenario: a diagnostics company wants its twelve pharmacy partners in Ikeja to report weekly on sample-collection activity, and a partner asks, reasonably from its own point of view, for "the full list of patients who tested this week so we can follow up on any that didn't collect results."

Run the five checks. The stated purpose (following up on uncollected results) is legitimate, but the minimum check asks whether an ID and a status can do the same job without a name attached. It can: a shared sheet with order ID, collection status, and days-outstanding lets the pharmacy flag the case back to the lab's own care-coordination team, which already holds the patient's contact detail and consent for that purpose. The role check clarifies that the lab, not the pharmacy, is the controller for the test result, so the follow-up call should come from the lab's system, unless a documented workflow says otherwise. The request design template turns "send us the patient list" into a defined field set — order ID, status, days-outstanding, nothing clinical — with a named reviewer and a retention limit: the safer design, and the one the pharmacy can act on without new training or new risk.

This guide is not the last word on a genuinely uncertain question — bring the proposed journey and fields to your privacy or legal adviser before launch, or contact Dr Tolu Ajidahun for help mapping the workflow first.