本文同步發表於個人部落格：讓更多人進來

三十天終於寫完了，現在，你手上應該有一個跑得動的 SMART app。

昨天把你學的東西分成兩種。一種是規範講死的，換伺服器、換語言都還在。另一種是我幫你選的，你隨時可以挑別的。今天要講的，是前面那一種要去哪裡查。

下面每一個連結我都在 2026 年 8 月左右實際查過一次，記下當時的狀態碼才寫進來。查不到的我就沒列進來。

網站會改版、路徑可能也會異動，所以你讀到的時候有可能已經不一樣了。不過，重點是這幾類資源各自能解決什麼問題，網址只是當下的入口而已。

你手上現在有什麼

經過三十天，你的專案是一支靠靜態網頁就跑得動的 SMART app。一個 HTML 進入點加幾支 ES module，沒有 package.json。不用裝套件，也沒有建置步驟。

它目前可以做的事情大致如下：

• 完成 standalone 授權，帶 PKCE 與 state
• 從 .well-known/smart-configuration 找出授權端點，並把結果快取（Cache）起來
• 讀病人基本資料、生命徵象、病況、用藥
• 把資料畫成趨勢圖
• 寫一筆自己量的血壓回去
• 把五種失敗轉成看得懂的訊息
• 跟完分頁，不會只拿到第一頁
• 對兩家醫院各自授權，整合出一個有來源的時間軸

還有一件沒有呈現在畫面上的，但一樣很重要的：你知道它哪裡還不夠。

一個是稽核軌跡。誰在什麼時候讀了哪一筆病人資料，這種紀錄要一行一行留下來。day27 那張安全清單的最後一條就是它，你的 app 沒有。

另一個是快取。day22 把每台伺服器的授權端點存了下來，存活時間 24 小時。這段期間對方要是換了端點，只能靠人去按那顆清除按鈕，程式自己不會發現。

前面說的那八項，只要照著這三十篇做一次就會有，抄一份現成範例也會有。但兩個缺口不一樣。你要先知道稽核軌跡應該要有，也要知道快取需要失效路徑，才看得出這兩個缺口。

真的要讓別人用你的 app，卡住你的多半是這種缺口，不是少一個功能。清楚自己缺哪一項、卡在哪裡，下一步就知道要先補哪一個。

規範去哪裡看

看規範這件事，很多人卡在不知道從哪一份開始。順序是這樣。

SMART App Launch。 這是本系列從頭到尾在講的東西。

• 正式版：https://hl7.org/fhir/smart-app-launch/
• 持續建置版：https://build.fhir.org/ig/HL7/smart-app-launch/app-launch.html

兩個都通。正式版比較穩，持續建置版會比正式版早幾個修訂。要查現在到底該怎麼做，看正式版；要查以後會變成怎樣，看持續建置版。

FHIR R4 規範：https://hl7.org/fhir/R4/。 資源長什麼樣、有哪些搜尋參數，都在這裡。day03 教的那些 base resource 就出自這一份。

底下那三份協定。 SMART 不是憑空冒出來的，它是蓋在這三份上面的：

• OAuth 2.0：https://datatracker.ietf.org/doc/html/rfc6749
• PKCE：https://datatracker.ietf.org/doc/html/rfc7636
• OpenID Connect Core：https://openid.net/specs/openid-connect-core-1_0.html

day07 到 day13 講的授權流程、PKCE 跟身分那幾塊，都可以追到這三份。scope 的寫法跟 launch context 是 SMART 自己訂的。那兩塊查 SMART App Launch。真的卡住的時候回頭翻，比找部落格文章可靠。

寫程式的時候會用到的

SMART Health IT 開發者文件：https://docs.smarthealthit.org/，授權那一章在 https://docs.smarthealthit.org/authorization/。

這是本系列用的 fhirclient 那個團隊維護的。規範講的是應該怎麼做，這一份講的是這套程式庫怎麼用。

SMART Health IT Launcher：https://launch.smarthealthit.org/。 你這三十天一直在用的那台，這個系列從頭到尾都連得上。

SMART App Gallery：https://apps.smarthealthit.org/。 別人做出來的 SMART app 目錄。想知道這個技術實際被拿來做什麼，看這裡最快。

Synthea：https://synthetichealth.github.io/synthea/。 sandbox 裡那些假病人就是它生出來的。它會自己跑出一批有完整病史的假資料。要另外裝執行環境，這裡只是告訴你有這條路可以走。

想要更多測試資料，或是想要有特定病況的病人，就是靠它自己生。

台灣自訂的部分

TW Core IG：https://twcore.mohw.gov.tw/ig/twcore/。 day25 整篇在講的那份，衛福部的核心實作指引。

TWPAS IG：https://nhicore.nhi.gov.tw/pas/。 健保署的事前審查實作指引。

臺灣醫療資訊標準大平台：https://medstandard.mohw.gov.tw/。 標準相關的入口網。

TW App Gallery：https://medstandard.mohw.gov.tw/tw-app-gallery。 同一個站台底下的應用程式目錄，按用途分成十類。

這一條是後來用瀏覽器補確認的，curl 只抓得到外殼。它不在下面那張圖上。

衛福部資訊處電子病歷專區：https://dep.mohw.gov.tw/DOIM/lp-7156-114.html。 政策與公告會出現在這裡。

社群要去哪裡找

國際上有 HL7 的官方討論區 https://chat.fhir.org/，那裡有一個討論 SMART 的頻道。我只列站台首頁，不列頻道網址。那個網址的 # 後面是前端路由，伺服器回的 200 只能證明站台還活著。

台灣這邊我找了一下，原本想列 HL7 Taiwan 的官網。但實際去抓的結果是 HTTPS 連不上，回的是連線被重置。改用沒加密的 HTTP 才通。

我沒有把它列進來，理由有兩個。一是查證那天它的 TLS 是壞的。一篇在教你做醫療 app 的文章，叫你去連那樣一個站，說不過去。二是我自己沒有參與過那個組織，列了也只是轉貼一個網址。

台灣應該還沒有一個專門在講 SMART on FHIR 的開發社群。 至少我找不到。

如果有興趣，或許大家可以一起成立一個。一開始也不用很正式，幾個人聊聊就可以。

五個可以動手做的題目

這五個題目來自我自己專案裡的一份路線圖，每一個都評估過法遵風險跟要花多少工。

第一個最適合當起點。 病人看的是自己的資料，沒有跨機構同意權的問題，而且使用者一眼就有感。你第四幕做的那條合併時間軸，已經是它的雛形了。

第二個要花的工最少，但要先有第一個。 剩下的幾乎只是把訊息組起來。價值在哪？單一家醫院只能說「這次升高了」，多家醫院才能說「這次比你過去每一次都高」。

第五個在那份路線圖上被標成擱置。 不是技術做不到，是兩家醫院都要願意接進來。那件事要先談成，比寫程式麻煩得多。

第四個要動手的話，規範在 https://hl7.org/fhir/uv/ips/。day25 介紹過它，那是國際病人摘要的實作指引。

要動手之前，那份路線圖列的三個難題值得先看一眼：

• 跨院怎麼認人。 不同醫院的 patient id 是不是同一個人
• 每一家的資料長得不一樣。 檢驗代碼大多一致，但各院還是有自己訂的，單位跟參考區間也不一樣
• 同意權管到哪裡。 在一台伺服器上拿到授權，不代表資料可以流到另一台去

第一個難題 day24 講過我們的做法：不做比對，讓病人每一家各自授權。 這個選擇順便也解掉了第三個難題。每一條連線都是病人本人授權的，合起來的又是他自己的資料。

跟著做：挑一個題目，寫三行字

最後一次跟著做。不寫程式。

從上面五個題目挑一個，或者你自己想一個。然後寫三行字：

第一行，它要讀哪些 FHIR 資源？ 拿 day03 的清單對一次。讀不到的資源，這個題目就做不成。

第二行，它需要哪些 scope？ 用 day10 和 day11 的規則組出來。組完看一眼，有沒有多要。

第三行，它會不會寫資料回去？ 如果會，day18 和 day27 那條「唯讀要寫成自己訂的規則」要先想清楚。

三行寫完，你就有一份可以動手的規格草稿了。寫不出來的那一行，不是你能力不夠，是這個題目還沒想清楚。

這三十天到底做出了什麼

回頭看整個系列。

第二幕那十篇是整個系列最硬的部分，也是後面所有東西的基礎。

三十篇裡有一件事我從第一篇做到最後。跟著做的每一步都能在公開 sandbox 重現，不需要任何醫院給你權限。

這正是 SMART on FHIR 最重要的一點。它是一套標準，授權那一套流程換到真的醫院也還是這樣走。至於對方核發哪些 scope、資料照哪一份 profile，那要一家一家問。day23 跟 day25 講過這件事。

附錄：程式碼在哪裡

範例都在 losehrt/ithome-2026-smart-app。MIT 授權。

每個資料夾都是一份完整可跑的專案。讀到哪一天就進哪個資料夾，不用回頭拼前幾天的檔案。跑法是 python3 -m http.server 5173，不需要 Node.js，也不用打包工具。

不想 clone 的話，下表「線上跑」那一欄點下去就會跑。線上版首頁也列了同一份清單。

想回到某一天當時的狀態，資料夾名稱前面那段就是 tag，git checkout day09 這樣用。

沒列到的那幾天沒有自己的資料夾。day01 到 day03、day05 是規範與請求的片段，讀文章就好。day07 全程在網址列上操作，一個檔案都不用改。day08 寫的 pkce.js 跟 day09-first-authorization/ 裡那份一字不差。day23 之後都沒有新的程式碼。

小結

day01 的收尾我寫過一句話：

這個系列真正想做的，是讓更多人有能力做出下一個火線超人。

三十天過去，那句話沒有變。醫療資訊這個領域最大的問題不是技術難，是兩邊都懂的人太少。懂臨床怎麼跑的人，跟寫得出 app 的人，很少是同一個。

三十篇範例，一行 Rails 都沒有，也沒有用到任何前端框架。這是故意的。醫療資訊的門檻，一半來自規範本身，另一半是那一整套語言跟框架墊高的。讀規範要懂 FHIR，跑個範例還得先會 Rails 或某個框架。光是後面這一關，就能嚇退大半個 web 圈的人。

換成瀏覽器原生 JS，後面那一關直接拿掉。剩下的難度，才是規範本身該有的難度。臨床那一關我拆不掉，那得自己去看現場怎麼跑，或者找一個願意講給你聽的人。

標準已經在那裡了。sandbox 是公開的，規範是免費的，程式庫是開源的。缺的是有人願意花三十天把它搞懂。

你已經花了。

那接下來就換你了。挑一個題目，寫那三行字，然後開始。