本設計控制(Design Control),以FDA的Design Control架構為基礎，並就產品生命週期(Product Life Cycle)的過程，作一個對應的說明
前言 Introduction
硬體的醫材設計，或是軟體的醫材設計，可能會有法規要求上的不同，但基本的核心架構Design Control 是一樣，這裡以FDA在1997年發布的Design Control圖(Fig.1)為基礎做個說明，並統整前4章內容
Design Control的核心精神為，把設計流程架構化為5個步驟，2個節點，也就是Verification(驗證) & Validation(確效），每個步驟經過審核（review)的手段，確保設計輸出的產品符合設計輸入的要求
使用者需求（User Needs)
這有可能是行銷部門或是客人在市場上看到的需求，此時將本需求提出給產品開發單位或是醫材公司等.
鑑於開立需求方的經驗，有些人可能可以把需求開到鉅細靡遺，如同一些OEM的案例.
但通常提供的需求可能比較籠統，比如說要一台大螢幕，可視型佳的血壓計，需要那些配件，預計銷售區域，價格需要在多少美元內等等，這大概描述了市場的需求，但距離產品實現則有一段距離
設計輸入(Design Input)
身為客戶與研發/工程單位的介面，如產品經理，接到行銷部門或是客人的需求時，其首要任務就是要把籠統的需求，轉變成研發/工程單位可以具體執行的需求，這時就是通稱的規格(Specification).
規格的要素在於可被量測（Measurable)如Fig2,如產品規格所提到的尺寸，以及法規要求的檢驗規範等.
因為可被量測（Measurable),所以在設計輸出時就可評量是否達到標的？
細項分類可參考Fig 3, 通常常見的作法是把客人的需求，由產品經理轉換成技術及法規需求.
經過法規鑑定，工程可行性分析後訂出工程及法規的需求.
工程的需求有功能，性能.
法規需求有安規測試，臨床性能等可以列入工程需求，也有非工程需求者如標示內容，手冊說明等
在很多公司，這類把前端需求所轉換成的需求書為產品需求書Product Requirements Documents (PRD),這類文件最大的好處為客人與工程兩端皆可了解的文件，甚至為開發合約的依據
最後，這些需求會轉換成規格，工程規格如電路設計，機構尺寸，非工程規格則為手冊標示，內容，步驟說明等
為何特別強調要列入法規需求的原因，在以下的文章已有詳細描述
此外，就實務面操作，以風險管理為例，參考下文，把風險控制列入設計輸入後，當設計輸出完成驗證，也代表了風險控制的手段已被確認，進而確認風險減低有其根據
美國國防部曾推崇Motorolla在軟體開發的作法，該公司花70%的時間在設計輸入規劃上，如流程圖，待架構確認完成， 30%的時間就用在細節的coding.
這裡也是強調類似觀念，把所有的需求整合成工程規格，建立其關聯性，最後在設計驗證結束後，可有效追溯其與需求的關係
另外，有些公司，法規與工程單位各行其事，常常發生遺漏的問題，用這類手段可有效避免這類問題發生
設計過程
工作樣品(Working Sample）
設計輸入後，開發部門將其開展細部設計，這時初步的成果會是原型機，重點是驗證基本功能是否達到，及評估可能的使用的問題，電路板可能經過不斷的跳線，而機構，這時不適合開模具，所以將機構設計用CNC，立體成形，或是3D列印的手法製作，除了測試基本機構功能外，也同時評估未來工廠組裝時可能遇到的問題，這時的樣品，稱為工作樣品(Working Sample)
此時，工作樣品是進行人因可用性工程的形成性評估(Formative Evaluation)的最佳選擇
人因可用性工程
人因可用性工程其就從產品的預期用途(Intended use)/使用者/使用環境之描述勾畫出產品的使用輪廓.
再從使用者介面/程序，參照相關類似產品的過去使用問題通報歷史如FDA的MAUDE資料庫，進行風險分析.
這還是設計輸入階段，但設計輸入不是一次的過程，在設計過程中會不斷的反饋至設計輸出
風險分析制訂初期形成性評估(Formative Evaluation)，這時可用工作樣品進行評估，決定關鍵任務，在最後的設計產出進行總結式評估(Summative Evaluation)，確認產品安全及有效性，如下圖
在進入工程樣品階段前，盡可能用測試發現問題，因為如果在工程樣品階段進行改良，這時所花的時間/成本遠高於工作樣品階段
設計輸出（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.
這類的表格，其實在軟體確效(Software V&V)文件常見，PRD改成SRS(software Requirement Spec), ES改成SDS（Software Design Spec)
確效Validation
Validation(確效）常用的手法為臨床試驗，確認該醫材的clinical performance在是否符合法規的要求，一個測不準的血壓計，或是血糖機，簡言之，就不是“有效能”的器材，故不能上市
完成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, 是一種有系統性的作事方式，以確保設計品質.
所有產品最大的問題，大都來自設計不良，這也是品質管理系統會重視設計管制的原因，好的品質，其實是設計出來的
如果讀者是剛進入的新手，要了解本流程最好的方式，為把本文內容，製作出一個流程圖，這時可形成一個架構，對專案管理會有一個系統性的掌握.