ISO/TR 17119:2005

TECHNICAL ISO/TR
REPORT 17119
First edition
2005-01-15
Health informatics — Health informatics
profiling framework
Informatique de santé — Cadre de profil d'informatique de santé

Reference number
©
ISO 2005
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2005
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2005 – All rights reserved

Contents Page
Foreword. iv
Introduction . v
1 Scope. 1
1.1 General. 1
1.2 Purpose. 1
1.3 Benefits . 1
1.4 Target users. 2
2 Terms and definitions. 2
3 Health informatics profiling framework — Overview . 3
3.1 General. 3
3.2 What is the health informatics profiling framework?. 4
3.3 How to use the health informatics profiling framework. 4
4 Health informatics profiling framework approach. 6
4.1 Overview of approach. 6
4.2 Artefact profiling . 6
4.3 Framework evolution. 10
5 Reference and comparisons of health informatics profiling framework to other initiatives . 11
Annex A (informative) Background . 12
Annex B (informative) Health informatics profiling framework example meta-model . 14
Annex C (informative) Framework cell examples. 17
Annex D (informative) Comparisons to other frameworks and models . 21
Annex E (informative) Health informatics profiling framework prototype tool and further
exploration opportunities. 23
Bibliography . 28

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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In exceptional circumstances, when a technical committee has collected data of a different kind from that
which is normally published as an International Standard (“state of the art”, for example), it may decide by a
simple majority vote of its participating members to publish a Technical Report. A Technical Report is entirely
informative in nature and does not have to be reviewed until the data it provides are considered to be no
longer valid or useful.
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.
ISO/TR 17119 was prepared by Technical Committee ISO/TC 215, Health informatics.
iv © ISO 2005 – All rights reserved

Introduction
The health informatics profiling framework (HIPF) is designed to bring order to the description of health
informatics standards artefacts. A common means of description is necessary to facilitate the coordination,
communication and comparability of health informatics standards across and between disciplines and
jurisdictions. The HIPF is an approach and tool to describe the variety of artefacts within the domain of health
informatics standards. It builds upon other key information frameworks. This Technical Report does not
constrain or drive conformance across informatics standards or their development, but it provides a useful
descriptive tool to describe existing and developing health informatics standards.
TECHNICAL REPORT ISO/TR 17119:2005(E)

Health informatics — Health informatics profiling framework
1 Scope
1.1 General
This Technical Report provides a common description framework for health informatics standards artefacts.
The aim of the health informatics profiling framework (HIPF) is to provide a consistent method for describing
and classifying artefacts within the domain of health informatics standards.
The HIPF establishes common concepts and a vocabulary for describing the complex domain of various
health informatics standards initiatives and their supporting artefacts. The use of the HIPF should promote the
reuse of health informatics knowledge and improve the identification of opportunities for health informatics
standards alignment, collaboration and coordination.
1.2 Purpose
The purpose of the HIPF is to facilitate shared descriptions and comparisons of health informatics standards.
In particular, it is the aim of the HIPF to:
 provide the capability to comprehensively define and classify health informatics standards artefacts,
 facilitate the coordination, communication and comparability of health informatics standards through a
common understanding of intended uses and content,
 help identify and coordinate health informatics standards development,
 provide a potential foundation for the development of a global health informatics standards knowledge
base,
 promote health informatics standards integration and alignment within and between standards from
different jurisdictions, and
 provide a framework to assist with the coordination of ISO/TC 215 work items both within the technical
committee and with related initiatives from other sources.
1.3 Benefits
The potential benefits of the HIPF include:
 introduction of classification concepts and terminology for health informatics standards artefacts,
 enhancement of health informatics standards development coordination through the identification of
potential duplication between standards initiatives, and
 enhancement of global understanding of health informatics standards in support of their knowledge
management.
1.4 Target users
The target users of the HIPF include:
 health informatics standards developers, and
 users of health informatics standards.
2 Terms and definitions
For the purposes of this Technical Report, the following terms and definitions apply.
2.1
artefact
any model, document, or work product
2.2
compatibility
capability of a functional unit to meet the requirements of a specified interface without appreciable modification
[ENV 12443:1996]
2.3
concept
units of thought constituted through abstraction on the basis of properties common to a set of objects
[ENV 12443:1996]
2.4
context
related conditions and situations that provide a useful understanding and meaning of a subject
2.5
data
“raw” alphanumeric text, objects, and symbols defined without any context in such a way that by itself one
cannot tell its correct meaning
2.6
framework
a structure for supporting or enclosing something else, often acting to partition something complex into simple
components
2.7
granularity
the boundary where an object functions as a self-contained, stand-alone unit to support a common vision or
goal
2.8
health informatics profiling framework
HIPF
an approach and tool to describe the variety of artefacts within the domain of health informatics standards
2.9
HIPF cell
the intersection of an HIPF perspective and an HIPF level of specificity that is defined within the context of the
HIPF classification matrix
2 © ISO 2005 – All rights reserved

2.10
HIPF classification matrix
a structure that includes dimensions for health informatics standards artefacts, levels of specificity, and
perspectives
2.11
HIPF perspective
a classification dimension for differentiating health informatics standards artefacts based on their viewpoints,
intended purpose or focus
NOTE This dimension includes the perspectives of what, how, where, who, when and why, which are further
described in 4.2.1.2.
2.12
HIPF specificity
a classification dimension for differentiating health informatics standards artefacts based on their level of
abstraction with respect to implementation specifications
NOTE This dimension includes the conceptual, logical and physical levels, which are further described in 4.2.1.1.
2.13
information
data in context that enable interpretation with meaning and relevance
2.14
interface
the shared boundary between two functional units defined by various characteristics pertaining to the
functions, physical interconnections, signal exchanges and other characteristics as appropriate
[ENV 12443:1996]
2.15
profile
a brief description, outline or overview
2.16
top-down
method or procedure that starts at the highest level of abstraction and proceeds towards the lowest level
[ENV 12443:1996]
3 Health informatics profiling framework — Overview
3.1 General
The HIPF provides the basis for a management tool to support the coordination of health informatics
standards initiatives. It does this by providing an approach for the classification of health informatics standards
artefacts. This approach is supported by an extensible architecture.
The HIPF is a descriptive tool. It includes a simple two-dimensional HIPF classification matrix that articulates
the dimensions of specificity and perspective. Although a simple structure, the matrix is capable of reflecting
complexity through multiple relationships between a standard artefact and the HIPF matrix components.
These relationships may be used to provide a comprehensive and comparable description of health
informatics standards.
Artefact profiles may be further enhanced through the use of optional HIPF attributes, in addition to the
classification matrix.
This Technical Report describes a methodological approach for using the HIPF matrix to “profile” health
informatics standards, and it also describes how these classifications may contribute to the evolution of a
health informatics standards knowledge base. This approach includes the following processes:
 health informatics standards profiling, and
 framework evolution.
These processes are intended to support the goal of sharing knowledge about and supporting the comparison
of health informatics standards artefacts.
3.2 What is the health informatics profiling framework?
The first component to be addressed is the concept of a “framework”. A framework is a structure for
supporting or enclosing something else. The HIPF is such a structure.
One of the essential features of both frameworks and models is that they allow highly complex systems to
become conceptually manageable. The difference between them is primarily in terms of comprehensiveness
and approach. Models are mostly concerned with describing what is wanted or what is available, often in a
visual manner. Frameworks are more commonly used to describe and structure enterprise architectures or
other comprehensive domains.
In developing the classification matrix portion of the HIPF, Zachman's widely known Enterprise Architecture
Framework was used as a starting point. The “domain” of the framework or, in Zachman's terms, the
“Enterprise”, which this architectural framework is to support, is the domain of “health informatics”.
Frameworks have the following properties.
 They partition the universe of interest into manageable chunks.
 They are comprehensive yet simple.
 They are composed of two or more dimensions. Most frameworks have two core dimensions though
multidimensional (e.g. cube) frameworks may also be used.
 One dimension is often contextual (e.g. concerned with a specific perspective). Often this is related to the
user of the information (e.g. designer, database builder) or domain (e.g. party, recipient).
 One can create one’s own framework or use an existing one if an appropriate structure is available for the
domain of interest.
The HIPF classification matrix partitions this domain in terms of the level of specificity and the perspective (or
focus area) as a consistent and generic method for describing health informatics standards artefacts. The
profile of an artefact may be further enhanced by additional attributers, such as approval status and other
optional detail.
In the HIPF, a “profile” is a brief description (including a classification) of a health informatics standards
artefact.
3.3 How to use the health informatics profiling framework
The HIPF provides classification guidelines so that a model or other standards artefact can be placed in one
or more of the cells defined in the matrix. The matrix partitions the domain of health informatics into
18 separate sub-domains. The classification matrix can help avoid unnecessary problems or confusion as the
cell placement indicates which artefacts are unlikely or likely candidates for comparison or integration. Those
that are placed in or mapped to the same cell have at least the characteristics of the cells to provide some
basis for comparison or collaboration.
4 © ISO 2005 – All rights reserved

The classification of a model or other standards artefact requires analysis of the model or standard against the
rows and columns of the matrix. The matrix allows for the co-location of artefacts that have like characteristics.
It does not ensure that these artefacts can or should be compared or aligned. Decisions regarding alignment
would be a subsequent exercise. The framework subdivides the health informatics universe into more
manageable conceptual “chunks”. Most likely, transformations will need to be determined and scope
alignment performed before comparisons of models within a cell can be conducted. As per set theory,
meaningful comparisons may only be made within the intersection space of the two sets or models.
The framework will require updating and re-versioning. A versioning process will enable the ongoing
“greening” of the framework and will continue to increase the validity and value for its using community.
It is important to note that the HIPF is not an end in itself. Determining the placement of standards artefacts in
the framework is only the first step. Working within a primary cell or a closely aligned group of cells to achieve
objectives, such as aligning or comparing design artefacts, is where the real benefits are derived.
The basic construct of the two-dimensional HIPF classification matrix including three rows of specificity and
six columns of perspectives provides a means of identifying and classifying the content of a health informatics
standards artefact. The intersection of these dimensions constitutes a framework cell. Artefact classification is
complete when an artefact is placed in one or multiple framework cell(s).
This matrix is a special application of Zachman's “Enterprise Architecture Framework”, but with different sets
of rows based upon observations about the nature of the various domains of interest and specificity. Zachman
uses perspectives of roles of people in the enterprise as criteria. During the development of this report, it was
determined that “levels of specificity” was a more appropriate criterion than Zachman's criteria for the
classification of artefacts of interest to the health informatics standards community.

Figure 1 — Health informatics profiling framework classification matrix
Some of the background to the evolution of this framework has been provided in Annex A.
In addition, a proposed formalized approach to artefact definition and classification has been suggested and
an example meta-model has been created to support artefact profiling and knowledge base development. This
example meta-model, representing the inter-relationships between HIPF constructs, has been provided in
Annex B.
4 Health informatics profiling framework approach
4.1 Overview of approach
The HIPF approach includes two processes: artefact profiling and framework evolution. Both of these
processes should support the profiling of health informatics artefacts and the ongoing evolution of an HIPF
knowledge base.
The artefact profiling process provides a brief description and common classification for health informatics
standards and their artefacts. This process may be iterative, as additional knowledge on the definition and
classification of an artefact may be attained at a later time. Profiled artefacts can be collected to form a
knowledge base of health informatics artefacts.
Framework evolution should be a continuous process to ensure the proactive support of the artefact profiling
requirements. The work products of framework evolution could be critical success factors for the artefact
profiling process.
4.2 Artefact profiling
The artefact profiling process includes artefact classification, mapping assessment and artefact definition (with
optional attributes).
This multi-step process is iterative. The definition of an artefact may change over time as more knowledge is
gained about the artefact and as changes in the HIPF definition are made.

Figure 2 — Artefact profiling process
6 © ISO 2005 – All rights reserved

4.2.1 Artefact classification
Artefact classification includes the mapping (placement) of an artefact with respect to one or many matrix cells.
An artefact is deemed classified once it has been placed within the context of the HIPF dimensions of
specificity and perspective. Artefact classification also provides the capability to cross-reference two or more
mapped artefacts.
The HIPF classification matrix provides a two-dimensional view of perspective (six columns) and levels of
specificity (three rows). This two-dimensional view is intended to encompass the universe of health informatics
artefacts. The HIPF classification matrix divides the domain of health informatics standards artefacts into
18 separate content sub-domains. These artefacts include models, standards, documents and other such
components of health informatics that provide the design or “architecture” for health information.
Example mappings to the HIPF matrix may be found in Annex C.
4.2.1.1 Levels of specificity
Levels of specificity provide differentiation of health informatics standards artefacts by defining levels that
move from abstract to exact implementation specifications. For example, one may move through the
framework from general population characteristics to specific attributes of a person. The main categories are
conceptual, logical and physical design.
4.2.1.1.1 Conceptual
This specificity level contains classes of things of interest within health informatics. This level has no specifics,
but contains shared fundamental meanings. It does not contain detailed health information characteristics.
This level may address health information management and administration from a strategic level.
Key mapping question: Does the artefact define fundamental meanings, without any detailed characteristics
and health information inter-relationships?
Examples: High-level and generic classifications of healthcare organizations or of health
information, guidelines for health information management, governance rules and
regulations.
4.2.1.1.2 Logical
This specificity level contains generalized models or informatics standards. It deals with specifics that provide
coherence, without concern for technological constraints. This level addresses health information
management and administration from a tactical level.
Key mapping question: Does the artefact define characteristics of information, without concern for
technological constraints?
Examples: Inter-related and detailed roles and responsibilities, data flow diagrams, interaction
models, business rules.
4.2.1.1.3 Physical design
This specificity level contains models and protocols with defined technological constraints. This level
addresses health information management and administration from an operational level.
Key mapping question: Does the artefact define information with technological constraints?
Examples: Information storage architectures, physical layouts, application system models.
4.2.1.2 Perspectives
Perspectives form the columns of the HIPF classification matrix.
It is important to note that many models, documents or artefacts may have characteristics of more than one
perspective. The challenge in placing or mapping them to the matrix lies in determining which characteristics
are most predominant in the model or standard (i.e. “What is the main purpose of this artefact in terms of
health informatics standards?”) or which collection of matrix cells is inherent in the model or standard.
In some cases, it may be necessary to place or map a particular artefact in more than one of the framework
cells. In addition, it is recommended that in the instance of multi-cell mapping, the primary and secondary
mappings should be differentiated. Multi-cell mapping is further described in 4.2.2.
Interrogatives are the basic questions that can be reviewed for any model or standard in order to address the
perspective dimension. By mapping health informatics standards artefacts to each of the interrogatives below
at the conceptual, logical and physical levels, all necessary information should be obtained to facilitate artefact
classification. For examples of artefacts for each matrix cell, see Annex D.
4.2.1.2.1 The “what” perspective
The “what” perspective contains models or other documents describing health information of interest. These
artefacts may help plan for the collection, use or dissemination of health data and information as a significant
business or scientific resource.
Key mapping question: Does the artefact define the subjects, topics or categories of interest in health data
and information?
Examples: Vocabularies and terminology definitions, data and information models and classes,
clinical models, models to measure treatment effectiveness, population health
characteristics and economic viability and sustainability models.
4.2.1.2.2 The “how” perspective
The “how” perspective contains models or directions for the way things should be done.
Key mapping question: Does the artefact define methods, processes, architectures, or procedures in health
information management or use?
Examples: Procedural business process models, application architectures, functionality
standards, methodologies, procedures, guidelines and data flow diagrams.
4.2.1.2.3 The “where” perspective
The “where” perspective includes artefacts dealing with location definitions. Note that “where” factors include
geography, climatic conditions, and environment. “Where” can have a geographical, jurisdictional (e.g. a
nation) or a functional viewpoint (e.g. a surgery room) in terms of location.
Key mapping question: Does the artefact define physical or logical locations for health information
management or use?
Examples: Climate models, facility infrastructure and blueprints, controlled environment models,
technical architecture and network architectures.
8 © ISO 2005 – All rights reserved

4.2.1.2.4 The “who” perspective
The “who” perspective includes artefacts that address the management and administration of people in health
informatics.
Key mapping question: Does the artefact define the attributes of people involved in health information
management and use? For example, does it define any of the following:
 people management or administration,
 workflow,
 skills, or
 roles and responsibilities.
Examples: Organization charts, organization flow and workflow models (who does what), who
has access (e.g. security profiles, systems, security classifications), skills
descriptions, personnel classifications and scope models, roles and responsibilities,
and population models.
4.2.1.2.5 The “when” perspective
The “when” perspective includes artefacts that define time-related factors.
Key mapping question: Does the artefact define schedules, events, cycles, timeframes or frequencies for
health information management or use?
Examples: Schedules, events, cycles, timeframes, frequencies, state transitions, critical paths
and reproductive cycles.
4.2.1.2.6 The “why” perspective
The “why” perspective contains informatics standards artefacts that describe the reason things are done. It
has been observed that not many models only focus on “why”. Certain aspects of health informatics standards
artefacts, however, may be “why” oriented. “Why” artefacts may also overlap with procedures (“how”).
Key mapping question: Does the artefact define strategy, goals, success criteria, purpose, policies or
governance for health information management or use?
Examples: Mission and strategic statements, clinical guidelines, goal models, success factors,
objectives, statements of purpose, rules and policies.
4.2.2 Artefact mapping
The framework provides for multi-cell mapping of artefacts. Every artefact mapping definition requires a
mapping designation that indicates the relative strength of the artefact mapping.
The HIPF classification matrix diagram (see Figure 1) shows the characteristics for mapping artefacts to
various specificity (row) and perspective (column) cells. The placement into the matrix cells can be determined
by asking questions about the intentions of the health informatics standards artefact. Answers about the
specificity and perspective of the artefact should be only one of the following:
 yes, it is a primary focus of the artefact,
 yes, it is a secondary focus of the artefact, or
 no, it is not a focus (or is a negligible focus) of the artefact.
4.2.3 Profile refinement
This section describes optional attributes for further refining a health informatics standards profile.
Optional HIPF artefact attribute sets have been suggested as follows:
 title (e.g. “Health informatics profiling framework”),
 reference code,
 organization responsible,
 contact details,
 level of standards approval (e.g. “working draft”),
 short narrative description,
 scope description,
 next planned update,
 previous version(s),
 language,
 technical or organizational implementation considerations (e.g. “local implementation profiles may be
needed”),
 setting/jurisdiction of application,
 target groups (expected primary users),
 other standards classification (e.g. referencing another standards category),
 related standards or projects,
 keywords, and
 comments.
4.3 Framework evolution
The framework evolution process supports the dynamic nature of the domain of health informatics standards
artefacts. Each of the products of this process (HIPF meta-model, knowledge base, and framework definition)
will continuously evolve to meet the requirements of standards artefacts profiling. The HIPF knowledge base
will grow as artefacts are profiled and re-profiled, as more is understood about the artefact profiling process,
and its inherent profiling patterns. The framework definition, which serves as a guideline for artefact profiling,
can be responsive to change through the analysis of the HIPF knowledge base and feedback from the HIPF
community of users and stakeholders.
4.3.1 Knowledge base assessment
This step involves the analysis of profiled artefacts within an HIPF knowledge base. A knowledge base
analysis is critical to the meta-model definition and framework definition steps as artefact profiling patterns can
be determined and gaps in the HIPF meta-model can be identified.
10 © ISO 2005 – All rights reserved

4.3.2 Meta-model architecture
The HIPF and its supporting meta-model architecture will continuously evolve to reflect the dynamic domain of
healthcare and health informatics artefacts. One of the key features of the HIPF is its supporting extensible
meta-model structure. The HIPF meta-model supports the inherent HIPF approach concepts through the
implementation of inter-relationships between HIPF meta-model constructs.
The meta-model step includes the analysis of the existing HIPF meta-model in the context of a thorough
knowledge base assessment and resulting framework definition. The objective of this step is to proactively
engineer meta-model constructs to support the ever-changing domain of health informatics standards
artefacts and evolving patterns of artefact profiling.
4.3.3 Framework definition
The framework definition will evolve as knowledge is gained about artefact types and their utility. The
framework definition can support the predictive modelling of key framework constructs such as artefact type
and objective.
During the framework definition step, previously mapped artefacts may be analysed for the determination of
patterns with respect to indirect artefact type and objective mappings to HIPF classification matrix cells. This
analysis may identify possible mappings of artefact type, objectives, and other meta-model concepts to the
HIPF classification matrix to be used during the mapping assessment phase.
5 Reference and comparisons of health informatics profiling framework to other
initiatives
Many frameworks related to health informatics have been developed and published over the past several
years. Several key frameworks and reference models were analysed from a purpose, scope, and difference
point of view, to determine use or possible adoption as informatics standards profiling frameworks. The goal
was to find a means to “coordinate, communicate, and compare models of health informatics and health
information standards”.
See Annex D for a comparison of the HIPF to the Health Level Seven Version 3 Reference Information Model,
[3] [5]
the Zachman Enterprise Architecture — A Framework, ENV 12443:1996 , and ISO/IEC 10746-2:1996 .
In addition, a prototype HIPF mapping and knowledge base tool is described in Annex E, along with a short
discussion of potential opportunities for future exploration.
Annex A
(informative)
Background
A.1 Overview
Health information is very complex, even at the “micro” or single situation (clinical encounter incident) level. In
many situations, individual health service providers cannot (and maybe should not) respond to a problem or
situation by themselves. It is often the case that an integrated network of skills, information, technologies and
facilities is required to accomplish a successful health outcome.
To assist in managing this complexity, health information models are developed. Models are patterns, plans,
examples or standards that may be used for imitation or comparison. One of the key benefits of modelling is
that it provides for the division of complexity into manageable components. In fact, one could argue that one
facet of medical education is the assimilation of models by the student.
ISO/TC 215’s Working Group 1 (WG1) is focused on facilitating the coordination of health information models
and standards across jurisdictional boundaries and determining how to interrelate models developed by
different jurisdictions. In 1999 and 2000, WG1 meetings addressed a general domain model work item.
Several challenges were encountered in launching this work item, including coming to consensus on the
definition and description of a “general domain model”, the purpose of developing such a model, and the
attempt to align or map high level health information models already in existence. More recent discussion has
highlighted the fact that the participants had different concepts of what the general domain model was to
accomplish. They recognized that the models being compared were developed to address different needs,
thus a fair comparison of them was impossible.
WG1 also found that models proposed by various participants as a basis for the “General Domain Model”
were too narrow in scope to meet all objectives. In some cases, attempts were being made to compare
models that addressed different levels of abstraction. Some were physical models that specified exactly the
data elements, their type and size and defined specific relationships, whereas others were conceptual, dealing
with general relationships between entities without identifying any attributes. Comparisons would not be valid
unless some preliminary transformation of the models was made first.
At the July 2000 WG1 meeting in Vancouver, Canada, WG1 members concluded that a single, all-
encompassing health information model was likely impossible and, even if it were developed, it would be so
complex that it would defeat the purpose of having an ISO model. It is important to note that there is not just
one type of health information model, there are many. Some healthcare information models are in the form of
standard medical practices and procedures. Other models specify:
 what information needs to be recorded,
 how they are to be done,
 where they need to be done,
 who needs to be involved,
 when tasks or activities need to be done and in what sequence, and
 why they need to be done.
At the government jurisdictional and at the inter-jurisdictional or ISO levels, another dimension is added to this
complexity. Some of the models are specific to a given jurisdiction or a given purpose (i.e. some specific
12 © ISO 2005 – All rights reserved

subset of healthcare, such as the treatment of cancer). Others are general enough that they may be viewed
as being independent of such “context”. Furthermore, the mission of ISO/TC 215 is to contribute to the
improvement and maintenance of health through the use of standards for informatics and to facilitate the
delivery of products, services and information over distances and across borders. This is a broad health
perspective encompassing a wide context from health services to alternative medicine to socio-economic and
environmental health factors. The coordination and facilitation of models need to encompass an equally wide
and complex context.
ISO/TC 215 WG1 decided at their meeting in June 2000 that the “present Work Item — General Domain
Model — be redefined and restarted at Stage 0, taking into account the related history and work, and
addressing a high level data framework. Included with the new work item proposal would be a first draft based
1)
upon the concept of a high level data framework.”
At a December 2000 WG1 General Data Framework Exploratory and Working Meeting (hosted by Canada
with participation from Japan and New Zealand), the possibilities, scope and purpose for a high-level
framework were discussed. An initial draft of such a framework was also developed. The initial matrix that was
developed was used as a basis for the draft developed in this document.

1) Draft minutes and presentation material from ISO TC215 WG1 Meeting in Vancouver, June 2000.
Annex B
(informative)
Health informatics profiling framework example meta-model
B.1 Introduction
The following is a depiction of an HIPF meta-model architecture. This example meta-model has been
engineered to support the HIPF processes of artefact profiling and framework evolution.
Specificity
Cell
Perspective
Artefact State
Artefact Status
Mapping Type
Artefact Mapping
Stakeholder Type
Project
Jurisdiction
Artefact Stakeholder
Artefact
Artefact Jurisdiction
Organization
Artefact Relationship
Artefact Objective
Artefact Relationship Type Artefact Type Objective

Figure B.1 — HIPF meta-model diagram
B.2 Health informatics profiling framework meta-model definitions
B.2.1 Artefact
The description of a model, document or work product that is used in healthcare by a jurisdiction to assist in
the management of healthcare and planning of healthcare initiatives. The artefact will include such information
as:
 full name of the artefact, as shown in source documents, as well as any commonly-used trademarks,
acronyms or abbreviations,
 brief description of the artefact and a scope identifying the focus of the artefact, including secondary
areas of note,
14 © ISO 2005 – All rights reserved

 technical and organizational implementation considerations, as stipulated in source data, or as
determined by the analyst recording the data,
 next planned update, along with the next update's version number and/or name,
 any closely related artefacts that may be of interest to the user, under the heading “See also…”,
 the original language of source text. In the case of a difference in content between different language
versions, the versions should be listed separately, with differences noted as an implementation
consideration, and with the alternate version noted in “See also…”.
B.2.2 Artefact relationship and artefact relationship type
Defines the relationship between an artefact and an artefact component (parent/child), such as the
immediately prior version of the standard, and any earlier versions of interest (note that the prior version of the
standard is likely to also exist in the database, and would itself reference the current version under the
heading of “Next Planned Update”).
B.2.3 Artefact jurisdiction
The association of a level of approval and a specific artefact instance for an indication of governance that may
be applied to the setting of a specific artefact. Identification of an artefact into an applicable jurisdiction is
stipulated in source documents, or is determined by the analyst recording the data. Each artefact will be given
one of the following levels of approval depending upon the state of the artefact:
 approved – the work has been formally approved as a standard in a jurisdiction by an organization with
responsibility for the jurisdiction,
 de facto – the work is so widely used that it is considered to be a default standard by knowledgeable
users across the jurisdiction,
 pilot phase – a potential standard that is in its final stages prior to be being promoted to “approved” status,
or
 developmental – a work that is under development with the expectation that it will be adopted as a
standard, but has not yet gone through pilot testing.
B.2.4 Artefact objective
The assignment of a purpose (global, jurisdictional, functional, etc.) to an artefact instance.
B.2.5 Artefact mapping
Maintains information specific to the placement of a specific artefact to an HIPF matrix cell.
This “classification” attribute is best described as a navigational attribute that exists in order to group together
artefacts with common characteristics.
B.2.6 Artefact stakeholder
The capability to define the role (e.g. publisher, sponsor, audience, approver) for an individual or entity with a
vested interest in development and utility of a health informatics artefact. A stakeholder can be a:
 developer – the primary organization(s) responsible for the development of the standard, as noted in
source documents. If an alternate organization is responsible for maintenance, this is also noted,
 contact or custodian – the primary organization(s) with the right to disseminate information on the
standard and/or distribute the standard, or
 target groups – the expected primary users of the standard, as stipulated in source documents, or as
determined by the analyst recording the data.
--------------------
...