軟體預先認證計畫(Pre-cert Program)及AI/ML Framework的核心觀念還是不離醫療器材法規的基本原則，保障安全，確認功效這兩個主軸.
但因應這類產品需要不斷精進的需求，法規上除了要確保以上的主軸，更需要與時俱進符合新世代軟體快速變化的挑戰，所以新式審核機制除了提出建議規範外，也給予製造商彈性的機會。
本文將探討如何在實務面來建立符合此規範的系統，能省下更多的開發的時間，並產出更紮實的軟體產品。
簡介
就FDA軟體預先認證 (Pre-cert)計畫，及採用Proposed Regulatory Framework for modifications to AI/ML based SaMD的要求之共同重點為
（1）採用TPLC手法
（2）軟體品質管理系統符合穩固的CQOE原則
（3）RWPA(真實市場表現分析）
就筆者對新世代法規的看法認為是開發廠商藉此升級的良機，除了建立一個卓越品質產出的架構其目的（1）符合法規需求（2）也因為紮實的管理流程保障品質，節省時間，維持高效的開發產出。
筆者的論點會是在實務面著墨，從設計管制流程中列入風險管理，人因工程，以及AI/ML架構中之Predetermine Control Plan (PCP)概念。
其中，也對執行程序的開發組織架構提出建議。
Pre-Cert Program與AI/ML Framework異同
細節文章看參考
這兩者的異同用Table 1來表示
此外，在該篇所建議的開發流程調和架構如下，Fig 1.
CQOE探討：與現行手法的差異
可參考一下對Pre-Cert Program的總結
其中提到CQOE的12項評鑑domain,就筆者的觀察，其實與ISO-62304的基本要求類似，但就實務面觀察，以下部分在很多產業很少有被落實，故有強化的必要。
(1) Transparency 透明度
就Appendix 12列舉的5項elements如下
a. Developing and maintaining systems or dashboards where all levels of the organization can rapidly see and understand how they are performing among metrics relevant to the organization.
b. Making defects, deviations, safety issues transparent to internal and external stakeholders, as appropriate.
c.Security and quality issues are communicated with internal and external stakeholders sufficiently to catalyze corrective and preventive action.
d. Buyers and users understand design assumptions about expected operational conditions/environment to use devices safely, securely, and effectively.
e. Buyers and users (patients/physicians) understand expected or minimum support lifetimes and levels.
就筆者的經驗，全世界有做到以上的項目應該屈指可數。
以上的透明度可以視為上市後監督的一部分，將監督的層面從組織內部延伸到外面使用者，也就是加重組織對外負責的責任，讓組織開發產品後的任何變化，皆公開透明，接受外界使用者檢視。
(2) Configuration Management and Change Control
這個在歐盟有些NB會非常重視，反而在FDA現有的軟體架構沒有被規範。但就實務運作觀之，這個本來就是軟體開發流程的基本功，筆者認為應趁法規要求之下，順勢落實。
(3) Measurement, Analysis, and Continuous Improvement of Processes and Products
通常大部分的業者在Continuous Improvement of Processes and Products方面都有作為，但前者的量測，分析則較少被著墨。
如果就CMMI [2]的level等級來觀之，一般業者通常會落在Level 3的等級，如果有做到（ Measurement, Analysis） 量測，分析者，至少是Level 4的等級。
所以這也是一個不得不升級到CMMI Level 4的機會。
RWPA探討：與現行手法的差異
就目前產業界的作法，會因爲法規，品質系統的要求，進行上市後監督（PMS, Post Market Surveillance) ,積極一點的公司也會收集客人回饋，做產品的改善，有些公司甚至會做應用外部臨床實驗，除了增加產品驗證功能的證據外，也是行銷上的一個策略。
個人就Pre-Cert Program提到的RWPA部分，提出現行產業需要加強的部分
Real World Health Analytics (RWHA)
Human Factors and Usability Engineering:
- Pre-Cert Organization: Support product claims by understanding user ability to comprehend and correctly navigate user interface
- All stakeholders: Demonstrate continuous improvement in usability engineering to drive health benefits and safety
人因工程或是使用性在美國，歐盟已開始被重視，相關法規已提出更多的要求。不過，這是與時俱進。不過大部分的廠商只著力在上市前的分析，而Pre-cert Program開始要求上市後的分析。
所以未來的風險管理報告（RM, Risk Management Report)需要再涵蓋上市後的回饋，並與人因工程或是可用性報告結合。
Clinical Safety:
- Pre-Cert Organization: Benefit from early safety signal detection across Pre-Cert organizations
- All stakeholders: Provide assurance that safety risks are managed and mitigated in a timely way
Health Benefits
- Pre-Cert Organization: Support product claims and future claim modifications by understanding clinical benefits
- All stakeholders: Demonstrate positive impact on health outcomes
以上這兩項其實可以與風險管理報告（RM, Risk Management Report)整合，個人認為Health Benefits一定要包含RM，最後進行Risk-Benefit的評判。這個工作也可與MDR，IVDR的PMCF要求順勢整合。
User Experience Analytics (UXA)
大部分的業者在這方面大致符合UXA的要求，但這一項，要求產品品質的臨床責任及卓越性。個人認為現行系統最或缺的地方。
User Feedback Channels:
- Pre-Cert Organization: Identify and resolve important user issues early and timely
- All stakeholders: Demonstrate clinical responsibility and excellence in product quality by ensuring that user feedback is representative of the full user population
Product Performance Analytics (PPA)
有些公司上市後的產品會不斷做應用研究（Application Study),但大多數者頂多做個一次為行銷用途，甚至上市後就沒有相關試驗。
在這個需求下，會需要一位類似臨床工程師的角色來規劃試驗設計，資料收集。
Product Performance:
- Pre-Cert Organization: Support product claims and future claim modifications
- All stakeholders: Demonstrate sustained analytical validity and excellence in continuous improvement in product quality
產品開發手法：
在設計管控可套用AI/ML的架構，在Pre-Cert類型產品進行簡化
這裡推薦採用Predetermined Change Control Plan（PCP）的架構來進行，其基本上如Fig 2
Predetermined Change Control Plan主要有SaMD Pre-specifcations (SPS)及Algorithm Change Protocol (ACP)構成。
SPS的基本觀念在於在架構上區分出可能改變的部分，並以此判斷後續可能審核的形式。
而ACP則是管制手法，針對資料及程序進行管控，以符合產品的功效性及安全性。
就AI/ML的ACP元件，與現行非AI/ML者比較的描述如下圖, Table 2
如果要將ACP套用在Pre-Cert Program, 只需採用後兩項元件。
可參考下圖(Fig 3)，就AI/ML架構在初次審核後因應軟體修改的審核流程，其實可有效對應Pre-Cert Program的審核路徑
採用Predetermined Change Control Plan可以有效套用在這2種軟體管理。更重要的，所有的組員只需用一種思維來管理2種產品。
故建議的調和後PCP為基礎的軟體開發流程架構如下， Fig 4.
如果是AI/MLFramework，Validation可用Testing data來確效，此外，每個版本一定要與上一版本作Equivalence study(等同研究，證明前後兩版本功效等同，或是新版本更佳）。Equivalence study的允收條件，可列在Performance 要求。
每次版本修改結束時以Design Control Summary作總結，目的是用Special 510K的審核手法來審核自己。列出每次設計的異同，內部進行審核。
實務建議
設計輸入的落實
ISO62304所強調的configuration management可善用equivalenece study進行整合。尤其是baseline的進版。
Configurations 這部分需要在軟體規格書（SRS， Software Requirement Specifications）上定義
而規格輸入的更具體手法會利用GAO/2004報告探討的軟體開發手法如Table 3，如何更具體建立開發流程。就個人經驗，規格輸入前一定要做到可量測者（measurable)如Table 3上紅色標示，否則在管理上無法有對應手法確認是否符合軟體規格書（SRS）的要求。
實務面運作方面，基本上從組織架構落實Design control之精神，再佐以符合ISO62304精神的管理手法及 確定產出文件組織，二階程序文件，三階工作指導書，規範細部規格需開發到具備measurable，而後可延伸成為測試計畫.
最後，結合Configuration management與Predetermined Change Control Plan下的設計輸入如Fig 5
另外，與傳統設計輸入不同處如下
1。人因測試的Fromative測試導入。就測試而言，功能測試，人因測試分開，人因測試需要兩階段（Formative, Summative）也就是Design Input後，還會至少有一次feedback。
2。SPS架構的導入，也就是具體導入Predetermined Change Control Plan的做法，以SPS來規劃Configuration Management.
組織規劃
主要三個單位，建立一個開發，內部測試，審核（Review）機制如Fig 6.
基本概念就像驗證AI有Training, Testing的手法，Training好比軟體開發team, testing則是在組織上的TE部門，測試制訂好的規格，如同第三方測試。審核如同FDA reviewer的角色。
組織上建立三個互不隸屬的單位執行任務。
由專制架構師設定可coding的架構，編制工程師執行coding的工作，而這些工程師可在測試，審核等部門輪值任務。
另外，審核部門的工作其實很類似專案管理，甚至產品管理的角色。
如果是臨時從其他部門抽調的人員編組，則是專案管理工作。如果是有產品管理單位處理，則為產品管理兼專案管理。所以這種組織的設計，有其彈性。
這除了是在有限的人力下最好的運用外，因為這些工程師在不同的工作function運作，職涯上可作橫向的連結。
公司未來擴張時，這些人可往深度的架構師發展，或是橫向的專案管理或產品管理發展。
其實類似觀念，也可用在Pre-Cert Program,Testing，其可視為內部第三方測試驗證
上市後監督
因為現今法規如MDR，IVDR對上市後監督（PMS）的要求已從早期的被動式PMS到主動式PMS，其中上市後臨床追蹤（PMCF）是近年強調的重點。
在RWPA真實世界的功能表現分析，具體方式可參考RWPA framework與PMCF plan之關聯如Table 4。未來可結合客服搜集資訊，反饋給設計輸入端。
小結
以上為初步架構的探討，未來將隨著法規的修訂進行調整。
但可以觀察到的趨勢在於法規審核單位已從單純產品面的要求，提升到產品面與組織面的要求。因為只有良好的組織，才能保證產品的品質。
所以，對未來要開發新世代SaMD或AI/ML型態軟體的公司，相對現行常見的系統，組織架構及思維需作大幅度的調整。
唯有在整個基礎架構完善規劃，才能因應未來法規變化及市場需求。
[1] https://global.udn.com/global_vision/story/8663/5745058
這張圖想要闡明基礎建設的重要，以個人敬重的中村哲醫師的貢獻成果闡述之。
[2] Capability Maturity Model is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.