Kegagalan aplikasi perangkat lunak untuk berfungsi dengan benar pada alat medis dapat mengakibatkan kematian atau cidera serius pada pasien. Sebuah analisis dari 3140 alat medis yang ditarik dari pasaran antara tahun 1992 dan 1998 oleh US FDA, mengungkapkan bahwa 242 (7,7%) dari alat-alat medis tersebut disebabkan oleh kegagalan perangkat lunak. Dari 242 kasus kegagalan perangkat lunak tersebut, 192 (79%) kasus disebabkan cacat setelah perangkat lunak di-upgrade.

Hal ini mengakibatkan perubahan pada banyak perusahaan produsen alat medisterhadap pendekatan mereka untuk meningkatkan proses perangkat lunak mereka serta untuk mengadopsi IEC 62304, yaitu standar desain produk medis yang didukung oleh Uni Eropa dan Amerika Serikat. IEC 62304 memperkenalkan struktur kepatuhan berbasis resiko yang dibagi menjadi 3 kelas, yaitu:

1.  Kelas A: Bila tidak mungkin terjadi cedera atau kerusakan pada kesehatan 
2.  Kelas B: Bila memungkinkan terjadi cidera yang tak serius 
3.  Kelas C: Bila memungkinkan kematian atau cidera serius

Standar ini menguraikan persyaratan untuk setiap tahap siklus pengembangan dan mendefinisikan aktivitas minimum dan tugas-tugas yang akan dilakukan untuk memberikan keyakinan bahwa perangkat lunak telah dibuat dengan suatu cara untuk menghasilkan produk perangkat lunak yang sangat handal dan aman. Seperti yang terlihat pada gambar 1, IEC 62304 berfokus pada proses pengembangan perangkat lunak, mendefinisikan sebagian besar proses dan aktivitas pembuatan dan verifikasi perangkat.

Proses manajemen resiko perangkat lunak berdasarkan IEC 62304 ini dimaksudkan untuk memberikan persyaratan tambahan, yaitu pengendalian resiko perangkat lunak. Menurut standar, produsen harus mengidentifikasi item perangkat lunak yang dapat berkontribusi pada situasi berbahaya dan penyebab potensialnya. Penyebab potensial ini harus didokumentasikan dalam file manajemen resiko, yang harus berisi identifikasi urutan kejadian yang dapat mengakibatkan situasi yang membahayakan.

Langkah-langkah kendali resiko untuk tiap penyebab potensial yang ada harus didefinisikan dan didokumentasikan. IEC 62304 mensyaratkan pengendalian resiko ini untuk kemudian dilaksanakan, diverifikasi dan didokumentasikan. Kemampuan telusur harus bisa dilakukan untuk situasi berbahaya, item-item perangkat lunak, penyebab masalah perangkat lunak yang berpotensi, langkah-langkah kendali resiko dan verifikasi langkah-langkah kendali resiko. Dengan cara ini, manajemen resiko memainkan peran utama dalam proses pemeliharaan perangkat lunak.

Pada IEC 62304, sebagaimana terlihat pada tabel 1, klasifikasi tingkat keamanan perangkat memainkan peran utama dalam menentukan kegiatan yang akan ditetapkan untuk pembuatan perangkat lunak. Sebuah perangkat kelas A membutuhkan kegiatan minimal untuk menghasilkan disain prangkat lunak, sedangkan perangkat Kelas C mengharuskan semua kegiatan untuk dilaksanakan.

Semua perangkat lunak alat  medis harus menjalani analisis manajemen kebutuhan dan kemampuan telusur di seluruh siklus hidup pembuatan  perangkat lunak. Kebutuhan  yang telah ditetapkan dan diverifikasi adalah penting untuk mendefinisikan apa yang akan dibuat, menentukan apakah perangkat lunak alat medis telah menunjukkan perilaku yang dapat diterima, dan menunjukkan apakah perangkat lunak alat  medis yang telah selesai siap digunakan.

IEC 63204 menuntut bahwa semua kebutuhan perangkat lunak diidentifikasi sehingga bisa untuk ditelusuri antara kebutuhan dan pengujian sistem perangkat lunak. Selain itu, hal  ini memungkinkan pengembang untuk metelusuri aktivitas pengendalian resiko kebutuhan perangkat lunak.

Kemampuan Telusur Kebutuhan

Kemampuan telusur kebutuhan secara luas diterima sebagai suatu praktik terbaik pembuatan perangkat lunak untuk memastikan bahwa semua kebutuhan telah diimplementasikan dan semua pembuatan artifak dapat ditelusur kembali. Otomasi kemampuan telusur membutuhkan Requirements Traceability Matrix (RTM).

Gambar 2 menunjukkan bagaimana manajer proyek dapat melihat dan membuat kebutuhan proyek, dan menelusuri mereka kembali ke sumber-sumber asal mereka saat ada permintaan tambahan atau perubahan kebutuhan. Pengembang dapat meninjau kebutuhan (dan menggunakan kasus jika ada) saat mereka sedang mendisain perangkat lunak. Penguji bisa menjadikannya sebagai lompatan awal untuk kegiatan pengujian dengan melihat kebutuhan proyek secara langsung. Administrator dapat mencakup kebutuhan saat membuat baseline proyek. Eksekutif dapat memonitor “dashboard” status proyek, mendapatkan informasi kinerja secara garis besar.

IEC 62304 sub klausa 5.1.1 seksi C secara khusus membahas kemampuan telusur yang ditetapkan antara kebutuhan sistem, kebutuhan perangkat lunak, uji sistem perangkat lunak dan langkah-langkah kendali resiko yang diimplementasikan dalam perangkat lunak. RTM memainkan peran utama dengan menghubungkan berbagai tingkatan dari siklus hidup pengembangan perangkat lunak. RTM menyediakan kemampuan telusur antara kebutuhan arsitektur tingkat tinggi dan rendah dari perangkat lunak. Hal ini juga membantu memastikan apakah ada penyimpangan dalam desain dari kebutuhan, termasuk yang terkait dengan pengendalian resiko per IEC 62304 sub klausa 5.3.6.

RTM menyediakan kemampuan telusur lebih lanjut antara arsitektur perangkat lunak dan desain detil perangkat lunak, di mana arsitektur perangkat lunak dirinci menjadi unit perangkat lunak. RTM membantu memastikan bahwa unit perangkat lunak tidak bertentangan dengan arsitektur perangkat lunak.

Pemrograman dimulai selama implementasi unit, dimana setiap unit perangkat lunak diimplementasikan sesuai dengan kebutuhan desain. RTM menelusuri unit yang diimplementasikan dengan unit perangkat lunak bersama dengan berbagai kegiatan verifikasi statis yang dilakukan selama verifikasi kode dan juga memetakan rencana verifikasi dengan analisis dinamis yang dilakukan selama pengujian unit, integrasi, dan sistem.

Penggunaan RTM memungkinkan manajer proyek untuk dapat memperkirakan dampak perubahan kebutuhan (analisis dampak) dan bagaimana hal itu mempengaruhi sistem. Kita bisa melihat dari diagram, bahwa ketika RTM menjadi pusat dari proses pembangunan, akan berdampak pada semua tahap desain, dari kebutuhan tingkat tinggi sampai pada kebutuhan tingkat rendah yang berbasis target.

Integrasi manajemen kebutuhan dengan alat bantu lain akan dapat menghemat waktu dan menghindari pengerjaan ulang. Kebutuhan terintegrasi dengan petelusuran cacat, pengembangan visual dan alat pengujian dapat menjadi batu loncatan bagi tim untuk merancang dan mulai melakukan kegiatannya, serta memberikan tiap peran dari tim akses langsung ke kebutuhan pengguna akhir.

IEC 62304 dan Perawatan

Tanggung jawab produsen tidak berakhir setelah merilis produk perangkat lunak. IEC 62304 juga mencakup fokus pada pemeliharaan produk. Banyak insiden dalam industri perangkat medis yang berkaitan dengan layanan atau pemeliharaan sistem perangkat medis, termasuk perbaikan dan upgrade perangkat lunak, proses perawatan perangkat lunak dianggap sama pentingnya dengan proses pengembangan perangkat lunak.

IEC 62304 berharap dapat mengurangi tingginya persentase cacat dari perangkat lunak alat medis setelah dirilis. Seperti yang terlihat pada gambar 4, sebuah proses pemeliharaan perangkat lunak yang sehat sangat mirip dengan proses pengembangan perangkat lunak yang solid, dengan penambahan analisis masalah dan modifikasi serta pelaksanaan kegiatan modifikasi. Proses pemeliharaan mengharuskan produsen memonitor umpan balik dari produk yang dirilis baik dari dalam organisasi maupun dari pengguna. Umpan balik ini harus didokumentasikan dan dianalisis untuk menentukan apakah ada masalah. Ketika masalah ditemukan, laporan masalah harus dibuat.

Menurut pedoman manajemen resiko IEC 62304, laporan masalah dievaluasi untuk menentukan bagaimana masalah ini mempengaruhi keamanan produk yang dirilis dan untuk memutuskan apakah diperlukan upgrade atau patch. Produsen juga harus memverifikasi bahwa upgrade atau patch tidak menimbulkan bahaya atau membuat resiko dalam perangkat lunak.

RTM kemampuan telusur otomatis yang baik memungkinkan produsen untuk mengadopsi proses pengembangan perangkat lunak yang ada untuk melaksanakan modifikasi. Analisis regresi menyeluruh memastikan bahwa modifikasi tidak menyebabkan bahaya baru dan berdampak buruk terhadap tindakan pengendalian resiko yang dibangun ke dalam perangkat yang ada.

Sebagai bagian dari alat  medis, proses perawatan perangkat lunak perlu memastikan bahwa  laporan masalah yang terkait dengan keselamatan ditangani dan dilaporkan kepada otoritas yang sesuai dengan peraturan dan pengguna yang terkena. Produk perangkat lunak harus divalidasi ulang dan dirilis ulang setelah modifikasi dengan kendali formal yang menjamin perbaikan dari masalah dan menghindari masalah lebih lanjut.

Sesuai IEC 62304, manajemen resiko merupakan bagian integral dari seluruh siklus hidup pengembangan perangkat lunak untuk alat  medis. Karena masalah endemik dengan update perangkat lunak secara langsung berkontribusi terhadap resiko keamanan, sebagian besar proses dan kegiatan yang terlibat dalam standar berbicara tentang manajemen resiko, langsung dari perencanaan pengembangan perangkat lunak, manajemen kebutuhan, desain arsitektur, coding dan verifikasi sampai pemeliharaan.

Pernyataan ini membutuhkan penggunaan proses manajemen resiko yang sesuai dengan ISO 14971. Manajemen resiko sebagaimana didefinisikan dalam ISO 14971 menawarkan kerangka kerja khusus untuk manajemen resiko yang efektif terkait dengan penggunaan alat-alat medis.

Kesimpulan

Munculnya IEC 62304 membawa perusahaan yang terlibat dalam sistem dan pengembangan perangkat lunak untuk industri medis ke dalam proses yang sama seperti rekan-rekan mereka dalam industri seperti aerospace dan kereta api. Semua kini menghadapi upaya yang diperlukan untuk mencapai kesesuaian dengan tuntutan standar.

Kebutuhan kepatuhan tersebut telah mengamanatkan evolusi bisnis di mana proses dan rencana proyek harus didokumentasikan, kebutuhan diakuisisi, implementasi dan verifikasi dilakukan sehubungan dengan kebutuhan, dan semua artefak sepenuhnya dikendalikan dalam sistem manajemen konfigurasi.

Mengadopsi IEC 62304 sebagai proses untuk pengembangan perangkat lunak alat medis memerlukan kesesuaian dengan proses, kegiatan dan tugas-tugas yang ditetapkan oleh standar. Klasifikasi keamanan perangkat yang ditetapkan oleh produsen memainkan peran utama dalam menentukan usaha yang diperlukan untuk mengembangkan perangkat lunak. Pada dasarnya, IEC 62304 menuntut bahwa kebutuhan mampu telusur dipenuhi pada semua tahap proses pengembangan perangkat lunak, serta kemampuan telusur terhadap tindakan kendali resiko juga.

Alat bantu yang terintegrasi dengan baik akan memastikan pengembang dapat mengotomatisasi proses lebih mudah dan efisien. Walau akan membutuhkan biaya awal dan berpotensi terjadi perubahan terhadap praktek yang telah berlangsung, kepatuhan terhadap IEC 62304 menghasilkan kualitas yang lebih tinggi. Sebuah produk yang aman akan menghindarkan resiko terhadap penarikan kembali prosuk cacat yang akan menimbulkan kerugian tak sedikit nilainya dan memastikan bahwa proses pembangunan yang sama dapat mendukung proses pemeliharaan dan upgrade. ROI pembuatan perangkat lunak akan dapat dicapai lebih cepat seiring dengan peningkatan kredibilitas dan reputasi.

[ROM]