Home/Offers/Healthcare & Life Sciences/Pharmaceutical Supply Risk API

Healthcare & Life Sciences

Pharmaceutical Supply Risk API

You usually learn a product is short when an order comes back unfilled. By then the therapeutic alternatives are being bought by everyone else as well.

  • Hospital pharmacy systems
  • Group purchasing organisations
  • Distributors
  • Health system supply chain teams

What your customers would see

example interface
Mockup of the Supply Risk interfacesupply.yourhealthsystem.org/formularyPlatformOverviewExploreAlertsAPI keysUsageSettingsSupply RiskAccountExample injectable 50 mg/5 mL78risk scoreHighContributing signalsweightedSingle ingredient source31%Fill rate decline27%Inspection finding22%Lead time extension12%Distributor substitution8%Formulary products at elevated risklivePRODUCTRISKCOVERALT RISKSTATUSExample injectable 50 mg7823d34act nowExample solution 2%6441d29monitorExample tablet 10 mg5288d18monitorExample consumable set4764d—no alternative

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Medicine shortages are structural rather than exceptional. A large share of generic injectables depends on a very small number of manufacturing sites, often a single active ingredient supplier, and the economics of low-margin generics mean there is no redundancy to fall back on. A quality inspection finding at one plant removes a meaningful share of global supply for a product, and the effect propagates through distributors over weeks.

Hospital pharmacy knows this and manages it with experience and phone calls. The information that would support it is scattered: regulatory inspection outcomes, official shortage notifications, manufacturer discontinuation notices, import alerts, customs and shipping data, and the hospital's own fill-rate history with its distributors. Each is accessible. Nobody is joining them.

The most valuable signal is also the most under-used, and it is internal. Declining fill rates on a product, lengthening lead times, and a distributor quietly substituting a different manufacturer all appear in purchase order history before any official notification exists. A shortage is usually visible in your own order data weeks before it is announced.

Who buys this

Hospital pharmacy systems, Group purchasing organisations, Distributors, Health system supply chain teams

What the API returns

What comes back

  • Shortage risk score per product with the contributing signals listed
  • Supplier and manufacturing site concentration for each product and ingredient
  • Active shortage and discontinuation notifications matched to your formulary
  • Fill rate and lead time trends from your own purchase order history
  • Substitution detection where a distributor has changed the manufacturer supplied
  • Therapeutic alternatives with their own independent supply risk, so a substitution plan is not built on a product sharing the same single source
  • Days-of-cover projections against current inventory and forecast usage
  • Disruption events: inspection findings, import alerts, plant closures, logistics interruptions

Endpoints

MethodPathReturns
GET/v1/products/{id}/riskShortage risk score with contributing signals
POST/v1/formulary/assessRisk assessment across a formulary
GET/v1/products/{id}/concentrationSupplier and site concentration
GET/v1/products/{id}/alternativesTherapeutic alternatives with independent risk
GET/v1/eventsSupply disruption events affecting your products
POST/v1/coverage/projectDays of cover against inventory and forecast usage

Request and response

illustrative

Request

{
  "formulary_id": "frm_main_2026",
  "include": ["risk", "concentration", "alternatives"],
  "critical_only": false,
  "usage_window_days": 180
}

Response

{
  "assessed_at": "2026-10-22T08:30:00Z",
  "products_assessed": 2184,
  "elevated_risk": 61,
  "products": [
    {
      "product_id": "prd_vial_0912",
      "name": "Example injectable 50 mg/5 mL",
      "risk_score": 78,
      "band": "high",
      "signals": [
        { "signal": "single_api_source", "weight": 0.31,
          "detail": "One identified active ingredient supplier" },
        { "signal": "fill_rate_decline", "weight": 0.27,
          "detail": "Fill rate 0.81 over 30 days, down from 0.97" },
        { "signal": "inspection_finding", "weight": 0.22,
          "detail": "Finding published at a registered manufacturing site" },
        { "signal": "lead_time_extension", "weight": 0.12,
          "detail": "Median lead time 14 to 27 days" }
      ],
      "days_of_cover": 23,
      "alternatives": [
        { "product_id": "prd_vial_1140", "shares_api_source": false, "risk_score": 34 },
        { "product_id": "prd_vial_0877", "shares_api_source": true, "risk_score": 71,
          "warning": "Same active ingredient supplier as the at-risk product" }
      ]
    }
  ]
}

Where the data comes from

Official shortage and discontinuation registersPublished notifications from the relevant medicines regulators, which are authoritative but typically late
Regulatory inspection and compliance recordsPublished inspection outcomes and import alerts, which frequently precede a shortage by weeks
Marketing authorisation and site registration dataWhich manufacturing sites are authorised for a product, and therefore where concentration actually sits
Your purchase order and fill-rate historyThe earliest and most specific signal available, and it is already in your procurement system
Your inventory and usage dataNeeded to turn a risk score into days of cover, which is the number that drives a decision
Trade and shipping dataLicensed import records where available; useful for ingredient flow but incomplete and expensive, and we would scope whether it earns its cost
On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

  • Signal fusion with weights fitted against historical shortages rather than assigned by hand, so the score reflects what actually preceded past events
  • Ingredient-level concentration mapping, because two products from different manufacturers frequently share one active ingredient supplier
  • Fill-rate change detection on your own orders using change-point methods, which catches degradation earlier than a threshold rule
  • Substitution detection by tracking manufacturer identifiers across deliveries of the same product code
  • Alternatives assessed for shared upstream dependency, since a substitution plan pointing at the same source is worse than no plan
  • Days-of-cover projection from forecast usage with intervals, not a flat division of stock by average consumption
  • Validation against historical shortage episodes measuring lead time of warning, with false positive rate reported at each threshold
  • Monitoring for register format changes and for products whose authorisation details change, which silently breaks concentration mapping

What it changes for the business

Warning before the unfilled order

Internal fill-rate and lead-time signals typically move before an official notification exists.

Substitution plans that hold

Alternatives screened for shared upstream suppliers avoid plans that fail for the same reason as the original.

Concentration made visible

Ingredient-level mapping shows where a formulary depends on a single site, which is not visible from the product list.

Buying decisions with cover attached

Days-of-cover projections put a time figure against each risk rather than a colour.

How it fits into your product

How it embeds

  • Deployed inside your environment or hosted, depending on whether procurement data can leave
  • Scheduled formulary-wide assessment with on-demand product lookups
  • Event webhooks into your procurement and pharmacy systems for disruption notifications
  • Integration with purchase order and inventory feeds you already produce, rather than a separate data entry burden
  • Risk thresholds and critical-product designations configured by your pharmacy team
  • Multi-site aggregation for group purchasing organisations, with per-member visibility controls

Included in every build

  • Authentication, scoped API keys and per-customer rate limiting
  • Input validation with predictable, documented error responses
  • Versioned endpoints so your integration never breaks without notice
  • Request and response logging for audit and dispute resolution
  • Latency, error-rate and usage monitoring with alerting
  • OpenAPI specification, sandbox environment and client examples
  • Backups, failover design and a documented recovery procedure
  • An agreed support arrangement once the service is live

How we would build it

about 12 weeks
1

Discovery and data review

Weeks 1–2

We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.

2

Architecture and prototype

Weeks 3–4

You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.

3

Production build

Weeks 5–10

Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.

4

Integration and handover

Weeks 11–12

We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Can you predict a shortage?

We score risk; we do not predict shortages with dates. The signals this uses have genuinely preceded past shortages, and they also fire on episodes that resolve without any disruption. Validation measures how much warning the score gave on historical events and what the false positive rate was at each threshold, and we report both. A buyer who treats a high score as a certainty will over-order.

How much does the internal data matter?

A great deal. Public registers and inspection records are useful but late and generic. Your own fill rates, lead times and substitution patterns are early and specific to your distributors. A deployment without the internal feeds is noticeably weaker, and we would be clear about that rather than building the thin version quietly.

Is trade and shipping data worth licensing?

Sometimes, and it is expensive. Import records can illuminate ingredient flows, but coverage is uneven, attribution to a specific product is often ambiguous, and the licences restrict redistribution. We would test during the prototype whether it adds measurable lead time over the free and internal signals before recommending the spend.

Does this make clinical substitution decisions?

No. It reports therapeutic alternatives drawn from your own formulary relationships and assesses their supply risk. Whether a given alternative is appropriate for a given patient or protocol is a pharmacy and clinical decision, and the API carries no therapeutic equivalence judgement of its own.

What about products where supplier information is not public?

Some supply chains are genuinely opaque, particularly upstream of the finished manufacturer. Where concentration cannot be established the API says the dependency is unknown rather than inferring one. An unknown is a real finding here — it usually means the risk cannot be managed by substitution planning alone.

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.