VC
VC

服務生醫產業超過25年,經歷研發/產品管理/事業開發/銷售業務/品保法規等工作,工作橫跨美國,台灣,產品經歷家用醫材/專業醫材/實驗室設備等,在這個園地貢獻自己一點經驗及想法。

醫材設計方法論(5)-核心觀念 設計管制 Design Control

本設計控制(Design Control),以FDA的Design Control架構為基礎,並就產品生命週期(Product Life Cycle)的過程,作一個對應的說明

前言 Introduction

硬體的醫材設計,或是軟體的醫材設計,可能會有法規要求上的不同,但基本的核心架構Design Control 是一樣,這裡以FDA在1997年發布的Design Control圖(Fig.1)為基礎做個說明,並統整前4章內容

Fig 1 Design Control Process with note of QSR reference https://www.qualitydigest.com/IQedit/Images/Articles_and_Columns/2014/Jan_2014/FdaDesign.jpg

Design Control的核心精神為,把設計流程架構化為5個步驟,2個節點,也就是Verification(驗證) & Validation(確效),每個步驟經過審核(review)的手段,確保設計輸出的產品符合設計輸入的要求

使用者需求(User Needs)

這有可能是行銷部門或是客人在市場上看到的需求,此時將本需求提出給產品開發單位或是醫材公司等,鑑於開立需求方的經驗,有些人可能可以把需求開到鉅細靡遺,如同一些OEM的案例,但通常提供的需求可能比較籠統,比如說要一台大螢幕,可視型佳的血壓計,需要那些配件,預計銷售區域,價格需要在多少美元內等等,這大概描述了市場的需求,但距離產品實現則有一段距離

設計輸入(Design Input)

身為客戶與研發/工程單位的介面,如產品經理,接到行銷部門或是客人的需求時,其首要任務就是要把籠統的需求,轉變成研發/工程單位可以具體執行的需求,這時就是通稱的規格(Specification),規格的要素在於可被量測(Measurable)如Fig2,如產品規格所提到的尺寸,以及法規要求的檢驗規範等,因為可被量測(Measurable),所以在設計輸出時就可評量是否達到標的?

Fig 2 Convert abstract info into Concrete & Measurable 轉換抽象的資訊至具體可量測的資訊

細項分類可參考Fig 3, 通常常見的作法是把客人的需求,由產品經理轉換成技術及法規需求,經過法規鑑定,工程可行性分析後訂出工程及法規的需求,工程的需求有功能,性能,法規需求有安規測試,臨床性能等可以列入工程需求,也有非工程需求者如標示內容,手冊說明等

在很多公司,這類把前端需求所轉換成的需求書為產品需求書Product Requirements Documents (PRD),這類文件最大的好處為客人與工程兩端皆可了解的文件,甚至為開發合約的依據

最後,這些需求會轉換成規格,工程規格如電路設計,機構尺寸,非工程規格則為手冊標示,內容,步驟說明等

Fig 3 Converting requirements into specification 需求轉換成規格

為何特別強調要列入法規需求的原因,在以下的文章已有詳細描述

https://medium.com/醫療器材工作者隨筆/醫材設計方法論-2-風險管理與設計輸入-觀念-242b1370f8fe

美國國防部曾推崇Motorolla在軟體開發的作法,該公司花70%的時間在設計輸入規劃上,如流程圖,待架構確認完成, 30%的時間就用在細節的coding,這裡也是強調類似觀念,把所有的需求整合成工程規格,建立其關聯性,最後在設計驗證結束後,可有效追溯其與需求的關係

另外,有些公司,法規與工程單位各行其事,常常發生遺漏的問題,用這類手段可有效避免這類問題發生

設計過程

工作樣品(Working Sample)

設計輸入後,開發部門將其開展細部設計,這時初步的成果會是原型機,重點是驗證基本功能是否達到,及評估可能的使用的問題,電路板可能經過不斷的跳線,而機構,這時不適合開模具,所以將機構設計用CNC,立體成形,或是3D列印的手法製作,除了測試基本機構功能外,也同時評估未來工廠組裝時可能遇到的問題,這時的樣品,稱為工作樣品(Working Sample)

此時,工作樣品是進行人因可用性工程的形成性評估(Formative Evaluation)的最佳選擇

人因可用性工程

人因可用性工程其就從產品的預期用途(Intended use)/使用者/使用環境之描述勾畫出產品的使用輪廓,再從使用者介面/程序,參照相關類似產品的過去使用問題通報歷史如FDA的MAUDE資料庫,進行風險分析,這還是設計輸入階段,但設計輸入不是一次的過程,在設計過程中會不斷的反饋至設計輸出

風險分析制訂初期形成性評估(Formative Evaluation),這時可用工作樣品進行評估,決定關鍵任務,在最後的設計產出進行總結式評估(Summative Evaluation),確認產品安全及有效性,如下圖

Page 4 of https://www.philips.com/c-dam/b2bhc/master/resource-catalog/landing/experience/breathing-and-respiratory-care/clinical-campaigns/2019/innospire-go-mesh-nebulizer-technology/innospire-go-usability-human-factors-discussion-guide.pdf

https://medium.com/醫療器材工作者隨筆/醫材設計方法論-3-人因可用性工程-39185369527

在進入工程樣品階段前,盡可能用測試發現問題,因為如果在工程樣品階段進行改良,這時所花的時間/成本遠高於工作樣品階段

設計輸出(Design Output)

就如同前面所述,在工作樣品(Working Sample)階段,會不斷找出問題,並加以改良,這是的設計輸出,還是在設計輸出->設計輸入->設計過程->設計輸出這個迴圈,但最後確認設計沒有問題,這時的設計輸出,等同設計移轉(Design Transfer)

設計移轉(Design Transfer)或工程試做(Engineering Transfer)

設計移轉(Design Transfer)的目的是把研發在實驗室階段的產品,移轉到工廠的工程單位,進行工程開發,轉換成工廠可以量產的產品,比如,原來是用CNC做成的機構,變成用模具製作,故可以速度快,品質一致,電路板經過調整,可以被SMT打件大量生產等,這時後試做出來的樣品為工程樣品(Enginnering Sample),通常在這個階段,產品已接近量產品等級,如果這時發現問題,則需回到原來的設計輸入,重新修正設計,這時對成本/時間所造成傷害,遠大於工作樣品階段

試量產(Pilot Run)

工作樣品確認沒問題時,這時候就根據工程試做所用的設備,以及工程設計,進行3批試產, 但確認試產產品符合允收規格時,這時符合進入大量生產(Mass Production) 的資格

驗證 Verification

因為試量產產品可視為等同量產產品,故可進行安規測試,如EMI/EMC,落下,震動等測試,以及人因工程的總結式評估(Summative Evaluation)

當安規測試結果符合規範時,理論上,這是符合安全規範的產品,所以才能進入臨床實驗

追溯矩陣Traceability Matrix

設計管制的核心精神為確認設計輸出符合設計輸入要求,但就專案執行上,常常會遇到項目遺漏,所以得補上設計,或是重新來過,這時在管理方面在設計的過程中,就要建立一個追溯手法,在產品需求書建立時,就需要參考風險分析結果,把列出的風險列入產品需求,製作產品需求書,一定要有條列項目編號,以利追蹤,下一步,開發工程規格(Enginnering Spec)時,最好建立一個工程規格與產品需求的關聯表,以確定設計需求都被導入了工程規格,最後規劃測試時,也從工程規格導入測試項目,行筆至此,讀者應該可以了解,為何規格需要具備可被量測(Measurable)的特性?因為如此才能被檢驗,所以這是一個科學的做事方式,最後把風險ID到最後的測試結果製作出一個關聯表,就是追溯矩陣(Traceability Matrix),如Fig 4.

Fig 4. Traceability Matrix

這類的表格,其實在軟體確效(Software V&V)文件常見,PRD改成SRS(software Requirement Spec), ES改成SDS(Software Design Spec)

確效Validation

Validation(確效)常用的手法為臨床試驗,確認該醫材的clinical performance在是否符合法規的要求,一個測不準的血壓計,或是血糖機,簡言之,就不是“有效能”的器材,故不能上市

https://medium.com/醫療器材工作者隨筆/醫材設計方法論-4-verification-驗證-validation-確效-b193b11e9b10

完成Validation(確效)後,就是整理出技術檔案(Technical Files),提供相關主管機關(Competent Authority)審核,取得上市許可

維護Maintenance

產品上市後,經過使用,會發現更多的問題,或是新的需求,這時候如果需要修改,則需進行工程變更需求Engineering Change Request (ECR),經過公司內部核可時,這時就開始發佈工程變更指令 Engineering Change Order (ECO)通知工程單位進行變更,變更結束後,確認符合設計需求,風險在可接受程度,這時發佈工程變更通知Engineering Change Notice (ECN),所有的設計技術資料進入新的版本

衍生機種Derivative Model 與工程變更 Engineering Change

有些公司在開發衍生機種時,採用工程變更的程序執行,這種作法不建議採用,原則上只有在確認衍生機種完全取代現有機種時,可採取工程變更的程序執行,但是如果有原生機種及衍生機種並存的需求,則衍生機種需要另外再開專案,否則無法鑑別產品差異,在整個產品控管肯定出大問題

後記 Note

從這幾節的描述,可發想設計管制Design Control, 是一種有系統性的作事方式,以確保設計品質,所有產品最大的問題,大都來自設計不良,這也是品質管理系統會重視設計管制的原因,好的品質,其實是設計出來的

如果讀者是剛進入的新手,要了解本流程最好的方式,為把本文內容,製作出一個流程圖,這時可形成一個架構,對專案管理會有一個系統性的掌握


CC BY-NC-ND 2.0 版权声明

喜欢我的文章吗?
别忘了给点支持与赞赏,让我知道创作的路上有你陪伴。

加载中…
加载中…

发布评论