ISO/IEC 19763-13:2026

• Abstract:

  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 can be faithfully exchanged between systems and system components, and associations expressed between sets of form designs whose data can be compared, joined or composed for analysis.

• Status: Published
• Publication Date: 26-Jul-2026
• ICS: 35.040.50 - Automatic identification and data capture techniques
• Technical Committee: ISO/IEC JTC 1/SC 32 - Data management and interchange
• Drafting Committee: ISO/IEC JTC 1/SC 32 - Data management and interchange
• Current Stage: 6060 - International Standard published
• Start Date: 27-Jul-2026
• Due Date: 04-Apr-2026
• Completion Date: 27-Jul-2026

• Revises: ISO/IEC TS 19763-13:2016 - Information technology — Metamodel framework for interoperability (MFI) — Part 13: Metamodel for form design registration
• Effective Date: 07-Jul-2022

Overview

ISO/IEC 19763-13:2026 defines a standardized metamodel for form design registration, supporting interoperability in information technology by providing a structured and abstract way to describe the structure and semantics of forms. This International Standard is part of the ISO/IEC 19763 Metamodel Framework for Interoperability (MFI) series and focuses on enabling reliable data exchange and harmonization between diverse systems.

This metamodel is designed to be independent of any application domain (such as healthcare, e-government, or e-business) and is agnostic to representation formats (e.g., paper, HTML, XForms, PDF, proprietary systems). By abstracting form designs from specific semantics and technologies, ISO/IEC 19763-13 enables stakeholders to register, compare, and compose form designs, promoting seamless data integration and interoperability across platforms.

Key Topics

• Metamodel Structure: The core of ISO/IEC 19763-13 is a set of standardized classes (metaclasses) for expressing form components, rules, templates, and responses, independent of business domain or technical implementation.
• Form Design Registration: Outlines how form designs and their components can be registered, identified, named, classified, and linked within metadata registries.
• Neutral Semantics: Provides a form-agnostic description that does not enforce domain-specific semantics, ensuring wide applicability.
• Conformance Levels: Describes requirements for both strictly conforming implementations (maximal interoperability) and conforming implementations (supporting potential extensions).
• Association and Mapping: Supports expressing associations between different sets of form designs, enabling data comparability and analytical composition.
• Integration with Metadata Registries: The metamodel links to the ISO/IEC 11179 Metadata Registry standards, ensuring a robust framework for metadata management.
• Support for Reuse and Comparison: Enables harmonizing form designs and supports reusability across different domains and systems.

Applications

The adoption of ISO/IEC 19763-13:2026 has significant benefits for organizations and solution providers aiming to achieve data interoperability and consistency across various platforms. Practical applications include:

• Cross-Domain Data Collection: Facilitates the standardized creation, registration, and management of electronic or physical forms in healthcare, research, public sector, and commercial applications.
• Interoperable Survey Tools: Enables survey and data collection tools to translate, compare, and reuse form components across systems and languages.
• Metadata Registries: Integrates with metadata management systems to provide comprehensive governance over form design elements, supporting both operational and analytical needs.
• Legacy System Integration: Abstracts form design away from specific technologies, supporting migration, modernization, or integration of legacy form-based applications.
• Automated Data Exchange: Supports seamless data transfer between heterogeneous systems by preserving the intent and structure of captured data.
• Form Template Repositories: Supports the creation and management of reusable form templates, enabling efficient deployment and adaptation in various contexts.

Related Standards

ISO/IEC 19763-13:2026 forms part of a broader interoperability ecosystem. Important related standards include:

• ISO/IEC 19763-10:2023 - MFI Core Model and Basic Mapping: Establishes foundational metamodel constructs used in this part.
• ISO/IEC 11179-3:2023 - Metadata Registries (MDR): Provides the metamodel for registering and administering metadata, including relationships critical to form design registration.
• ISO/IEC 11179-3:2023/Amd1 - Enhancements to Item Mapping: Adds advanced mapping capabilities relevant to form data elements.
• ISO/IEC 19763-1:2023 - MFI Framework: Presents the overall architecture and principles for the Metamodel Framework for Interoperability.
• ISO/IEC 11179-31:2023 - Data Specification Registration: Extends registry capabilities to detailed data specifications.

Conclusion

Implementing ISO/IEC 19763-13:2026 delivers practical value for organizations seeking to standardize and interoperate form-based data collection systems. By providing a robust, technology-neutral metamodel for form design registration, it enables seamless data exchange, flexible reuse, and the foundation for interoperable information systems across every sector. For those building, administering, or modernizing metadata registries and form-driven applications, this standard is essential for achieving future-ready interoperability.

International
Standard
ISO/IEC 19763-13
First edition
Information technology —
2026-07
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 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
Contents Page
Foreword .v
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
3.1 General terms .1
3.2 Terms related to form structure .2
3.3 Terms related to form behaviour .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 .8
5.4 Basic Datatypes 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_Form_Design_Element_State .10
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_Language . 13
5.5.3 Form_Design_Hierarchy_Constraint .14
5.5.4 Form_Design_Element . .14
5.5.5 Form_Design_Template . 15
5.5.6 Presentation_Element .16
5.5.7 Section_Element . .16
5.5.8 Media_Element .17
5.5.9 Text_Element .18
5.5.10 Localised_Text .19
5.5.11 Question_Element. 20
5.5.12 Response_Field .21
5.5.13 Attachment_Response_Field . 23
5.5.14 Text_Response_Field . 23
5.5.15 Lookup_Response_Field . .24
5.5.16 List_Response_Field . 25
5.5.17 List_Response_Field_Item . 26
5.5.18 List_Response_Field_Item_Selected_State.27
5.5.19 Media_Annotation_Response_Field . 28
5.5.20 Rule . 28
5.5.21 Expression . 29
5.5.22 Constant . 30
5.5.23 Variable . 30
5.5.24 Operation .31
5.5.25 Datatype.32
5.5.26 Unit_Of_Measure . 33
Annex A (informative) Description of the metamodel .34

© ISO/IEC 2026 – All rights reserved
iii
Annex B (normative) Relationship of metaclasses to the MDR Metamodel .40
Annex C (informative) Example form designs .43
Annex D (informative) Mapping between this document and CDISC ODM .54
Bibliography .56

© ISO/IEC 2026 – All rights reserved
iv
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.
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 document 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 or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, 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 www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 32, Data management and interchange.
This first edition of ISO/IEC 19763-13 cancels and replaces ISO/IEC TS 19763-13:2016, which has been
technically revised.
The main changes are as follows:
— Formal association between ISO/IEC 19763-10:2023 and ISO/IEC 11179-3:2023 requires that Form_
Design and Form_Design_Element instances are identified.
— An association class has been created - Form_Design_Hierarchy_Constraint - to allow form definitions to
be composed directly from other form definitions.
— A new response type - Media_Annotation_Response_Field - describing metadata about media annotation
fields makes it easier to describe these structures.
— Response class names have received minor edits to make the sub-type hierarchy more clear.
— Order number attributes have been added to Form_Design_Element to make explicit the item order in
ordered Section and Form instances.
— Annex A has been removed, having become a part of ISO/IEC 11179.
Future revisions of this edition will replace the rule model, and definitions of the classes Datatype, and Unit_
of_Measure with those specified in ISO/IEC 11179-3:2023 and ISO/IEC 11179-3:2023/Amd1.
Conformant ISO/IEC TS 19763-13:2016 Form Designs will also conform to this revision if Form_Design and
Form_Design_Element instances are identified and the designs are unordered, but ordered designs will
require the generation of an explicit ordinal number for the place of ordered elements in their sequence. It

© ISO/IEC 2026 – All rights reserved
v
is recommended that registrars transform designs that require media annotation to use the new response
kind.
A list of all parts in the ISO/IEC 19763 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2026 – All rights reserved
vi
Introduction
0.1 General
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 reuse 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 the encoding of knowledge in the database schema is not understood,
or if some anomaly in the data captured is suspected, the original form design and the context of its use
frequently provide answers. Furthermore, in order 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, 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
[1]
particulars”. Other ISO definitions of a form include ISO 5127 , “document (printed or otherwise produced),
[2]
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”. These definitions are recognisable, but do not precisely match the
needs of this document. Thus, a form is defined as a structured collection of spaces, suitable instructions and
rules that support the collection of specific information that can be subsequently compared and processed
in a routine fashion. A form design is thus a description of a particular form such that it can 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.
Form designs can be implemented on paper, or encoded in electronic format. Electronic forms can be
rendered natively in standard formats such as HTML, XForms or PDF, or proprietary ones such as Windows
forms, Cocoa or Java Swing. They can 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 can be said to share the same design. A model that is
adequate to record these form designs is the subject of this document.
The primary purpose of the ISO/IEC 19763 series is to specify a metamodel framework for interoperability.
Given a standard metamodel for the registration of form designs, ISO/IEC 19763-10:2023 and
ISO/IEC 11179-3:2023 provide important facilities for the creation and annotation of form designs.
ISO/IEC 19763-10:2023 supports the registration of form designs and section elements as models and
model elements, and allows the association of form designs with the data models that are used to store data
captured by their instances. ISO/IEC 11179-3:2023 provides classes and types that support the identification,
naming, classification, registration, completion logic and administration of form designs and supporting
documents, provides facilities to record associations between the components of two or more form designs,
particularly derivation, specialization, extension and reuse, 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, these International Standards 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 D.

© ISO/IEC 2026 – All rights reserved
vii
0.2 Key standards
Throughout this document, the key standards are referred to in the following short form to aid readability.
MFI Core: ISO/IEC 19763-10:2023, Information technology — Metamodel framework for interoperability
(MFI) — Part 10: Core model and basic mapping
MDR Metamodel: ISO/IEC 11179-3:2023, Information technology — Metadata registries (MDR) — Part 3:
Metamodel for registry common facilities
MFI Form Design Registration: ISO/IEC 19763-13:2026, Information technology — Metamodel framework
for interoperability (MFI) — Part 13: Metamodel for form design registration
MDR Mapping: ISO/IEC 11179-3:2023/Amd1, Information technology — Metadata registries (MDR) - Part
3: Metamodel for registry common facilities, Amendment 1: Enhancements to Item Mapping, clause 11
MDR Data Definition: ISO/IEC 11179-31:2023, Information technology — Metadata registries (MDR) —
Part 31: Metamodel for data specification registration

© ISO/IEC 2026 – All rights reserved
viii
International Standard ISO/IEC 19763-13:2026(en)
Information technology — Metamodel framework for
interoperability (MFI) —
Part 13:
Metamodel for form design registration
1 Scope
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 can be faithfully exchanged between systems and system components,
and associations expressed between sets of form designs whose data can be compared, joined or composed
for analysis.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 11179-3:2023, Information technology — Metadata registries (MDR) — Part 3: Metamodel for registry
common facilities
ISO/IEC 11179-3:2023/Amd 1, Information technology — Metadata registries (MDR) — Part 3: Metamodel for
registry common facilities Amendment 1: Enhancements to Item Mapping
ISO/IEC 19763-1:2023, Information technology — Metamodel framework for interoperability (MFI) — Part 1:
Framework
ISO/IEC 19763-10:2023, Information technology — Metamodel framework for interoperability (MFI) — Part
10: Core model and basic mapping
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19763-1:2023,
ISO/IEC 19763-10:2023, ISO/IEC 11179-3:2023 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1 General terms
3.1.1
owl: s a me A s
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.

© ISO/IEC 2026 – All rights reserved
3.1.2
s ko s : r el at e d
semantic relation asserting that the object of the labelled relationship is related to the subject
Note 1 to entry: See https:// www .w3 .org/ TR/ skos -reference.
3.2 Terms related to form structure
3.2.1
field
space on a form (3.2.2) for the recording of a response (3.2.7)
3.2.2
form
document or human interface comprising a structured collection of fields (3.2.1), suitable instructions (3.2.6)
and rules (3.3.6) that support the collection of specific information that can be subsequently compared and
processed in a routine fashion
3.2.3
form design
specification for the creation of equivalent forms (3.2.2) in different languages, applications and media
3.2.4
form template
partial form design (3.2.3) 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 (3.2.2) sections with instructions describing
what kind of questions are required to create a completed design.
3.2.5
question
sentence worded or expressed so as to elicit information from a person
3.2.6
instruction
sentence that directs a person in some aspect of the completion or submission of a form (3.2.2)
3.2.7
response
information elicited from a person by a question (3.2.5)
3.2.8
section
subcomponent of a form (3.2.2) whose contained questions (3.2.5), instructions (3.2.6) and rules (3.3.6) share
a common purpose, meaning or context
3.2.9
attachment
digital object that is required as a response (3.2.7) to a question (3.2.5) on a form (3.2.2)
Note 1 to entry: Used to indicate that the response (3.2.7) to a question (3.2.5) includes a file on an accessible file-
system that will be loaded when the form (3.2.2) transaction is complete.
3.2.10
completed form
form (3.2.2) for which all response (3.2.7) elements have been completed as required according to its
instructions (3.2.6) and rules (3.3.6)

© ISO/IEC 2026 – All rights reserved
3.3 Terms related to form behaviour
3.3.1
expression
statement that evaluates to a string or numeric value
3.3.2
compliance rule
specification for some aspect of a form design (3.2.3) that is required to be satisfied for that design to be a
correct use of a reusable component
3.3.3
constraint
expression (3.3.1) about form design (3.2.3) elements that evaluates to a Boolean value
3.3.4
combinator
operator that joins two constraints (3.3.3) (to make a binary constraint) returning a result based upon both
EXAMPLE Conjunction, disjunction, implication.
3.3.5
consequence
expression (3.3.1) that sets or specifies some property of an element of a form design (3.2.3) when its related
constraint (3.3.3) evaluates to true
3.3.6
rule
principle guiding the behaviour of some aspect of a form (3.2.2)
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 in this clause.
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 can be limited in usefulness but is maximally interoperable with
respect to this document. A conforming implementation can be more useful, but can 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;
b) shall not support any extensions to the metamodel specified in Clause 5.

© ISO/IEC 2026 – All rights reserved
4.2.3 Conforming implementation
A conforming implementation
a) shall support the metamodel specified in Clause 5;
b) may support extensions to the metamodel specified in Clause 5;
c) may support the MDR Mapping package specified in ISO/IEC 11179-3:2023/Amd1, Clause 11.
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);
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.
5 Structure of MFI form design registration
5.1 Overview of MFI form design registration
In the remainder of this clause and Annexes A and B, this document uses:
— bold font to highlight terms which represent metadata objects specified by the metamodel;
— normal font for terms which represent concepts defined in Clause 3.
EXAMPLE Form_Design is a metaclass, each instance of which represents the design of a specific form (3.2.2).
Figure 1 shows the metamodel for the registration of form (3.2.2) designs.

© ISO/IEC 2026 – 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 (3.3.6) language used to describe such
dependencies between form (3.2.2) elements: textual expressions in this language are used to complete the
rule attribute of the Form_Design_Element 5.5.4 class.

© ISO/IEC 2026 – All rights reserved
Figure 2 — Rule
The metamodel for form design registration comprises the following metaclasses:
— Attachment_Response_Field 5.5.13
— Constant 5.5.22
— Datatype 5.5.25
— Expression 5.5.21
— Form_Design 5.5.1
— Form_Design_Element 5.5.4
— Form_Design_Hierarchy_Constraint 5.5.3

© ISO/IEC 2026 – All rights reserved
— Form_Design_Template 5.5.5
— Form_Language 5.5.2
— Image_Annotation_Response_Field 5.5.19
— List_Response_Field 5.5.16
— List_Response_Field_Item 5.5.17
— List_Response_Field_Item_Selected_State 5.5.18
— Localised_Text 5.5.10
— Lookup_Response_Field 5.5.15
— Media_Element 5.5.8
— Operation 5.5.24
— Presentation_Element 5.5.6
— Question_Element 5.5.11
— Response_Field 5.5.12
— Rule 5.5.20
— Section_Element 5.5.7
— Text_Element 5.5.9
— Text_Response_Field 5.5.14
— Unit_of_Measure 5.5.26
— Variable 5.5.23
The purpose and use of the metamodel is described in detail in Annex A. Detailed specifications of the
metaclasses are provided in the remainder of this clause.
5.2 Relationship of metaclasses to the MDR Metamodel
The major classes in Figure 1 are subclassed from one or other of the classes in the MFI Core model (see
ISO/IEC 19763-10:2023, Clause 6), which in turn are subclassed from the Item class (see ISO/IEC 11179-3:2023,
6.4.2.1) allowing instances of these classes to be identified, registered, administered, named, defined and
classified.
Typically, a Form_Design 5.5.1 instance will be registered as an Administered_Item, while associated
Form_Design_Element 5.5.4 instances will be registered as Attached_Items, unless a Form_Design_
Element instance is intended to be shared across multiple Form_Design instances, in which case it should
be registered as an Administered_Item in its own right. In addition:
— any instance of a Form_Design_Element 5.5.4 can be mapped to an instance of a Concept;
— any instance of a Question_Element 5.5.11 can be mapped to an instance of a Data_Element;
— any instance of a List_Response_Field_Item 5.5.17 can be mapped to a Concept and or a Permissible_
Value.
© ISO/IEC 2026 – All rights reserved
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;
— a list of attributes;
— a list of references.
For each attribute, the following details are shown:
— the name of the attribute; where the attribute is one that is provided by a class defined in the MDR
metamodel, the name is italicized;
— the datatype for values of the attribute;
— the multiplicity of the attribute;
— 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 Datatypes and Enumerations in MFI form design registration
5.4.1 General
Basic Datatypes specify common datatypes for use in the metaclasses. A datatype is a set of distinct values,
[3]
characterized by properties of those values and by operations on those values (see ISO/IEC 11404:2007 ).
The datatypes used in the specification of the metaclasses (see 5.5) are restricted to BLOB, Boolean, Integer,
Date, Value, Sign, Postal_Address, String, Natural_Range, Datetime, String, Reference_Document, Notation
and Phone_Number (see MDR Mapping, 6.2.14). The datatypes used in the metaclasses are based on this core
set of datatypes, and any compliant implementation of a metadata registry should include an implementation
of the semantics specified in these core datatypes.
NOTE These datatypes are used in specification of the metaclass attributes themselves, and are not intended to
constrain the datatypes that can be used in specifying responses.
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;

© ISO/IEC 2026 – All rights reserved
— 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;
— 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 5.5.6, Section_
Element 5.5.7, Question_Element 5.5.11 or a List_Response_Field_Item 5.5.17 that can be addressed by
a Rule 5.5.20 (see Figure 2).
Datatype
String
The values of the Property enumeration are specified in Table 1.
Table 1 — Values in the Property enumeration
Value Description
read_only Indicates that the Form_Design_Element 5.5.4 read_only property is to be test-
ed or set as part of an Expression 5.5.21 in a Rule
available Indicates that the Form_Design_Element 5.5.4 available property is to be test-
ed or set as part of an Expression 5.5.21 in a Rule 5.5.20
The state of the available property can also be set by a List_Response_Field_
Item that has a dependent_element association with the respective Form_De-
sign_Element 5.5.4
visible Indicates that a Form_Design_Element’s 5.5.4 visibility to the user interacting
with the form (3.2.2) is to be tested or set as part of an Expression 5.5.21 in a
Rule 5.5.20
style Indicates that the Form_Design_Element 5.5.4 style property is to be tested or
set as part of an Expression in a Rule 5.5.20
5.4.3 Question_Element_Property
Question_Element_Property is an enumeration of values listing additional properties of a Question_
Element 5.5.11 that can be addressed in a Rule 5.5.20 (see Figure 2).
Supertype
Property 5.4.2
Datatype
String
The values of the Question_Element_Property enumeration are specified in Table 2.

© ISO/IEC 2026 – All rights reserved
Table 2 — Values in the Question_Element_Property enumeration
Value Description
default_value Indicates that the Question_Element 5.5.11 default_value property is to be test-
ed or set as part of an Expression 5.5.21 in a Rule 5.5.20
value Indicates that the Question_Element 5.5.11 value property is to be tested or set
as part of an Expression 5.5.21 in a Rule 5.5.20
5.4.4 Target_Form_Design_Element_State
Target_Form_Design_Element_State is an enumeration of values listing the possible states that a
dependent Form_Design_Element 5.5.4 can take when a List_Response_Field_Item 5.5.17 is selected.
Datatype
String
The values of the Target_Form_Design_Element_State enumeration are specified in Table 3.
Table 3 — Values in the Target_Form_Design_Element_State enumeration
Value Description
revealed Indicates that the dependent Form_Design_Element 5.5.4 should be visible or
available for input when the List_Response_Field_Item 5.5.17 is selected
hidden Indicates that the dependent Form_Design_Element 5.5.4 should be hidden or
unavailable for input when the List_Response_Field_Item 5.5.17 is selected
5.4.5 Operation_Type
Operation_Type is an enumeration of values describing the operation between two items in an
Expression 5.5.21 (see Figure 2).
Datatype
String
The values of the Operation_Type enumeration are specified in Table 4.
Table 4 — Values in the Operation_Type enumeration
Value Description
plus Indicates the mathematical addition operation between the two items in the
Expression 5.5.21
minus Indicates the mathematical subtraction operation between the two items in the
Expression 5.5.21
times Indicates the mathematical multiplication operation between the two items in
the Expression 5.5.21
div Indicates the mathematical division operation between the two items in the
Expression 5.5.21
or Indicates a logical “or” between the two items in the Expression 5.5.21
and Indicates a logical “and” between the two items in the Expression 5.5.21
not Indicates a logical “not” between the two items in the Expression 5.5.21
greater_than Indicates the mathematical “greater-than” operation between the two items in
the Expression 5.5.21
less_than Indicates the mathematical “less-than” operation between the two items in the
Expression 5.5.21
© ISO/IEC 2026 – All rights reserved
TTabablele 4 4 ((ccoonnttiinnueuedd))
Value Description
greater_than_or_ equal_to Indicates the mathematical “greater-than or equal-to” operation between the
two items in the Expression 5.5.21
less_than_or_ equal_to Indicates the mathematical “less-than or equal-to” operation between the two
items in the Expression 5.5.21
equal_to Indicates the mathematical “equals” operation between the two items in the
Expression 5.5.21
not_equal_to Indicates the mathematical “not equal to” operation between the two items in
the Expression 5.5.21
mod Indicates the mathematical modulo operation between the two items in the
Expression 5.5.21
in Indicates an operation between two items in the Expression 5.5.21 where one
item is a list. It evaluates to “true” if the item is one of the enumerations. For
example, an expression (3.3.1) “condition person.ecog IN (0,1,2) consequence
(3.3.5) person.eligible-for-trial = true” would set the person.eligible-for-trial
question (3.2.5) to “true” if the value entered for the person.ecog question (3.2.5)
is 0, 1 or 2
con Indicates the programmatic “string concatenation” operation between the two
items in the Expression 5.5.21
exp Indicates the programmatic “exponent” operation between the two items in the
Expression 5.5.21
is null Tests an item in the Expression 5.5.21 evaluating if the item has no value
is not null Tests an item in the Expression 5.5.21 evaluating if the item has a value
5.5 Metaclasses in MFI for form design registration
5.5.1 Form_Design
5.5.1.1 Description of Form_Design
Form_Design is a metaclass, each instance of which represents the design of a specific form (3.2.2), which is
a formulary document with blanks for the insertion of particulars (see Figure 1).
5.5.1.2 Direct superclass of Form_Design
Form_Design is a subclass of Model (defined in MFI Core ).
5.5.1.3 Attributes of Form_Design
See Table 5.
© ISO/IEC 2026 – All rights reserved
Table 5 — Attributes of Form_Design
Attribute Datatype Multiplicity Description
name String 1.1 A mandatory attribute that represents the name by
which this Form_Design is known with a maximum
cardinality of one
header Section_Element 0.1 Optional, single top level Section_Element 5.5.7
providing text and questions that are displayed at
the beginning of a form (3.2.2) where the maximum
multiplicity is one.
footer Section_Element 0.1 Optional, single top level Section_Element 5.5.7
containing text and questions that appear at the end
of a form (3.2.2), where the maximum multiplicity is
one.
context String 0.1 An optional attribute representing the description
of the universe of discourse for which this Form_De-
sign 5.5.1 was created with a maximum cardinality
of one
implementation BLOB 0.* An optional attribute containing a file that imple-
ments the described form (3.2.2)
rights_assertion Reference_Docu- 0.* Optional single Reference_Document 5.5.25 de-
ment scribing any rights asserted over the use of the form
design (3.2.3).
5.5.1.4 References of Form_Design
As a subclass of Model, Form_Design inherits Model’s references. References added in this metaclass are
shown in Table 6
Table 6 — References of Form_Design
Reference Class Multiplicity Description Inverse Precedence
superform Form_De- 0.* A form (3.2.2) whose subform no
sign 5.5.1 model contains this
form (3.2.2) where the
maximum multiplicity
is unbounded.
subform Form_De- 0.* A form (3.2.2) whose superform yes
sign 5.5.1 model is a component of
this form (3.2.2) where
the maximum multiplic-
ity is unbounded.
describing_lan- Form_Lan- 1.* The languages used in described_de- yes
guage guage 5.5.2 the description of this sign
form (3.2.2) where the
maximum multiplicity
is unbounded.
contained_ele- Form_Design_El- 1.* The set of form (3.2.2) containing_ yes
ment ement 5.5.4 elements that comprise form
this form (3.2.2) where
the maximum multiplic-
ity is unbounded
Sub- and superform references have the association class Form_Design_Hierarchy_Constraint 5.5.3

© ISO/IEC 2026 – Al
...