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 |
A business-friendly walkthrough of how APIX orchestrates the regulatory lifecycle — from initial submission to final decision.
APIX uses a Task-based workflow model. Every regulatory interaction — submissions, questions, decisions, payments — is represented as a FHIR Task resource. The lifecycle of a regulatory procedure is a series of Tasks, each with a status that progresses from draft → requested → received → accepted → in-progress → completed. Both parties subscribe to real-time notifications so they instantly know when something changes.
The following diagram shows the complete lifecycle of a regulatory procedure through APIX.
sequenceDiagram
participant C as Company
participant R as Regulator
Note over C,R: Phase 1: Submission & Validation
C->>R: Register & Authenticate
C->>R: Upload Documents (Binary / Bundles)
C->>R: Create DocumentReferences
C->>R: POST Task (Submission)
R->>R: Validate Package
alt Validation Passes
R-->>C: Task.status → accepted
else Validation Fails
R->>C: Request Missing Documents
C->>R: Submit Missing Documents
end
Note over C,R: Phase 2: Review Cycles
par Technical Review
R->>R: Assess Submission
and Financial Review
R->>C: Payment Task
C-->>R: Proof of Payment
end
loop Q&A (if needed)
R->>C: Question Task
C-->>R: Response in Task.output
end
Note over C,R: Phase 3: Decision
alt Approved
R-->>C: Task.status → completed + Decision Letter
else Rejected
R-->>C: Task.status → rejected + Rejection Reasons
end
Every interaction (submission, question, decision) is a Task. Tasks carry metadata (who, what, when) and reference documents via Task.input and Task.output.
Each uploaded file gets a metadata wrapper (title, type, CTD section). The regulator discovers files through the Task, downloading the payload only when needed.
Both parties subscribe to events (status changes, new Tasks). Notifications arrive instantly at configured endpoints — no polling required.
All Tasks within a single regulatory procedure share the same groupIdentifier, enabling portfolio-wide search and reporting.