Note – for information on the compilation of eCTD dossiers please follow this link

The following documentation should be provided for each amendment:

• the covering letter
  • either an amendment application form (see model completed form for guidance) or revised APIMF form (for amendment #1) (in both Word and portable document (PDF) format)
  • a single document outlining, explaining, discussing and justifying the proposed change(s) (in Word format or text-selectable PDF)
  • documentation that supports the proposed amendment (in Word or text-selectable PDF), as described in the amendment guidance and presented in a folder entitled "supporting documentation"
  • the sub-sections of the APIMF that are affected by the change(s) and that have been revised accordingly (see also Documentation requirements)
  • an updated API-quality information summary (API-QIS) (if available; see note below)

Documentation of each change should be sufficiently detailed to enable the WHO assessor to quickly determine whether the appropriate reporting category has been used.

Revision of API quality information summary (API-QIS)

The API quality information summary (API-QIS) provides a summary of the key quality information of the APIMF. It is an attachment to the original APIMF acceptance letter and to any subsequent amendment acceptance letters that are issued. The API-QIS should be revised whenever information changes in any of the API-QIS sections affected by the amendment occur. Revised information should be typed in red and obsolete details struck through.

The revised API-QIS should be submitted as part of the amendment package. If there is no change to the API-QIS as a result of the amendment, a statement should be made in the amendment application form to this effect. If there is no currently agreed API-QIS, then an API-QIS is not required. For such APIMFs an API-QIS will be provided at the conclusion of the assessment of the next major amendment, or following the submission of the next periodically revised APIMF.

Documentation requirements

Revised subsections submitted with amendments

A revised subsection should be submitted whenever a requested change affects the details of that subsection. The submitted revised subsection should include all accepted details relevant to that section. It should not be only an excerpt reflecting the revised details: the revised subsection must replace the existing subsection in its entirety. For example, if an amendment is submitted to introduce an alternative source of API starting material, the revised subsection (3.2.S.2.3.1) must include information on both the existing API starting material source and the proposed, alternative API starting material source(s).

In terms of detail, replacement subsections should generally not go beyond level  3.2.S.X.X. More detailed subsections may be submitted in some instances, provided the overall context of the change is not lost.

Any replacement subsection should be assigned an amendment version number. It must include reference to the open part (OP) of the APIMF.

Page numbers may be set at 1 at the start of each section or subsection.

Version numbering

The open part (OP) and restricted part (RP) of the APIMF should each be assigned a unique document version number. This number should appear on the document cover page, together with the name of the API and the APIMF holder's name, indicate whether it refers to the OP or RP of the APIMF, and give the date of issue. For example:

Drugs Inc/Artemether/OP/01/Feb-2013.

If a replacement subsection of an APIMF is issued by the applicant, it is referred to as an amendment and should be assigned an amendment version number. The amendment version number should include reference to the "parent" OP document. For example:

Drugs Inc/Artemether/OP/01/Feb-2013/Amend 01 – April-2013.

A change in the open part version version number, e.g. from OP/01  to OP/02 would indicate the availability of a complete and revised version of the open part of the APIMF. 

This new version (AP/02) would be assumed to incorporate all the accepted amendments made to the earlier version (AP/01), including all applicable CTD headings.

Example of the life cycle of an APIMF
The table below presents an example of the life cycle of an APIMF. Three amendments to the OP were received, following submission of the original APIMF. Each time an amendment was received, the amendment number and date were added to APIMF version number. Finally, a year after submission of the APIMF, a revised version of the OP was submitted, consolidating the previous amendments. Since no changes were made to details in the RP, submission of a revised RP was not necessary.

Electronic requirements

No single electronic file should exceed 50 MB in size.

File or folder names should not exceed 64 characters in length.

Path lengths should not exceed 180 characters, including the file name, and extension. Abbreviated file or folder names can be used.

The use of special characters in folder or file names should to be avoided in order to prevent software conflicts. These special characters include:

• angle brackets (<>)
• ampersand (&)
• asterisk (*)
• backslash (\)
• braces ({})
• colon (:)
• forward slash (/)
• number sign (#)
• percent (%)
• plus sign (+)
• pipe (|)
• question mark (?)
• quotation mark (")
• tilde (~).

Where to submit an APIMF amendment application

An application for an amendment application and subsequent responses can either be sent:

On CD or DVD to:

World Health Organization
WHO Prequalification Team: medicines
MHP/RPQ/PQT Room M613
20, Avenue Appia
1211 Geneva 27
Switzerland

Or

2. Via a secure link to an online document repository. The link should be sent in an email to the following email address: APIassessment@who.int. The subject line of the emails should clearly indicate the application and the specific medicine procedure referred too. The date of receipt will be the date the file is successfully downloaded. If you have any questions regarding this please contact Dr Matthias Stahl, stahlm@who.int.