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

APIX Task Structure

Page standards status: Informative

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, useful in precise filtering of status‑change notifications
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, or for a Regulator to ask questions or make requests. Can reference DocumentReferences.
Task.output	0..*	type = regulatory-document valueReference = Reference(DocumentReference)	Used by the regulator to return assessment reports, decisions, etc. Or, used by Applicant to provide responses to Regulator questions or requests. Can reference DocumentReferences.
Task.groupIdentifier	1..1	Procedure identifier, e.g. PROC-2025-00047	Identical across every Task in the same regulatory procedure
Task.basedOn	0..*	Reference to the parent Task (e.g. a response points to the question Task), ordered lineage of Tasks (oldest → newest).	The element is an ordered array with the most distant ancestor Task as the first Task of the array (e.g. an initial request for review). The parent Task will be in the last position of the array.
Task.partOf	0..*	Reference to a set of Tasks	Explicitly can build threads and hierarchies of Task to be performed as one set.
Task.requester	1..1	Applicant Organization that initiated the procedure	Fixed for the entire procedure lifecycle
Task.owner	0..1	Organization responsible for completion and mangement of the Task	Designated performer Organization (e.g. Applicant or Regulator). In FHIR, the Task.owner data element is defined as the entity responsible for managing task execution and status, 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. An Applicant would be the the Organization in Task.owner for a Task assigned to the Applicant by the Regulator. Upon the Applicant's completion of the Task, and the Applicant providing a response in Task.output, the Regulator determines if an additional Task or child Task is necessary.
Task.performer	0..1	Organization producing/performing the task	Can be different from the Task.owner. The Task.owner Organization is responsible for the Task execution and tracking completion.
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 four 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. basedOn relates a child Task to its parent Task.
4. partOf indicates a set of Tasks performed together.

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