ISO/IEC TS 19763-13:2016

TECHNICAL ISO/IEC TS
SPECIFICATION 19763-13
First edition
2016-12-01
Information technology —
Metamodel framework for
interoperability (MFI) —
Part 13:
Metamodel for form design
registration
Technologies de l’information — Cadre du métamodèle pour
l’interopérabilité (MFI) —
Partie 13: Métamodèle pour l’enregistrement de la conception des
formulaires
Reference number
©
ISO/IEC 2016
© ISO/IEC 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/IEC 2016 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 3
4 Conformance . 3
4.1 General . 3
4.2 Degrees of conformance . 3
4.2.1 General. 3
4.2.2 Strictly conforming implementation . 3
4.2.3 Conforming implementation . 4
4.2.4 Implementation Conformance Statement (ICS) . 4
5 Structure of MFI form design registration . 4
5.1 Overview of MFI form design registration . 4
5.2 Relationship of metaclasses to the MDR Metamodel . 7
5.3 Details provided in each metaclass definition . 7
5.4 Basic Types and Enumerations in MFI form design registration . 8
5.4.1 General. 8
5.4.2 Property . . . 9
5.4.3 Question_Element_Property . 9
5.4.4 Target_Element_State . . 9
5.4.5 Operation_Type .10
5.5 Metaclasses in MFI for form design registration .11
5.5.1 Form_Design .11
5.5.2 Form_Design_Language .11
5.5.3 Form_Design_Template .11
5.5.4 Form_Design_Element .11
5.5.5 Presentation_Element .12
5.5.6 Section_Element .13
5.5.7 Media_Element .14
5.5.8 Text_Element .14
5.5.9 Localised_Text .15
5.5.10 Question_Element .16
5.5.11 Response .17
5.5.12 Attachment .18
5.5.13 Text_Field.18
5.5.14 Lookup_Field .18
5.5.15 List_Field .19
5.5.16 List_Item .20
5.5.17 List_Item_Selected_State .21
5.5.18 Rule .21
5.5.19 Constant.22
5.5.20 Expression .22
5.5.21 Variable .23
5.5.22 Operation .23
5.5.23 Reference_Document .24
5.5.24 Datatype .24
5.5.25 Unit_Of_Measure .25
Annex A (normative) MDR Mapping Package.26
Annex B (informative) Description of the metamodel .31
© ISO/IEC 2016 – All rights reserved iii

Annex C (informative) Relationship of metaclasses to the MDR Metamodel .37
Annex D (informative) Example form designs .40
Annex E (informative) Mapping between this document and CDISC ODM .44
Bibliography .47
iv © ISO/IEC 2016 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
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 World Trade Organization (WTO) principles in the
Technical Barriers to Trade (TBT) see the following URL: www.iso.org/iso/foreword.html.
The committee responsible for this document is ISO/IEC JTC 1, Information Technology, Subcommittee
SC 32, Data management and interchange.
A list of all parts in the ISO/IEC 19763 series can be found on the ISO website.
© ISO/IEC 2016 – All rights reserved v

Introduction
There is an increasing demand for systems to interoperate by exchanging data, and for data to be
reused outside of the original context of its collection. For data exchange or reuses to be meaningful,
the business information requirements that are met by the data stored in these systems must be
understood so that suitable data exchange mechanisms can be developed and interpretation of the data
is reliable.
Not only does this require a clear understanding of the meaning of the data, it also frequently requires
the coordination of data capture. Where data input is manual, the definitive source of data semantics
is the design of the data entry form. Indeed if we do not understand the encoding of knowledge in the
database schema or we suspect some anomaly in the data captured, we inspect the original form and
the context of its use. Furthermore, if we wish to gather interoperable data, it is frequently necessary
to harmonize aspects of form design before information systems are developed and data is captured.
However, there is no abstract, universal metamodel for form designs that supports the registration
and comparison or harmonization of form designs and faithful implementation of these designs in
information systems. This is the intent of this document.
The Oxford English dictionary defines a form as “a formulary document with blanks for the insertion
of particulars”. Other ISO definitions of a form include ISO 5127, “document (printed or otherwise
produced), with pre-designated spaces for the recording of specific information”, and ISO 9241-143,
“structured display of fields and other user-interface elements that the user reads, fills in, selects entries
for (e.g. through check boxes or radio buttons) or modifies”. While we recognize these definitions, none
precisely matches the needs of this document. Thus, we will define a form as a structured collection
of spaces, suitable instructions and rules that support the collection of specific information that may
be subsequently compared and processed in a routine fashion. A form design is thus a description of a
particular form such that it may be rendered in any suitable information system, and the metamodel for
registration of form designs contained within this document describes the attributes that are necessary
to represent the semantics and syntax of form designs.
Given a standard metamodel for the registration of form designs, ISO/IEC 19763 Metamodel
framework for interoperability (MFI) and ISO/IEC 11179 Metamodel for metadata registries provide
important facilities for the creation and annotation of form designs. ISO/IEC 19763 supports the
registration of form designs and section elements as models and model elements, provides facilities
to record associations between the components of two or more form design, particularly derivation,
specialization, extension and reuse, and allows the association of form designs with the data models
that are used to store data captured by their instances. ISO/IEC 11179 provides classes and types that
support the identification, naming, registration and administration of form designs and supporting
documents, and provides a model either for an associated, standardized question bank or a rich source
of question-level metadata attributes with which to explain the meaning of individual data items. When
used together, the International Standards can support the rapid design and reuse of form designs,
wrap and hide the complexity of semantic annotation from subject matter experts, and provide a ready
reference of associations and transformations for users seeking to collect and use interoperable data.
This document does not supplant or replace computer languages such as XForms, Windows Forms,
Adobe Forms or relevant parts of HTML, which describe how a form design is implemented, and is
deliberately devoid of domain or content specific semantics to ensure wide applicability. However,
given the universal applicability of forms, it should be of no surprise that elements of the model can be
recognized in many forms standards. Some of these have been mapped to this document in Annex A to
Annex E.
Forms may be printed on paper, or encoded in electronic format. Electronic forms may be rendered
natively in standard formats such as HTML, XForms or PDF, or propriety ones such as Windows forms,
Cocoa or Java Swing. They may also be implemented in a common survey framework such as Survey
Monkey or Lime Survey. Despite this diversity, it is eminently possible to create forms in different
formats that support the same comparisons and downstream processing provided the spaces and
instructions share the same semantic intent. Such a collection of forms could be said to share the same
design. A model that is adequate to record these form designs is the subject of this document.
vi © ISO/IEC 2016 – All rights reserved

TECHNICAL SPECIFICATION ISO/IEC TS 19763-13:2016(E)
Information technology — Metamodel framework for
interoperability (MFI) —
Part 13:
Metamodel for form design registration
1 Scope
The primary purpose of the ISO/IEC 19763 series is to specify a metamodel framework for
interoperability. This document specifies a metamodel for registering form designs.
This document provides a metamodel to describe the structure and semantics of an implemented
form devoid of any specific, domain semantics, e.g. in healthcare, social science, e-government and
e-business, or representation format so that data may be faithfully exchanged between systems and
system components, and associations expressed between sets of form designs whose data may be
compared, joined or composed for analysis.
2 Normative references
There are no normative references in this document.
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19763-1, ISO/IEC 19763-
10, ISO/IEC 11179-3 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
3.1.1
attachment
digital object that is required as a response (3.1.15) to a question (3.1.14) on a form (3.1.9)
Note 1 to entry: Used to indicate that the response to a question includes a file on an accessible file-system that
will be loaded when the form transaction is complete.
3.1.2
combinator
operator that joins two constraints (3.1.6) (to make a binary constraint) returning a result based
upon both
EXAMPLE Conjunction, disjunction, implication.
3.1.3
compliance rule
specification for some aspect of a form design (3.1.10) that shall be satisfied for that
design to be a correct implementation of a form template (3.1.11)
© ISO/IEC 2016 – All rights reserved 1

3.1.4
completed form
form (3.1.9) for which responses (3.1.15) have been completed as required according to its instructions
(3.1.12) and rules (3.1.16)
3.1.5
consequence
expression (3.1.7) that sets or specifies some property of an element of a form design (3.1.10) when its
related constraint (3.1.6) evaluates to true
3.1.6
constraint
expression (3.1.7) about form design (3.1.10) elements that evaluates to a
Boolean value
3.1.7
expression
statement that evaluates to a string or numeric value
3.1.8
field
space on a form (3.1.9) for the recording of a response (3.1.15)
3.1.9
form
document or human interface comprising a structured collection of fields (3.1.8), suitable instructions
(3.1.12) and rules (3.1.16) that support the collection of specific information that may be subsequently
compared and processed in a routine fashion
3.1.10
form design
specification for the creation of equivalent forms (3.1.9) in different languages, applications and media
3.1.11
form template
partial form design (3.1.10) that establishes a pattern for the creation of other form designs
Note 1 to entry: A form template will often have empty or incomplete form sections with instructions describing
what kind of questions are required to create a completed design.
3.1.12
instruction
sentence that directs a person in some aspect of the completion or submission of a form (3.1.9)
3.1.13
owl:sameAs
property of the Web Ontology Language that indicates that individuals in an OWL DL ontology refer to
the same thing, or in OWL Full to additionally indicate that two classes are equal
Note 1 to entry: See http://www.w3.org/TR/owl-ref/#sameAs-def.
3.1.14
question
sentence worded or expressed so as to elicit information from a person
3.1.15
response
information elicited from a person by a question (3.1.14)
2 © ISO/IEC 2016 – All rights reserved

3.1.16
rule
principle guiding the behaviour of some aspect of a form (3.1.9)
3.1.17
section
subcomponent of a form (3.1.9) whose contained questions (3.1.14), instructions (3.1.12) and rules
(3.1.16) share a common purpose, meaning or context
3.1.18
skos:related
semantic relation asserting that the object of the labelled relationship is related to the subject
Note 1 to entry: See http://www.w3.org/TR/skos-reference.
3.2 Abbreviated terms
MFI Core and mapping
ISO/IEC 19763-10, Information technology — Metamodel framework for interoperability (MFI) —
Part 10: Core model and basic mapping
MDR Metamodel
ISO/IEC 11179-3, Information technology — Metadata registries (MDR) — Part 3: Registry metamodel
and basic attributes
MFI Form design registration
Information technology — Metamodel framework for interoperability (MFI) — Part 13: Metamodel for
form design registration
4 Conformance
4.1 General
An implementation claiming conformance with this document shall support the metamodel specified in
Clause 5, depending on a degree of conformance as described below.
4.2 Degrees of conformance
4.2.1 General
The distinction between “strictly conforming” and “conforming” implementations is necessary
to address the simultaneous needs for interoperability and extensions. This document describes
specifications that promote interoperability. Extensions are motivated by needs of users, vendors,
institutions and industries, but are not specified by this document.
A strictly conforming implementation may be limited in usefulness but is maximally interoperable
with respect to this document. A conforming implementation may be more useful, but may be less
interoperable with respect to this document.
4.2.2 Strictly conforming implementation
A strictly conforming implementation
a) shall support the metamodel specified in Clause 5, and
b) shall not support any extensions to the metamodel specified in Clause 5.
© ISO/IEC 2016 – All rights reserved 3

4.2.3 Conforming implementation
A conforming implementation
a) shall support the metamodel specified in Clause 5, and
b) may support extensions to the metamodel specified in Clause 5 that are consistent with the
metamodel and the MDR mapping package in Clause 5.
4.2.4 Implementation Conformance Statement (ICS)
An implementation claiming conformance with this document shall include an Implementation
Conformance Statement stating
a) whether it is a strictly conforming implementation or a conforming implementation (see 4.2.2), and
b) what extensions are supported if it is a conforming implementation (see 4.2.3).
Conformance statements for systems that implement this document shall additionally describe the
languages used to convey Rules, and the relationship types available for the Mapping_Relation class.
5 Structure of MFI form design registration
5.1 Overview of MFI form design registration
Figure 1 shows the metamodel for the registration of form designs.
4 © ISO/IEC 2016 – All rights reserved

Figure 1 — Form design metamodel
Forms have questions and sections that are constrained or unavailable for completion dependent upon
the answers given to earlier questions. Figure 2 is a model for the rule language used to describe such
dependencies between form elements: textual expressions in this language are used to complete the
rule attribute of the Form_Design_Element class.
© ISO/IEC 2016 – All rights reserved 5

Figure 2 — Rule
6 © ISO/IEC 2016 – All rights reserved

The metamodel for information model registration comprises the following metaclasses:
Attachment_Field Media_Element
Constant Operation
Datatype Presentation_Element
Expression Question_Element
Form_Design Response
Form_Design_Element Reference_Document
Form_Design_Template Rule
Form_Design_Language Section_Element
List_Field Text_Element
List_Item Text_Field
List_Item_Selected_State Variable
Localised_Text Unit_of_Measure
Lookup_Field
The purpose and use of the metamodel is described in detail in Annex A. Detailed specifications of the
metaclasses are provided in Annex B.
5.2 Relationship of metaclasses to the MDR Metamodel
As explained in ISO/IEC 19763-10, instances of the metaclasses defined in this subclause may be
extended by the types defined in the MDR Metamodel as follows.
— Form_Design may be extended as an Identified_Item, Designatable_Item, Registered_Item,
Administered_Item and Classifiable_Item.
— Form_Design_Element may be extended as an Identified_Item, Designatable_Item and
Classifiable_Item.
— Any instance of a Form_Design_Element may be mapped to an instance of a Concept.
— Any instance of a Question_Element may be mapped to an instance of a Data_Element.
— List_Item may be extended as an Identified_Item; any instance of which may be mapped to a
Concept and/or Permissible_Value.
— Rule may be extended as an Identified_Item and Designatable_Item.
5.3 Details provided in each metaclass definition
For each metaclass, the following details are shown:
— a definition that describes the role or significance of instances of the metaclass;
— the name of its immediate supertype;
— any alternative names (synonyms or aliases) for the metaclass;
© ISO/IEC 2016 – All rights reserved 7

— a list of attributes;
— a list of references.
For each attribute, the following details are shown:
a) the name of the attribute; where the attribute is one that is provided by the type defined in the
MDR metamodel by which when instances of the metaclass are extended, the name is italicized;
b) the datatype for values of the attribute;
c) the multiplicity of the attribute;
d) a description that describes the role or significance of values of the attribute.
For each reference, the following details are shown:
— the name of the reference; this is the role name that describes the role played by the referenced
metaclass with respect to the association identified by this reference;
— the name of the referenced metaclass;
— the multiplicity of the reference;
— a description that describes the role or significance of the instance, or instances, of the referenced
metaclass with respect to an instance of this metaclass;
— the name of the reference in the referenced metaclass that provides the inverse definition for the
association;
— an indication as to whether this metaclass is responsible for the maintenance of the association, i.e.
the precedence of the metaclass with respect to the association.
5.4 Basic Types and Enumerations in MFI form design registration
5.4.1 General
Basic Types specify common datatypes for use in the metaclasses. A datatype is a set of distinct values,
characterized by properties of those values and by operations on those values (see ISO/IEC 11404). The
datatypes used in the specification of the metaclasses (see 5.5) are restricted to Boolean, Integer, Date,
Value, Sign, Postal_Address, String, Natural_Range, Datetime, String, Notation and Phone_Number
(MDR Metamodel 6.2.1 Overview of Basic Types). The types used in the metaclasses are based on this
core set of types, with a single addition of the type Binary Large Object (BLOB), and any compliant
implementation of a metadata registry should include an implementation of the semantics specified in
these core types.
NOTE These datatypes are used in specification of the metaclass attributes themselves, and are not intended
to constrain the datatypes that may be used in specifying Response datatypes.
Enumerations specify the list of value for use with metaclass attributes.
For each enumeration, the following details are shown:
— the name of the referenced enumeration;
— a description of the enumeration;
— the datatype of the values in the enumeration;
— the name of each value in the enumeration;
— a description of the semantics of each enumeration value;
8 © ISO/IEC 2016 – All rights reserved

— the name of the metaclass where this enumeration is used;
— the name of the attribute where this enumeration is used.
5.4.2 Property
Property is an enumeration of values listing properties of a Presentation_Element, Section_Element,
Question_Element or a List_Item that may be addressed by a Rule (see Figure 2).
Datatype
String
Value Description
read_only Indicates that the Form_Design_Element read_only property is to be tested or set
as part of an Expression in a Rule
available Indicates that the Form_Design_Element available property is to be tested or set as
part of an Expression in a Rule
The state of the available property may also be set by a List_Item that has a depend-
ent_element association with the respective Form_Design_Element.
style Indicates that a Form_Design_Element style property is to be tested or set as part
of an Expression in a Rule
visible Indicates that a Form_Design_Element’s visibility to the user interacting with the
form is to be tested or set as part of an Expression in a Rule
5.4.3 Question_Element_Property
Question_Element_Property is an enumeration of values listing additional properties of a Question_
Element that may be addressed in a Rule (see Figure 2).
Supertype
Property
Datatype
String
Value Description
default_value Indicates that the Question_Element default_value property is to be tested or set as
part of an Expression in a Rule
value Indicates that the Question_Element value property is to be tested or set as part of
an Expression in a Rule
5.4.4 Target_Element_State
Target_Element_State is an enumeration of values listing the possible states that a dependent Form_
Design_Element may take when a List_Item is selected.
Datatype
String
© ISO/IEC 2016 – All rights reserved 9

Value Description
revealed Indicates that the dependent Form_Design_Element should be visible or available
for input when the List_Item is selected
hidden Indicates that the dependent Form_Design_Element should be hidden or unavaila-
ble for input when the List_Item is selected
5.4.5 Operation_Type
Operation_Type is an enumeration of values describing the operation between two items in an Expres-
sion (see Figure 2).
Datatype
String
Value Description
plus Indicates the mathematical addition operation between the two items in the
Expression
minus Indicates the mathematical subtraction operation between the two items in the
Expression
times Indicates the mathematical multiplication operation between the two items in the
Expression
div Indicates the mathematical division operation between the two items in the
Expression
or Indicates a logical “or” between the two items in the Expression
and Indicates a logical “and” between the two items in the Expression
not Indicates a logical “not” between the two items in the Expression
nor Indicates a logical “nor” between the two items in the Expression
greater_than Indicates the mathematical “greater-than” operation between the two items in the
Expression
less_than Indicates the mathematical “less-than” operation between the two items in the
Expression
greater_than_or_ Indicates the mathematical “greater-than or equal-to” operation between the two
equal_to items in the Expression
less_than_or_ Indicates the mathematical “less-than or equal-to” operation between the two items
equal_to in the Expression
equal_to Indicates the mathematical “equals” operation between the two items in the
Expression
not_equal_to Indicates the mathematical “not equal to” operation between the two items in the
Expression
mod Indicates the mathematical modulo operation between the two items in the
Expression
10 © ISO/IEC 2016 – All rights reserved

in Indicates an operation between two items in the Expression where one item is a list.
It evaluates to “true” if the item is one of the enumerations. For example, an expres-
sion “condition person.ecog IN (0,1,2) consequence person.eligible-for-trial = true”
would set the person.eligible-for-trial question to “true” if the value entered for the
person.ecog question is 0, 1 or 2.
con Indicates the programmatic “string concatenation” operation between the two items
in the Expression
exp Indicates the programmatic “exponent” operation between the two items in the
Expression
5.5 Metaclasses in MFI for form design registration
5.5.1 Form_Design
Form_Design is a metaclass, each instance of which represents the design of a specific form, which is
formulary document with blanks for the insertion of particulars (see Figure 1).
5.5.2 Form_Design_Language
Form_Design_Language is a metaclass, each instance of which represents the selection of languages
used to express aspects of the design of the associated Form_Design (see Figure 1).
5.5.3 Form_Design_Template
Form_Design_Template is a metaclass, each instance of which represents a specific form template
which is a partially complete form design intended to guide the creation of similar form designs (see
Figure 1).
Superclass
Form_Design
Attribute Datatype Multiplicity Description
implementation_ String 0.* An optional instruction describing how to
instruction instantiate a valid Form_Design instance from
this Form_Design_Template instance
5.5.4 Form_Design_Element
Form_Design_Element is an abstract metaclass, each instance of which represents some component
of an instance of the class Form_Design (see Figure 1).
SuperClass
Model_Element (defined in MFI Core and mapping)
© ISO/IEC 2016 – All rights reserved 11

Attribute DataType Multiplicity Description
style String 0.* An optional set of statements in some style
language about this element and its contained
elements that declares layout properties such as
emphasis, colour, font size, typeface, line-style
and position where the maximum multiplicity is
unbounded
rule Rule 0.* A set of expressions that describe functional
dependencies and constraints upon data entry
relevant to the semantics of the completed form
Reference Class Multiplicity Description Inverse Precedence
contained_ Section_Element 0.* The optional set contained_ yes
section of Section_Ele- element
ment instances
contained by this
instance of Form_
Design_Element
where the maxi-
mum multiplicity is
unbounded
containing_form Form_Design 0.* The instance of contained_ no
Form_Design element
within which this
Form_Design_El-
ement instance is
contained where
the maximum
multiplicity is un-
bounded
NOTE It is not intended that a Question_Element can contain a Section_Element, although some
Presentation_Element instances could, e.g. a box. It is preferred to add a stylesheet reference to the section to
include a box around contained elements.
5.5.5 Presentation_Element
Presentation_Element is an abstract metaclass, each instance of which is a presentation component
of the form, for example some image, box, line or text (see Figure 1).
Presentation element instances should have no notable semantic context unless they are explicitly
linked to a Section_Element, Question_Element, Response or List_Item instance.
A Text_Element instance may be associated with a Question_Element instance so as to make it the
Prompt for a question on the form, or a Media_Element instance may be associated with some seman-
tic Text_Element instance as a representation of the concept that Text_Element instance conveys.
Superclass
Form_Design_Element
12 © ISO/IEC 2016 – All rights reserved

5.5.6 Section_Element
Section_Element is a metaclass, each instance of which is a section of an instance of the class Form_
Design that describes a structural association between a set of Form_Design_Element instances (see
Figure 1).
Superclass
Form_Design_Element
Attribute DataType Multiplicity Description
ordered Boolean 1.1 A flag that indicates if the order of child Form_
Design_Element instances is semantically signif-
icant where the maximum multiplicity is one.
NOTE  There are no requirements for a
specific implementation of ordering in a con-
formant system. Implementers are free to use
the natural capabilities of their implementation
environment to support ordering.
Section_title_text Text_Element 0.1 An optional attribute that declares a particular
Text_Element as the section title where the
maximum multiplicity is one
section_ Text_Element 0.* An optional association that declares a particular
instruction_text Text_Element as a section_instruction with a
maximum multiplicity of unbounded
section_label_ Text_Element 0.1 An optional attribute that specifies a sequence
text label for this section with a maximum
multiplicity of one
maximum_ String 1.1 A mandatory attribute specifying the maximum
cardinality number of repetitions of this Section_Element
instance that are allowed on the completed form
that this Form_Design instance describes
minimum_ String 1.1 A mandatory attribute specifying the minimum
cardinality number of repetitions of this Section_Element
instance that are allowed on the completed form
that this Form_Design instance describes
Reference Class Multiplicity Description Inverse Precedence
contained_ Form_Design_ 0.* The optional set of contained_ yes
element Element Form_Design_El- section
ement instances
contained by this
Section_Element
instance where the
maximum multi-
plicity is unbound-
ed
© ISO/IEC 2016 – All rights reserved 13

5.5.7 Media_Element
Media_Element is a metaclass, each instance of which represents some image, audio or video element
presented within a form (see Figure 1).
Superclass
Form_Design_Element
Attribute DataType Multiplicity Description
resource BLOB 1.1 A mandatory attribute containing the media file
that is to be displayed on the form with a maxi-
mum multiplicity of one
type String 1.1 A mandatory attribute conveying the mime-type
of the media file that is to be displayed with a
maximum multiplicity of one
Reference Class Multiplicity Description Inverse Precedence
meaning Text_Element 0.* An optional representation yes
association to a par-
ticular instance of a
Text_Element that
describes the mean-
ing of the media
element with a max-
imum multiplicity of
unbounded
5.5.8 Text_Element
Text_Element is a metaclass, each instance of which is a textual presentation element of a form
intended to instruct or explain to the user of the form what the data should mean, how it should be
completed and any actions that should be taken with the completed form (see Figure 1).
Superclass
Presentation_Element
14 © ISO/IEC 2016 – All rights reserved

Reference Class Multiplicity Description Inverse Precedence
localised_text Localised_Text 1.* A mandatory containing_ yes
association to an text
instance of a
Localised_Text class
which contains the
displayed text to-
gether with the natu-
ral, human language
of that text where the
maximum multiplici-
ty is unbounded
representation Media_Element 0.* An optional meaning no
association to a
Media_Element for
representation of a
particular Text_El-
ement where the
maximum multiplici-
ty is unbounded
5.5.9 Localised_Text
Localised_Text is a metaclass, each instance of which represents a pairing of a text string to be
displayed to the user of the form and its human language designator. Localised_Text provides the
capability to register a set of semantically identical forms, and forms that display multiple human lan-
guages in a singular item (see Figure 1).
Attribute DataType Multiplicity Description
text String 1.1 The text string itself
language String 0.* A language designation in ISO 639-3 which
identifies the language of the associated text entry
This attribute may be omitted if the form is
mono-lingual and either the language is declared
using the textual_language attribute of the Form_
Design_Language class (see 5.5.2), or if the lan-
guage of the form is the primary language of the
registry (see MDR Metamodel 8.1.2.9.2.7).
NOTE  Some, mainly paper, forms are
multilingual by having alternate languages in
the same question and thus may require multiple
language identifiers, e.g. “Q1. Surname/Nom de
famille/Familien-oder Nachname” …
Reference Class Multiplicity Description Inverse Precedence
containing_text Text_Element 1.1 A mandatory localised_text no
association to the
containing Text_Ele-
ment instance
© ISO/IEC 2016 – All rights reserved 15

5.5.10 Question_Element
Question_Element is a metaclass, each instance of which represents a question in a Form_Design
instance (see Figure 1).
Question_Element instances and the values of their attributes may be associated or sourced from a
related MDR Metamodel Data_Element instance.
Superclass
Form_Design_Element
Attribute DataType Multiplicity Description
question_label Text_Element 0.1 An optional attribute, each instance represents
the label or number of this question instance with
a maximum multiplicity of one.
NOTE 1  An attribute of either question_label or
question_pr
...