英國實行個人健康和社會照護資訊連結服務（care.data）
隨著英國國家健康服務（National Health Service, NHS）的改革，英國於去（2012）年3月27日通過衛生和社會照護法（The Health and Social Care Act 2012）。當中一項主要的變革即是成立衛生與社會照護資訊中心（The Health and Social Care Information Centre, HSCIC）作為醫療健康資料的專責機構。而這樣的變革，也影響過去病歷資料的蒐集、分享和分析方式。依據衛生和社會照護法的規定，HSCIC若受到衛生部長（Secretary of State for Health）指示、或來自照護品質委員會（Care Quality Commission, CQC）、英國國家健康與臨床卓越研究院（National Institute for Health and Clinical Excellence, NICE）、醫院監管機構Monitor的命令要求時，在這類特定情況之下，可以無需尋求病患同意，而從家庭醫師（GP Practice）處獲得病患的個人機密資料（Personal Confidential Data, PCD）。
今(2013)年3月獲NHS授權， 由HSCIC於6月開始執行的care.data服務，即是依據前述立法所擬定之方案。care.data藉由定期蒐集醫療照護過程中的相關資料，對病患於國內所為的各項健康和社會照護資訊（例如病患的住院、門診、意外事故和緊急救護記錄）進行具延續性之連結。以提供即時、正確的NHS治療和照護資訊給民眾、門診醫師和相關部門之官員，進而達到care.data所設定的六項目標，支援病患進行治療的選擇、加強顧客服務、促進資訊透明性、優化成果產出、增加問責性，並驅動經濟成長。
然而，由於care.data是以英國民眾就醫行為中，屬於基礎醫療的家庭醫師（General Practitioner, GP）系統為基礎，所提取的資料包括家族歷史、接種疫苗、醫師診斷、轉診記錄、生理指標，以及所有NHS處方。其次，care.data在進行初級和次級資料連結時，將會透過NHS號碼、生日、性別和郵遞區號，這四項可識別資料的比對。因此雖然care.data在涉及敏感性資料時會加以排除，但此項服務仍引起社會上相當大的爭議。包括部分醫師、隱私專家和的社會團體皆提出質疑，質疑care.data是否有充分告知病人、HSCIC所宣稱的匿名性是否足夠、此項服務對醫病關係的衝擊、該服務所宣稱的資料分享退出機制（opt-out）並未妥善等。
care.data是NHS所推出的創新資料現代化服務，但同時也涉及病患隱私權保護之議題。反觀我國近來所推動的醫療健康資訊加值再利用政策，英國的案例值得我們持續觀察其發展。
- Data and information, NHS England
- Care.data – modern data service for the NHS, NHS England
- Rebecca Todd, Care.data extract needs explanation, EHEALTH INSIDER, Feb. 20, 2013
- Rebecca Todd, Care.data IG reconsidered, EHEALTH INSIDER, Mar. 27, 2013
- Rebecca Todd, Care.data approved, EHEALTH INSIDER, Apr. 10, 2013
- Rebecca Todd, Care.data implemented this month, EHEALTH INSIDER, June 3, 2013
- Rebecca Todd, GP group does care.data campaign, EHEALTH INSIDER, Agu 2, 2013
現行微波通訊頻段（microwave services）為固定及移動廣播輔助服務業者（Fixed and Mobile Broadcast Auxiliary Service, BAS）及有線電視中繼服務業者（Cable TV Relay Service）於新聞採訪時節目傳輸使用。 而一般基地台與核心網路間的傳輸係藉由銅線或光纖。在FCC解除法規管制後，將可允許固定服務業者（fixed service）於未有執照之區域使用此頻段，而不會造成既有業者的干擾。可使用6875-7125 MHz及12700-13100 MHz頻段，總計達650Mhz。固定服務業者可用於基地台中程傳輸（middle mile）使用，並可加快4G網路佈建目標。FCC估計此範圍涵蓋50%國土面積及10%之人口。 FCC放寬之管制內容如下︰ 1.取消「最後連結」（final link）規範-使業者得以微波通訊來進行內容傳輸，且可減少設施的重複佈建。 2.允許適性調變（Adaptive Modulation）-允許固定服務業者在訊號不良時可減慢傳輸速度，以維持通訊連線。 3.不得架設輔助式基地台（Auxiliary station）-因FCC尚未有明確證據顯示當輔助式基地台與主要基地台共存時，是否造成干擾。因此不得架設輔助式基地台。
日本擬以金融商品交易法對虛擬貨幣之首次代幣發行予以監管由日本金融廳（FSA）與各界相關人士組成的「虛擬貨幣交換產業相關研究會」（仮想通貨交換業等に関する研究会）於2018年11月2日再度召開會議，本次會議主要針對是否需就ICO監管予以討論。 按ICO，乃是指虛擬貨幣之首次代幣發行（Initial Coin Offering），即向社會大眾發行數位代幣（token），並收取主流虛擬貨幣之籌資行為。在過去，日本僅以向金融廳諮詢會報的方式督導，對於虛擬貨幣之交易所僅課予註冊義務，並未對於ICO行為予以規範。而ICO因其大量之籌資行為可能產生之風險如詐欺、非法募資或洗錢，從而日本金融廳研擬將ICO列入「金融商品交易法」規範之。 而就ICO是否有受到金融監管之必要，會議中主要之考量有以下兩點： 使用虛擬貨幣之行為是否具有金錢上融資之功能，會議中對於不具權利性質之虛擬貨幣認為無監管必要； 引入金融監督機制是否符合社會期待。 另外，會議中並就ICO和首次公開募股（Initial Public Offerings，以下簡稱IPO）進行比較，有認為，倘若ICO具有如同IPO籌集資金之經濟功能，並且也可能產生如同IPO之相同風險，理應受到相同之規範。可為之規範例如對於賣家進行最低度審查，避免透過籌資為詐欺之可能；限制權利內容模糊不清之虛擬貨幣流通，並對發行人之財務和業務狀況進行篩選；課予ICO負有如同IPO之揭露義務，並須在網站上公布對於投資人有影響性之資訊；使發行價格更有衡量基準。另外JVCEA（日本仮想通貨交換業協会）作為監管機構，擬對於ICO在銷售開始、銷售結束，甚至銷售結束後仍課予持續的情報提供義務。 而於後續2018年11月26日召開之第十次會議中，表示對於ICO在未來不會採取禁止之態度，仍保持鼓勵之立場，但對於投資人之保護需要更全面予以考量，減少利用ICO詐欺之情形。另外，對於虛擬貨幣交換業者，需要加強對客戶財產之管理和維護，亦可能對其施加信託義務，俾利加強投資人信心。 ICO在日本非常盛行，但也因此詐欺案件頻傳，對於日本將以何種方式監管ICO；對於虛擬貨幣交換業者之規範，對投資人之保護是否足夠；又或是此類規範將形成交換業者反抗，依目前會議頻繁討論之程度應很快會有定論。惟對於此種新創之產業，往往需在監管與鼓勵發展間求取平衡，而日本在虛擬貨幣之發展上，又領先亞洲各國，對於此次監管議題後續發展，實值關注，並得以借鏡我國，作為我國在相同議題上之參考。
世界衛生組織發布人工智慧於健康領域之監管考量因素文件，期能協助各國有效監管健康領域之人工智慧世界衛生組織（World Health Organization, WHO）於2023年10月19日發布「人工智慧於健康領域之監管考量因素」（Regulatory considerations on artificial intelligence for health）文件，旨在協助各國有效監管健康領域之人工智慧，發揮其潛力同時最大限度地降低風險。本文件以下列六個領域概述健康人工智慧之監管考量因素： （1）文件化與透明度（Documentation and transparency） 開發者應預先規範（pre-specifying）以及明確記錄人工智慧系統（以下簡稱AI系統）之預期醫療目的與開發過程，如AI系統所欲解決之問題，以及資料集之選擇與利用、參考標準、參數、指標、於各開發階段與原始計畫之偏離及更新等事項，並建議以基於風險之方法（Risk-based approach），根據重要性之比例決定文件化之程度、以及AI系統之開發與確效紀錄之保持。 （2）風險管理與AI系統開發生命週期方法（Risk management and AI systems development lifecycle approaches） 開發者應在AI系統生命之所有階段，考慮整體產品生命週期方法（total product lifecycle approach），包括上市前開發管理、上市後監督與變更管理。此外，須考慮採用風險管理方法（risk management approach）來解決與AI系統相關之風險，如網路安全威脅與漏洞（vulnerabilities）、擬合不足（underfitting）、演算法偏差等。 （3）預期用途、分析及臨床確效（Intended use, and analytical and clinical validation） 開發者應考慮提供AI系統預期用途之透明化紀錄，將用於建構AI系統之訓練資料集組成（training dataset composition）之詳細資訊（包括大小、設定與族群、輸入與輸出資料及人口組成等）提供給使用者。此外，可考慮透過一獨立資料集（independent dataset）之外部分析確效（external analytical validation），展示訓練與測試資料以外之效能，並考慮將風險作為臨床確效之分級要求。最後，於AI系統之上市後監督與市場監督階段，可考慮進行一段期間密集之部署後監督（post-deployment monitoring）。 （4）資料品質（Data quality） 開發者應確認可用資料（available data）之品質，是否已足以支援AI系統之開發，且開發者應對AI系統進行嚴格之預發布評估（pre-release evaluations），以確保其不會放大訓練資料、演算法或系統設計其他元素中之偏差與錯誤等問題，且利害關係人還應考慮減輕與健康照護資料有關之品質問題與風險，並繼續努力創建資料生態系統，以促進優質資料來源之共享。 （5）隱私與資料保護（Privacy and data protection） 開發者於AI系統之設計與部署過程中，應考慮隱私與資料保護問題，並留意不同法規之適用範圍及差異，且於開發過程之早期，開發者即應充分瞭解適用之資料保護法規與隱私法規，並應確保開發過程符合或超過相關法規要求。 （6）參與及協作（Engagement and collaboration） 開發者於制定人工智慧創新與部署路線圖之期間，需考慮開發可近用且具有充足資訊之平台，以於適合與適當情況下促進利害關係人間之參與及協作；為加速人工智慧領域實務作法之進化，透過參與及協作來簡化人工智慧監管之監督流程即有必要。