健康經濟學指標

第 63 個主題，共 91 個· 軟體工程與數位化交付

DORA指標

DORA（DevOps研究與評估）指標是衡量軟體交付表現的四項指標——部署頻率、變更前置時間、變更失敗率，以及部署失敗後的恢復時間——再加上作為第五項的可靠性。它們是該領域中經過最充分驗證的交付基準，且每一項都能直接對應到健康經濟學的解讀方式。

為何重要

DORA長達十年的研究，將這些指標與組織績效直接關聯起來。2024年度報告中的分組：**卓越（elite）**團隊按需部署（每天多次），從提交到生產環境不足一天，變更失敗率約5%，恢復時間不到一小時；**低效（low）**團隊每月部署一次或更少，耗時數月，變更失敗率約40%，恢復需要數週。對醫療系統而言，這些絕非IT部門自娛自樂的虛榮數位：它們決定了臨床價值觸達病患的速度，以及每一次變更所攜帶的風險大小。

計算方法

部署頻率       = 生產環境部署次數 / 時間
變更前置時間   = t(部署時刻) − t(提交時刻)，取中位數
變更失敗率     = 失敗的變更數 / 變更總數 × 100
恢復時間（MTTR）= t(恢復時刻) − t(故障發生時刻)，取中位數
可靠性         = SLO達成情況（可用性、延遲、正確性）

健康經濟學層面的轉譯：

前置時間   → cost-of-delay.md：在流水線中滯留的週數 × 延遲成本（£或QALY/周）
失敗率     → 軟體變更的"不良事件率"：變更失敗率 × 每次事件的成本
恢復時間   → 停機造成的危害：MTTR × (損失的臨床活動 + 安全風險敞口)/小時
可靠性     → 效益折扣：一項可用性為99%的服務，實際交付的效益約為其
             建模效益的0.99倍——這正是軟體版本的"依從性"

實例演算

某信託機構病患流轉軟體團隊，在進行交付工程投資前後的對比：

                    投資前      投資後
部署頻率            每月一次    每週一次
前置時間            6周         4天
變更失敗率           25%        8%
MTTR                2天         2小時

該團隊每年交付約30項改進，每項改進的平均價值為每週£4,000（參見延遲成本）。前置時間縮短約5.4周，使每一項改進的效益流都提前到來：30 × 5.4 × 4,000 ≈ 每年£648,000的價值被更早交付。變更失敗率的改善：30 × (0.25 − 0.08) = 每年約減少5次失敗變更 × 每次事件平均成本£15,000（臨床系統停機、補救處置） = 每年£76,500。這筆交付工程投資，正是以與任何臨床介入完全相同的貨幣單位來估值的。

與軟體工程的聯絡

這份檔案本身就屬於軟體的那一側——真正值得指出的，是反向的對映關係：DORA指標其實是披著不同外衣的醫院營運指標。前置時間 ↔ 轉診至治療；變更失敗率 ↔ 再入院率（"彈回"的工作）；MTTR ↔ 急診回應；部署頻率 ↔ 門診吞吐量。改進方法在兩個方向上都可以相互遷移，因為二者本質上都是在安全約束下運作的排隊系統。同樣值得注意的是DORA 2025年度報告關於AI的發現：如今AI的採用與更高的吞吐量相關，卻也與更差的穩定性相關——這是一種既有療效、又有副作用的介入措施，恰恰需要本書所教授的那種淨收益分析（參見AI開發者生產力）。

陷阱

  • 指標操縱：透過無實際意義的空釋出虛增部署次數；透過不將熱修復計入失敗來壓低變更失敗率。應像衛生技術評估界定終點指標那樣，精確界定每一類事件。
  • 跨團隊排行榜：DORA的分組比較的是實踐方式，而非風險狀況各異的團隊本身；一個處於"高效"分組的臨床系統團隊，可能已是最優解，而追求"卓越"反而可能是魯莽之舉。
  • 只最佳化單一指標：只追求速度而不顧變更失敗率/可靠性，正是"吞吐量-穩定性"權衡取捨的陷阱——應始終將這四項指標一併報告（它們構成的是一份成本後果表，而非一個單一分數）。

來源