IEC/DIS 81001-5-1

Health software and health IT systems safety, effectiveness and security

Titre manque

Standards Content (sample)

DRAFT INTERNATIONAL STANDARD
IEC/DIS 81001-5-1
ISO/TC 215 Secretariat: ANSI
Voting begins on: Voting terminates on:
2020-12-09 2021-03-03
Health software and health IT systems safety, effectiveness
and security —
Part 5-1:
Security — Activities in the product life cycle
ICS: 35.240.80; 35.080
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
This document is circulated as received from the committee secretariat.
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
This draft is submitted to a parallel vote in ISO and in IEC.
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
IEC/DIS 81001-5-1:2020(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION. IEC 2020
---------------------- Page: 1 ----------------------
62D/1419/CDV -3- IEC CDV 81001-5-1  IEC:2020
49 5.8.4 Controls for private keys24
50 5.8.5 Assessing and addressing SECURITY-related issues24
51 5.8.6 ACTIVITY Completion25
52 5.8.7 SECURE Decommissioning guidelines for HEALTH SOFTWARE25
53 6 SOFTWARE MAINTENANCE PROCESS26
54 6.1 Establish SOFTWARE MAINTENANCE plan26
55 6.1.1 Timely delivery of SECURITY updates26
56 6.2 Problem and modification analysis26
57 6.2.1 Monitoring public incident reports26
58 6.2.2 SECURITY Update VERIFICATION26
59 6.3 Modification implementation27
60 6.3.1 SUPPORTED SOFTWARE SECURITY update documentation27
61 6.3.2 MAINTAINED SOFTWARE SECURITY update delivery27
62 6.3.3 MAINTAINED SOFTWARE SECURITY update INTEGRITY27
63 7 SECURITY RISK MANAGEMENT28
64 7.1 RISK MANAGEMENT Context28
65 7.1.1 PRODUCT SECURITY CONTEXT28

66 7.2 Identification of VULNERABILITIES, THREATS and associated adverse impacts28

67 7.3 Estimation and evaluation of SECURITY Risk29
68 7.4 Controlling SECURITY RISKS29
69 7.5 Monitoring the effectiveness of RISK CONTROLS29
70 8 Software CONFIGURATION MANAGEMENT PROCESS30
71 9 Software problem resolution PROCESS30
72 9.1 Overview30
73 9.2 Receiving notifications about VULNERABILITIES30
74 9.3 Reviewing VULNERABILITIES30
75 9.4 Analysing VULNERABILITIES31
76 9.5 Addressing SECURITY-related issues31
77 10 Quality management system33
78 10.1 SECURITY expertise33
79 10.2 SOFTWARE ITEMS from third-party suppliers33
80 10.3 Continuous improvement33
81 10.4 Disclosing SECURITY-related issues33
82 10.5 Periodic review of SECURITY defect management34
83 10.6 ACCOMPANYING DOCUMENTATION review34
84 Annex A (informative)35
85 Rationale35
86 A.1 Relationship to IEC 6244335
87 A.2 Relationship to IEC 6230435
88 A.3 Risk Transfer35
89 A.3.1 Introduction35
90 A.3.2 MAINTAINED SOFTWAREError! Bookmark not defined.
91 A.3.3 SUPPORTED SOFTWAREError! Bookmark not defined.
92 A.3.4 REQUIRED SOFTWAREError! Bookmark not defined.
93 A.4 Secure Coding Best Practices36
94 Annex B (informative) Guidance on Implementation of SECURITY LIFE CYCLE
95 ACTIVITIES37
96 B.1 Overview37
---------------------- Page: 2 ----------------------
62D/1419/CDV -3- IEC CDV 81001-5-1  IEC:2020
49 5.8.4 Controls for private keys24
50 5.8.5 Assessing and addressing SECURITY-related issues24
51 5.8.6 ACTIVITY Completion25
52 5.8.7 SECURE Decommissioning guidelines for HEALTH SOFTWARE25
53 6 SOFTWARE MAINTENANCE PROCESS26
54 6.1 Establish SOFTWARE MAINTENANCE plan26
55 6.1.1 Timely delivery of SECURITY updates26
56 6.2 Problem and modification analysis26
57 6.2.1 Monitoring public incident reports26
58 6.2.2 SECURITY Update VERIFICATION26
59 6.3 Modification implementation27
60 6.3.1 SUPPORTED SOFTWARE SECURITY update documentation27
61 6.3.2 MAINTAINED SOFTWARE SECURITY update delivery27
62 6.3.3 MAINTAINED SOFTWARE SECURITY update INTEGRITY27
63 7 SECURITY RISK MANAGEMENT28
64 7.1 RISK MANAGEMENT Context28
65 7.1.1 PRODUCT SECURITY CONTEXT28

66 7.2 Identification of VULNERABILITIES, THREATS and associated adverse impacts28

67 7.3 Estimation and evaluation of SECURITY Risk29
68 7.4 Controlling SECURITY RISKS29
69 7.5 Monitoring the effectiveness of RISK CONTROLS29
70 8 Software CONFIGURATION MANAGEMENT PROCESS30
71 9 Software problem resolution PROCESS30
72 9.1 Overview30
73 9.2 Receiving notifications about VULNERABILITIES30
74 9.3 Reviewing VULNERABILITIES30
75 9.4 Analysing VULNERABILITIES31
76 9.5 Addressing SECURITY-related issues31
77 10 Quality management system33
78 10.1 SECURITY expertise33
79 10.2 SOFTWARE ITEMS from third-party suppliers33
80 10.3 Continuous improvement33
81 10.4 Disclosing SECURITY-related issues33
82 10.5 Periodic review of SECURITY defect management34
83 10.6 ACCOMPANYING DOCUMENTATION review34
84 Annex A (informative)35
85 Rationale35
86 A.1 Relationship to IEC 6244335
87 A.2 Relationship to IEC 6230435
88 A.3 Risk Transfer35
89 A.3.1 Introduction35
90 A.3.2 MAINTAINED SOFTWAREError! Bookmark not defined.
91 A.3.3 SUPPORTED SOFTWAREError! Bookmark not defined.
92 A.3.4 REQUIRED SOFTWAREError! Bookmark not defined.
93 A.4 Secure Coding Best Practices36
94 Annex B (informative) Guidance on Implementation of SECURITY LIFE CYCLE
95 ACTIVITIES37
96 B.1 Overview37
---------------------- Page: 3 ----------------------
62D/1419/CDV -4- IEC CDV 81001-5-1  IEC:2020
97 B.2 THREAT / RISK ANALYSIS (TRA)37
98 B.3 THREAT and RISK MANAGEMENT38
99 B.4 Software Development Planning38
100 B.4.1 Development PROCESS38
101 B.4.2 Development environment SECURITY38
102 B.5 HEALTH SOFTWARE Requirements Analysis38
103 B.5.1 HEALTH SOFTWARE SECURITY requirements38
104 B.5.2 SECURITY requirements review39
105 B.5.3 Software Architectural Design39
106 B.5.4 SECURITY architectural design review39
107 B.5.5 Software Unit Implementation and VERIFICATION39
108 B.5.6 Secure implementation40
109 B.5.7 SECURITY testing40
110 Annex C (informative) THREATTHREAT MODELTHREAT MODELLING42
111 C.1 General42
112 C.2 ATTACK-Defense Trees42
113 C.3 CAPEC / OWASP / SANS42
114 C.4 CWSS42
115 C.5 DREAD42
116 C.6 List Known Potential VULNERABILITIES42
117 C.7 OCTAVE42
118 C.8 STRIDE42
119 C.9 Trike43
120 C.10 VAST43
121 Annex D (informative) Relation to practices in IEC 62443-4-144
122 D.1 ISO/IEC 81001-5-1 to IEC 62443-4-1:201844
123 D.2 IEC 62443-4-1:2018 to IEC/ISO 81001-5-145
124 Annex E (informative) Document specified in IEC 62443-4-146
125 E.1 Introduction46
126 E.2 Release Documentation46
127 E.2.1 HEALTH SOFTWARE DEFENSE-IN-DEPTH documentation46
128 E.2.2 DEFENSE-IN-DEPTH measures expected in the environment47
129 E.2.3 SECURITY hardening guidelines47
130 E.2.4 SECURITY Update Information48
131 E.3 Documents for Decommissioning HEALTH SOFTWARE48
132 Annex F49
133 (normative)49
134 TRANSITIONAL HEALTH SOFTWARE49
135 F.1 Introduction49
136 F.2 Pre-Market ACTIVITIES49
137 F.3 Rationale for use of TRANSITIONAL HEALTH SOFTWARE50
138 F.4 Post-Market ACTIVITIES50
139 Bibliography51
---------------------- Page: 4 ----------------------
62D/1419/CDV -5- IEC CDV 81001-5-1  IEC:2020
140 INTERNATIONAL ELECTROTECHNICAL COMMISSION
141 ____________
142 Health software and health IT systems safety, effectiveness and security
143 Part 5: Security
144 Part 5-1: Security - Activities in the product life cycle
145
146
147 FOREWORD

148 1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising

149 all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international

150 co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and

151 in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,

152 Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Their

153 preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with

154 may participate in this preparatory work. International, governmental and non-governmental organizations liaising

155 with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for

156 Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.

157 2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international

158 consensus of opinion on the relevant subjects since each technical committee has representation from all

159 interested IEC National Committees.

160 3) IEC Publications have the form of recommendations for international use and are accepted by IEC National

161 Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC

162 Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any

163 misinterpretation by any end user.

164 4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications

165 transparently to the maximum extent possible in their national and regional publications. Any divergence between

166 any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.

167 5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity

168 assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any

169 services carried out by independent certification bodies.

170 6) All users should ensure that they have the latest edition of this publication.

171 7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and

172 members of its technical committees and IEC National Committees for any personal injury, property damage or

173 other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and

174 expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC Publications.

175 8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is

176 indispensable for the correct application of this publication.

177 9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent

178 rights. IEC shall not be held responsible for identifying any or all such patent rights.

179 This Committee Draft of future International Standard IEC 81001-5-1 has been prepared by subcommittee

180 62A/ JWG7 of IEC technical committee 62 and ISO/TC 215/JWG 7.
181

182 Full information on the voting for the approval of this International Standard can be found in the report

183 on voting indicated in the above table.

184 This document has been drafted in accordance with the ISO/IEC Directives, Part 2.

185 The committee has decided that the contents of this document will remain unchanged until the stability

186 date indicated on the IEC website under "http://webstore.iec.ch" in the data related to the specific

187 document. At this date, the document will be
188 • reconfirmed,
189 • withdrawn,
190 • replaced by a revised edition, or
191 • amended.
192

193 The National Committees are requested to note that for this document the stability date is 2026

194 THIS TEXT IS INCLUDED FOR THE INFORMATION OF THE NATIONAL COMMITTEES AND WILL BE DELETED AT THE

195 PUBLICATION STAGE.
196
---------------------- Page: 5 ----------------------
62D/1419/CDV -6- IEC CDV 81001-5-1  IEC:2020
197 Introduction

198 This International Standard specifies supplementary ACTIVITIES that will be performed by the

199 MANUFACTURER of HEALTH SOFTWARE – including software incorporated in medical devices –as

200 a part of a secure development LIFE CYCLE. This document can therefore support conformity to

201 IEC 62443-4-1.
202

203 This document is intended to supply minimum best practices for a secure software LIFE CYCLE.

204 Local legislation and regulation have to be considered.
205 PROCESS requirements have been derived from IEC 62443-4-1 PRODUCT LIFE CYCLE

206 Management. Implementations of these specifications will extend existing PROCESSES at the

207 MANUFACTURER’s organization –notably existing PROCESSES conforming to IEC 62304.

208 This document specifies ACTIVITIES for HEALTH SOFTWARE, the LIFE CYCLE of which can be part

209 of an incorporating PRODUCT project. Some ACTIVITIES specified in this document depend on

210 input and support from the PRODUCT LIFE CYCLE (for example to define specific criteria).

211 Examples include:
212 • RISK MANAGEMENT
213 • Requirements
214 • Testing
215 • Post-Market

216 In cases where ACTIVITIES for HEALTH SOFTWARE need support from PROCESSES at the PRODUCT

217 level, this document specifies respective requirements beyond the HEALTH SOFTWARE LIFE CYCLE.

218 Similar to IEC 62304, this document does not prescribe a specific system of PROCESSES, but it

219 requires that certain ACTIVITIES are being performed during the HEALTH SOFTWARE LIFE CYCLE.

220 This document specifies ACTIVITIES to be performed by the MANUFACTURER. For the purpose of

221 this document this includes all entities responsible for construction ACTIVITIES in the LIFE CYCLE

222 of HEALTH SOFTWARE.

223 Clause four specifies that MANUFACTURERS develop and maintain HEALTH SOFTWARE within a

224 quality management system (see 4.1) and a RISK MANAGEMENT SYSTEM (4.2).

225 Clauses five to eight specify ACTIVITIES and resulting output as part of the software LIFE CYCLE

226 PROCESS implemented by the MANUFACTURER. These specifications are arranged in the ordering

227 of IEC 62304.

228 Clauses nine and ten specify ACTIVITIES and resulting output as part of the problem resolution

229 PROCESS and quality management system respectively, implemented by the MANUFACTURER.

230 The scope of this document is limited to HEALTH SOFTWARE and its connectivity to its INTENDED

231 ENVIRONMENT OF USE, based on IEC 62304, but with emphasis on information SECURITY.

232 For expression of provisions in this document,
233 — "can" is used to describe a possibility or capability; and
234 — "must" is used to express an external constraint.
235

236 Note: HEALTH SOFTWARE can be placed on the market as software, incorporated into medical

237 devices, as software that in itself is considered a medical device, or incorporated into a general-

238 purpose computing platform.
---------------------- Page: 6 ----------------------
62D/1419/CDV -7- IEC CDV 81001-5-1  IEC:2020
239 Health software and health IT systems safety, effectiveness and security
240 Part 5: Security
241 Part 5-1: Security - Activities in the product life cycle
242
243
244 1 Scope
245 * Purpose

246 This document defines the LIFE CYCLE requirements for development and maintenance of HEALTH

247 SOFTWARE needed to support conformity to IEC 62443-4-1 – taking the specific needs for HEALTH

248 SOFTWARE into account. The set of PROCESSES, ACTIVITIES, and TASKS described in this

249 document establishes a common framework for secure HEALTH SOFTWARE LIFE CYCLE PROCESSES.

250
251

252 Fig. 1: HEALTH SOFTWARE LIFE CYCLE PROCESSES (derived from IEC 62304, Ed 1.1)

253

254 The purpose is to increase the information SECURITY of HEALTH SOFTWARE by establishing certain

255 ACTIVITIES and TASKS in the HEALTH SOFTWARE LIFE CYCLE PROCESSES and also by increasing the

256 SECURITY of SOFTWARE LIFE CYCLE PROCESSES themselves.

257 It is important to maintain an appropriate balance of the key properties SAFETY, effectiveness

258 and SECURITY as discussed in IEC 81001-1.
259 This document excludes specification of ACCOMPANYING DOCUMENTATION contents.
260
261 * Field of application

262 This document applies to the development and maintenance of HEALTH SOFTWARE by a

263 MANUFACTURER, but recognizes the critical importance of bi-lateral communication with

264 organizations (e.g. HDOs) who have SECURITY responsibilities for the HEALTH SOFTWARE and the

265 systems it is incorporated into, once the software has been developed and released. The

266 IEC/ISO 81001-5 series of standards (for which this is part 1, is therefore being designed to

267 include future parts addressing SECURITY that apply to the implementation, operations and use

268 phases of the LIFE CYCLE for organizations such as HDOs.

269 Medical device software is a subset of HEALTH SOFTWARE. Therefore, this document applies to:

270 − Software as part of a medical device;
---------------------- Page: 7 ----------------------
62D/1419/CDV -8- IEC CDV 81001-5-1  IEC:2020
271 − Software as part of hardware specifically intended for health use;
272 − Software as a medical device (SaMD); and
273 − Software-only PRODUCT for other health use.
274

275 Note: In this document, the scope of software considered part of the LIFE CYCLE ACTIVITIES for

276 secure HEALTH SOFTWARE is larger and includes more software (drivers, platforms, operating

277 systems) than for SAFETY, because for SECURITY the focus will be on any use including

278 foreseeable unauthorized access rather than just the INTENDED USE.
HEALTH SOFTWARE
MEDICAL
DEVICE
Software as
software
Software as
part of
part of a
specific
MEDICAL DEVICE
For specific
health
hardware
hardware
For general
Software as
computing Software-only
a MEDICAL
platform product for
DEVICE
other
(SAMD)
health use
Other health use
MEDICAL DEVICE use
279
280 Fig. 2: HEALTH SOFTWARE field of application (source: IEC 62304 Ed 2)
281
282 Conformance

283 HEALTH SOFTWARE conformance with this document is defined as implementing all of the

284 PROCESSES, ACTIVITIES, and TASKS identified in the normative parts of this document - with the

285 exception of Annex F.

286 Conformance of TRANSITIONAL HEALTH SOFTWARE with Annex F of this document is defined as

287 only implementing the PROCESSES, ACTIVITIES, and TASKS identified in Annex F of this document.

288 Conformance is determined by inspection and establishing traceability of the PROCESSES,

289 ACTIVITIES and TASKS required.

290 The quality management system may be implemented according to ISO 13485 or other

291 equivalent quality management system standards.

292 IEC 62304 specifies ACTIVITIES, based on the software SAFETY classification. The required

293 ACTIVITIES are indicated in the normative text of IEC 62304 as "[Class A, B, C]", "[Class B, C]"

294 or "[Class C]", indicating that they are required selectively depending on the classification of

295 the software to which they apply. The requirements in this document have a special focus on

296 information SECURITY and therefore do not follow the concept of SAFETY classes. For conformity

297 to this document the selection of ACTIVITIES is independent of SAFETY classes.

298 Implementing the PROCESSES, ACTIVITIES and TASKS specified in this document is sufficient to

299 implement the PROCESS requirements of IEC 62443-4-1. MANUFACTURERS may implement the

300 specifications for Annex E in order to achieve full conformity to IEC 62443-4-1.

301 This document requires establishing one or more PROCESSES that comprise of identified

302 ACTIVITIES. The LIFE CYCLE PROCESSES shall implement these ACTIVITIES. None of the

303 requirements in this document requires to implement these ACTIVITIES as one single PROCESS

---------------------- Page: 8 ----------------------
62D/1419/CDV -9- IEC CDV 81001-5-1  IEC:2020

304 or as separate PROCESSES. The ACTIVITIES specified in this document will typically be part of an

305 existing LIFE CYCLE PROCESS.
306
307 2 Normative references
308 There are no normative references in this document.
309
310 3 Terms and definitions

311 ISO and IEC maintain terminological databases for use in standardization at the following

312 addresses:
313 • IEC Electropedia: available at www.electropedia.org/
314 • ISO Online browsing platform: available at www.iso.org/obp
315
316
317 ACCOMPANYING DOCUMENTATION

318 documentation accompanying a HEALTH SOFTWARE and HEALTH IT SYSTEM or an accessory,

319 containing information for the responsible organization or operator, particularly regarding

320 SAFETY
321 [SOURCE: ISO 81001-1:2020, 3.1]
322
323
324 ACTIVITY
325 set of one or more interrelated or interacting TASKS
326 [SOURCE: IEC 62304:2021, 3.1]
327
328
329 ARCHITECTURE

330 fundamental concepts or properties of a system in its environment, embodied in its elements,

331 relationships, and in the principles of its design and evolution
332 [SOURCE: ISO/IEC/IEEE 24765:2017, 3.216, definition1]
333
334
335 ASSET

336 physical or digital entity that has value to an individual, an organization or a government

337 Note 1 to entry: As per the definition for ASSET this can include the following:

338 a) data and information;
339 b) HEALTH SOFTWARE and software needed for its operation;

340 c) hardware components such as computers, mobile devices, servers, databases, and networks;

341 d) services, including SECURITY, software development, IT operations and externally provided

342 services such as data centres, internet and software-as-a-service and cloud solutions;

343 e) people, and their qualifications, skills and experience;
---------------------- Page: 9 ----------------------
62D/1419/CDV -10- IEC CDV 81001-5-1  IEC:2020

344 f) technical procedures and documentation to manage and support the HEALTH IT

345 INFRASTRUCTURE;

346 g) HEALTH IT SYSTEMS that are configured and implemented to address organizational objectives

347 by leveraging the ASSETS; AND
348 h) intangibles, such as reputation and image.
349 [SOURCE: ISO 81001-1:2020, 3.3]
350
351
352 ATTACK

353 attempt to destroy, expose, alter, disable, steal or gain unauthorized access to or make

354 unauthorized use of an ASSET
355 [SOURCE: ISO/IEC 27000:2018, 2.3]
356
357
358 ATTACK SURFACE

359 physical and functional interfaces of a system that can be accessed and, therefore, potentially

360 exploited by an attacker
361 [SOURCE: ISO/IEC 62443-4-1, 3.1.7]
362
363
364 AVAILABILITY
365 property of being accessible and usable upon demand by an authorized entity
366 [SOURCE: ISO/IEC 27000:2018, 2.9]
367
368
369 CONFIDENTIALITY

370 property that information is not made available or disclosed to unauthorized individuals, entities,

371 or PROCESSES
372 [SOURCE: ISO/IEC 24767-1:2008, 2.1.2]
373
374
375 CONFIGURATION ITEM
376 entity that can be uniquely identified at a given reference point
377 [SOURCE: IEC 62304:2021]
378
379
380 CONFIGURATION MANAGEMENT

381 PROCESS ensuring consistency of CONFIGURATION ITEMS by using mechanisms for identifying,

382 controlling and tracking versions of CONFIGURATION ITEMS
383 [SOURCE: IEC 81001-1:2020, modified]
384
---------------------- Page: 10 ----------------------
62D/1419/CDV -11- IEC CDV 81001-5-1  IEC:2020
385
386 DEFENSE-IN-DEPTH

387 approach to defend the system against any particular ATTACK using several independent

388 methods

389 Note to entry: DEFENSE-IN-DEPTH implies layers of SECURITY and detection, even on single

390 systems, and provides the following features:

391 • is based on the idea that any one layer of protection, can and probably will be defeated;

392 • attackers are faced with breaking through or bypassing each layer without being

393 detected;
394 • a flaw in one layer can be mitigated by capabilities in other layers;

395 • system SECURITY becomes a set of layers within the overall network SECURITY; and

396 • each layer should be autonomous and not rely on the same functionality nor have the

397 same failure modes as the other layers.
398 [SOURCE: IEC 62443-4-1: 3.1.15]
399
400
401 EXPLOIT (noun)

402 defined way to breach the SECURITY of information systems through some VULNERABILITY

403 [SOURCE: ISO/IEC 27039:2015]
404
405
406 HEALTH IT INFRASTRUCTURE

407 combined set of IT ASSETS available to the individual or organization for developing, configuring,

408 integrating, maintaining, and using IT services and supporting health, patient care and other

409 organizational objectives
410 [SOURCE: ISO 81001-1:202x, 3.21]
411
412
413 HEALTH IT SYSTEM

414 a combination of interacting health information elements (including HEALTH SOFTWARE, medical

415 devices, IT hardware, interfaces, data, procedures and documentation) that is configured and

416 implemented to support and enable an individual or organization’s specific health objectives

417 [SOURCE: ISO 81001-1:2020, 3.22]
418
419
420 HEALTH SOFTWARE

421 software intended to be used specifically for managing, maintaining, or improving health of

422 individual persons, or the delivery of care, or which has been developed for the purpose of

423 being incorporated into a medical device

424 Note 1 to entry: HEALTH SOFTWARE fully includes what is considered software as a medical device.

425 [SOURCE: ISO 81001-1:2020, 3.23]
426
---------------------- Page: 11 ----------------------
62D/1419/CDV -12- IEC CDV 81001-5-1  IEC:2020
427
428 HEALTHCARE DELIVERY ORGANIZATION
429 HDO

430 facility or enterprise such as a clinic or hospital that provides healthcare services

431 [SOURCE: ISO 81001-1:2020, 3.24]
432
433
434 INTEGRITY
435 property of accuracy and completeness
436 [SOURCE: ISO/IEC 27000:2018, 2.40]
437
438
439 INTENDED ENVIRONMENT OF USE

440 conditions and setting in which users interact with the HEALTH SOFTWARE – as specified by the

441 MANUFACTURER
442
443
444 INTENDED USE
445 INTENDED PURPOSE

446 use for which a PRODUCT, PROCESS or service is intended according to the specifications,

447 instructions and information provided by the MANUFACTURER

448 Note 1 to entry: The intended medical indication, patient population, part of the body or type of

449 tissue interacted with, user profile, INTENDED ENVIRONMENT OF USE, and operating principle are

450 typical elements of the INTENDED USE.

451 [SOURCE: ISO 81001-1:2020, 3.28, note 1 to entry modified – “USE ENVIRONMENT” replaced by

452 “INTENDED ENVIRONMENT OF USE”.]
453
454
455 LIFE CYCLE

456 series of all phases in the life of a PRODUCT or system, from the initial conception to final

457 decommissioning and disposal
458 [SOURCE: ISO 81001-1:2020, 3.32]
459
460
461 MAINTAINED SOFTWARE

462 SOFTWARE ITEM for which the MANUFACTURER will assume the risk related to SECURITY

463 Note to entry: See also Annex A.3
464
465
466 MANUFACTURER

467 natural or legal person responsible for construction ACTIVITIES in the LIFE CYCLE of HEALTH

468 SOFTWARE
---------------------- Page: 12 ----------------------
62D/1419/CDV -13- IEC CDV 81001-5-1  IEC:2020

469 Note 1 to entry: Construction includes ACTIVITIES for conception, design, implementation,

470 packaging, distribution, maintenance of HEALTH SOFTWARE.

471 Note 2 to entry: Responsibility extends to supporting ACTIVITIES during operations.

472 Note 3 to entry: Responsibility can be with multiple entities along the supply chain, with service

473 providers, or with entities at different stages in the LIFE CYCLE.

474 Note 4 to entry: Independent of this, any specific legal accountability is defined by contracts

475 and legislation.
476
477
478 PROCESS

479 set of interrelated or interacting ACTIVITIES that use inputs to deliver an intended result (outcome)

480 [SOURCE: ISO 81001-1:202x, 3.38, modified – added “(outcome)” after “result”.]

481
482
483 PRODUCT

484 output of an organization that can be produced without any transaction taking place between

485 the organization and the customer

486 Note 1 to entry: Production of a PRODUCT is achieved without any transaction necessarily taking

487 place between provider and customer, but can often involve this service element upon its

488 delivery to the customer.

489 Note 2 to entry: The dominant element of a PRODUCT is that it is generally tangible.

490 [SOURCE: ISO 81001-1:2020, 3.39]
491
492
493 REQUIRED SOFTWARE

494 SOFTWARE ITEM for which the MANUFACTURER will consider SECURITY-related risks known before

495 release of the HEALTH SOFTWARE
496 Note to entry: this includes SUPPORTED SOFTWARE. See Annex A.3.
497
498
499 RESIDUAL RISK
500 risk remaining after RISK CONTROL measures have been implemented
501 [SOURCE: ISO 81001-1:2020, 3.42]
502
503
504 RISK CONTROL

505 PROCESS in which decisions are made and measures implemented by which risks are reduced

506 to, or maintained within, specified levels
507 [SOURCE: ISO 81001-1:2020, 3.47]
508
---------------------- Page: 13 ----------------------
62D/1419/CDV -14- IEC CDV 81001-5-1  IEC:2020
509
510 RISK MANAGEMENT

511 systematic application of management policies, procedures and practices to the TASKS of

512 analysing, evaluating, controlling and monitoring risk
513 [SOURCE: ISO 81001-1:2020, 3.50]
514
515
516 SAFETY
517 freedom from unacceptable risk

518 Note 1 to entry: In the context of SAFETY, risk is the combination of probability of occurrence of

519 harm and severity of harm (see ISO/IEC Guide 51:2014).

520 Note 2 to entry: SECURITY incidents can lead to harm and can therefore have an impact on

521 SAFETY.
522 [SOURCE: ISO 81001-1:2020, 3.55, modified
...