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

Real-Time Subscriptions

Key Points about FHIR Task and its use

1. Task.owner: In FHIR, the Task.owner data element is defined as the entity responsible for managing task execution, having the "Performer; Executer" role. In this IG, it is the Organization which controls the Task.status and which indicates Task completion. e.g. A Regulator is the Task.owner of an initial application Task to review an application. The Regulator determines if the application Task is complete, noting the outcome with Task.output.

How It Works (Conceptual)

1. SubscriptionTopic: The Regulator server hosts SubscriptionTopics which allow a client system to 'subscribe' to certain events. In our case, there should be a SubscriptionTopic that allows Subscriptions to status changes of a specific Task. Additionally, the Regulator system will need a SubscriptionTopic that allows the Regulator to subscribe applicant systems to receive notification when Tasks are created with the Applicant system as the Task owner.

Applicant System 2a. Subscribe: The Applicant's system (e.g., RIM) sends a Subscription resource to the Regulator's APIX server that registers for the 3b. Trigger: A change occurs (e.g., an assessor changes a Task status from received to in-progress). 4b. Notify: The Regulator's server matches the change to the Subscription criteria and immediately sends a notification to the Applicant's endpoint.

Regulator System 2a. Subscribe: The Regulator system sends a Subscription resource to the Regulator's APIX server that registers a subcription for the Task creation SubscriptionTopic, filtered to respond only to specific Tasks where the Applicant is the Task.owner. 3b. Trigger: A change occurs (e.g., an assessor changes a Task status from received to in-progress). 4b. Notify: The Regulator's server matches the change to the Subscription criteria and immediately sends a notification to the Applicant's endpoint.

The Topic-Based Subscription Model

APIX uses the R5 Topic-Based Subscription model (SubscriptionTopic) to define standard events.

Standard Subscription Topics

Creating a Subscription

To start receiving notifications, an Applicant POSTs a Subscription resource.

Example: Subscribe to all updates for a specific Procedure

{
  "resourceType": "Subscription",
  "status": "active",
  "topic": "http://hl7.org/fhir/uv/apix/SubscriptionTopic/task-update",
  "filterBy": [
    {
      "filterParameter": "group-identifier",
      "value": "Procedure-2025-00123"
    }
  ],
  "channelType": {
    "system": "http://terminology.hl7.org/CodeSystem/subscription-channel-type",
    "code": "rest-hook"
  },
  "endpoint": "https://rim-system.pharma-corp.com/apix-webhook"
}

Notification Channels

APIX supports two primary channel types for different architectural needs:

1. REST Hook (Server-to-Server):
   • Best for: Production RIM systems, cloud integrations.
   • Mechanism: The regulator sends a POST request to a URL registered by the applicant.
   • Payload: Can be id-only (ping) or full-resource (contains the updated Task).
2. WebSocket (Client-Side):
   • Best for: UI dashboards, lightweight apps, or firewalled environments where inbound webhooks are difficult.
   • Mechanism: The client maintains an open socket connection to receive stream updates.

Process Analytics & Cycle Time

Because every regulatory milestone is a timestamped event, the subscription feed doubles as a real-time analytics stream.

By storing the notification history, an organization can automatically reconstruct the full timeline of any procedure and calculate performance metrics without manual data entry:

• Time-to-Submission: Task.authoredOn (Draft) vs Task.lastModified (Requested)
• Regulatory Cycle Time: Task.authoredOn (Received) vs Task.lastModified (Completed)
• Clock-Stop Duration: Time elapsed while status = on-hold
• Process Bottlenecks: Visualizing which step (Validation vs Assessment vs Response) consumes the most time.

From Event Stream to Dashboards

For worked examples of what this analytics stream produces — a full single-procedure lifecycle timeline reconstructed from Task versions, a regulator's live activity board, and auto-generated annual performance reports — see the Scenario Examples on the Use Cases page.