提交內容是讓委員更能瞭解軟體的臨床需求與特色，包含應用程式的影響力、成熟度、創新性，以及與「台灣核心資料群（TW Core）」的相容性與支援度等，都是第一波重要的評分條件。報名時需提交應用程式連結（App Demo URL），可填寫於二處，擇一提供，一是電子病歷應用程式內容說明 ( 限1000字數)* (請於內容說明中提供App Demo URL)，二是備註 (請於此處提供App Demo URL)，以利委員評選出進入決選之名單後，逕行進行軟體功能測試。
常見問題（FAQ）
常見問題（FAQ）
一、 評選標準與流程細節
1.1
在本次競賽中，評審對於提交的內容（如說明文件、架構、支援度）與應用程式本身的功能完整度及使用體驗，兩者的評分比重如何？
1.2
若進入決選階段，評審選用的病人資料不足以完全呈現 SMART App 的完整功能或所有關鍵應用情境，是否有其他方式可以補充說明或提供更全面的演示資料？
提交內容是讓委員更能瞭解該軟體的臨床需求與特色，包含應用程式的影響力、應用程式的成熟度、應用程式的創新性與應用程式與「台灣核心資料群（TW Core）」的相容性與支援度等，都是第一波重要的評分條件； 待委員評選出進入決選之名單，即會進行軟體功能測試，因此主辦方會通知入選者提供SMART on FHIR 標準格式打包並通過市集上架沙盒驗測流程的軟體，由主辦方提供輔導與測試服務，以協助入選團隊完成SMART市集要求上架產品需符合OAuth2.0及OpenID Connect技術標準之要求，以確保使用者下載程式集後可成功運作。 因此，若貴團隊進入決選後，我們也會通知貴單位提供合適的檢測資料，以完成相關驗測與情境展示，謝謝！
1.3
針對「優先支持應用類別」，若系統同時支援「臨床決策支援類 (CDS)」及「資料視覺化類」，評選時主要的評分項目與權重為何？
無論哪一個項目，皆是以：應用程式的影響力、成熟度、創新性，以及與「台灣核心資料群（TW Core）」的相容性與支援度等，來作為第一波重要的評分條件。您可以評估您的軟體在哪一個應用類別上更具優勢來選定參賽類別。
1.4
本次徵選是否強制規定必須使用 Taiwan Core Implementation Guide (Tw Core IG)？ 使用 Tw Core IG 或不使用，對於最終評分結果是否會有差異或額外加分？
本競賽規定要能對齊與「台灣核心資料群（TW Core）」的相容性與支援度，此為必要項目，會列為評分之一。
1.5
在評選過程中，主要會僅依據參選方提供的影片進行評分？還是會實際開啟並操作應用程式進行檢視？
評選分為兩階段：第一階段以提交內容（應用程式的影響力、應用程式的成熟度、應用程式的創新性與應用程式與「台灣核心資料群（TW Core）」的相容性與支援度等）作為評分基礎；待委員評選出進入決選名單後，即會進行軟體功能測試。
1.6
若會實際開啟應用程式，請問評審委員將會呼叫哪一方提供的 FHIR Server 進行資料串接測試？
待委員評選出進入決選之名單，即會進行軟體功能測試，因此主辦方會通知入選者提供SMART on FHIR 標準格式打包並通過市集上架沙盒驗測流程的軟體，由主辦方提供輔導與測試服務，以協助入選團隊完成SMART市集要求上架產品需符合OAuth2.0及OpenID Connect技術標準之要求，以確保使用者下載程式集後可成功運作。
1.7
提交第一階段內容時，應用程式尚未完全開發完成是否仍可參賽？，以書面內容、架構與規劃為主即可？或是否仍需提供部分可運作之版本以利評選？
報名時需提交應用程式連結，可填寫於二處，擇一提供，一是電子病歷應用程式內容說明 ( 限1000字數)* (請於內容說明中提供App Demo URL)，二是備註 (請於此處提供App Demo URL)；以利委員評選出進入決選之名單後，逕行進行軟體功能測試。通過軟體功能測試後，由主辦方提供輔導與測試服務，以協助入選團隊完成SMART市集要求上架產品需符合OAuth2.0及OpenID Connect技術標準之要求，以確保使用者下載程式集後可成功運作。
1.8
本次徵案是否有限定一個公司或一個人可以投遞的案件數量？
沒有限定案件數量，歡迎優秀作品踴躍參加。
1.9
SMART on FHIR 徵案所提交的應用程式（APP）可以是 Power BI 的儀表板嗎？
可以。但最終是否有實際應用效益將由審查會議決定。
二、 技術細節與資料串接
2.1
如何申請 FHIR API 的串接？若醫院內有 FHIR 格式的病歷資料庫，是否可直接申請串接？
醫院病歷資料（含 FHIR 格式）受法規規範，對外公開與應用皆有規範。若有串接需求，請廠商直接與目標醫院聯繫洽談。
2.2
在醫療資訊大平台網頁上，沙盒測試僅提供 FHIR Server URL 和簡短說明，是否有更詳盡的手冊或其他說明？
目前已在以下網站放置測試沙盒教學影片，請參考連結：https://thas.mohw.gov.tw/
・測試沙盒教學影片前往連結2.3
本次臺灣 50 徵案（SMART Marketplace）的施作方式，可以參考國外 HL7 SMART 嗎？還是有臺灣專屬的實作手冊或其他說明？
SMART 實作方式可參考 10/14 SMART 工作坊的課程教學，請參考當日簡報連結：https://thas.mohw.gov.tw/
・當日簡報連結前往連結2.4
關於必須支援的 FHIR Resource 類型，在各個「優先支持應用類別」中是否有明確的規定或建議清單？
本競賽規定要能對齊與「台灣核心資料群（TW Core）」的相容性與支援度，此為必要項目。
2.5
本次 SMART App 上架是否支援 Standalone Launch 方式啟動？
已調整沙盒，現在 Standalone Launch 與 EHR Launch 兩種模式皆可支援。
三、 市集永續與應用程式管理
3.1
衛福部建立的臺灣 SMART 市集是否有永續發展的規劃？在計畫經費結束後，有無長期的營運規劃？
市集經營會轉為商化永續營運。114-115 年採取徵案模式快速建立生態系。待計畫於 116 年結束後，會透過建立付費驗證機制與上架費之模式，逐步達成自給自足，永續經營之目標。
3.2
市集中的應用程式將如何進行定期檢測？是否是當天會議中提到的，年底將成立一個臨床AI註冊網頁，由開發者向負責任AI中心進行生命週期管理驗證嗎？能否舉例
年底會建立臨床AI註冊網頁，規定已上架之醫療AI需要定期將醫院使用數據上傳至該註冊網頁，以維護軟體之準確性，其管理方式跟衛福部負責任AI執行中心管理機制一致。如上架後之醫療AI產品需先至臨床AI註冊網頁註冊，同時規劃說明，將在哪些醫院驗證使用並提出數據，即會先規劃是半年或一年時，將上傳產品生命週期監測數據，讓註冊網頁得以瞭解並掌握該產品在醫院實際使用的準確度，若半年或一年期間，準確度有維持在某些標準之上，就繼續使用，若已經下降到某些臨界點，達顯著不準確的狀態，待在本註冊網頁回報後，即會將該醫療AI自市集下架，以達成良好的管理，因為透明化的管理機制，會讓每個下載使用的醫院都能安心使用AI。
3.3
請舉例說明醫療 AI 產品在上架後如何通過臨床 AI 註冊網頁進行生命週期管理？
醫療 AI 產品上架後需至臨床 AI 註冊網頁註冊，並規劃說明將在哪些醫院驗證使用及提出數據。規劃每半年或一年上傳產品生命週期監測數據，讓註冊網頁掌握產品在醫院實際使用的準確度。若準確度維持在標準之上，則繼續使用；若下降至臨界點，達顯著不準確的狀態，回報後即會將該醫療 AI 自市集下架，以達成透明化的良好管理。
3.4
已有產品的廠商參加徵案，其得獎產品在獲獎後半年內是否有限制不能販售？
歡迎已有產品的廠商參加。徵案辦法中提及的「需要提供半年試用期」，主要是希望透過試用，加速智慧醫療 App 的市場推廣機會。第一波徵案上架的廠商，試用範圍僅限於 SMART 打包上架市集的試用版本，非在 SMART 上架的販售版本不受此限制，因此廠商可以自行販售智慧醫療 App 產品。
3.5
廠商如何同時符合半年試用期規範與一般販售的需求？
廠商可以將 SMART 打包上架的產品區分為「半年試用版」與「一般販售版」，以符合規範。廠商可使用標配降規的方式來處理免費試用，確保已經付費使用者可擁有全部功能，也不影響現有使用者的權益。