ISO/TR 19669:2017

TECHNICAL ISO/TR
REPORT 19669
First edition
2017-10
Health informatics — Re-usable
component strategy for use case
development
Informatique de santé — Stratégie de composants réutilisables pour
le développement de cas pratiques
Reference number
©
ISO 2017
© ISO 2017, 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 2017 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 3
5 Objectives for the re-usable component strategy . 4
6 Use case basics . 4
6.1 General . 4
6.2 Use case scenarios, events and actions . 4
6.3 Use case actors . 4
7 Use case component candidates . 4
7.1 General . 4
7.2 Identify-ability . 5
7.3 Catalogue-ability . 5
7.4 Commonality . 5
7.5 Computability . 5
8 Use case components . 5
8.1 General . 5
8.2 Requirements . 5
8.3 Actors and roles . 6
8.4 Scenarios, events and actions . 6
8.5 Data objects and elements . 6
9 Use case scenarios . 7
9.1 General . 7
9.2 Events and event steps . 7
9.3 Actors and roles . 7
9.4 Actions taken . 7
9.5 Inputs and outputs . 7
10 Use case requirements template . 7
10.1 Preface and introduction . 7
10.2 Initiative overview . 8
10.2.1 General. 8
10.2.2 Initiative challenge statement . 8
10.3 Use case scope . 8
10.3.1 General. 8
10.3.2 Background. 8
10.3.3 In scope . 8
10.3.4 Out of scope . 8
10.3.5 Stakeholders . 8
10.4 Value statement . 9
10.5 Use case assumptions . 9
10.6 Pre-conditions . 9
10.7 Post-conditions . 9
10.8 Actors and roles . 9
10.9 Use case diagram .10
10.10 Use case scenario(s) .10
10.11 User story .11
10.12 Activity diagram .11
10.13 Flow .11
10.13.1 Base flow .11
10.13.2 Alternate flow .12
10.13.3 Functional requirements .12
10.13.4 Information interchange requirements .13
10.13.5 System requirements .13
10.13.6 Sequence diagram .13
10.14 Risks, issues and obstacles .13
10.15 Dataset requirements .13
11 Methodology for component capture, cataloguing and re-use .14
11.1 General .14
11.2 Component — Requirements .14
11.3 Derivation of common requirements from existing use case template .14
11.3.1 General.14
11.3.2 Re-use of common requirements in new use case scenario.14
11.4 Component – Actors/roles .17
11.4.1 General.17
11.4.2 Derivation of common actors/roles from existing use case template .17
11.4.3 Re-use of common actors/roles in new use case scenario .17
11.5 Component — Scenarios .17
11.5.1 General.17
11.5.2 Derivation of scenarios from existing use case template .18
11.5.3 Re-use of common scenarios in new use case .18
11.6 Component — Events .18
11.6.1 General.18
11.6.2 Derivation of events from existing use case template .18
11.6.3 Re-use of common events in new use case scenario.18
11.7 Component — Actions .20
11.7.1 General.20
11.7.2 Derivation of actions from existing use case template .20
11.7.3 Re-use of common actions in new use case scenario event steps .20
11.8 Component — Data objects/elements .21
11.8.1 General.21
11.8.2 Derivation of data objects/elements from existing use case template .21
11.8.3 Re-use of common data objects/elements in new use case data requirements .21
12 Progression — Use case development to implementation .23
12.1 General .23
12.2 Use case requirements phase .23
12.2.1 General.23
12.2.2 Subject matter experts .24
12.2.3 Use case analysts.24
12.2.4 Initial sketch of the clinical/business case .24
12.2.5 Comprehensive statement of the clinical/business case .24
12.2.6 Components of the clinical/business case .24
12.2.7 Finalization of clinical/business case requirements .24
12.3 Anchor for traceability .24
12.4 Fulfilment of clinical/business case requirements.25
Bibliography .26
iv © ISO 2017 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the 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 the following
URL: www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 215, Health informatics.
This document is based in part on ISO/TR 21089 and ISO/HL7 10781.
Introduction
Use cases are often utilized to establish key objectives and requirements for software design and
development, system testing, certification and implementation. This document offers a methodology
for use case development that discovers common components of use case scenarios, then establishes
a component catalogue for subsequent re-use and re-purposing of those components in new use case
scenarios. The methodology establishes re-use as a key foundation for consistent infrastructure and
build-out of software application systems in healthcare (and potentially other industries). Re-use of
requirements often leads to re-use of software solutions (to those requirements). The methodology
leads to uniformity in, and optimization of, requirement specification, standards and implementation
guidance, software development, testing and certification and ultimately implementation. The
methodology establishes the basis for requirements traceability, at each progression step, and end-to-
end (use case to implementation).
vi © ISO 2017 – All rights reserved

TECHNICAL REPORT ISO/TR 19669:2017(E)
Health informatics — Re-usable component strategy for
use case development
1 Scope
This document specifies a use case development methodology, facilitated by a dynamic catalogue of
re-usable components. Use cases are a basic tool in describing requirements for health and healthcare
settings, service provision, information technology and software products. Use case development often
follows a uniform template with components such as actors, roles, scenarios, event steps, actions, data
objects/elements and requirements statements. This document includes a basic use case template and
the methods of component identification, capture, cataloguing and re-use. This document also includes
guidance for software designed to implement the methodology in the form of a use case authoring tool.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
3.1
action
activity or task performed by an entity at a given point in time
Note 1 to entry: A use case event is comprised of one or more actions occurring in sequence.
Note 2 to entry: It can also be defined as an element of an event (step) that a user performs during a procedure
(see ISO/IEC 26514).
3.2
actor
health professional, healthcare employee, patient/consumer, sponsored healthcare provider, healthcare
organisation, subject of care, device, system or application that acts (performs a role) in a health related
communication or service
[SOURCE: ISO 17090-1:2013, 3.1.3, modified]
3.3
assumption
condition that is accepted as true
Note 1 to entry: It can also be defined as factors that, for planning purposes, are considered to be true, real, or
certain without proof or demonstration (see ISO/IEC/IEEE 24765) or a statement that describes the expected
behaviours of a system or actors who will use the system (see Reference [20]).
3.4
data element
data concept represented by a specific value domain and that describes a single atomic property about
an object class
[SOURCE: ISO 14817-1:2015, 4.17, modified - Note 1 to entry deleted]
3.5
data object
collection of data that has a natural grouping and may be identified as a complete entity
Note 1 to entry: It can also be defined as a collection (set) of logically related data elements, e.g. “patient vital
signs typically comprise heart rate, respiration rate, temperature and blood pressure”.
[SOURCE: ISO/TS 27790:2009, 3.20, modified - Note 1 to entry has been added]
3.6
electronic health record
repository of information regarding the health of a subject of care, in computer processable form
Note 1 to entry: It can also be defined as comprehensive, structured set of clinical, demographic, environmental,
social, and financial data and information in electronic form, documenting the health care given to a single
individual (ASTM 1769) or information relevant to the wellness, health and healthcare of an individual, in
computer-processable form and represented according to a standardized information model (ISO 18308).
[SOURCE: ISO 13606-2:2008, 4.7, modified - Note 1 to entry replaced]
3.7
event
performance of a specified set of functions or operations
Note 1 to entry: It can also be defined as a health care interaction that involves a patient and that may be delivered
[21]
by a health care provider or be provided as a service .
[SOURCE: ISO/IEC 23006-2:2016, 3.1.6, modified - Note 1 to entry has been added]
3.8
entity
legal (e.g. a corporation, labour union, state or nation) or natural person or system (e.g. device, software)
[SOURCE: ISO 15782-1:2009, 3.35, modified - text has been added to the definition and the example has
been deleted]
3.9
health/care
health and/or healthcare
EXAMPLE Health/care providers support individual health and provide healthcare services.
3.10
initiative
collaboration of business/clinical experts to develop one or more use cases
3.11
pre-condition
condition which must be true prior to undertaking use case action(s)
3.12
post-condition
condition which must be true after undertaking use case action(s)
2 © ISO 2017 – All rights reserved

3.13
requirement
requirement statement
declaration of necessary condition(s)
Note 1 to entry: “specified requirement” is a need or expectation that is stated (requirements are intended to
define some feature of a real implementation and offer the possibility of testing) (see ISO/IEC 17007:2009, 3.4).
3.14
re-usable component
element of the use case description that can be excerpted, labelled, catalogued and retained (in a
persistent file) for selection and inclusion in a future use case or scenario
3.15
scenario
sequence of event (steps) necessary to complete a business/clinical process
Note 1 to entry: It can also be defined as a description of high level business activities defining process and
requirements (see ISO/IEC 19501:2005).
3.16
subject of care
one or more persons scheduled to receive, receiving, or having received a health service
Note 1 to entry: It can also be defined as any person who uses, or is a potential user of, a health care service (see
ISO/TS 22220:2011).
[SOURCE: ISO 18308:2011, 3.47, modified - definition has been amended and Note 1 to entry added]
3.17
use case
set of scenarios which address a particular business/clinical domain or topic
Note 1 to entry: It can also be defined as a specification of interactions between external actors and the system
to attain particular goals (technopedia.com) or methodology used in system analysis to identify, clarify, and
organize system requirements (whatis.com).
3.18
user story
simple narrative illustrating the user goals that a software function will satisfy
[SOURCE: ISO/IEC/IEEE 26515:2011, 4.16]
4 Symbols and abbreviated terms
EHR electronic health record
EHR-S electronic health record system
HIT health information technology
SKMT ISO TC215 Standards Knowledge Management Tool
SME subject matter expert
UCR use case requirements
UCA use case analyst
UCAT use case authoring tool
5 Objectives for the re-usable component strategy
The re-usable component strategy (for use case development) is based on the following objectives.
a) To formalize a process of identifying and cataloguing common use case components and patterns
of re-use from developing use cases.
b) To save new resource investment by allowing business requirements analysts to quickly identify
and re-use catalogued use case components already specified or to add new ones, when appropriate.
c) To formalize a process of identifying and cataloguing implementable software modules and data
objects, either commercial or open source, which implement various aspects of required use case-
identified software functionality, data/record management and exchange.
d) To save new resource investment by allowing software developers to readily identify and re-use
catalogued software modules and data objects in their solutions.
e) To facilitate and promote uniformity in requirement specification, standards and implementation
guidance.
f) To lay the foundation for uniform and consistent information infrastructure and build-out.
g) To ensure requirements traceability step-by-step and end-to-end (use case to implementation).
6 Use case basics
6.1 General
In healthcare, use cases typically describe scenarios involving patient flows (with the patient as an
actor), provider/work flows (with provider(s) as actor(s)) and information flows [with systems or
devices as actor(s)]. Use cases resolve to actors taking actions in sequence, as a progression of steps.
EHR (or other) systems capture record entries resulting from actions taken, as persistent evidence of
their occurrence.
6.2 Use case scenarios, events and actions
A use case has (is specified in terms of) one or more scenarios. Each scenario has (is specified in terms
of) one or more events (in step-wise sequence) to support individual health and to provide healthcare.
Each event/event step has (is specified in terms of) one or more actions (in step-wise sequence).
6.3 Use case actors
Use cases have business and clinical actors, as individuals or organizations acting in roles (e.g.
performer, assistant, observer, author, scribe, attester). Use cases have technical actors, as systems and
devices, also acting in roles (e.g. originator, sender or receiver).
7 Use case component candidates
7.1 General
Use case components are a vital part of a typical use case narrative, but don’t necessarily include all
elements (e.g. all sections of the use case requirements template). As specified in this document, use
case components candidates have four distinctions, in arbitrary order: 1) identify-ability, 2) catalogue-
ability, 3) commonality and potential for re-use, 4) computability.
4 © ISO 2017 – All rights reserved

7.2 Identify-ability
The use case component is consistently evident (identifiable) in the use case scenario or narrative.
(Clause 10).
7.3 Catalogue-ability
The use case component is readily captured and retained as entry in a catalogue or registry, allowing it
to be queried and selected then re-used or re-purposed in subsequent use cases.
7.4 Commonality
The use case component is evident in existing use case scenarios and has a significant potential for
re-use in new or revised scenarios. Note that re-use often extends to the solution and thus, once a
requirement has a designated software or dataset solution re-selecting that same component in a new
use case or scenario offers potential for re-use of the same solution.
7.5 Computability
The use case component has characteristics which may be computable and thus may be implemented as
standard software modules and/or data constructs.
8 Use case components
8.1 General
Based on distinctions identified in Clause 7 and review of the use case template in Clause 10, four basic
categories of use case components are evident: 1) requirements, 2) actors and roles, 3) scenarios, events
and actions, 4) data objects and elements.
8.2 Requirements
Use case requirements are statements of necessary conditions, which must be determined “true” to
satisfy fulfilment. Use case requirements may be offered as proof statements and/or conformance
criteria. (See examples in Tables 6 and 7.)
a) Requirements state necessary conditions which occur before, during and/or after each use case
scenario.
b) Requirements may take the form of assumptions (10.5), pre-conditions (10.6), post conditions
(10.7) or system functional requirements (10.13.3).
c) Requirements may be applicable (and accountable) to particular actors, at specific event steps or
actions.
d) As a result, discrete requirements may be fulfilled by, and are thus traceable to, particular use case
actors and actions.
e) Requirements are typically stated as SHALL (required), SHOULD (preferred) or MAY (optional).
f) Common requirements statements are catalogued as re-usable components.
8.3 Actors and roles
In the use case requirements template (Clause 10), use case actors are enumerated (10.8) and shown
taking/performing actions in scenario events (10.10). (See examples in Table 8.)
a) Actors are individuals or organizations whose actions are often facilitated by EHR or other system
software.
b) Actors (in roles) perform (and are typically accountable for) use case actions.
c) In separate actions, an actor may play a different role.
d) Actors may fulfil established requirements by performing specific actions (showing requirements
traceability).
e) Common actors and roles are catalogued as re-usable components.
8.4 Scenarios, events and actions
In the use case requirements template, use case scenarios, events and actions are specified in 10.10.
(See examples in Tables 10 and 11.)
a) Scenarios are comprised of discrete event steps in a typical sequence.
b) Scenarios have a base flow and may have one or more alternate flows.
c) Event steps are broken into discrete action(s) taken.
d) Actions are taken/performed by actor(s) in role(s).
e) Actors and actions may invoke EHR or other system functions.
f) Actions may be auditable at each occurrence.
g) Actions may be attestable (with signature).
h) Events and actions have discrete data inputs and outputs.
i) Inputs and outputs may be specified in terms of required data objects and elements (8.5).
j) Common actions are catalogued as re-usable components.
8.5 Data objects and elements
In the use case requirements template (Clause 10), data requirements are specified in 10.15. (See
examples in Table 11.)
a) Data requirements resolve to data objects and elements essential to undertake events and actions
in use case scenarios.
b) Data requirements typically include data objects and elements specified as, data/record inputs to
and/or outputs from, use case events and actions.
c) Common data objects and elements are catalogued as re-usable components.
6 © ISO 2017 – All rights reserved

9 Use case scenarios
9.1 General
Use case scenarios describe a typical health/care work flow interwoven with patient,
provider/practitioner and information flows. Use case scenarios describe a sequence of event steps
with actors taking actions.
9.2 Events and event steps
Regarding events and event steps
a) Each event step comprises one or more action(s) taken.
b) Each event step is initiated by an actor performing [taking action(s)] in a role.
c) Each event step has inputs and outputs.
d) Inputs include data/records required to take/initiate action(s).
e) Outputs are new data/records produced by action(s) taken/performed.
Events and event steps may be re-usable components.
9.3 Actors and roles
Each event step is initiated by an actor performing in a particular role. Actors and roles are re-usable
components.
9.4 Actions taken
Each action is a discrete task, operation or process initiated or performed by an actor. Each action may
have inputs and outputs. An action may be designated as auditable (at run-time). An action may be
designated as attestable with signature (at run-time). An action may invoke one or more EHR (or other)
system functions. Actions are re-usable components.
NOTE See ISO/HL7 10781 and ISO/HL7 16527.
9.5 Inputs and outputs
Each event and action has specified data as inputs to or outputs from specified functions and processes.
Inputs and outputs resolve to data requirements in the form of data objects and elements. Data objects
and elements are re-usable components and may be drawn from a formalized information model.
NOTE See Reference [18].
10 Use case requirements template
10.1 Preface and introduction
The preface and introduction explains the purpose of use case development. A use case focuses on a
topic area for software development, typically with the intent to promote consistency and uniformity.
A new scenario might fit within an existing use case or might be better included in a new use case. This
may be a subjective decision. Format is paragraph(s).
10.2 Initiative overview
10.2.1 General
The initiative overview articulates the overarching subject area(s), business case(s) and issues that the
initiative aims to address. The initiative’s goal is generally at a higher level than those of the use case
and are distinguished as such in this section. When an initiative has multiple use cases, this initiative
overview should be consistent for each use case. A recommended starting point for this content
is the project charter and related research collected during the pre-development phase. Format is
paragraph(s).
10.2.2 Initiative challenge statement
The initiative challenge statement states the current challenge or problem, on a healthcare industry
level, that the initiative seeks to address. Related issues should be included within this clause, with the
exception of risks, which are outlined later in the use case. Format is paragraph(s).
10.3 Use case scope
10.3.1 General
This section describes the scope of the use case. Most use cases in healthcare informatics focus on
information processes and flows, step-wise and integral to health care/business processes, often tightly
interwoven with patient flows and provider/practitioner work flows. The scope statement outlines
flows and processes pertinent to this use case. If there are multiple use cases within the same Initiative,
this section can be used to explain how the scope of this use case relates to the others. Subclauses 10.4.2
to 10.4.4 further define scope at a more granular level. Diagrams and other supplemental data/examples
often help to provide context and clarify the basis for the use case. Format is paragraph(s), with optional
diagrams.
10.3.2 Background
The background section goes into more detail than the initiative overview to describe the relevance
of the use case in terms of gaps and misalignments in health care/business flows and processes. Also
describe key policy and/or regulatory issues as well as dependencies that may impact the use case.
Format is paragraph(s).
10.3.3 In scope
The in scope section offers the opportunity to further define and refine the scope, adding details. The
section can further elaborate how health/care data/records are captured, retained and conveyed in in
a particular business context. It can describe exchange transactions and data content to be included. It
can describe specific aspects that need to be in place to enable the information to be sent, received and
understood the same at both ends of the transmission. Format is bulleted list.
10.3.4 Out of scope
This section indicates what is out of scope for the use case. This section may highlight dependencies on
the feasibility, implement-ability, and usability that result in limitations of the use case. It is not intended
to be an exhaustive enumeration of all possibilities. At a higher level, that which is not declared “In
Scope”, is by definition, “Out of Scope”. Format is bulleted list.
10.3.5 Stakeholders
The stakeholder section identifies particular individuals and organizations that are potentially affected
by content of the use case. It is not intended to be an exhaustive enumeration but rather focus on those
with most direct impact. Format is a table of identified communities (see Table 1).
8 © ISO 2017 – All rights reserved

Table 1 — Stakeholders (example)
Stakeholder Working definition
Patient Healthcare consumers who are recipients of healthcare services and
products.
Health Care Provider A person or organization that's licensed to offer healthcare services.
10.4 Value statement
The value statement provides a high level description of values and/or anticipated benefits of this use
case to the healthcare community. This section also identifies anticipated outcomes and metrics that will
be used to assess success factors. Format is paragraph(s) followed by a bulleted list of values/benefits.
10.5 Use case assumptions
This section describes use case assumptions or those characteristics, functions or processes needed to
establish the circumstances within which use case requirements are properly met or realized (e.g. an
encompassing privacy and security framework). These points may be more functional in nature and
may be stated in terms of broad overarching concepts of the Initiative. Success metrics for software
design, development, testing, certification and implementation may include criteria based on use
case assumptions. Format is bulleted list. Assumptions are re-usable components (as requirements
statements). (See examples in Tables 6 and 7.)
10.6 Pre-conditions
This section describes use case pre-conditions or the state of the health/care environment or system
that must be true before use case operations, processes, activities or tasks can be executed. Success
metrics for software design, development, testing, certification and implementation may include
criteria based on pre-conditions. Format is bulleted list. Pre-conditions are re-usable components (as
requirements statements). (See examples in Tables 6 and 7.)
10.7 Post-conditions
This section describes use case Post-Conditions or the state of the health/care environment or
system that will be true after successful execution of use case operations, processes, activities and
tasks. Success metrics for software design, development, testing, certification and implementation
may include criteria based on Post-Conditions. Format is bulleted list. Post-Conditions are re-usable
components (as requirements statements). (See examples in Tables 6 and 7.)
10.8 Actors and roles
This section describes business actor(s) who participate (play a role) in use case scenarios, events and
actions (see Table 2). A Business actor (person or organization) typically uses an EHR or other system
to perform/fulfil health/care functions and processes including information interchange. Format is a
table of business actors and related roles. Actors and roles are re-usable components. (See examples in
Table 8.)
Table 2 — Actors and roles (example)
Actor System Role
Primary Care Physician EHR System Sender
Specialist EHR System Receiver
10.9 Use case diagram
This section describes the use case conceptually as a use case diagram. The diagram offers an overview
use case scenarios as described in user stories and shows interactions between business actors a
...