API for the Exchange of Medicinal Product Information (APIX)
0.1.0 - ci-build International flag

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

Workflow Overview

Page standards status: Informative

Workflow Overview

A business-friendly walkthrough of how APIX orchestrates the regulatory lifecycle — from initial submission to final decision.


How APIX Works — The Big Picture

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.

⚠️ Key Principle: The Regulator does not directly "send" messages to the Company. Instead, the Regulator updates the Task on the server. The Company, having subscribed to that Task, receives an automatic notification whenever a change occurs.

The Three Phases

Phase 1
Submission & Validation
  1. Company registers and authenticates
  2. Company uploads documents (PDFs, FHIR Bundles)
  3. Company creates DocumentReferences (metadata)
  4. Company posts the Task (the "orchestrator")
  5. Regulator validates the package
Phase 2
Review Cycles
  1. Parallel technical & financial reviews
  2. Regulator issues Questions (as new Tasks)
  3. Company provides Responses (in Task.output)
  4. Fee payment via proof-of-payment flow
  5. Iterative Q&A until all issues resolved
Phase 3
Final Decision
  1. Regulator completes the original Task
  2. Decision letter attached to Task.output
  3. Company receives instant notification
  4. Full audit trail preserved in Provenance

Workflow Diagram

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

Key Concepts

📋 Task = Regulatory Envelope

Every interaction (submission, question, decision) is a Task. Tasks carry metadata (who, what, when) and reference documents via Task.input and Task.output.

📄 DocumentReference = Library Card

Each uploaded file gets a metadata wrapper (title, type, CTD section). The regulator discovers files through the Task, downloading the payload only when needed.

🔔 Subscription = Real-Time Alert

Both parties subscribe to events (status changes, new Tasks). Notifications arrive instantly at configured endpoints — no polling required.

🔗 groupIdentifier = Procedure Thread

All Tasks within a single regulatory procedure share the same groupIdentifier, enabling portfolio-wide search and reporting.


Example: Shelf-Life Update

🔍 Technical Deep-Dive: For the full step-by-step technical detail of this workflow including FHIR resource examples, see the Workflow Deep-Dive.