BS IEC 82304-1:2016 pdf download – Health software Part 1: General requirements for product safety
c) the need for RISK CONTROL measures for estimated RIsKs that are considered
unacceptable.
NOTE 1 Subclause 4.1 does not require a formal and full RISK(MANAGEMENT as,for example,per IS0 14971.However,performing the initial steps of that process is considered good practice.
NOTE 2 RISK CONTRoL measures can be hardware,an independent software system, health care procedures,orother means.
NOTE 3 Sources of information on SECURITY vulnerabilities include publicly available reports from authorities,aswell as publications by suppliers of, for instance, operating systems and third party software.
4.2HEALTH SOFTWARE PRODUGT use requirements
The MANUFACTURER shall determine and document:a) requirements that address the INTENDED USE;
b) interface requirements, including usER interface requirements where applicable;
NOTE 1 ln contrast to the usER interface specification as part of the HEALTH SOFTWARE PRODucT systemrequirements, usER interface requirements do not describe technical (realization) requirements. They describe thepurpose of the technical requirements.
EXAMPLE“The displayed information shall be readable from a distance of 3 m in an emergency unit.”NOTE 2 IEC 62366-1:2015 provides a process to establish uSER interface requirements.
c) requirements for immunity from or susceptibility to unintended influence by other softwareusing the same hardware resources;
d) privacy and SECURITY requirements addressing areas such as authorised use,person
authentication,health data integrity and authenticity,and protection against maliciousintent;
NOTE 3 See 7.2.3.1 and lEC TR 80001-2-2 (list of sECURITY capabilities) for further information on SECURITYaspects.
e) requirements for AcCOMPANYING DOCUMENTs such as instructions for use (see 7.2.2);f)requirements to support:
1) upgrades from previous versions,includingmaintaining data integrity, andcompatibility with prior versions,
2) rollback to the previous version after upgrade,
3) timely sECURITY patches and updates,
4) software distribution mechanism that ensures integrity of installation,5) decommissioning, irreversible deletion,transfer and/or retention of data;
g) requirements derived from applicable regulation, including rules for protected information.
NOTE4 lIn some jurisdictions, data protection regulations (e.g. European data protection directive 95/46/EC,revised in 2016) mandate citizens to maintain control over their personal data such as to delete or export data.European directive 95/46/EC will be replaced by the European General Data Protection Regulation (2016/679) on25 May 2018.
4.3VERIFICATION of HEALTH SOFTWARE PRODUGT use requirements
The MANUFACTURER shall verify that the HEALTH SOFTWARE PRODUCT use requirements are:a) defined and documented as input for system requirements;
b) such that the MANUFACTURER is able to meet the defined use requirements.The results of the vERIFICATION shall be recorded.
4.4 Updating HEALTH SOFTWARE PRODuCT use requirements
The MANUFACTURER shall ensure that the HEALTH SOFTWARE PRODUcT use requirements areupdated as appropriate,e.g. as a result of HEALTH SOFTWARE PRODUCT use requirementsVERIFICATION (see 4.3) or as a result of vALIDATION.
4.5system requirements
The MANUFACTURER shall specify and document the system requirements for the HEALTHSOFTWARE PRODUCT.These requirements shall include the functionality for INTENDED usE and,as applicable:
a) inter-operability;
b) localization and language support;
c)RISK CONTROL measures that have to be implemented in the HEALTH SOFTWARE PRODucT atsystem level, based on the initial RISK ASSESSMENT of 4.1;
d) usER interface specification;
e) requirements on the software and hardware platforms for the HEALTH SOFTWARE PRODUCTto function as expected under expected load,and with required performance levels;
f) features that allow for sEcuRITY compromises to be detected, recognized, logged, timed,
and acted upon during normal use;
g) features that protect essential functions,even when the software SECURITY has beencompromised;
h) methods for retention and recovery of product configuration by an authenticated privileged
uSER.
The HEALTH SOFTWARE PRODucT system requirements shall meet the HEALTH SOFTWAREPRODUCT use requirements (see 4.2).
NOTE 1 The website http:/www.himss.org/librarylinteroperability-standards/what-is-interoperability provides onesource of information on inter-operability.
NOTE 2 Technical requirements for the uSER interface can include display colour, character size, or placement ofthe controls.
NOTE 3 The typical software platform includes, but is not limited to: operating system, device drivers, sofwarelibraries, and other uSER application(s)-
NOTE 4 There is not necessarily a difference between soFTWARE SYSTEM requirements of lEC 62304:2006,5.2.1and and HEALTH SOFTWARE PRODUCT system requirements.
4.6VERIFICATION of system requirements
The MANUFACTURER shall verify that the system requirements:a) do not contradict each other;
b) are expressed in terms that avoid ambiguity;
c) are stated in terms that permit the establishment of test criteria and performance of teststo determine that test criteria have been met; and
d) can be uniquely identified.
The results of the VERIFICATION shall be recorded.BS IEC 82304-1 pdf download.