API for the Exchange of Medicinal Product Information (APIX), published by Gravitate Health Project. 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

APIX Task Structure

In APIX, the Task resource is the universal envelope and workflow engine for all biopharmaceutical regulatory interactions. Whether it is a clinical trial application, marketing authorization application, post-approval variation, response to questions, decision letter, or review report, it is all represented as an individual Task resource.

​The following are examples of Tasks with synthetic content: Sample Task (Shelf Life), Initial Submission, Questions, Response, and Decision.

The following table provides an overview of the key elements of the APIX Task resource. For a technical description of the Task resource, see the APIX Task profile.

Element	Cardinality (APIX)	Value / Example	Purpose / Notes
Task.meta	1..1	• versionId (Mandatory) • lastUpdated (Mandatory) • profile (Fixed)	Technical metadata for versioning and conformance
Task.text	1..1	Narrative description	Free text description of the task for human readers
Task.identifier	1..2	• Canonical Task UUID (mandatory) • Procedure-scoped number (optional), e.g. EMEA/H/C/001234/II/0045	Technical ID + Official Procedure Number
Task.status	1..1	draft | requested | received | accepted | rejected | in-progress | on-hold | completed | cancelled | entered-in-error	Drives the APIX state machine and UI
Task.statusReason	0..1	CodeableConcept from APIX RejectionReason ValueSet	Mandatory when status = rejected or cancelled
Task.intent	1..1	proposal	Fixed value for all regulatory Tasks
Task.priority	0..1	routine | urgent | asap | stat	Used for accelerated/conditional procedures
Task.code	1..1	From APIX TaskCode ValueSet, e.g. • initial-maa • variation-type-ia • validation-question • response-to-question • approval-letter	Defines the regulatory message type and triggers specific business rules
Task.for	0..1	Reference to MedicinalProductDefinition or RegulatedAuthorization	Identifies the medicinal product that is the subject of the procedure
Task.requestedPeriod	0..1	start = Clock Start end = Deadline	Regulatory clock management
Task.input	0..*	type = regulatory-document valueReference = Reference(DocumentReference)	Primary mechanism to attach submission content
Task.output	0..*	type = regulatory-document valueReference = Reference(DocumentReference)	Used by the regulator to return assessment reports, decisions, etc.
Task.groupIdentifier	1..1	Procedure identifier, e.g. PROC-2025-00047	Identical across every Task in the same regulatory procedure
Task.partOf	0..*	Reference to the parent Task (e.g. a response points to the question Task)	Explicitly builds threads and hierarchies
Task.requester	1..1	Applicant Organization that initiated the procedure	Fixed for the entire procedure lifecycle
Task.requestedPerformer	0..1	Organization producing/performing the task	Designated performer (e.g. Applicant or Regulator)
Task.businessStatus	0..1	Detailed regulatory status (e.g. clock-short, validated)	Enables detailed process analytics and clock-stop tracking
Task.authoredOn	1..1	Date/time the sender created the Task	Starting point for regulatory cycle-time metrics
Task.lastModified	1..1	Automatically updated on every change	Critical for audit and performance reporting

Task Identifiers

Each regulatory message (initial submission, response to questions, approval letter) is a separate Task instance.

Each Task is connected by three identifiers:

1. Task.groupIdentifier is a common UUID used to group all Tasks within a regulatory activity.
2. Task.RegulatoryProcedureIdentifier is the procedure number or application number assigned by the regulator.
3. partOf relates a child Task to its parent Task.

Task Status

In addition to the identifiers mentioned above, APIX uses Task Status (see here for the Task Status Valueset) to drive the the regulatory workflow.

The following table lists each status and its purpose throughout the workflow.

Code	Display	Meaning in APIX Regulatory Context
draft	Draft	Task created locally by company, not yet submitted
requested	Requested	Company has POSTed the Task to the regulator
received	Received	Regulator server has received the Task (auto-transition)
accepted	Accepted	Gateway/technical validation passed
rejected	Rejected	Fatal validation failure → procedure terminated
in-progress	In Progress	Scientific/regulatory assessment ongoing
on-hold	On Hold	Clock stopped – regulator has raised questions
completed	Completed	Procedure complete and regulatory decision delivered
cancelled	Cancelled	Company withdraws the procedure
entered-in-error	Entered in Error	Task created by mistake

Typical State Transitions in a Regulatory Procedure

The following table demonstrates how the Status on a given Task changes throughout a regulatory activity.

Status Change From → To	Trigger / Example	Who updates	Subscription notification sent?
draft → requested	Company finalises and POSTs the Task	Company	Yes
requested → received	Auto-receipt on regulator server	Regulator	Yes
received → accepted	Gateway validation successful	Regulator	Yes (validation passed)
received → rejected	Gateway validation fails	Regulator	Yes (rejection)
accepted → in-progress	Assessment team begins review	Regulator	Yes
in-progress → on-hold	Regulator creates child Task with questions	Regulator	Yes (clock-stop)
on-hold → in-progress	Company responds → regulator restarts clock	Regulator	Yes (clock-restart)
in-progress → completed	Decision letter issued	Regulator	Yes (final decisoin)
any → rejected	Scientific rejection	Regulator	Yes
any → cancelled	Company withdraws	Company	Yes