API for the Exchange of Medicinal Product Information (APIX), published by HL7 International / Biomedical Research and Regulation. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/APIX---API-Exchange-for-Medicinal-Products/ and changes regularly. See the Directory of published versions
| Page standards status: Informative |
APIX replaces today's fragmented, procedure-specific exchange mechanisms with a single, unified API doorway for everything.
One FHIR interface covers every regulated product type and every regulatory procedure โ eliminating per-procedure portal maintenance.
FedEx-style visibility across the entire portfolio. Every milestone is a timestamped event delivered via real-time subscriptions.
Machine-to-machine exchange enables automated validation, instant Q&A routing, and zero-delay decision delivery.
Once a regulator or company implements APIX, they gain the ability to receive, process, and exchange every regulatory interaction โ across all product types (drugs, biologics, devices, veterinary) and all procedures โ through the same single API interface.
Exchanging all regulatory activities for all products through a common standard.
Fragmented channels and proprietary systems for different product types increase complexity and costs.
A single, common way to exchange any regulatory activity for any product based on open web standards.
One platform, one interface, one standard for every regulated interaction across the entire lifecycle.
Eliminating the manual burden of high-volume variations.
Thousands of minor changes (Type IA/IB) consume vast resources in manual data entry and portal uploads.
Machine-to-machine exchange. RIM systems auto-compile and submit; regulators auto-validate and accept.
โ80% reduction in submission preparation time. Zero increase in admin staff for massive volume growth.
Ending the "Black Box" of communication delays.
Information Requests arrive via email or static letters. Delays are invisible until deadlines are missed.
Questions arrive as actionable FHIR Tasks directly into workflow systems. Responses route back instantly via API.
โ30% reduction in total "Clock Stop" duration. Full transparency for both sides.
Complete visibility across the portfolio.
Companies lack real-time visibility into where their submission sits in the agency's queue.
Unified status API. Every milestone triggers a real-time update visible in the company's dashboard.
โ95% reduction in "where is my submission?" admin inquiries. Predictable product launches.
Because every regulatory milestone in APIX is a timestamped, machine-readable event (see Real-Time Subscriptions), the raw exchange data can be transformed into decision-ready visuals with no manual data entry. The worked examples below are all reconstructed from the same underlying Task history.
This is the "FedEx tracking view" of one procedure at full fidelity. The timeline below is derived entirely from the timestamped Task versions of the shelf-life update test scenario (procedure NDA-214365-S-021): a terminally rejected first submission, filing review and user-fee clearance, two Information-Request clock stops (RTQ XML), and the closing approval. Hover over any bar or milestone to see the underlying Task ids and status transitions.
The same feed rolls up across the whole portfolio, giving an applicant a live pipeline view of every procedure at every agency:
Task.status / Task.businessStatus across every connected regulator · hover a segment for detailRegulators get the mirror image of the applicant's tracking view — for free. Because every procedure is an APIX Task with a full, timestamped status history, an agency can generate performance dashboards directly from its own exchange data: a real-time board of current activity, and aggregated quarterly or annual performance reports.
A real-time view of everything currently in the house — like an airport departure board. Each status change anywhere in the agency updates the board instantly via the same subscription framework offered to applicants.
| PROCEDURE | PRODUCT | TYPE | CURRENT PHASE | DAY | STATUS |
|---|---|---|---|---|---|
| SUB-2027-1204 | Dermacort 1% cream | Type IA Variation | Submission received | 0 | ● RECEIVED |
| VAR-IB-2027-118 | Cardizal 5 mg | Type IB Variation | Technical validation | 2 | ● VALIDATION |
| MAA-2027-0057 | Virestat 200 mg | Initial MAA | Filing review | 12 | ● IN REVIEW |
| MAA-2027-0042 | Oncomab 50 mg | Initial MAA | CMC assessment | 142 | ● IN REVIEW |
| NDA-214365-S-021 | Stelbatolol 10 mg | Supplement (shelf-life) | Awaiting applicant response (IR 001) | 133 | ❚❚ CLOCK STOP |
| REN-2027-031 | Neurofen XR 75 mg | Renewal | Decision preparation | 55 | ◆ DECISION DUE |
| VAR-II-2026-889 | Oncomab 50 mg | Type II Variation | Closed | 201 | ✓ APPROVED |
Every row is a parent APIX Task; the CURRENT PHASE column is Task.businessStatus and the STATUS column is Task.status. A task-update subscription notification flips the row the moment an assessor changes the Task — no polling, no data entry. Note the shelf-life test scenario (NDA-214365-S-021) sitting in its first clock stop, exactly as shown on the timeline in Scenario Example 1.
The same event history, aggregated over a reporting period, produces the statutory performance metrics that agencies publish today through manual compilation — outcome counts, average review times by procedure type, and bottleneck analysis. With APIX these are a query, not a project.
Median time to approval — the headline figure of a regulator’s annual performance report (e.g., a PDUFA-style report to Congress or an EMA annual report), computed directly from Task timestamps instead of manual compilation:
Task.authoredOn → Task.lastModified (approved)First-cycle approval rate — the quality-of-review metric regulators publish each year, derived from the Task status history (was the application approved without a resubmission cycle?):
Bottleneck detection — where does the time actually go?