大阪框架（Osaka Track）
2019年6月28日於日本大阪舉行的G20高峰會上，大阪框架（大阪トラック、Osaka Track）再次躍上國際檯面，日本首相安倍晉三在G20高峰會的數位經濟議程當中，倡議建立大阪框架作為資料跨境流通之標準。安倍強調數位化對促進各國經濟發展與創新意義重大，而在數位時代下資料作為重要的成長動力來源，為了能最大化資料運用的可能性與發展潛力，建立一套國際通用的資料流通機制顯然已勢在必行。
「大阪框架」概念的首次提出，源自2019年1月23日安倍首相於瑞士達沃斯所舉辦的世界經濟論壇（World Economic Forum）中所發表的演講，強調資料將是21世紀經濟發展的關鍵資源，透過建立一套國際通用的資料自由流通機制，將有助於確保在數位時代下各種新興科技的創新與發展，不會受到各國管制措施及資料在地化（data localization）政策所阻礙。
「大阪框架」的核心為建立「可資信任的資料自由流通機制」（Data Free Flow with Trust，簡稱DFFT），透過建構國際所共同信任的資料跨境流通機制，將有助於推動包含電子商務在內等各式資料之流通與利用，進而促進數位創新；安倍宣示2019年大阪G20高峰會為大阪框架的起始點，並強調基於此前提出之WTO電子商務共同聲明，期許能透過WTO各會員國的合作，實現建立國際通用的資料跨境流通機制之目標。
本文為「經濟部產業技術司科技專案成果」
范晏儒
專案經理 編譯整理
地理空間資料（Geospatial Data），資訊工業策進會科技法律研究所，https://stli.iii.org.tw/article-detail.aspx?no=57&tp=5&i=6&d=8202&lv2=6 （最後瀏覽日：2019/06/03）。
美國聯邦通訊委員會（Federal Communications Commission, FCC）於2024年3月14日通過「衛星補充涵蓋（Supplemental Coverage from Space, SCS）」的監理架構，未來將增修聯邦法規電信專章（Title 47 of Code of Federal Regulation）開放600 MHz、700MHz、800 MHz、1800MHz中部分頻段及AWS H-block（1915-1920 /1995-2000 MHz），容許衛星通訊業者向地面行動通訊業者租用頻譜提供SCS服務。 SCS能讓用戶透過手機等既有的行動通訊終端接收衛星訊號，如Starlink目前正與T-mobile合作試驗，透過其第二代低軌衛星提供的手機直連（Direct to Cell）服務，能大幅延伸地面行動通訊系統的涵蓋區域。但為了最大程度防止有害干擾，FCC劃出6個獨立地理區域（Geographically Independent Area, GIA），地面行動通訊業者若要將頻譜出租予衛星通訊業者，除出租頻率需屬於SCS頻段外，還必須在一個GIA內擁有所有與出租頻率同頻的所有執照（all co-channel licenses），而衛星通訊業者僅能基於頻率租用協議，在該GIA內以次級使用的方式提供SCS服務。 雖然2023年底於杜拜落幕的世界無線通訊大會（WRC-23）才剛決議（Resolution com6/9 WRC-23）把「研究指配新頻率供衛星直接與地面行動通訊終端連接，以補充地面行動通訊的涵蓋範圍」納入WRC-27的議程項目 (Agenda Item 1.13 WRC-27)，FCC就搶先開放SCS頻段，但表示會積極參與國際研究與活動，確保在國際電信聯盟（International Telecommunication Union, ITU）的無線電規則（Radio Regulation）下建立的SCS相關國際監理機制能取得重大進展，並隨著SCS市場的發展逐步開放能夠運用的頻段與應用場景，期能充分發揮衛星通訊與地面行動通訊整合的效益，互補不易涵蓋的區域並無縫銜接，達成「未來單一網路」（Single Network Future）的政策願景。
加拿大政府提交予國會《人工智慧資料法案》加拿大政府由創新、科學和工業部長（Minister of Innovation, Science and Industry）代表，於2022年6月16日提交C-27號草案，內容包括聯邦的私部門隱私權制度更新，以及新訂的《人工智慧資料法案》（Artificial Intelligence and Data Act, 下稱AIDA）。如獲通過，AIDA將是加拿大第一部規範人工智慧系統使用的法規，其內容環繞「在加拿大制定符合國家及國際標準的人工智慧設計、開發與應用要求」及「禁止某些可能對個人或其利益造成嚴重損害的人工智慧操作行為」兩大目的。雖然AIDA的一般性規則相當簡單易懂，但唯有在正式發布這部包含絕大多數應用狀況的法規後，才能實際了解其所造成的影響。 AIDA為人工智慧監管所設立的框架包含以下六項： （1）方法 以類似於歐盟《人工智慧法案》採用的方式，建立適用於人工智慧系統具「高影響力」的應用方式的規範，關注具有較高損害與偏見風險的領域。 （2）適用範圍 AIDA將適用於在國際與省際貿易及商業行動中，設計、發展或提供人工智慧系統使用管道的私部門組織。「人工智慧系統」的定義則涵蓋任何「透過基因演算法、神經網路、機器學習或其他技術，自動或半自動處理與人類活動相關的資料，以產生結果、做出決策、建議或預測」的技術性系統。 （3）一般性義務 I 評估及緩和風險的措施 負責人工智慧系統的人員應評估它是否是一個「高影響系統」（將在後續法規中詳細定義），並制定措施以辨識、評估與減輕使用該系統可能造成的傷害風險或具有偏見的結果。 II 監控 對該「高影響系統」負責的人員應建立準則，以監控風險緩解措施的遵守情況。 III 透明度 提供使用管道或管理「高影響系統」運作的人員應在公開網站上，以清晰的英語揭露 i 系統如何或打算如何使用。 ii 系統所生成果的類型及它所做出的決策、建議與預測。 iii 為辨識、評估與減輕使用該系統可能造成的傷害風險或具有偏見的結果，而制定的緩解措施。 iv 法規明定應揭露的其他訊息。 IV 記錄保存 執行受規範活動的人員應遵守紀錄保存要求。 V 通知 若使用該系統將導致或可能導致重大傷害，「高影響系統」的負責人應通知部門首長。 VI 匿名資料的使用 從事法案所規定的活動及在活動過程中使用或提供匿名資料的人員，必須依據規範制定關於（a）資料被匿名化處理的方式（b）被匿名化資料的使用與管理，兩方面的措施。 （4）部長命令 部門首長可以透過命令要求（a）製作紀錄（b）從事審計或聘請一位獨立的審計師執行（c）成立一個專責執行審計程序的組織（d）成立一個在有理由相信「高影響系統」之使用可能造成急迫重大傷害風險時負責進行終止或准許的組織。 （5）行政管理 AIDA為部門首長制定一項，可指定其所管轄部門中一名高級官員為「人工智慧與資料專員」的權利，其職責在協助部門首長管理與執行AIDA。 （6）罰則 違反AIDA規範之罰則主要為按公司、個人之收入衡量的罰款。特定嚴重狀況如以非法方式取得人工智慧訓練用資料、明知或故意欺騙大眾造成嚴重或心理傷害或財產上重大損失，亦可能判處刑事監禁。
日本個人資料保護委員會發布「禁止不當利用」與「停止利用」論點資料作為將來發布指引參考日本為因應去年6月通過「個人資料保護法」之修正（下稱「新法」），個人資料保護委員會於2021年2月19日第166次會議議題「禁止不當利用與停止利用之完備指引論點」（改正法に関連するガイドライン等の整備に向けた論点について（不適正利用の禁止・利用停止等）），公開兩份論點資料，作為將來發布指引之參考，並使企業等關係者在新法實施準備期間，得採取適當措施以達到法遵要求。 新法第16條之2「禁止不當利用」，旨在防止不當利用個人資料致本人權益受損。於「禁止不當利用之論點資料」指出具體要件有(1)「違法或不當行爲」，係指違反個人資料保護法及其他法令之行爲，或有違公序良俗，在社會觀念上非屬正當之行為；(2)「助長或誘發之危害」，在認定上將限縮在以業者提供時有認識第三方將違法利用個人資料，並可預見提供個人資料將受違法利用之情形，以免造成寒蟬效應。若第三方刻意隱瞞取得目的，即使已盡相當注意仍不能預見違法利用之情形，則非屬「危害」。 新法第30條第5項擴大「停止利用」請求權範圍，於「停止利用之論點資料」指出適用要件有(1)「個人資料處理業務已無利用個人資料之需要」，即個人資料利用目的已消失或該事業已中止時；(2)「發生第22條之2第1項本文情形」，係指發生資料外洩依規定須報告委員會之情形；(3)「可能損害本人權益時」，係指依法受保護之正當權益有受損可能為必要。另論點指出請求停止利用必須在「為防止本人權益受損必要限度內」，故業者對於超出必要限度之部分得拒絕之。而對於停止利用所費不貲或顯有重大困難之情形，得依個案具體考量採取適當替代措施。
人工智慧技術用於醫療臨床決策支援之規範與挑戰—以美國FDA為例人工智慧技術用於醫療臨床決策支援之規範與挑戰—以美國FDA為例 資訊工業策進會科技法律研究所 蔡宜臻法律研究員 2018年11月27日 壹、事件摘要 美國係推動人工智慧用於醫療服務的領航國家，FDA轄下的數位健康計畫（Digital Health Program）小組負責針對軟體醫療器材規劃新的技術監管模式，在過去五年中，該計畫發布了若干指導文件 ，嘗試為醫用軟體提供更為合適的監督管理機制。但由於指導文件並非法律，監管的不確定性依舊存在，因此近兩年 FDA推動修法並做成多項草案與工作計畫，望以更具約束力的方式回應軟體醫療器材最新技術於臨床之適用。當中最為重要的法制變革，便是2016年底國會通過之《21世紀治癒法》（21st Century Cures Act）。該法重新定義了醫用軟體的監管範圍，一般認為是對人工智慧醫用軟體的監管進行鬆綁，或有助於人工智慧醫用軟體的開發與上市。然而在新法實施近兩年以來，實務上發現人工智慧的技術特質，會導致在進行某些「臨床決策支援之人工智慧軟體」是否為醫療器材軟體之認定時，產生極大的不確定性。對此FDA也於2017年12月作成《臨床與病患決策支持軟體指南草案》（Clinical and Patient Decision Support Software-Draft Guidance for Industry and Food and Drug Administration），望能就部份《21世紀治癒法》及其所修正之《聯邦食品藥物化妝品法》（Federal Food, Drug, and Cosmetic Act, FD&C Act）[1]裡的規範文字提供更為詳細的說明。 本文望能為此項法制變革與其後續衍生之爭議進行剖析。以下將在第貳部分重點說明美國2016年頒布的《21世紀治癒法》內容；在第參部份則針對人工智慧技術用於醫療臨床決策支援所發生之爭議進行分析；最後在第肆部份進行總結。 貳、重點說明 2016年12月美國國會頒布了《21世紀治癒法》，在第3060節明確界定了FDA對數位健康產品（Digital Health Products）之管轄範圍，將某些類型的數位健康產品排除在FDA醫療器材（medical device）定義之外而毋須受FDA監管。此規定亦修正了美國《聯邦食品藥物化妝品法》第520節（o）項有關FDA排除納管之軟體類別之規定。 根據新修正的《聯邦食品藥物化妝品法》第520節（o）（1）項，美國對於醫用軟體的監管範疇之劃設乃是採取負面表列，規定以下幾種類型的軟體為不屬於FDA監管的醫用軟體： 行政管理目的[2]；或 目的在於非關診斷、治療、緩解、預防或病症處置之健康維持或健康生活習慣養成[3]；或 目的在於進行電子化的個人健康紀錄[4]；或 目的用於傳輸、儲存、格式轉換、展示臨床研究或其他裝置資料與結果[5]；或 同時符合以下四點之軟體： (1)不從體外醫療器材或訊號蒐集系統來讀取、處理或分析醫療影像或訊號[6]。 (2)目的在於展示、分析或印製病患醫療資訊，或其他醫療訊息（例如：偕同診斷之醫療研究、臨床處置指南）[7]。 (3)目的在於替醫療專業人員就疾病或症狀之預防、診斷或處置提供支持或臨床建議[8]。 (4)使醫師在使用該軟體時尚能獨立審查「臨床建議產生之基礎」，因此醫師所做成之臨床診斷或決策，並非主要依賴該軟體提供之臨床建議[9]。 雖然大多數被排除的類別相對無爭議，但仍有一部分引起法律上不小的討論，即《聯邦食品藥物化妝品法》第520節（o）（1）（E）項所指涉的某些類型之臨床決策支援軟體（Clinical Decision Support Software，以下簡稱CDS軟體）。 CDS軟體係指分析數據以幫助醫療手段實施者（例如：醫師）做出臨床決策的軟體。多數以人工智慧為技術基礎的醫療軟體屬於此一類型，比方病理影像分析系統。根據《21世紀治癒法》與《聯邦食品藥物化妝品法》，CDS軟體是否被排除在FDA的管轄範圍之外，取決於該軟體是否「使醫師在使用該軟體時尚能獨立審查『臨床建議產生之基礎』，因此醫師所做成之臨床診斷或決策，並非主要依賴該軟體提供之臨床建議」[10]。若肯定，則將不被視為FDA所定義之醫療器材。為使此一規定更加明確，FDA於2017年12月8日發布了《臨床與病患決策支持軟體指南草案》，該指南草案針對如何評估軟體是否能讓醫師獨立審查臨床建議產生之基礎進行說明。FDA表示該軟體至少要能清楚解釋以下四點[11]： 該軟體功能之目的或用途；及 預期使用者（例如超音波技師、心血管外科醫師）；及 用於產生臨床建議的原始資料（例如患者的年齡和性別）；及 臨床建議產生背後之邏輯或支持證據 後續方有機會被FDA認定係令醫療專業人員使用該軟體時，能「獨立審查」臨床建議產生之基礎。換言之，指南草案所提的四點，為FDA肯認醫師在使用軟體時尚能「獨立審查」之必要前提。除此之外，指南草案尚稱預期使用者必須能自己做成與軟體相同之判斷，並且要求「用於生成臨床建議與演算邏輯的原始資料必須可被預期使用者辨識、近用、理解，並為公眾可得」[12]，進而方有機會符合《聯邦食品藥物化妝品法》第520節（o）（1）（E）（iii）之規定；若該軟體亦同時符合第520節（o）（1）（E）之其他要件，則有望被劃分為非醫療器材而不必受FDA監管。 由於規範內容較為複雜，指南草案亦提供案例說明。比方若一糖尿病診斷軟體是由醫生輸入患者參數和實驗室測試結果（例如空腹血糖、口服葡萄糖耐量測試結果或血紅蛋白A1c測試結果），並且該裝置根據既定臨床指南建議患者的病情是否符合糖尿病的定義，可被FDA認定為「非醫療器材」[13]；而諸如分析電腦斷層、超音波影像之軟體，則仍維持屬於醫療器材[14]。 另需注意的是，《聯邦食品藥物化妝品法》在第520節（o）（3）（A）（i）項亦建立「彌補性納回（claw-back）」機制，FDA需遵守通知評論程序（notice-and-comment process）以便及時發現軟體可能對健康造成嚴重危害的風險，並隨時將之納回監管範疇中。同時FDA每兩年必須向國會報告醫療器材軟體的實施經驗[15]。 參、事件評析 《21世紀治癒法》頒布至今兩年，FDA已核准多個以人工智慧為技術核心的軟體，例如在2018年2月13日通過能自動偵測可疑的大血管阻塞（large vessel occlusion, LVO），並迅速通知醫師病人可能有的中風危險的臨床決策支援軟體：Viz.AI Contact application；又比如於2018年4月11日通過利用演算法分析由視網膜攝影機（Topcon NW400）所獲得的影像，快速篩檢糖尿病病人是否有必須由專業眼科醫師治療的視網膜病變的IDx-DR。 然而，在CDS軟體以人工智慧為技術核心時，現有的法規與監管框架依舊有幾點疑慮： 一、「理解」演算法？ 根據新修正之《聯邦食品藥物化妝品法》，如果CDS軟體欲不受FDA監管，醫師的決策必須保持獨立性。目前規定只要該醫療產品「企圖」（intended to）使醫師等專業人員理解演算法即可，並不論醫師是否真正理解演算法。然而，若FDA肯認理解演算法對於執行醫療行為是重要的，那麼當CDS係基於機器學習產生演算法時，具體該如何「理解」就連開發者本身都未必能清楚解釋的演算法？有學者甚至認為，CDS軟體是否受到FDA法規的約束，可能會引導至一個典型的認識論問題：「我們是怎麼知道的？（How do we know?）」[16]。對此問題，我們或許需要思考：當醫師無法理解演算法，會發生什麼問題？更甚者，未來我們是否需要訓練一批同時具備人工智慧科學背景的醫療人員？[17] 二、如何要求演算法透明度？ 指南草案所提之「清楚解釋臨床建議產生背後之邏輯或支持證據」以及資料來源為公眾可得、醫生對演算法使用的資料來源之近用權限等，被認為是FDA要求廠商應使CDS軟體之演算法透明[18]。但根據FDA指南草案公告後得到的反饋，醫療軟體廠商對此要求認為並不合理。廠商認為，應該從實際使用效益來審視人工智慧或機器學習軟體所提出的臨床建議是否正確，而不是演算法是什麼、怎麼產生[19]。 三、醫療專業人員之獨立專業判斷是否會逐漸被演算法取代？未來醫療軟體廠商與醫療專業人員之責任該如何區分？ FDA目前的法規與指南並未直接回應此二問題，惟其對於不被列管之CDS軟體之規定係需使醫師並非主要依賴該軟體提供之臨床建議、醫師能自己做成與軟體相同之判斷。由反面解釋，即FDA肯認部份CDS軟體具備與醫師雷同之臨床診斷、處置、決策之功能，或能部份取代醫師職能，因此需受FDA監管。是故，醫師之專業能力與人工智慧演算法相互之間具有取代關係，已是現在進行式。惟究竟醫師的判斷有多少是倚靠人工智慧現階段尚無法取得量化證據，或需數年時間透過實證研究方能研判。往後，醫療軟體廠商與醫師之責任該如何區分，將會是一大難題。 肆、結語 隨著醫療大數據分析與人工智慧技術的發展，傳統認知上的醫療器材定義已隨之改變。雖然硬體設備仍然在診斷、治療與照護上扮演極為重要的角色，但軟體技術的進步正在重新改寫現代醫療服務執行以及管理模式。這些新產品及服務為醫療器材市場帶來活水，但同時也形成新的監管議題而必須採取適當的調整措施。美國FDA針對近年來呈爆炸性發展的醫療軟體產業不斷調整或制定新的監管框架，以兼顧使用者安全與新技術開展，並於2016年通過了極具改革意義的《21世紀治癒法》，且以此法修正了《聯邦食品藥物化妝品法》。 然而，新法實施後，關於個別醫用軟體是否納為不受FDA監管的醫療器材仍有法律認定上的灰色空間。舉例而言，倍受矚目的以人工智慧為核心技術的CDS軟體，在新法框架下似乎可能存在於監管紅線的兩側。根據新修正之《聯邦食品藥物化妝品法》，一CDS軟體是否屬於醫療器材軟體，關鍵在於醫師能否「獨立審查」從而「非主要依賴」軟體所提供之臨床建議。也由於此要件概念較為模糊，FDA後續在2017年發布《臨床與病患決策支持軟體指南草案》為此提供進一步解釋，然而仍無法妥適處理人工智慧機器學習技術所導致的演算法「該如何理解？」、「透明度該如何認定？」等問題。更甚者，從整體醫療服務體系納入人工智慧協助臨床決策診斷之趨勢觀之，未來醫療專業人員的獨立判斷是否會逐漸被演算法取代？未來人工智慧軟體與醫療專業人員之責任該如何區分？都是醞釀當中的重要議題，值得持續關注。 [1] 21 U.S. Code §360j [2] FD&C Act Sec. 520(o)(1)(A) [3] FD&C Act Sec. 520(o)(1)(B) [4] FD&C Act Sec. 520(o)(1)(C) [5] FD&C Act Sec. 520(o)(1)(D) [6] FD&C Act Sec. 520(o)(1)(E) [7] FD&C Act Sec. 520(o)(1)(E)(i) [8] FD&C Act Sec. 520(o)(1)(E)(ii) [9] FD&C Act Sec. 520(o)(1)(E)(iii) [10] “Enabling such health care professionals to independently review the bases for such recommendations that such software presents so that it is not the intent that such health care professional rely primary on any of such recommendations to make clinical diagnosis or treatment decisions regarding individual patient.” FD&C Act, Sec. 520(O)(1)(E)(iii) [11] FOOD AND DRUG ADMINISTRATION[FDA], Clinical and Patient Decision Support Software-Draft Guidance for Industry and Food and Drug Administration (2017), .at 8 https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm587819.pdf (last visited Sep. 21, 2018) [12] 原文為 “The sources supporting the recommendation or underlying the rationale for the recommendation should be identified and easily accessible to the intended user, understandable by the intended user (e.g., data points whose meaning is well understood by the intended user), and publicly available (e.g., clinical practice guidelines, published literature)”, id, at 8 [13] FOOD AND DRUG ADMINISTRATION[FDA], supra note 11 [14]FOOD AND DRUG ADMINISTRATION[FDA], supra note 11 [15] 21th Century Cures Act, Sec. 3060(b) [16] Barbara J. Evans & Pilar Ossorio, The Challenge of Regulating Clinical Decision Support Software after 21st Century Cures. AMERICAN JOURNAL OF LAW AND MEDICINE (2018), https://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID3142822_code1078988.pdf?abstractid=3142822&mirid=1 (last visited Sep. 21, 2018) [17] Id. [18] Gail H. Javitt & J.D., M.P.H., ANESTHESIOLOGY, Regulatory Landscape for Clinical Decision Support Technology (2018), http://anesthesiology.pubs.asahq.org/article.aspx?articleid=2669863 (last visited Sep. 21, 2018) [19] REGULATIONS.GOV, Clinical and Patient Decision Support Software; Draft Guidance for Industry and Food and Drug Administration Staff; Availability(Dec. 8, 2017) https://www.regulations.gov/docketBrowser?rpp=25&po=0&dct=PS&D=FDA-2017-D-6569&refD=FDA-2017-D-6569-0001 (last visited Sep. 25, 2018)