醫療不良事件系統從0到1設計分享(一)
編輯導語:醫療不良事件,也就是由醫療導致的傷害,延長了病人的住院時間,導致殘疾的一切事件。本文作者分享了之前做過的一款醫療不良事件系統的設計過程,希望能給你帶來幫助。
今年年初,設計了一款醫療不良事件系統,今天我想把從0到1的設計過程分享給大家,希望對不知道如何入手做一款產品的伙伴有所幫助,另一方面是希望可以和醫療行業的產品經理互相學習,此系統從0到1主要經歷了如下階段。
一、名詞定義
何為醫療不良事件呢?不良事件定義為由醫療導致的傷害,與疾病的自然轉歸相反,延長了病人的住院時間,導致殘疾的一切事件,包括可預防和不可預防的不良事件。不可預防的不良事件指正確的醫療行為造成的不可預防的損傷;可預防的不良事件指醫療中由于未能防范的差錯或設備故障造成的損傷(來源:百度百科)。
二、了解政策規范
我們做的是醫療產品,所以做產品前一定要查閱相關規范,在合規的基礎上開展業務是一個產品面世的前提條件。
三、產品架構圖
產品架構是至關重要的,一個清晰的產品架構可以使人一眼就知道產品的演進地圖,產品架構我分為了表現層、業務層、基礎支撐層三部分,三個部分分工不同,基礎支撐層給業務做支撐,它并不參與實際的業務,但是業務過程中需要依賴它,業務層是產品具體要做的功能范圍,表現層是用戶實際操作的的入口。
四、業務流程圖
對于B端產品來說,業務流程圖是繞不過去的,前期,一定要梳理好醫療不良事件的業務流程,只有清楚了業務的流程,才能將業務的流程映射到系統功能的流程里。
五、狀態機圖
狀態機圖可以清晰的表示出系統里不良事件的狀態流轉,不同的動作會觸發事件流向不同的狀態,從待提交狀態到已完成/作廢狀態,代表了事件整個的生命周期。
六、功能清單(部分)
功能清單就是比較具體的內容,功能清單是我們產品要做的具體事情了,功能清單可以按照一級模塊、二級模塊,功能名稱、功能描述,備注去列出,功能名稱和功能描述我的建議是分開列出。
七、事件上報模塊
事件上報要定義好事件的類型,默認系統有14個事件類型:醫療不良事件、藥品不良事件、護理不良事件、輸血不良事件、院感不良事件等。
每個事件類型填寫的內容是不同的,需要通過編輯器軟件進行填寫,填寫的信息涉及到數據源的,也有非數據源的,如患者姓名就是數據源;患者的基本信息可以通過輸入住院號或者門診號快捷填充。
事件填寫完成后,提交分為兩種情況:一種是正常提交,一種是匿名提交,匿名提交的事件無法操作退回,上報人會顯示匿名。
上報里一個比較重要的內容,是事件的審批流程,目前我們是用的第三方的審批組件,配置好事件的審批流程,在不同的節點會自動提交給對應的審批人。
八、事件處理模塊
事件處理是對提交的事件進行處理操作,包括審核、退回、改派、協辦、結束。
- 審核:即審核通過,審核時需要輸入原因分析和整改措施,審核完成后事件會自動進入下一個審批節點,直到完成
- 退回:可以對事件進行退回,退回需要填寫退回原因,以及選擇退回給上報人還是上一級審批人,退回的事件需要重新提交進行審批
- 改派:改派用于審批人無法處理事件,改派給其它科室的人進行處理,改派可以理解為事件審批發生轉移
- 協辦:協辦是審批人需要邀請其他人一起進行審批,協辦完成的事件還會回到審批人最終進行審批
- 結束:結束事件用于提前結束事件
- 作廢:作廢事件,作廢的事件相當于結束狀態
九、總結
不良事件上報的一期就分享到這里,不良事件系統雖然不是日常的診療業務,但是在醫院里都很重視不良事件,發生不良事件要及時上報、處理,分析發生的原因,提出整改措施或處理意見,久而久之才可以減少不良事件的發生。
下期我們將審批中的會簽、或簽,事件魚骨圖等內容進行講解。
本文由 @醫療產品大本營 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協議。
寫得真不錯,如果在產品0-1的過程中,除了了解政策以外,把需求調研與分析的過程能講清楚,產品架構除了上報業務外,如果將分析管理部分考慮進來,整個產品將更加完整了。點贊?。?!
感謝
您好,協辦流程是如何處理的
文章介紹的很詳細呀,第一次這么清楚的知道醫療方面的一些知識