WIXLIB

Medical Device Software Standardsfor Safety and Regulatory ComplianceSherman Eagles 1 .com

Assuring safe softwareSAFEAll hazards havebeen addressedRisks have beenreduced to acceptablelevelsAdequate process hasbeen implemented(compliance withstandards is oftenconsidered ademonstration ofadequate process.)Process is effectiveIEC 62304AAMI TIR 45IEC 80002-1IEC 60601-1IEC80001

3IEC 62304 background Specifically created for medical device softwareIEC 60601-1-4 and general software engineeringstandards were not considered adequateSignificant FDA involvement from startScope includes “stand-alone software” and “embeddedsoftware”Based on ANSI/AAMI/SW68 with a few significantdifferencesOmits requirements duplicated elsewhere (QMS)Adds requirements considered essential for medicaldevices (safety aspects)

4Status of IEC 62304 Approved by both IEC and ISO as an internationalstandard (joint development effort)Adopted by CENELEC as EN and harmonized 11/08under the MDD, AIMDD and IVDDAdopted by ANSI as US national standard (replacingANSI/AAMI/SW 68)Recognized by FDA for use in premarket submissionsChina – SFDA adopted 62304Translations exist in French, German, Spanish, Chineseand JapaneseAdopted as a Japan Industry Standard

562304 philosophy Safe medical device software requires riskmanagement, quality management and goodsoftware engineeringGood software engineering requires critical thinking– can’t be done by checklistManufacturers know more about their products thanregulatorsThe variety of medical devices requires a variety ofapproaches – one size does not fit allResources should be used on what is importantA standard should have minimum requirements, notbest practices

6IEC 62304 - What is it? A framework – processes, activities and tasks– Process is the top level, a process has activities andan activity has tasks. Specific requirements in IEC62304 are generally at the task level.Identifies requirements for what needs to bedone and what needs to be documentedSpecifies a software safety classification system–additional requirements apply as safety classificationincreases6

7IEC 62304 - What is not in it? Does not prescribe how to accomplishrequirements– Does not require a specific software life cycleDoes not specify documents– Not a “how to” with defined methods or practicesWhat to document, not where it must go.All of these decisions are left to themanufacturer7

8IEC 62304 - Key concepts Quality management and risk managementare necessary for safe medical devicesoftwareSoftware safety is classified according toseverity of potential harmThere are different requirements based onsoftware safety classification8

9IEC 62304 - Key concepts Software systems may be partitioned and thepartitions assigned different software safetyclassifications The software life cycle doesn’t end withproduct release9

10IEC 62304 Lifecycle IEC 62304 is a standard on lifecycles,however–– It does not define a specific lifecycle modelIt does not define specific documentsIt does define processes and activities thatmust be included in a conforming lifecycleIt implies dependencies between processes10

11Life cycle principles Process outputs should be maintained in aconsistent state– A change in an output requires related outputs tobe updatedProcess outputs should be available whenneeded as inputBefore release of software, all processoutputs should be consistent and alldependencies met11

62304 Table of Contents1.2.3.4.5.6.7.8.9.12ScopeNormative ReferencesTerms & DefinitionsGeneral RequirementsDevelopment ProcessMaintenance ProcessRisk ManagementConfiguration MgmtProblem Resolution Annex A –Rational forSafety Class Activities& TasksAnnex B – GuidanceAnnex C – Relationshipto other standardsAnnex D –Implementation in aformal Quality System

13Two types of requirements Process requirements which are necessarydetermine the RISKS arising from theoperation of each SOFTWARE ITEM in thesoftware;Process requirements which are necessaryto achieve an appropriately low probability ofsoftware failure for each SOFTWARE ITEM,chosen on the basis of these determinedrisks.13

14IEC 62304 - Process requirements Process requirements differ for differentsoftware safety classificationsAll classes – requirements needed for riskmanagement or software safety classificationClass B and C – requirements that enhance theconfidence in the reliability of the software orsupport the correction of safety-related problems14

1562304 Software SafetyClassificationSoftware System Overall Class A:No injury or damage to health is possible Class B:Non-serious injury is possible Class C: Death or serious injury is possibleClassification shall be documentedSoftware System may have lower worst case risk thandevice overall, but cannot be higher Both direct and indirect harm are includedClass C is the default assumption15

16Navigating 62304 Each normative section with an asterisk in the title has acorresponding explanatory section in Annex B.Annex B can be very helpful in interpreting the main bodyof the standard.Annex C provides comparison to other standards.––––– C.1 13485C.2 14971C.3 60601-1C.4 60601-1-4C.5 12207Annex D – Implementation into a Quality System16

17ANSI/AAMI/IEC 62304:2006Development Maintenance Risk Management Configuration Management Problem Resolution

18Software item Any structural part of the software. The toplevel is called the software system. Thelowest level is called the software unit.

19SOUPSoftware of unknown provenance– Commercial off the shelf software– Public domain software– Legacy software components withlimited information on developmentprocess or inadequate process Called OTS or COTS in other standards

20“As Appropriate” Where “as appropriate” is used, the intentionis that it shall be done unless there is adocumented justification for not doing it.– “as appropriate” is used a lot in IEC 62304to provide an escape for having to dothings that don’t make sense for a specificdevice. But, there must be a documentedjustification!

IEC 60601-1Medical ElectricalEquipment - Generalrequirements for basicsafety and essentialperformance

22Where does IEC 60601-1 fit? A product safety standardIncludes requirements for products that areprogrammable electrical medical systems(PEMS)PEMS decompose into programmable electricalsub-systems (PESS)Software is a PESSPEMS requirements apply to software (but alsoto any hardware developed for the PEMS)

23When the PEMS clause applies PEMS requirements do not apply if the PESSprovides no safety functionPEMS requirements do not apply if it can beshown using 14971 that the failure of thePESS does not lead to unacceptable riskAll PEMS requirements apply to software62304 is required in the first amendment to60601-1

IEC 80002-1

2580002-1 Scope Scope: Medical Devices containing software–Many of the same techniques used to assuresoftware reliability and quality are relevant toassuring software safety. This report does notdiscuss general aspects of software qualityassurance. Rather it is intended to highlight andexplain approaches to assuring that software safetyis adequately addressed part of an overallsoftware quality assurance process.Outside Scope production or assembly line software software tools (e.g. quality assurance systems)

26IEC TR 80002-1 Medical Device Software - Part 1: Guidance onthe application of ISO 14971 to medical devicesoftwareClause structure follows ISO 14971 – for eachrisk management activity of ISO 14971 additionalguidance is provided for softwarePublished by IEC in September, 2009

AAMI TIR 45

28 AAMI TIR 45 Guidance on the use of agilepractices in the development of medicaldevice software.

29TIR 45 Scope provides perspectives on the application ofAGILE during medical device softwaredevelopment. It relates them to the followingexisting standards, regulations, andguidance:ISO 13485:2003,IEC 62304,ISO 14971:2007FDA regulations and software guidance

IEC 80001 series

31An international effort IEC 80001-1:2010, Application of riskmanagement for IT-networks incorporatingMEDICAL DEVICES – Part 1: Roles,responsibilities and activities

3280001 approach Establish a framework for maintaining patientsafety, technology effectiveness and datasecurity when the point of care is a networknode and network use and technologyrapidly changeUtilize this framework to manage risk whenchanges are made to the network32

33What properties need to be ensured? From IEC 80001-1Risk management should be applied toaddress the following key properties .:–––safety;effectiveness (ability to achieve the intendedresult for the patient and the responsibleorganization); anddata and system security

34Who is needed? Responsible organization managementNetwork integrators and maintainersClinical engineersMedical device manufacturersNon-medical network technology vendorsNone of these parties can address the problemalone, problem solution for networks incorporatingmedical devices must be shared in a partnership orfederated model.

35What is a medical devicemanufacturer required to do? If the device is intended to connect to a network,provide information on:–––– Characteristics necessary to make the connection tosupport the deviceSecurity specificationsIntended information flow to other medical devices orapplicationshazardous situations resulting from a failure of the ITnetworkThese are equivalent to the requirements in IEC60601-1:2005 clause 14.13

36New challenges Supporting the hospital after sale of thedevice––– Additional information for hospital riskmanagementSupport for virus protection/security updates andpatchesDefined joint responsibility agreementWho will be responsible for these things forthe medical device manufacturer?

37How will IEC 80001-1 help? Will provide an approach that identifies roles,responsibilities and process necessary toaddress converging technologiesWill define standardized roles, riskmanagement process and information toallow effective sharing of experiencesIf used widely, will standardize how medicaldevice manufacturers and IT vendors provideinformation to hospitals

38IEC guidance documents Four guidance documents are available–––– Step by Step Risk Management of Medical ITNetworks; Practical Applications and ExamplesGuidance for the communication of medical devicesecurity needs, risks and controlsGuidance for wireless networksImplementation guidance for Healthcare DeliveryOrganizationsAdditional guidance documents being developed–––Guidance for distributed alarm systemsSelf-assessment of IEC 80001-1 in the hospitalSecurity requirements and assurance38

Changes to IEC 62304

40Revision of IEC 62304 Initiated in 2012Planned publication date of October 2015– Working group hopes to be earlyRecommended changes were to scope,software safety classification, legacysoftware, removal of common defects,addition of an annex on capability maturityassessment and various improvements andclarifications40

41IEC 62304 Revision Revision of 62304 will be done in 3 parts–Amendment to 62304 edition 1 –– Change to software safety classificationRequirements for legacy softwareMiscellaneous clarifications and technical changesCapability assessment will become a separateTechnical ReportSecond edition will expand scope from medical devicesoftware to health softwareAmendment to be published by October, 2015Assessment TR expected in 2015Second edition expected in 2016

42IEC 62304 AmendmentSoftware safety classification Needed change because too much softwarewas being classified as Class C Changes to software safety classification––Uses risk instead of consequence to determinesoftware safety classApplies system level risk management withoutsoftware risk controls prior to software safetyclassification

62304 Draft Amendmentclassification flow chart