Specialty Pharmacy Status Codes: How to Map SP and Hub Statuses Into One Patient Status Model

Why the same patient has four different statuses

A specialty brand with a hub and a limited network of specialty pharmacies receives patient status from every one of them. Each partner sends its own codes, at its own level of detail, on its own schedule. One pharmacy reports a case as pending, another as on hold with a reason code, a third sends a numeric status that only makes sense next to its data dictionary. The hub has its own case statuses on top.

Somebody has to turn all of that into one picture of where patients stand. In many teams that happens in a spreadsheet lookup maintained by one analyst, updated when a partner changes a code and somebody notices. The result is a patient status report where the categories drift quarter to quarter, the pending bar keeps growing, and two dashboards built on the same feeds disagree.

The fix is not a better report. It is a patient status model: one agreed set of stages and reasons that every source status maps into, owned and versioned like any other piece of master data. This article sets out what that model looks like and how to build it. It builds on our guides to specialty pharmacy data and a unified patient view across SP, hub and claims.

What a patient status model contains

• Stages

  A short, ordered list of where a patient can be: referral received, benefits verification, prior authorisation, financial assistance, ready to fill, on therapy, discontinued, cancelled. Every source status lands in exactly one stage.

  • Six to ten stages is usually enough
  • Ordered, so progress can be measured
  • The same list for hub and every SP

• Reasons

  Why a patient is sitting in a stage: waiting on payer, waiting on prescriber, waiting on patient, waiting on pharmacy. Reasons are what turn a pending bucket into a list of owners.

  • Kept separate from the stage
  • Each reason has a named owner
  • Unknown is allowed, but reported

• Dates

  The date a patient entered each stage, taken from the source event rather than the file date. Without stage entry dates there is no time to therapy by stage and no way to see where patients stall.

  • Event date, not load date
  • Kept for every stage, not only the latest
  • Needed for cohort reporting

• The mapping table

  Every source, every source code, the stage and reason it maps to, and the date the mapping took effect. This is the asset that makes the reports agree, so it is owned, reviewed and versioned.

  • One row per source code
  • Effective dated when a partner changes codes
  • Unmapped codes raise an alert

Where status mapping usually goes wrong

Stage and reason in one field. When a source status like on hold, PA submitted is mapped into a single label, the report can show either the stage or the reason, never both. Keep them as two fields from the start.

Silent new codes. Specialty pharmacies add or change status codes as their own systems change. If the mapping simply drops unknown codes, patients disappear from the report. If it parks them in other, the pending bar grows and nobody knows why. An unmapped code should stop the line and alert an owner.

Latest status only. Many feeds are loaded as a current snapshot. That answers where patients are today, but not how long they waited at each step. Keeping the history of status changes is what makes time to therapy by stage possible.

Statuses counted before patients are linked. A patient transferred from one pharmacy to another shows as cancelled at the first and new at the second. Link the patient across sources first, then apply the model, as covered in our article on abandonment versus reversal.

How to build the model

Questions leaders ask about patient status data