歐盟執委會(European Commission, EC)於2020年4月8日發布新聞稿,說明歐盟將制定紓困計劃,投入資金支援全球盟國對抗新冠肺炎。歐盟的行動將側重於解決急迫的衛生問題以及人道主義需求,加強盟國的健康、供水和公共衛生環境,及協助盟國發展對抗流行病的研究和準備能力,減輕疾病對國家經社之影響。
此次計劃立基於「Team Europe」,「Team Europe」是歐盟執委會因應疫情採取全球及跨境協調的紓困方案,強調整併來自歐盟、歐盟成員國及金融機構──特別是歐洲投資銀行(European Investment Bank, EIB)和歐洲復興開發銀行(European Bank for Reconstruction and Development, EBRD)──的資金,提供全球盟國立即而精準的援助,目前已投資超過156億歐元的資金。而在此次全球紓困中,歐盟短期面提供盟國資金,長期面則協助解決盟國因疫情引發的社會經濟問題。
本次紓困計畫區分為三大部分,分別為:
本文為「經濟部產業技術司科技專案成果」
2025年8月6日,行動支付技術開發公司Fintiv向喬治亞州北區聯邦地方法院亞特蘭大分院控訴Apple科技公司以詐欺手段竊取Fintiv公司的前身公司CorFire的專屬行動支付技術,違反《保護營業秘密法》(Defend Trade Secrets Act,DTSA)及《喬治亞州營業秘密法》(Georgia Trade Secrets Act,GTSA)等規定,向法院尋求賠償。 Fintiv公司主張Apple公司在2011年至2012年間,以行動支付技術之業務合作為由,與CorFire公司進行多次技術性洽談。Apple公司利用雙方簽訂之保密契約,取得CorFire公司的行動支付技術的詳細實施方案之接觸權限,並要求CorFire公司上傳部分機密資料至Apple公司管理的共享平臺,以促進合作交流關係,最終Apple公司放棄與CorFire公司的合作計畫,Apple公司卻將協商期間所獲技術內容整合,並應用於其在2014年推出的Apple Pay行動支付服務。Fintiv公司進一步主張Apple公司為將Apple Pay商業化,與信用卡處理商及銀行組成企業聯盟,並隱瞞其非法取得技術的真相,宣稱Apple公司自主研發Apple Pay。Fintiv公司指出,Apple公司此舉不僅損害Fintiv公司的合法權益,也嚴重破壞市場競爭秩序。此外,Fintiv公司表示,Apple公司多年來有系統地採取類似策略,如以合作名義獲取其他企業之機密,進而不當使用多項機密以進行商業化使用。 觀察前述實務案例可得知,即使雙方基於保密契約交換機密資料,仍存在終止合作衍生的機密外洩糾紛,如:機密資料歸屬不清、逾越授權範圍使用機密資料等風險。建議企業在「資料提供前」,應先透過「盤點」營業秘密與機密「分級」,確認合適揭露的機密資料,再藉由「審查」機制確認必要揭露的內容;在「資料提供後」,要求他方提供機密資料之「收受證明」以明確歸屬,並在合作關係結束後,要求他方「聲明返還或銷毀機密資料」,以降低他方不當使用機密資料的風險。 前述建議之管理作法已為資策會科法所創意智財中心於2023年發布之「營業秘密保護管理規範」所涵蓋,企業如欲精進系統化的營業秘密管理作法,可以參考此規範。 本文為資策會科法所創智中心完成之著作,非經同意或授權,不得為轉載、公開播送、公開傳輸、改作或重製等利用行為。 本文同步刊登於TIPS網站(https://www.tips.org.tw)
<開原碼條例>建置醫療資源共享架構UCLA醫學中心以開放原始碼軟體Zope建置資訊系統,展開一項稱為「治療成效開放式架構」(OIO, Open Infrastructure for Outcomes) 的計畫,構築起未來醫療資訊系統的新基石。讓治療成效的資訊,能在一個共通的平台架構上進行資源分享。 長期以來,醫療資訊系統面臨的挑戰主要來自於下列三個面向:一、如何讓資訊系統提供令人滿意的服務功能,以取代將醫療記錄登載在紙張上的傳統方式。二、資訊系統的需求經常會改變,如何快速因應系統的改變需求。三、如何與其他醫療團隊夥伴,共同分享資料與工具。 OIO計劃透過資訊共享可加速醫療研究。開放式架構計畫的主要目的,並不是用來要求臨床工作者與醫療研究中心分享病歷資料,而是提供一個分享管理工具的機制,讓使用者能夠利用這些管理工具,進行資料的收集與分析,並和特定的診療研究人員進行溝通,而透過系統安全的機制,在過程當中並不會讓其他人得知資料內容。不過,如果有人想要進行管理工具或資料的進一步加值利用,僅需額外投入相當小的成本。 另外, 開放式架構計畫的設計極具彈性,除了目前所專注的治療成效資訊統計之外,其系統概念也可以用來管理客戶資訊、進銷存資訊、會計資訊等。整個系統開發環境是針對使用者而設計,而非程式人員,並且以網頁應用程式來實作,力求操作的便利性,目的之一是讓使用者能夠動手創造出自己所需的表格資料。另一方面,設計上也面對來自於法律與技術層面的挑戰,例如取得病患的同意及對系統的信任感,促使這套系統在實作時,必須能夠提供高度的修改彈性與安全性。 由於 OIO 在設計上,包含低成本、高效益、使用者導向、架構具有彈性等特色,並以開放源碼開發模式來鼓勵使用者測試及提供回饋意見,目前的應用效果持續擴大中。
歐盟提出現行個資保護指令規範之修正草案歐盟提出現行個資保護指令規範之修正草案 科技法律研究所 2013年10月07日 壹、事件摘要 歐盟於1995年所制定之「個人資料保護指令」(Data Protection Directive,95/46/EC,下稱個資保護指令),其基本原則確保了歐盟會員國個人資料基本權利之保障,後續也成為國際相關立法時之參考依據。但由於個資保護指令制定時為框架式立法模式,歐盟各會員國仍須將相關規定內國法化,導致各會員國間對於個人資料保護標準產生差距。 貳、重點說明 一、立法緣起 歐盟現行之「個資保護指令」是第一部解決關於個人資料處理與自由流通保護之指令,主要在於提供歐盟境內關於個人資料及隱私權保護之規定。但由於該指令使各會員國之規範不具統一性,且制定之時科技尚屬發展階段。為解決科技發展與各國形成之保護差距,歐盟執委會(European Commission)在2012年1 月25 日,向歐洲理事會(European Commission)及歐洲議會(European Parliament)正式提出「一般個人資料保護規則」(General Data Protection Regulation)草案共91 條。預計於2015年施行,並取代現行個資保護指令,全面並一致性適用於各會員國。 二、關鍵改變 本次一般個人資料保護規則草案相較於現行個資保護指令,主要有資料當事人權利行使新增與強化、當事人同意要件標準提高、適用主體擴大、申訴權力強化、資料管理人資料保護責任之加重、損害賠償與相關罰則之規定等,並將各項規定更加明確化,以解決長期以來歐盟會員國間因保護水準不一所形成之衝突現象。 參、事件評析 一般個人資料規則草案提出後,歐盟與英國分別針對新規則草案進行評估。歐盟執委會認為,新規則可協助歐盟境內解決長期以來因個資法保護水準不一所形成之衝突,進而為當地企業帶來約23億歐元之效益;但英國當地卻持反面見解,認為新法將使企業提高所需擔負之行政成本,且高規格之法遵要求也使資料管理人陷入難以遵守之情況,進而影響歐盟之競爭力。國際上激烈的討論聲浪與分歧之見解,也使得該規則草案自提出至今已一年多的時間,仍未正式拍板定案。 歐盟於1995年制定之個資保護指令,自1998年生效之後,不僅在各會員國進行個資保護時扮演關鍵性角色,更為國際上個人資料保護或隱私保護之參考依據,其動向更為各國所專注與留意。而隨著時代轉變與科技演進,歐盟期許未來不只是在歐盟境內,更可將個人資料或隱私保護相關資訊與要求,擴及歐盟以外之國家,因而於2012年提出新規則草案,而後續相關發展,更值得我們持續留意跟進。
英國政府公布「英國醫療器材監管的未來」公眾諮詢結果並確立未來監管方向英國藥物及保健產品管理局(Medicines and Healthcare Products Regulatory Agency, MHRA)於2022年6月22日公布「英國醫療器材監管的未來之公眾諮詢政府回應」(Government response to consultation on the future regulation of medical devices in the United Kingdom),確立未來醫材監管方向。本次諮詢收到將盡900件回應(民眾與業者大約各半),結果顯示民眾業者對於強化醫療器材安全監管的支持。 MHRA將強化MHRA的執法權力,以確保病患安全,並且關注健康不平等議題並減少AI偏見問題;其監管設計上會考量歐盟和全球標準,並致力於建立英國符合性評鑑(UK Conformity Assessed, UKCA)。MHRA於安全方面,將增加製造商、進口商與經銷商的責任,並要求有英國地址的負責人對瑕疵商品負擔法律責任(構成法律責任的要件與製造商同)。其亦將要求製造商賠償被不良事件影響的人、禁止行銷上使用引人錯誤之表示、導入醫材之單一識別碼(Unique Device Identifiers, UDI)與增加註冊所需提供之資料,且製造商須建置上市後不良反應監測系統並回報統計上顯著的不良事件趨勢。創新方面,MHRA欲增設「創新醫療器材上市管道」和「軟體醫材上市管道」,以顧及創新與軟體醫材特殊需求。針對一般軟體醫材(software as a medical device, SaMD)與人工智慧軟體醫材(AI as a medical device, AIaMD)的監管,MHRA僅欲於法規中增加「軟體」的定義,其他規範將由指引的形式公布。此外,其將AIaMD視為SaMD的一種,並不會額外訂定AIaMD相關規範。