How Pharmacies That Serve HMO Enrollees in Nigeria Can Flag Early Refills and Duplicate Dispensing of Chronic Medication (2027)

Take an illustrative case. A customer collects a 30-day supply of a maintenance medicine, then asks for it again two weeks later. The bottle may be lost, or something else may be going on. At a busy counter, searching old sales takes time. This guide shows how a licensed pharmacy that serves customers linked to an HMO in Nigeria can flag early refills and duplicate dispensing at the till in ClinikEHR. It also shows how an approved HMO can read the flags through the ClinikEHR API (api.clinikehr.com).

Quick Answer

To flag early refills and duplicate dispensing, attach a registered customer to each chronic-medicine sale, record a days supply, and let the till's four checks warn the pharmacist.

• Use the Pharmacy edition on the Professional plan or above. The till then runs four checks: early refill, dispensed again today, prescription number repeated and unusual quantity.
• Attach a registered customer and record a days supply of 30, 60, 90 or a custom number. A walk-in cannot be checked, and the early-refill check stays silent without a days supply.
• Read the warning at the till. It never stops the sale, and the pharmacist's reason is optional.
• Open the review list under Pharmacy Station, Dispensing Checks, to see every flagged sale with its evidence and reason.
• If an HMO needs the flags, it can read them, read-only, through the ClinikEHR API for customers linked to it, once the approvals in this guide are in place.

What Fraud, Waste and Abuse Means at the Counter, in Plain Words

An HMO, short for health maintenance organisation, is a company that pays for part or all of its members' care. In this guide the HMO is the payer. It is a separate organization from the pharmacy. The pharmacy is licensed, holds its own stock and keeps its own sales records.

The problem is often called fraud, waste and abuse. Here it means medicine handed out that should not have been, or handed out twice. This guide uses the name only as a label. It gives no figure for how common the problem is, because no source for one was found.

Three terms help. A days supply is the number of days a dispensed quantity should last. A registered customer is a person with a customer record in ClinikEHR, unlike a walk-in with no name on file. A flag is a warning the till raises when a sale looks like an early refill or a repeat.

A flag is a question for the pharmacist, not a finding of wrongdoing. A lost bottle, a changed dose or a trip away are all real reasons to dispense again.

The Four Checks at the Till

When a sale to a registered customer looks wrong, the till shows an amber warning above the cart. It names the medicine and the reason, and it shows the evidence behind it. This happens before the sale is completed. The warning never stops the sale, and the person at the counter always decides.

All the examples below are illustrative. They are invented to show how a check works, and they are not data.

Early refill

The early-refill check compares today's sale with the last time this customer received the medicine. It also uses the days supply recorded then. Another brand of the same drug counts as the same medicine.

Illustrative: a customer is given a 30-day supply on 1 March, and 30 is recorded as the days supply. On 16 March, which is day 15, the same customer asks for it again. The check compares the request with the date the next supply was due. If it finds the request early, the till shows a warning. The warning says when the medicine was last supplied, how many days the supply was meant to last and when the next one was due. The pharmacist may go ahead and may record a reason, such as travelling.

Whether a given day raises a warning depends on the early-refill grace period the pharmacy uses. The owner, a manager or anyone granted the permission can adjust it, as Step 6 explains.

Dispensed again today

This check looks for the same medicine, or another brand of the same drug, already sold to the same customer earlier in the day.

Illustrative: a customer buys a maintenance tablet in the morning. In the afternoon, a different brand of the same drug is rung up for the same customer. The second sale shows a warning with its evidence, and the pharmacist decides whether it is right.

Note that "the same medicine twice in a week" is not a separate check. This check covers a single day. The early-refill check covers longer gaps.

Prescription number repeated

This check looks for the same prescription number filled on any other sale. The prescription number is optional on the till, and this is the only check that uses it.

Illustrative: the same prescription number is entered on two different sales. The second sale shows a warning with its evidence. A repeat can only be caught if the number was typed in.

Unusual quantity

This check compares a request with that exact item's own recent sales. It looks for a request well above what is usually sold of the item.

Illustrative: a customer asks for a quantity of one medicine far above the usual sale size of that medicine. The till shows the warning with its evidence. A large quantity can be correct. The check asks the question and leaves the answer to the pharmacist.

Set Up the Till So the Checks Can Run

The checks compare only what has been recorded. These steps make sure there is something to compare.

Step 1: Confirm your edition and plan

The checks run on the Pharmacy edition, on the Professional plan or above. The Pharmacy plans are Starter, Professional, Business and Enterprise, so Starter does not include them. The Pharmacy edition page and the Help Center guide to choosing a plan list the plans.

A new pharmacy can start a 7-day trial on the Professional plan, with no card. The Help Center page on refill and duplicate-dispensing checks shows which plans have them. This guide covers the Pharmacy edition.

What you need: the pharmacy's owner or manager.

How you know it worked: the owner can open Sidebar, Pharmacy Station, Dispensing Checks.

The mistake people make: judging the checks on the Starter plan and concluding they do not work.

Step 2: Attach a registered customer to the sale

A warning appears only when the sale is linked to a registered customer. A walk-in sale does not create a customer record, so there is nothing to check it against. Open the Customer tab in the cart and attach the person.

For a medicine marked as chronic or maintenance, the till helps. If no customer is on the sale, it asks once per sale whether to attach one. You can choose Attach customer or Skip. The question does not appear when a customer is already on the sale, and it never appears while the till is offline.

What you need: a customer record for the person.

How you know it worked: the customer is attached to the sale before you complete it.

The mistake people make: choosing Skip because the queue is long. The sale then has no history to check.

Step 3: Mark chronic medicines and record a days supply

Open Dispensing details in the cart toolbar. For each line you can record a days supply of 30, 60, 90 or a custom number. You can also mark a medicine as chronic or maintenance. Mark it once, and every future sale of that medicine nudges staff to record a days supply.

What you need: the number of days the dispensed quantity should last.

How you know it worked: on the customer's next request that comes too soon, the warning names the last supply and the date the next one was due.

The mistake people make: leaving the days supply blank on the first sale. The next sale then has nothing to compare, and the early-refill check stays silent.

Step 4: Enter the prescription number when there is one

In the same Dispensing details panel, type the prescription number. It is optional, and it is used only for the repeated-number check.

What you need: the number from the prescription.

How you know it worked: a second sale that uses the same number shows the repeated-number warning.

The mistake people make: assuming the repeat check works with no number entered. It has nothing to compare.

Step 5: Read the warning and decide

Anyone at the till can see a warning and act past it. Read the evidence, then decide. If you go ahead, press Add a reason. You can pick from a short list or write your own words.

The reason is optional and never needed to complete the sale. If you record one, it stays with the flag. The API reports it as one of six codes, with an optional note. The codes are lost, damaged, dose changed, travelling, prescriber instruction and other.

What you need: nothing beyond access to the till.

How you know it worked: the sale completes, and the flagged sale appears in the review list with its evidence and any reason.

The mistake people make: skipping the reason when there is one. The next person to read the flag then sees only the evidence.

Step 6: Review the flagged sales

The owner, a manager or anyone granted the permission can open Sidebar, Pharmacy Station, Dispensing Checks. The review list shows every flagged sale with its evidence and any reason. You can filter it by check and by date.

The same page shows how many sales in the period had a maintenance medicine sold with no customer identified. It is a count, not a list of who. It can show you how often that happens.

The Thresholds tab lets you turn a check off. It also lets you adjust the early-refill grace period and the unusual-quantity multiple. So "four checks" describes what the till offers, not what every pharmacy leaves switched on. Look at which ones are on.

What you need: the owner's permission to open the list.

How you know it worked: filtering by one check and a date range returns the flagged sales with their evidence.

The mistake people make: opening the list only after a complaint. Look at it on a regular schedule.

When a Check Stays Silent

A check can only compare what exists. When it has nothing to compare against, it says nothing. That silence is not the same as "clear". The table shows the usual cases.

An offline sale needs a closer look. The check needs ClinikEHR's own record of the customer's history, which an offline till cannot see. The sale still completes normally. Once it reaches ClinikEHR, the same check runs. If it finds something, the finding appears later in the review list for someone to look at. It never changes or reverses the sale.

Searching for a registered customer needs a connection. So an offline sale often has no registered customer on it, and then there is nothing to check even after it syncs. A finding appears only when a registered customer was on the sale.

What the checks do not do

• They do not guarantee that every early refill or repeat is caught. Some sales will pass without a warning.
• They compare what your pharmacy recorded. The Help Center describes no comparison with other pharmacies, other member cards or other HMOs.
• They send no reminder. There is no refill scheduler. ClinikEHR keeps a days supply per line and runs the early-refill check at the till.
• The Pharmacy edition does not bill an HMO, hold HMO price lists or check whether a customer is covered. Its till has an Insurance payment option that asks for a claim number and shows a note that insurance payments may need extra checks. How an HMO pays the pharmacy is outside this guide.

That last point matches the top 10 pharmacy software review. ClinikEHR Pharmacy is built for the pharmacy counter, not for HMO claims.

Reading History and Flags Through the ClinikEHR API

The pharmacy records the flags. The HMO is the payer. If the pharmacy chooses, an approved HMO can read the flags and the dispensing history for customers linked to it. Read-only means the HMO can look but cannot change anything. Linked means the connection between the pharmacy and the HMO reaches that customer. Every other customer stays out of reach.

An API is a set of requests that lets one program ask another for data. A key is the secret code the program sends with each request to prove who it is. The ClinikEHR API is the API of the ClinikEHR app, at api.clinikehr.com. It is not ClinikAPI (clinikapi.com), a separate product built on FHIR, a standard format for health data, with its own keys and licence. The API documentation has the full reference. This section follows the docs page on dispensing history and flags.

Two routes exist, and both are read-only.

Both need a permission called dispensing:read. A permission is a named right that a key carries. This one covers patient information. Neither route ever shows a price, another customer of the pharmacy or the name of a staff member.

An HMO does not need the pharmacy's keys. There are two separate kinds of key.

The pharmacy's own key

A pharmacy can create a key for its own systems, for example to bring its flags into its own reports. Reading patient information with it needs the API add-on (an Enterprise contract includes it) and the pharmacy owner's acceptance of the current API data agreement. The docs page on dispensing also says the pharmacy's subscription must be Enterprise for this permission. If your plan is different, ask through the contact page before you build.

An HMO has no part in this. The key reaches only the pharmacy that created it.

How an HMO reads the flags

This is the way an HMO reads flags. The HMO is an organization with its own workspace and its own key. Several things must be in place, and some are the HMO's and some are the pharmacy's.

On the HMO's side:

1. A verified developer workspace, with a domain check and a business profile.
2. The Enterprise contract plan, which ClinikEHR sets on request. There is no self-serve checkout, so the HMO uses Contact us.
3. Approval for the Dispensing history kind of patient data, decided by a ClinikEHR reviewer. Linking customers uses the Patients kind. No timeline is stated.
4. Acceptance of the current data-protection addendum. This is a written agreement on how patient information is handled, between Bettar Platforms, Inc. and the organization. It has terms under the Nigeria Data Protection Act (NDPA) for an organization established in Nigeria, or one that handles the information of people in Nigeria.

On the pharmacy's side:

1. The pharmacy is on the Enterprise plan. A pharmacy must be on it to grant patient data to a connected organization.
2. The pharmacy's owner generates a one-time connection code and hands it to the HMO directly. A connection cannot be made any other way.
3. The pharmacy approves the dispensing:read permission for that connection and records a legal basis for sharing, which is the reason the law allows the pharmacy to share the information.
4. The customer is linked to the connection.

The pharmacy stays in control. It can narrow what an HMO may read, or end the connection, at any time. Access stops with the next request. Every read is recorded in the pharmacy's access log. This describes how access works. It does not mean any HMO has been approved or connected.

An organization's key sees only linked customers. A customer who is not linked, one the pharmacy has restricted and one who does not exist all give the same not-found answer. The HMO cannot tell them apart.

What the HMO sees in a flag

Each flag carries these fields.

Treat the words in flags as plain text. Only one of them, refill_too_soon, appears in the public docs, and new words can appear over time. The keys inside evidence depend on the check. A check_state of shown_acknowledged means the pharmacist saw the warning and went on.

Try it in the sandbox first

The docs show both requests with a test key. A test key reaches only a sandbox, which is a practice area of invented data. For any customer id it returns two invented dispensed items and one invented flag. A pharmacy's own key has no test mode, so only a developer with an organization workspace can try this.

curl "https://api.clinikehr.com/v1/clinics/YOUR_CLINIC_ID/dispensing/history?patient_id=PATIENT_ID&limit=25" \
  -H "Authorization: Bearer ehr_test_EXAMPLEKEYID0000000000_EXAMPLESECRET…"

{
  "data": [
    {
      "id": "4e8c2a10-1111-4a2b-9c3d-0123456789ab",
      "medicine": {
        "name": "Example Amoxicillin 500mg",
        "generic_name": "amoxicillin",
        "brand_name": null,
        "identifiers": [{ "system": "nafdac", "value": "A4-0000-EXAMPLE" }]
      },
      "quantity": 21,
      "days_supply": 7,
      "dispensed_at": "2026-09-25T10:15:00Z"
    }
  ],
  "has_more": false,
  "next_cursor": null
}

curl "https://api.clinikehr.com/v1/clinics/YOUR_CLINIC_ID/dispensing/flags?since=2026-09-01T00:00:00Z&until=2026-10-01T00:00:00Z" \
  -H "Authorization: Bearer ehr_test_EXAMPLEKEYID0000000000_EXAMPLESECRET…"

{
  "data": [
    {
      "id": "5f9d3b21-2222-4b3c-8d4e-123456789abc",
      "patient_id": "9d2e7a10-2222-4b3c-8d4e-123456789abc",
      "medicine": {
        "name": "Example Amoxicillin 500mg",
        "generic_name": "amoxicillin",
        "brand_name": null,
        "identifiers": [{ "system": "nafdac", "value": "A4-0000-EXAMPLE" }]
      },
      "days_supply": 7,
      "date": "2026-10-02T14:00:00Z",
      "check_state": "shown_acknowledged",
      "flags": ["refill_too_soon"],
      "evidence": {
        "previous_fill_at": "2026-09-25T10:15:00Z",
        "expected_next_fill_at": "2026-10-09T10:15:00Z"
      },
      "reason": { "code": "travelling", "text": "Patient travelling, needs an early refill." }
    }
  ],
  "has_more": false,
  "next_cursor": null
}

These samples show the shape of a response. The history sample shows one item; the sandbox returns two. Every id, date and the medicine are example values. A real read needs a live key and a linked pharmacy. With an organization key it also needs a connection the pharmacy approved and a linked customer.

Developers can also use the published clients: @clinikehr/api for TypeScript (0.1.3 is current) and clinikehr for Python (0.1.1). The guides are at TypeScript and Python.

Reading the pages

Both routes return a page at a time. Use limit (1 to 100, default 25). Pass each next_cursor back as starting_after until has_more is false. The history comes back ordered by id, not by date, so read every page and then sort by dispensed_at. Flags are also ordered by id, so sort them by date.

What you need: the requirements above, and a customer linked to the connection.

How you know it worked:

• A request for a linked customer answers with a list, has_more and next_cursor.
• A request that lacks a requirement answers 403 with a code that names what is missing.
• On the history route with an organization key, a customer who is not linked answers 404, the same as one who does not exist. The flags route has no customer id, so it leaves unlinked customers out.

The mistake people make: reading only the first page. A flag on page two never reaches the reviewer.

Mistakes That Cost Pharmacies Money

• Reading an empty flag list as a clean record. The API returns a flag only when a check found something. A walk-in, or a sale where no check ran, is never returned.
• Treating a null days supply as zero. In the history and the flags, null means the pharmacy did not record it. Read it as unknown.
• Reading one pharmacy's history as the whole picture. The history is what this pharmacy dispensed to the customer, one line for each item sold.
• Giving the review-list permission to everyone, or to no one. The owner grants it. Decide who reviews flags and give the permission to them.
• Putting an API key in a web page or a mobile app. Keep it on your own server and call the API from there.

Frequently Asked Questions

How can a pharmacy flag early refills of chronic medication in Nigeria?

Use the Pharmacy edition on the Professional plan or above. Attach a registered customer to the sale and record a days supply of 30, 60, 90 or a custom number. The till then compares the sale with that customer's earlier supplies. It shows a warning with the evidence when the sale looks too soon. The pharmacist decides whether to go ahead.

Do the checks stop a sale?

No. The till shows a warning with its evidence and never stops the sale. The person at the counter always decides, and recording a reason is optional. The checks flag a sale so someone can ask a question. They do not guarantee that every early refill or repeat is caught.

Which plan has the checks, and can I try them first?

On the Pharmacy edition the checks need the Professional plan or above, so Starter does not include them. A new pharmacy can start a 7-day trial on the Professional plan with no card. The trial runs on a plan that has the checks.

Why did a sale I expected to be flagged show no warning?

The checks compare only what was recorded. There is no warning for a walk-in sale with no registered customer. The early-refill check stays silent when no days supply was recorded. A sale taken offline is not checked at the counter. No warning is not the same as clear.

Does the pharmacist have to give a reason?

No. Adding a reason is optional and is never needed to complete the sale. The pharmacist can pick from a short list or write their own words. A recorded reason stays with the flag in the review list. An HMO that is approved to read flags sees it too.

Can an HMO read the flags and the dispensing history?

Yes, once it has been approved and linked. It reads them, read-only, through the ClinikEHR API, for customers linked to it. It needs a verified developer workspace, approval for the Dispensing history kind of patient data, the data-protection addendum and a connection the pharmacy approved. The pharmacy must be on the Enterprise plan.

What does an HMO not see through the API?

It never sees a price or margin, another customer of the pharmacy or the name of a staff member. It does not see a walk-in, or a sale to a person the pharmacy could not identify. A flag appears only when a check found something. The pharmacy can narrow the connection or end it at any time.

Does the Pharmacy edition bill an HMO or check a customer's cover?

No. The Pharmacy edition has no insurance module. It does not bill an HMO, hold HMO price lists or check cover. Its till has an Insurance payment option that asks for a claim number. The checks in this guide are about dispensing, not payment.

Conclusion

The checks work because the till has something to compare. Attach the customer, record the days supply, enter the prescription number when there is one, and then read the warnings and the review list. A warning is a question for the pharmacist. It is never a verdict.

The 7-day trial on the Professional plan lets you see the warnings on your own counter first. If an HMO needs the flags, the reading is read-only, covers linked customers only and stays under the pharmacy's control. HMO teams that want to connect can contact ClinikEHR.

Related Articles

• Running a Pharmacy That Serves HMO Enrollees in Nigeria: The Complete 2027 Guide to Chronic-Medication Refills
• How to Connect an HMO Portal to a Licensed Pharmacy in Nigeria: Stock Availability and Drug Request API (Developer Guide, 2027)
• Getting Paid by HMOs in Nigeria: The Complete 2027 Guide for Hospital Owners and Billers
• Top 10 Pharmacy Management Software in Nigeria 2027 (Updated Review)
• Offline-First Pharmacy POS: Why It Matters When Your Internet Drops
• Refill and duplicate-dispensing checks (Help Center)
• Dispensing history and flags (API docs)
• ClinikEHR API documentation
• ClinikEHR pricing

Facts are as of the dates shown. Check the linked sources for updates. This is general information, not legal or professional advice.