ISO/TS 20440:2016

TECHNICAL ISO/TS
SPECIFICATION 20440
First edition
Health informatics — Identification
of medicinal products —
Implementation guide for ISO
11239 data elements and structures
for the unique identification and
exchange of regulated information on
pharmaceutical dose forms, units of
presentation, routes of administration
and packaging
Informatique de santé — Identification des produits médicaux —
Guide de mise en oeuvre des éléments de données et structures pour
l’identification unique et l’échange d’informations réglementées sur
les formes des doses pharmaceutiques, les unités de présentation, les
voies d’administration et les emballages de l’ISO 11239
PROOF/ÉPREUVE
Reference number
©
ISO 2016
ISO/CEN PARALLEL PROCESSING
This final draft has been developed within the International Organization for Standardization (ISO), and pro-
cessed under the ISO-lead mode of collaboration as defined in the Vienna Agreement. The final draft was
established on the basis of comments received during a parallel enquiry on the draft.
This final draft is hereby submitted to the ISO member bodies and to the CEN member bodies for a parallel
two-month approval vote in ISO and formal vote in CEN.
Positive votes shall not be accompanied by comments.
Negative votes shall be accompanied by the relevant technical reasons.
© ISO 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Organization of controlled terms . 1
2.1 General . 1
2.2 Code-term pair and coded concept . 2
2.2.1 General. 2
2.2.2 Code-term pair. 2
2.2.3 Coded concept . 5
2.3 Versioning. 6
2.3.1 Versioning of the term . 6
2.3.2 Versioning of the terminology . 9
3 Terminologies . 9
3.1 General . 9
3.2 Pharmaceutical dose form .10
3.2.1 Pharmaceutical dose form overview .10
3.2.2 Pharmaceutical dose form schema .11
3.2.3 Pharmaceutical dose form example: Prolonged-release tablet .16
3.3 Combined pharmaceutical form .21
3.3.1 Combined pharmaceutical dose form overview .21
3.3.2 Combined pharmaceutical dose form schema .22
3.3.3 Combined pharmaceutical dose form example: Powder and solvent for
solution for injection .23
3.3.4 Other authorized combinations of terms — Combined terms and
combination packs .24
3.4 Unit of presentation .25
3.4.1 Unit of presentation overview .25
3.4.2 Unit of presentation schema .26
3.4.3 Unit of presentation example: Tablet .27
3.5 Route of administration .28
3.5.1 Route of administration overview .28
3.5.2 Route of administration schema .28
3.5.3 Route of administration example: Intravenous use .29
3.6 Packaging .29
3.6.1 Packaging overview .29
3.6.2 Packaging schema .29
3.6.3 Packaging example: Ampoule (Packaging category: Container) .31
3.6.4 Packaging example: Screw cap (Packaging category: Closure) .32
3.6.5 Packaging example: Oral syringe (Packaging category: Administration device) .34
3.6.6 Packaging concept summaries .35
4 Mapping of regional terms .36
4.1 Differences in granularity between regional terminologies .36
4.2 Organization of regional terms in the database .37
4.2.1 General.37
4.2.2 Addition of regional terms to the database .37
4.2.3 Mapping regional terms to central coded concepts .40
4.2.4 Versioning of mapped regional terms .40
4.2.5 Mapped regional term example: Extended-release caplet .40
Bibliography .42
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT), see the following URL: Foreword — Supplementary information.
The committee responsible for this document is ISO/TC 215, Health informatics, in collaboration with
CEN/TC 251, Health informatics.
iv PROOF/ÉPREUVE © ISO 2016 – All rights reserved

Introduction
The terminologies described in EN/ISO 11239:2012 (hereafter referred to as ISO 11239) and in this
Technical Specification are essential for the implementation of the IDMP standards as a whole.
Each region traditionally uses its own sets of terminologies to describe the concepts covered in
ISO 11239 within their regions; these terminologies are not harmonized with those of the other regions.
Therefore, harmonized controlled terminologies need to be provided to ensure that all regions can refer
to a given concept in the same manner. The purpose of this Technical Specification is to describe how
these controlled vocabularies are constructed and illustrate their use for ISO 11239 implementation.
TECHNICAL SPECIFICATION ISO/TS 20440:2016(E)
Health informatics — Identification of medicinal products
— Implementation guide for ISO 11239 data elements and
structures for the unique identification and exchange of
regulated information on pharmaceutical dose forms, units
of presentation, routes of administration and packaging
1 Scope
This Technical Specification describes data elements and structures for the unique identification and
exchange of regulated information on pharmaceutical dose forms, units of presentation, routes of
administration and packaging.
Based on the principles outlined in this Technical Specification, harmonized controlled terminologies
will be developed according to an agreed maintenance process, allowing users to consult the
terminologies and locate the appropriate terms for the concepts that they wish to describe. Provisions
to allow for the mapping of existing regional terminologies to the harmonized controlled terminologies
will also be developed in order to facilitate the identification of the appropriate terms. The codes
provided for the terms can then be used in the relevant fields in the PhPID, PCID and MPID in order to
identify those concepts.
This Technical Specification is intended for use by
— any organization that might be responsible for developing and maintaining such controlled
vocabularies,
— any regional authorities or software vendors who wish to use the controlled vocabularies in their
own systems and need to understand how they are created,
— owners of databases who wish to map their own terms to a central list of controlled vocabularies,
— other users who wish to understand the hierarchy of the controlled vocabularies in order to help
identify the most appropriate term to describe a particular concept.
The terminology to be applied in the context of this Technical Specification and set out in ISO 11239 is
under development. All codes, terms and definitions used as examples in this Technical Specification
are provided for illustration purposes only, and are not intended to represent the final terminology.
2 Organization of controlled terms
2.1 General
This Clause describes how each controlled term is built, describing the data types used to convey
the information and the versioning requirements for tracking their creation and evolution. Clause 3
describes the different types of terminologies and sub-vocabularies that use these data types, and any
relevant relationships between them.
Each field in Clause 2 is described under a separate subclause, consisting of the title of the field and a
table containing the following:
— “User Guidance”, a description of the field;
— “Data Type”, a description of the data type;
— “Conformance”, a description of whether the field is mandatory, optional, or conditional;
— “Value Allowed”, indicating the possible values for the field;
— “Business Rules”, providing technical guidance for the field.
2.2 Code-term pair and coded concept
2.2.1 General
The code-term pair and the coded concept are the data types that are used to represent the
information that is required to describe each term in each terminology or sub-vocabulary, in each
language/region combination.
2.2.2 Code-term pair
2.2.2.1 Code-term pair overview
This is the underlying class for each term, and is used to describe and define a term in a specific language
and for a specific region. It contains the core attributes for each concept, including the identifier, the
textual representation of the term (i.e. the controlled term itself), the definition, an optional domain to
indicate whether a term is restricted to veterinary use, an optional textual comment, and the language
and region codes.
Each controlled term or sub-term has a unique code-term pair for each language/region combination.
This combination of language and region allows for regional variants of a specific language to be catered
for; for example, where the spelling of a term or definition differs between UK English and US English, it
is possible to reflect this difference. Where terms and definitions already exist for a particular language
for a particular region, and the same language is used in a second region, it is a regional implementation
issue to decide whether terms and definitions need to be provided for the second region, or whether the
terms and definitions of the first region shall be used.
When a new concept is required, a new coded concept must be created, and at least one code-term pair
is required in order to hold the data to describe the concept. The language/region combination chosen
to represent the “value” shall always be created first to represent the concept, even when the request
originates from a different language/region combination. The maintenance organization shall provide
instructions on how to request a new term or a revision to an existing term.
2.2.2.2 Code-term pair: Code
User Guidance This field contains a unique, machine-readable identifier for the code-term pair. In this
Technical Specification, the following format is used for the code:
— XXX-12345678-LL-RR
where
— XXX represents the class of term (see Table 1);
— 12345678 represents a unique 8-digit number; for sub-vocabularies, a 4-digit
number is used;
— LL represents the language code;
— RR represents the region/country code.
Data Type String
Conformance Mandatory
Value Allowed Free text
Business Rule(s) Each code-term pair shall have one code.
2 PROOF/ÉPREUVE © ISO 2016 – All rights reserved

The codes used in this Technical Specification to represent the various classes of term in the examples
that follow are shown in Table 1.
Table 1 — Codes used to represent the class of term
Code Class
SOM State of matter
BDF Basic dose form
RCA Release characteristics
TRA Transformation
ISI Intended site
AME Administration method
PDF Pharmaceutical dose form
CDF Combined pharmaceutical dose form
UOP Unit of presentation
ROA Route of administration
PCA Packaging category
CON Container
CLO Closure
DEV Administration device
MAP Mapped term
2.2.2.3 Code-term pair: Term
User Guidance This field contains the textual term description for the code-term pair.
Data Type String
Conformance Mandatory
Value Allowed Free text
Business Rule(s) Each code-term pair shall have one term.
2.2.2.4 Code-term pair: Definition
User Guidance This field contains the textual definition for the code-term pair. The definition is as com-
prehensive as possible, in order to guide the user to the most appropriate term to describe
a given concept. For example, it should be detailed enough to distinguish between similar
pharmaceutical dose forms, and may exceptionally make direct reference to related terms
in order to exclude them, although such references may be considered more appropriate
in the Comments section instead.
Data Type String
Conformance Mandatory for the default code-term pair; optional for the translation code-term pairs
Value Allowed Free text
Business Rule(s) Each code-term pair may have one definition. For each coded concept, the default code-
term pair (e.g. EN-GB) shall have one definition. If a code-term pair for a given language/
region combination does not have a definition provided, the definition in the code-term
pair for the default language/region combination is adopted.
2.2.2.5 Code-term pair: Domain
User Guidance This field is used to identify whether a term is considered appropriate for both human
and veterinary use, or whether it is considered appropriate for veterinary use only.
Data Type Concept Descriptor
Conformance Optional
Value Allowed “Human and veterinary”; “Veterinary only”
Business Rule(s) Each code-term pair may have one domain. Although veterinary medicines are outside the
scope of IDMP, certain regions use a single terminology system to cover both medicines
for human use and medicines for veterinary use; this optional field is therefore included
in order to allow veterinary-only terms to be easily distinguished in such systems.
2.2.2.6 Code-term pair: Comment
User Guidance This optional field contains a textual comment for the code-term pair. It is used to provide
to the user additional information and guidance that would not be strictly appropriate
to appear as part of the definition.
Data Type String
Conformance Optional
Value Allowed Free text
Business Rule(s) Each code-term pair may have one comment.
2.2.2.7 Code-term pair: Language code
User Guidance This field contains the language in which the term, definition and comment are described;
in this Technical Specification, the working language is English. The language code used
is in line with ISO 639-1.
Data Type Concept Descriptor
Conformance Mandatory
Value Allowed ISO 639-1 code, OID reference 1.0.639.1
Business Rule(s) Each code-term pair shall have one language code.
2.2.2.8 Code-term pair: Region code
User Guidance This field contains the region/country that uses this code-term pair, in the language de-
scribed above; it can be used to differentiate between regional variants of that language;
in this Technical Specification, the default region is the United Kingdom. The region code
used is in line with ISO 3166-1. Alpha-2 (i.e. 2-letter) codes are used. The additional code
EU is also allowed to represent the European Union. It should be noted that the United
Kingdom is represented in ISO 3166-1 by the 2-letter code GB, as in the examples used in
this Technical Specification.
Data Type Concept Descriptor
Conformance Mandatory
Value Allowed ISO 3166-1 alpha-2 code, OID reference 1.0.3166.1.2.2.
Business Rule(s) Each code-term pair shall have one region code.
2.2.2.9 Code-term pair example
An example of a code-term pair for the concept “Tablet”, a pharmaceutical dose form, is shown in
Table 2. Since the working language of this Technical Specification is UK English, the language is English
and the region is the United Kingdom.
4 PROOF/ÉPREUVE © ISO 2016 – All rights reserved

Table 2 — Example code-term pair for pharmaceutical dose form “Tablet” in UK English
Code PDF-10219000-EN-GB
Term Tablet
Solid single-dose uncoated preparation obtained by compressing uniform volumes of par-
ticulate solids or by other means such as extrusion or moulding. Tablets include single-layer
tablets resulting from a single compression of particles and multi-layer tablets consisting of
Definition concentric or parallel layers obtained by successive compressions of particles of different com-
position. Tablets are intended for oral use to release active substance(s) in the gastrointestinal
fluids by a rate depending essentially on the intrinsic properties of the active substance(s)
(conventional release).
languageCode EN
regionCode GB
2.2.3 Coded concept
2.2.3.1 Coded concept overview
This is the class that is used to represent the concept itself, and is a collection of all of the code-term
pairs that define the same concept for each language/region combination. The code-term pairs for a
given concept can be considered as different translations of that concept; the coded concept groups
those various translations under a single, unique code. In order to represent the coded concept, one of
the code-term pairs is selected as the “value”, while each other code-term pair is a “translation”.
The use of a coded concept in another system allows for the identification of a concept without
specifying a particular language and region. The code-term pair selected as the “value” may be used
by default to represent the coded concept when a textual term is requested. The default code-term pair
in this Technical Specification is English/United Kingdom. Where a language/region combination is
specified by the requesting system, the appropriate code-term pair for that combination can be used to
represent the coded concept.
As described in 2.2.2.1, when a new concept is required, a new coded concept must be created, and at least
one code-term pair is required in order to hold the data to describe the concept. The language/region
combination chosen to represent the “value” must always be created, even when the request originates
from a different language/region combination. The maintenance organization shall provide instructions
on how to request a new term, as well as how to request a revision to an existing term.
2.2.3.2 Coded concept: Code
User Guidance This field contains a unique, machine-readable identifier for the coded concept.
Data Type String
Conformance Mandatory
Value Allowed Free text
Business Rule(s) Each coded concept shall have one code.
2.2.3.3 Coded concept: Value
User Guidance This field contains the identifier of the code-term pair that has been chosen to represent
the coded concept. In this Technical Specification this code-term pair is always that of
the English/United Kingdom combination.
Data Type String
Conformance Mandatory
Value Allowed Code-term pair identifier
Business Rule(s) Each coded concept shall have one value, which is considered to be its default code-term
pair. Whenever a new concept is created, the code-term pair with the language/region
combination that is chosen for the “value” shall always be created first, even if the request
is made for a different language/region combination.
2.2.3.4 Coded concept: Translation
User Guidance This repeatable field contains the identifier of the code-term pair that represents the
concept using a language/region combination that is different from that of the code-term
pair used for the above coded concept value. In this Technical Specification, since the above
value is always represented by English/United Kingdom, these code-term pairs will rep-
resent combinations such as English/United States, Japanese/Japan, French/France, etc.
Data Type String
Conformance Optional
Value Allowed Code-term pair identifier
Business Rule(s) Each coded concept may have zero to many translations.
2.2.3.5 Coded concept example
An example of a coded concept for the concept “Tablet” is shown in Table 3. Since the working language
of this Technical Specification is UK English, the value is the code-term pair that has English as the
language and United Kingdom as the region (as shown in Table 2). In order to simplify the example, just
two translations are associated with it here: the code-term pair that has French as the language and
France as the region, and the code-term pair that has Japanese as the language and Japan as the region.
As can be seen from Table 3, only the code-term pair identifiers are required, since each one represents
all of the necessary information for each language/region combination, (such as for English and the
United Kingdom as shown in Table 2). The overall concept of “Tablet” (i.e. including all language/region
combinations) has its own identifier (code PDF-10219000 in this example).
Table 3 — Example coded concept for pharmaceutical dose form “Tablet”, linking the code-term
pairs for the concept in English for the United Kingdom, French for France, and Japanese for Japan
code PDF-10219000
value PDF-10219000-EN-GB
PDF-10219000-FR-FR
translation
PDF-10219000-JA-JP
2.3 Versioning
2.3.1 Versioning of the term
ISO/TR 14872 includes guidance on principles and procedures for versioning and change control.
Code-term pairs are used to populate a terminology database, and as such they can be considered as the
current representation of specific concepts for specific language/region combinations. They contain
the information that is considered to be the most important and relevant to the database user. However,
6 PROOF/ÉPREUVE © ISO 2016 – All rights reserved

as controlled vocabularies can evolve over time, the situation arises whereby terms in a database need
to be revised, which means that code-term pairs therefore need to be revised.
In order to maintain a traceable history of a code-term pair, including any changes that are made to it,
each code-term pair is associated with versioning information. This is done with the use of versions.
Each time a code-term pair is created or modified, a version of that code-term pair is created.
A version acts as a record of a code-term pair at a specific point in time. It contains the elements of the
code-term pair at that point in time, as well as a timestamp, an identifier of the operator that made the
modification, and a description of the modification that took place. Also recorded in the version is the
status of the term; any change in status of a code-term pair will evoke the creation of a new version
of that code-term pair. Certain information, such as the identifier of the operator, may not be made
publicly available, but is nevertheless recorded.
These additional elements of versioning information are described in more detail below.
The coded concept can be considered as the container for all of the translations (i.e. code-term pairs)
for a given concept; it does not therefore require versioning information itself. The addition of a new
translation (i.e. a new code-term pair) does not therefore result in the creation of a new version of the
coded concept.
2.3.1.1 Versioning: Code
User Guidance This field contains the unique, machine-readable identifier for the version of the code-
term pair that is the subject of the versioning.
In this Technical Specification, the following format is used for the code:
— XXX-12345678-LL-RR-V
where
— XXX-12345678-LL-RR represents the code-term pair;
— V represents the version number, the length of which is not limited to a single
digit.
Data Type String
Conformance Mandatory
Value Allowed The code is generated automatically from the code-term pair and the version number.
Business Rule(s) Each version shall have one code.
2.3.1.2 Versioning: Creation date
User Guidance This field contains the time and date upon which the concept was first created. The time
stamp used is in line with ISO 8601.
Data Type Timestamp
Conformance Mandatory
Value Allowed YYYY-MM-DD hh:mm:ss
Business Rule(s) The creation date refers to the creation of the coded concept and the first code-term pair
for the default language/region. The time standard chosen to measure the point in time
(e.g. UTC, UTC+1) is used consistently throughout the database.
2.3.1.3 Versioning: Created by
User Guidance This field contains an identification of the operator who created the concept, such as
their name or identifier.
Data Type String
Conformance Mandatory
Value Allowed Free text
Business Rule(s) This information is not made publicly available to all users, but is recorded in the database
and is accessible to the database administrator.
2.3.1.4 Versioning: Version date
User Guidance If a modification has been made to a term, then a new version of that term is created,
and this field contains the time and date upon which that version was created. This also
applies to the creation of the first version of the code-term pair. The first version of the
first code-term pair represents the creation of the coded concept itself, and therefore has
particular importance, which is why it is considered appropriate always to indicate that
date, even for subsequent versions and for different translations. The time stamp used
is in line with ISO 8601.
Data Type Timestamp
Conformance Mandatory
Value Allowed YYYY-MM-DD hh:mm:ss
Business Rule(s) Each version of a code-term pair shall have one version date.
2.3.1.5 Versioning: Modification made
User Guidance If a modification has been made to a term, then a new version of that term is created, and
this field shall be used to add a description of or explanation for the modification that was
made. This also applies to the creation of the first version of the code-term pair.
Data Type String
Conformance Mandatory
Value Allowed Free text, although a drop-down list of common modifications may be considered appro-
priate in order to help harmonize the entries.
Business Rule(s) Each version of a code-term pair shall have one entry for modification made.
2.3.1.6 Versioning: Modification by
User Guidance If a modification has been made to a term, then a new version of that term is created,
and this field contains an identification of the operator who made the modification,
such as their name or identifier. This also applies to the creation of the first version of
the code-term pair. The first version of the first code-term pair represents the creation
of the coded concept itself, and therefore has particular importance, which is why it is
considered appropriate always to record the creator, even for subsequent versions and
for different translations.
Data Type String
Conformance Mandatory
Value Allowed Free text
Business Rule(s) This information is not made publicly available to all users, but is recorded in the database
and is accessible to the database administrator.
8 PROOF/ÉPREUVE © ISO 2016 – All rights reserved

2.3.1.7 Versioning: Concept status
User Guidance This field contains the status of the term.
Data Type Concept descriptor
Conformance Mandatory
Value Allowed “Current”; “Deprecated”; “Rejected”; “Pending”
Business Rule(s) Each version of a code-term pair has a status, which allows the history of any change in
status of a term to be recorded. For example, if an existing, current term (version 1) is
to be deprecated, then a new version of the code-term pair is created (version 2), with
the status changed from “current” to “deprecated”. It is the intention that, for any given
concept, the status is the same for all of the translations; therefore, a mechanism should
be implemented to ensure that the status of each code-term pair of a coded concept is
changed at the same time.
2.3.1.8 Versioning: Current concept
User Guidance If a term has been deprecated or rejected, and one or more other terms are identified
as a replacement, this repeatable field contains the identifier of the replacement term.
Data Type String
Conformance Conditional
Value Allowed Coded concept identifier
Business Rule(s) This field is conditional on the status of a term being “deprecated” or “rejected”, and there
being a replacement term identified.
2.3.1.9 Versioning: Version number
User Guidance This field contains an identifier for the particular version of the term being described,
in the form of a whole number. When a modification to a term is made, a new version is
created and identified through the version number, which increases by a value of 1 from
the previous version of the term. When a term is first created this field has the value 1.
Data Type Integer
Conformance Mandatory
Value Allowed Positive integer greater than zero.
Business Rule(s) Each version shall have one version number.
2.3.2 Versioning of the terminology
The terminology is intended to be updated on a continuous basis, as new concepts and translations are
added. Therefore it is not envisaged that there will be periodic updates of the terminology released
and identified with fixed version numbers. However, a snapshot of the database shall be recorded on
a regular basis, and thus there shall be periodic versions of the database available in case reversion to
a previous instance of the database is required (e.g. in case of corruption of the database due to some
unforeseen circumstances).
3 Terminologies
3.1 General
Each of the sets of terminologies described in this Clause make use of the data types described in
Clause 2 to carry the information required to describe each individual concept.
The following subclauses describe each set of terminologies and provide examples to illustrate them.
All of the terms and definitions used are for illustration purposes only, and are not intended to reflect
the exact terms and definitions that will constitute the terminologies as such.
Each element in Clause 3 is described under a separate subclause, consisting of a title and a table
containing the following:
— “User Guidance”, a description of the element;
— “Data Type”, a description of the data type;
— “Conformance”, a description of whether the element is mandatory, optional, or conditional;
— “Value Allowed”, indicating the possible values for the element;
— “Business Rules”, providing technical guidance for the element.
3.2 Pharmaceutical dose form
3.2.1 Pharmaceutical dose form overview
The pharmaceutical dose form is the physical manifestation of a product that contains the active
ingredient(s) and/or inactive ingredient(s) that are intended to be delivered to the patient.
A product can be described at two distinct stages: the stage at which it has been manufactured
(where it is referred to as the “manufactured item(s)”), and the stage at which it is administered to
the patient (where it is referred to as the “pharmaceutical product”). If a manufactured item has to
undergo some form of transformation in order to produce the pharmaceutical product, this means
that the pharmaceutical dose form of a product will differ depending on whether it is describing the
manufactured item or the pharmaceutical product.
A medicinal product can therefore be described with two “types” of pharmaceutical dose form:
— the manufactured dose form (i.e. the pharmaceutical dose form of the manufactured item, as
produced by the manufacturer);
— the administrable dose form (i.e. the pharmaceutical dose form of the pharmaceutical product,
ready to be administered to the patient) (see Figure 1).
Figure 1 — Diagram illustrating the relationship between manufactured item and
manufactured dose form, and pharmaceutical product and administrable dose form, for a
medicinal product
In cases where no transformation is required, and the manufactured item is the same as the
pharmaceutical product, the manufactured dose form and the administrable dose form are the same.
When a pharmaceutical dose form is described, there is no specific reference made to whether it can
be a manufactured dose form or an administrable dose form, although it can be deduced that, while
any pharmaceutical dose form can be a manufactured dose form, only a pharmaceutical dose form
that specifies no transformation can be an administrable dose form (this property may be used by the
maintenance organization to help identify whether a term can be considered as a manufactured dose
10 PROOF/ÉPREUVE © ISO 2016 – All rights reserved

form only, or as either a manufactured dose form or an administrable dose form). The purpose of using
these terms is to simplify the language used:
— “manufactured dose form” = “pharmaceutical dose form of the manufactured item”;
— “administrable dose form” = “pharmaceutical dose form of the pharmaceutical product”.
3.2.2 Pharmaceutical dose form schema
3.2.2.1 Schema overview
The pharmaceutical dose form is organized according to its basic dose form, which in turn is organized
according to its state of matter. This is the simple, three-level hierarchy by which the pharmaceutical
dose forms are categorised.
In addition to this hierarchy, each pharmaceutical dose form has a number of characteristics attributed
to it, which can be used to help index the pharmaceutical dose form. These characteristics are:
release characteristics, transformation, intended site, and administration method; they allow for
pharmaceutical dose forms to be more easily identified, and for related pharmaceutical dose forms to
be identified together more easily and in a number of different ways (see Figure 2).
Figure 2 — Pharmaceutical dose form basic schema showing the principal hierarchy (solid
arrows) and characteristics (dotted arrows)
This same schema is shown in the form of a unified modelling language (UML) class diagram in
Figure 3, with the additional information of the value for each class (in each case a coded concept) and
the relationship between the classes. The relationships are shown using the crow’s feet format, which is
explained in the legend of the figure.
StateOfMatter
+value: codedConcept
Legend
0to Many (0.n)
Oponal
1 to Many (1.n)
Mandatory
BasicDoseForm
+value: codedConcept
PharmaceuticalDoseForm
+value: codedConcept
ReleaseCharacteristics AdministrationMethod
+value: codedConcept +value: codedConcept
Transformation IntendedSite
+value: codedConcept +value: codedConcept
Figure 3 — Pharmaceutical dose form schema with crow’s feet entity-relationship notation
These relationships reflect the following conditions.
— A state of matter may have one or more (i.e. 0 to many, optional) basic dose forms associated to it;
while it is possible that a given state of matter may have no basic dose forms associated to it, this is
unlikely in practice, bearing in mind the very limited number of states of matter.
— Each basic dose form shall be associated with one state of matter.
— A basic dose form may have one or more (i.e. 0 to many, optional) pharmaceutical dose forms
associated to it; while it is possible that a given basic dose form may have no pharmaceutical dose
forms associated to it, this is only likely to occur when a new basic dose form concept has been
created and there are as yet no related pharmaceutical dose forms in the terminology.
— Each pharmaceutical dose form shall be associated with one basic dose form.
— Each pharmaceutical dose form shall be associated with one or more (i.e. 1 to many, mandatory) of
each of the following: Release characteristics, Transformation, Intended site, and Administration
method; where there is, for example, no transformation required, an appropriate null value shall be
available for selection.
— Each release characteristic, transformation, administration method and intended site may
be associated with one or more (i.e. 0 to many, optional) pharmaceutical dose forms; a given
characteristic may be associated with no pharmaceutical dose forms, for example when the
characteristic is first created, before the creation of any pharmaceutical dose form that requires it.
These characteristics are principally used for indexing purposes, and will not always need to be
reflected in the pharmaceutical dose form term itself, but in some cases they will. For example, a
solution that is intended to be instilled into the eye in the form of drops might be called “Eye drops,
solution”, a term in which the basic dose form (solution), intended site (ocular, i.e. the eye)
...