Dignity Health 是我在 Cal Poly 做的第二個專案。專案目標很簡單：改進放射科，但該改進目標為何、如何分析和怎麼改進都取決於各個小組，所以比起 Oracle 專案又多了一層挑戰。
資料、問題和切入點
當初 DH 的 Kickoff meeting 就在 Oracle 的後一週，由於兩者時間軸大致重疊，中途 Dean 和 Director 決定將 DH 延期，報告日改到了第三學期。當 Team 5 完成 Oracle 的報告時，DH 也剛完成期中 Check-in，可以想見 DH 受到 Oracle 專案的影響不小，這點稍後再提。
根據維基百科上的介紹，DH 旗下有 40 間醫院，是加州最大的非營利醫療網，我平常在 SF 走走就會遇到幾間。對如此龐大的醫療集團，任何細微的改進都能產生顯著的影響，於是早在專案開始前，DH 的管理層就集思廣益，希望能找到適合的題目。最後他們將眼光放在了放射科上。如果我沒記錯，選擇放射科的原因包括了業務花費高昂，臨床看片、診斷、到治療的品質有時很難掌握，也就成了改進空間大、影響也大的領域。改善得宜的話，不但能為患者和醫院雙方省下不少費用，也能提升醫療品質。
有了改進放射科這個題目以後，DH 所提供的資料是某段時間內的匿名診斷紀錄，包括就醫時間和地點、患者種族背景、檢查項目、診斷結果和評論（free text & ICD）等等。為了照顧我們這群基本沒 pre-med 背景的小蘿蔔頭，DH 也補充了幾個改善方向：
- 降低業務成本
- 降低等待時間和回診率
- 降低患者輻射曝露量
整個專案最令我興奮的地方在於 DH 的 Director 在開小組會議時很明確的跟我們說：「我們就把你們當顧問，希望你們可以幫我們解決問題。」於是從一開始想吃天鵝肉的我就興致勃勃，希望能在茫茫資料海中挖掘洞見。
從 ACR Guideline 到一致性
經過了兩三週的討論以後，Team 5 最後將分析重點放在了改進檢驗項目上。畢竟只要能選擇正確的檢驗項目，就能降低不必要的開銷、免除不必要的檢查，也就能降低等待時間、回診和輻射量。聽起來不錯，但是該怎麼衡量準確率呢？
我們最初的構想是源於 DH 所提供的 Appropriateness Criteria 資料。Appropriateness Criteria 是一份由 American College of Radiology 所發佈的指南，目的是為不同病徵中提供檢驗項目的參考依據。比方說，如果有位患者的 clinical condition 是 Acute Chest Pain，點進 Acute Chest Pain 的 Narrative & Rating Table 中就能看到 X-ray、CTA 等檢驗項目的評比、備註和放射量程度。也就是說，Appropriateness Criteria 可以當作衡量醫療品質的參考。
雖然 AC 是很好的參考資料，它所涵蓋的病徵與檢驗項目畢竟有限，也只能根據片面的病徵判斷檢驗項目的合適程度。於是我們轉念一想：既然 ACR 點出了病徵和檢驗項目之間的關係，那我們能不能乾脆訓練一套模型去學習如何診斷，並根據不同情況下——病徵、種族、甚至就診時間——的預測準確率判斷決策是否一致，進而檢驗醫療品質？這個分析的假設是「一套好的醫療流程在相似的條件下，應該具有穩定、一致、可預測的決策」，於是具有低預測準確率的情況自然就成了改進的重點。
| 分析方法 | Appropriateness Criteria | Predictability |
|---|---|---|
| 品質衡量依據 | ACR 所提供的檢驗項目評比 | 實際診斷是否和模型預測結果一致 |
| 優點 | 具有堅實的 domain knowledge | 參考變因廣、應用靈活 |
| 缺點 | 病徵和檢驗項目資料有限 | 過於依賴資料和分析假設 |
現在看來，其實用模型判斷結果來衡量醫療品質也會產生兩個問題：
- 模型能正確學習病徵和檢驗項目之間的關係嗎？
- 就算模型學習正確，與預測結果一致就是好的診斷嗎？反之亦然？
第一個問題和模型的訓練方法有關，我們或許能透過合理的演算法或資料能解決這個問題；第二個問題就比較偏改進的目標，也得考慮如此分析後，對醫院內部文化所帶來的影響。這種分析方法或許只適用於追求一致性的目標，但如果醫院的目的是不斷創新、尋求不同的解決方案的話，恐怕就不太適用，或是在解讀上要格外小心。
不過這些都是一年後寫這篇文章所想到的後話。當時的 Team 5 並沒有想這麼多。以下繼續接著談我們最後交出的成品。
故事、故事、故事
在決定好方向後，我們就走上了和當初 Oracle 差不多的路——建模、分析、並利用 dashboard 呈現結果。由於 DH 的報告就在 Oracle 後一週，我們收到的評論自然是一面倒的「你們應該要多花些心思在故事上」。我們從那之後就開始針對特定場景列出建議。
由於我們的 dashboard 是一張很直觀的 heat map——縱軸是醫院的流水號，橫軸是場景，顏色偏暗代表預測率低，顏色偏亮代表預測率高。我們說的故事，也就是將幾個預測率特低的場景拿出來，分析可能的原因，並尋找潛在的建議。比方說，有幾個病徵本身就很籠統，檢測項目的預測率也就變得很低，這時我們可能就會建議紀錄更細節的病徵，或是針對這些籠統病徵強化判斷流程。
最後我們在期末報告時成功扳回一城——有 dashboard，有故事，也有確實的建議。雖然準確率這㝛切入點還是帶有濃濃的實驗性，在我們報告建議時，有幾位高管說「這些醫院確實是比較需要注意的幾間醫院。」我們事前並不知道任何醫院的背景資料，甚至也不知道它們的地理位置。高管的解讀稍稍驗證了這套分析方法的有效性。
問對的問題
最後我們還是很可惜地和 Best Team 猜肩而過。最後勝出的小組是利用 NLP 分析 free text，並根據這些額外資訊改善醫療品質。我想他們會勝出的原因應該是因為應用更實際，也是 healthcare 本來就很有興趣做的項目，相較之下也有可能是我們的分析方法太有實驗性，DH 沒辦法輕易驗證有效性。不過不管原因為何，我都覺得 DH 專案是一次很寶貴的經驗。我們成功在 Oracle 的基礎上強化了 storytelling，也再次入圍決選名單。
最後，我覺得 DH 專案最大的 takeaway，應該是我們從收到問題和資料到擬定分析方向的摸索期——構思分析流程，檢視流程是否可行，再根據新事實調整流程。不論你認為這段摸索期是 MECE、design thinking 還是 computational thinking，我相信累積摸索的經驗，並掌握拆解問題所需的分析（analytical）、量化（quantitative）與溝通技巧，是成為顧問所必備的能力，在團隊中也才能漸漸往管理的位置走。