把紙本、共用試算表或通訊軟體中的診所流程改成系統時，需求清單常只有掛號、候診、修改資料、查詢與匯出。這些功能即使都能操作，仍不代表系統已具備可上線的資料治理：櫃檯是否看得到不必要的敏感內容？共用帳號修改後能否找到操作者？輸入錯誤時是覆蓋原值、刪除紀錄，還是留下更正脈絡？
客製化系統開發的驗收，需要同時描述「誰可以做什麼」與「做完留下什麼證據」。本文用診所流程作為具體情境，但不是法律或醫療資訊系統認證建議。實際適用規範、資料保存與專業責任，仍應由機構依業務及法律意見確認；系統團隊的工作，是把已確認的規則轉成權限、畫面與測試案例。
不要直接把紙本欄位全部搬上線
盤點現況時，除了記錄表單名稱與欄位，也要問資料為何蒐集、由誰提供、誰會使用、何時需要更正，以及多久後不再需要。紙張放在不同櫃位，原本可能自然形成某種存取限制；改成集中資料庫後，若所有帳號都能搜尋、匯出，就會把原先局部可見的資料擴大到整個組織。
全國法規資料庫的個人資料保護法第 2 條將病歷、醫療、健康檢查與可識別個人的聯絡方式等列入個人資料範圍；第 5 條要求蒐集、處理或利用不得逾越特定目的必要範圍，第 6 條則對病歷、醫療等資料另有規定。規劃時不應把「公司內部使用」當成全部開放的理由，而要由負責單位逐欄確認必要性與適用依據。
可把欄位分成基本識別、聯絡、預約與候診、專業紀錄、付款或申報，以及系統管理資訊。每一類列出可查看、可新增、可更正、可匯出與可刪除的角色。列表不能只寫「管理員全部權限」；還要區分帳號管理者、業務資料主管與技術維運者，避免維護系統的人自然取得所有業務內容。
權限驗收要測畫面、查詢與匯出
角色權限常只在選單上隱藏按鈕，實際網址或匯出功能仍能取得資料。驗收案例應從具體角色開始，例如櫃檯可建立掛號及更新候診狀態，但不能查看專業紀錄全文；專業人員可查看所需內容並完成紀錄；主管能處理例外與查核；技術人員則只取得完成維運所需的最小範圍。
每個角色都要測正常與拒絕路徑：從選單進入、直接輸入網址、使用搜尋、下載附件、批次匯出及呼叫後端介面。拒絕不能只依前端把按鈕藏起來，伺服器仍應依登入身分檢查操作。帳號離職、代理、跨院支援與臨時權限也要有啟用、到期、撤銷與複核方式，並確認歷史紀錄仍指向原操作者，不因帳號停用而消失。
以沐光身心診所 門診管理展示案例為例，畫面把掛號候診、看診狀態與健保申報整合在同一個儀表板。這是展示作品，不代表真實診所導入成果，也不能據此認定符合特定法規或醫療標準。它適合用於權限訪談：櫃檯需要看到哪些候診狀態才能調度？申報資訊由誰確認？對外候診畫面應呈現哪些最少資訊？同一筆資料在不同角色畫面中，不一定要暴露相同欄位。
操作紀錄不是資料庫備份
資料庫備份用於災難復原；操作紀錄則用來回答誰在何時對哪一筆資料做了什麼，以及結果成功或失敗。兩者目的不同，不能以「每天有備份」替代逐筆活動記錄。新增、修改、作廢、匯出、權限變更、登入失敗及系統設定調整，應依風險決定是否記錄與由誰查閱。
OWASP 的 Logging Cheat Sheet指出，應用程式本身掌握使用者身分、角色、權限、目標、動作與結果等脈絡；文件也將資料新增、修改、刪除及匯出列為稽核軌跡的例子。同時它提醒日誌不宜過多或過少，且來自其他信任區域的資料可能遭偽造或重播。轉成需求就是：記錄必要的識別與結果，但不要把完整敏感內容、密碼或存取憑證原樣抄入日誌。
發案時可為每類事件定義操作者、角色、時間、目標紀錄識別、動作、結果、失敗原因與關聯請求。還要指定日誌保存位置、誰能讀取、誰能調整記錄層級，以及如何防止一般管理者任意修改或刪除。保存期間與存取流程不能由開發者猜測，應由機構依實際目的與適用要求決定。
更正要保留原因，作廢不能等同消失
紙本寫錯時常以劃線、簽名與日期更正；數位系統若只提供覆蓋與永久刪除，反而失去前後脈絡。規格要區分輸入尚未送出的修改、正式送出後的更正、重複資料合併，以及依核准流程進行的作廢。每一種情況需要不同權限、理由與畫面提示。
驗收可建立一筆掛號，由櫃檯修正聯絡資訊，再由有權限者更正狀態；接著測試未授權角色查看、匯出與作廢均被拒絕。最後由查核角色確認時間軸能顯示必要的前後狀態、操作者、原因及結果，日誌中沒有多餘敏感內容。再測帳號停用後，既有操作仍可追溯，但該帳號不能繼續登入。
紙本流程數位化不是把欄位照抄到瀏覽器，而是重新確認資料目的、角色責任與例外處理。先把權限矩陣、事件清單、更正方式與驗收劇本寫進範圍，開發團隊才能估算後端檢查、介面差異、記錄保存及測試工作；使用單位也能用同一套證據判斷系統是否真的可上線。
