มาตรฐานซอฟต์แวร์เครื่องมือแพทย์ (ตอนที่ 3)

มาตรฐาน IEC 60601-1 Cl.14 และ IEC 62304

กระบวนการพัฒนาซอฟต์แวร์ในมาตรฐาน IEC 62304 และ IEC60601-1 Clause 14 ใช้กระบวนการพัฒนาซอฟต์แวร์แบบจำลองวี (V Model) แสดงดังรูปที่ 6 ซึ่งใน IEC60601-1 Clause 14  ข้อกำหนดของซอฟต์แวร์ (Software System) เป็นหนึ่งในข้อกำหนดย่อยของ Programmable electrical medical system (PEMS)

ในระหว่างการพัฒนา PEMS มาตรฐาน IEC 62304 สามารถนำไปประยุกต์ใช้ในระดับคอมโพแนนท์ของ PEMS (PEMS component level) จากคุณลักษณะของความต้องการซอฟต์แวร์ ไปยังการประกอบของ ชิ้นส่วนซอฟต์แวร์ (Software Items) สู่การประกอบ ระบบซอฟต์แวร์ (Software System) ซึ่งระบบซอฟต์แวร์นี้คือส่วนหนึ่งของ Programmable electrical  subsystem (PESS) ดังนั้นมาตรฐาน IEC 62304 จะเป็นการทำการทวนสอบของระบบซอฟต์แวร์ (Software verification) ของ PESS ซึ่งไม่ครอบคลุมการตรวจสอบของระบบซอฟต์แวร์ (Software  validation)

จากรูปที่ 6 แสดงสัญลักษณ์ซึ่งมีความหมายดังต่อไปนี้

• พื้นที่เฉพาะสีเขียวคือ กระบวนการพัฒนาซอฟต์แวร์ในมาตรฐาน IEC 62304
• พื้นที่สีขาวรวมสีเขียวคือ กระบวนการพัฒนา PEMS ของ IEC60601-1 Clause 14
• กล่องสี่เหลี่ยม แทน กิจกรรมการพัฒนา
• ลูกศรเส้นทึบ แทน สิ่งส่งมอบ (Deliverables) ที่ถูกนำเข้า/ส่งออก ของกิจกรรม
• ลูกศรเส้นประ แทน สิ่งส่งมอบที่ถูกนำเข้าใน เอกสารการจัดการความเสี่ยง (Risk Management File)
• ลูกศรหนาหัวลูกศรไปทางขวา แทน สิ่งนำออก (Outputs) จากกระบวนการแก้ไขปัญหาซอฟต์แวร์ (Problem resolution Process)
• ลูกศรหนาหัวลูกศรไปทางซ้าย แทน สิ่งนำเข้า (Inputs) ในกระบวนการแก้ไขปัญหาซอฟต์แวร์ (Problem resolution Process)

IEC62304 ประกอบได้ด้วยข้อกำหนดหลัก 6 ข้อกำหนด คือข้อกำหนดที่ 4 – 9 ดังรูปที่ 7 ซึ่งอธิบายได้ดังนี้

4.1 IEC62304 Clause 4 General Requirement

ประกอบด้วยข้อกำหนดย่อย ดังนี้

• Clause 4.1 Quality management System เป็นข้อกำหนดการพัฒนาซอฟต์แวร์เครื่องมือแพทย์โดยมีระบบการจัดการด้านคุณภาพ โดยส่วนใหญ่อ้างอิงตาม ISO 13485
• Clause 4.2 Risk Management System เป็นข้อกำหนดการพัฒนาซอฟต์แวร์เครื่องมือแพทย์โดยมีระบบการจัดการด้านความเสี่ยง โดยส่วนใหญ่อ้างอิงตาม ISO 14971
• Clause 4.3 Software safety classification เป็นข้อกำหนดในการระบุประเภทความปลอดภัยของระบบซอฟต์แวร์ (Software System) ทั้งนี้ขออธิบายนิยามคำศัพท์ต่อไปนี้
• ประเภทความปลอดภัยของระบบซอฟต์แวร์ (The Software safety class) ถูกระบุตามระดับความรุนแรง (Severity) ดังนี้
  • Class A: ซอฟต์แวร์ที่ไม่ทำให้บาดเจ็บหรือเสียหายต่อสุขภาพ
  • Class B: ซอฟต์แวร์ที่อาจทำให้เกิดการบาดเจ็บเล็กน้อย (Non-SERIOUS INJURY)
  • Class C: ซอฟต์แวร์ที่อาจทำให้เกิดการบาดเจ็บขั้นสาหัส (SERIOUS INJURY) หรือ ตาย
• Software system คือระบบซอฟต์แวร์ หรือ PESS ซึ่งประกอบไปด้วยหลาย Software item
• Software item คือ ชิ้นส่วนซอฟต์แวร์ ซึ่งสามารถประกอบไปด้วยหลาย Software item
• Software of unknown provenance – SOUP เป็นซอฟต์แวร์ที่นำมาพัฒนาโดยไม่ทราบกระบวนการพัฒนาซอฟต์แวร์ และไม่ทราบคุณลักษณะความปลอดภัย
• Legacy software เป็นซอฟต์แวร์ที่นำมาพัฒนาโดยทราบกระบวนการพัฒนาซอฟต์แวร์ และทราบคุณลักษณะความปลอดภัย

รูปที่ 8 โครงสร้างองค์ประกอบระบบซอฟต์แวร์และประเภทความปลอดภัยของซอฟต์แวร์

การระบุประเภทความปลอดภัยของระบบซอฟต์แวร์ มีขั้นตอนดังนี้ โดยเริ่มจาก ต้องทราบถึงโครงสร้างองค์ประกอบของระบบซอฟต์แวร์ที่ประกอบไปด้วยหลายชิ้นส่วนซอฟต์แวร์ หลังจากนั้นจะดำเนินการประเมินระดับความรุนแรง (Severity) ของแต่ละชิ้นส่วนซอฟต์แวร์ ทั้งนี้จะสรุปได้ว่าระบบซอฟต์แวร์นั้นๆ เป็นประเภทความปลอดภัยประเภทไหน โดยจะมีเงื่อนไขการพิจารณาจากระดับความรุนแรงของชิ้นส่วนซอฟต์แวร์ที่รุนแรงมากที่สุด ยกตัวอย่างเช่น

• ตัวอย่างที่ 1 ถ้ามีชิ้นส่วนของซอฟต์แวร์ที่มีระดับความรุนแรงทั้ง C B A ดังนั้นระบบซอฟต์แวร์เป็น ประเภทความปลอดภัย C
• ตัวอย่างที่ 2 ถ้ามีชิ้นส่วนของซอฟต์แวร์ที่มีระดับความรุนแรงทั้ง B A ดังนั้นระบบซอฟต์แวร์เป็น ประเภทความปลอดภัย B
• ตัวอย่างที่ 3 ถ้ามีชิ้นส่วนของซอฟต์แวร์ที่มีระดับความรุนแรงทั้ง A ดังนั้นระบบซอฟต์แวร์เป็น ประเภทความปลอดภัย A

ยกตัวอย่างเช่น โครงสร้างองค์ประกอบระบบซอฟต์แวร์ เป็นดังรูปที่ 8 คือ ระบบซอฟต์แวร์ ประกอบไปด้วย ชิ้นส่วนซอฟต์แวร์ X และ Y โดยที่ ชิ้นส่วนซอฟต์แวร์ Y ประกอบไปด้วย ชิ้นส่วนซอฟต์แวร์ W และ Z ซึ่งมีระดับความรุนแรง Class B และ C ตามลำดับ แสดงว่า ชิ้นส่วนซอฟต์แวร์ Y มีระดับความรุนแรง Class C แม้ว่า ชิ้นส่วนซอฟต์แวร์ X มีระดับความรุนแรง Class A แต่ ชิ้นส่วนซอฟต์แวร์ Y มีระดับความรุนแรง Class C สรุปว่า ระบบซอฟต์แวร์นี้ มีระดับความรุนแรง Class C

4.2 IEC62304 Clause 5 Software development process

ซึ่งขั้นตอนการพัฒนาซอฟต์แวร์เป็นไปตามรูปที่ 6 ประกอบด้วยข้อกำหนดย่อย ดังนี้

• Clause 5.1 Software development planning คือการวางแผนพัฒนาซอฟต์แวร์
• Clause 5.2 Software requirement analysis คือการวิเคราะห์ความต้องการซอฟต์แวร์ ซึ่งต้องมีการวิเคราะห์ความต้องการซอฟต์แวร์ด้าน การทำงานเชิงหน้าที่ (Functional Suitability) และคุณภาพด้านอื่นๆ (Non Functional)
• Clause 5.3 Software Architectural design คือ การออกแบบสถาปัตยกรรมซอฟต์แวร์ ดังตัวอย่างโครงสร้างระบบซอฟต์แวร์ในรูปที่ 8 เป็นต้น ซึ่งต้องมีการวิเคราะห์การระบุ Software item, SOUP, Legacy software
• Clause 5.4 Software detail design คือการออกแบบซอฟต์แวร์อย่างละเอียด
• Clause 5.5 Software unit implementation and verification คือการดำเนินการโค้ดแต่ละ Software item และการทำทวนสอบของซอฟต์แวร์ (Software verification)
• Clause 5.6 Software integration and integration testing คือการประกอบแต่ละ Software item และการทำทดสอบระดับการประกอบ ยกตัวอย่างรูปที่ 9 มี 2 การประกอบคือ 1) ประกอบ Software item Y โดยการประกอบ Software item W และ Z แล้วทดสอบการประกอบ และ 2) ประกอบ Software System โดยการประกอบ Software item X และ Y
• Clause 5.7 Software system testing คือ การทดสอบทั้งระบบซอฟต์แวร์ แสดงดังรูปที่ 9 พื้นที่วงกลม
• Clause 5.8 Software release คือการเตรียมการติดตั้ง ติดตั้ง ทดสอบการติดตั้ง

 รูปที่ 9 ระดับการทดสอบซอฟต์แวร์

4.3 IEC62304 Clause 6 Software maintenance process

ประกอบด้วยข้อกำหนดย่อย ดังนี้

• Clause 6.1 Establish software maintenance plan คือการจัดทำแผนการบำรุงรักษาซอฟต์แวร์
• Clause 6.2 Problem and modification analysis คือการวิเคราะห์ปัญหาและการแก้ไข หลังจากที่ส่งมอบระบบซอฟต์แวร์แล้ว
• Clause 6.3 Modification Implementation คือ การดำเนินการแก้ไขหลังจากที่ทำ Clause 6.2 แล้ว

4.4 IEC62304 Clause 7 Software Risk management process

ประกอบด้วยข้อกำหนดย่อย ดังนี้

• Clause 7.1 Analysis of software contributing to hazardous situations คือการวิเคราะห์สถานการณ์อันตรายจาก Software item, SOUP, Legacy software
• Clause 7.2 Risk control measures คือมาตรการการลดความเสี่ยงของ Clause 7.1
• Clause 7.3 Verification of risk control measures คือ การทวนสอบของมาตรการการลดความเสี่ยง
• Clause 7.4 Risk management of software changes คือการจัดการความเสี่ยงของการเปลี่ยนแปลงซอฟต์แวร์

ทั้งนี้ IEC62304 Clause 7 สามารถต่อยอดจาก IEC62304 Clause 4.2 Risk Management

4.5 IEC62304 Clause 8 Software configuration management process

ประกอบด้วยข้อกำหนดย่อย ดังนี้

• Clause 8.1 Configuration identification คือการระบุ work product/output ที่จะควบคุม ดังตัวอย่างรูปที่ 10 เช่น เอกสารการออกแบบ เป็น Configuration identification-CI การควบคุมได้แก่
• การตั้งชื่อ (Naming convention) เป็นการตั้งชื่อเอกสาร เช่น
  • แบบฟอร์ม มีหลักการตั้งชื่อเอกสารมาตรฐานมีรูปแบบดังนี้

 F-ลำดับเอกสาร –ชื่อเอกสารภาษาอังกฤษ 

โดย ชื่อเอกสารภาษาอังกฤษ จะต้องใช้ชื่อที่สื่อความหมายเหมาะสมกับเนื้อหา ซึ่งตัวอักษรแรกของคำเป็นตัวพิมพ์ใหญ่เสมอ ยกเว้นเป็นคำบุพบทหรือคำเชื่อมตัวอย่าง

เช่น F-001-SoftwareDevelopmentPlan แบบฟอร์มแผนการพัฒนาซอฟต์แวร์

ตั้งชื่อไฟล์เป็น xxx-SoftwareDevelopmentPlan

• การจัดเก็บ เช่น เก็บในสื่ออิเล็กทรอนิกส์ (Floder) เก็บในแฟ้มหรือตู้
• การระบุเวอร์ชัน (Versioning) เป็นการกำหนดการระบุเวอร์ชันของ work product/output ดังรูปที่ 11 ด้านซ้าย
• การกำหนดเส้นทางการพัฒนา (Development Path) เป็นการกำหนดการระบุเส้นทางพัฒนาของโค้ดโปรแกรม ดังรูปที่ 11 ด้านขวา
• Clause 8.2 Change control คือการควบคุมการเปลี่ยนแปลง ยกตัวอย่างกระบวนการการควบคุมการเปลี่ยนแปลง ดังรูปที่ 12
• Clause 8.3 Configuration status accounting คือ กระบวนการติดตามสถานะของ Configuration เช่น สถานะ การจัดทำ การทบทวน การอนุมัติ เป็นต้น

รูปที่ 10 ตัวอย่าง Configuration Item

รูปที่ 12 ตัวอย่างกระบวนการเปลี่ยนแปลงซอฟต์แวร์ (Software Change Process)

4.6 IEC62304 Clause 9 Software problem resolution process

ประกอบด้วยข้อกำหนดย่อย ดังนี้

• Clause 9.1 Prepare problem reports คือการเตรียมการรายงานปัญหา
• Clause 9.2 Investigate the problem คือการตรวจสอบปัญหา
• Clause 9.3 Advise relevant parties คือ การดำเนินการผู้ที่เกี่ยวข้อง
• Clause 9.4 Use change control process คือ การใช้กระบวนการควบคุมการเปลี่ยนแปลง
• Clause 9.5 Maintain records คือ การบันทึกสถานะการแก้ปัญหา
• Clause 9.6 Analyse problems for trends คือการวิเคราะห์แนวโน้มของปัญหาที่อาจจะเกิดขึ้น
• Clause 9.7 Verify software problem resolution คือ การทวนสอบการแก้ปัญหาซอฟต์แวร์
• Clause 9.8 Test documentation contents คือ การทดสอบเนื้อหาของเอกสารต่างๆ

ตัวอย่างกระบวนการแก้ไขปัญหาซอฟต์แวร์ (Software Problem Resolution) แสดงดังรูปที่ 13

รูปที่ 13 ตัวอย่างกระบวนการแก้ไขปัญหาซอฟต์แวร์ (Software Problem Resolution)

หลังจากพัฒนาซอฟต์แวร์เครื่องมือแพทย์แล้วสามารถตรวจสอบ รายการหลักฐาน (Evidence List) ดังรูปที่ 14 ซึ่งเป็น รายการหลักฐาน ตามข้อกำหนดหลักและข้อกำหนดย่อยของ IEC62304 เพื่อเตรียมตัวส่งหลักฐานทั้งหมดให้กับ Testing Lab ต่อไป

บทความทั้ง 3 ตอนนี้ คือภาพรวมของมาตรฐาน IEC62304 ซึ่งเป็นมาตรฐานเกี่ยวกับกระบวนการพัฒนาซอฟต์แวร์เครื่องมือแพทย์ ซึ่งในบทความต่อไป เราจะมาพูดถึงในส่วนของมาตรฐานที่เกี่ยวข้องกับซอฟต์แวร์เครื่องมือแพทย์อีก 1 มาตรฐาน นั่นก็คือ IEC60601-1 Clause14  แล้วพบกันค่ะ…

อ้างอิง

[1] Roger Pressman. 2009. Software Engineering: A Practitioner’s Approach (7 ed.). McGraw-Hill, Inc., New York, NY, USA.

[2] Ivan Mistrik, Richard M. Soley, Nour Ali, John Grundy, and Bedir Tekinerdogan. 2015. Software Quality Assurance: In Large Scale and Complex Software-Intensive Systems (1st ed.). Morgan Kaufmann Publishers Inc., San Francisco, CA, USA.

[3] Medical Device Software—Software Life Cycle Processes, ANSI/AAMI/IEC 62304, 2006.

ผู้เขียน : ดร.พนิตา เมนะเนตร

ภาพปก : https://bit.ly/3eTeoHV