背景介紹
實現意義
框架搭建
詳細實現
背景介紹
醫護“上門”自古有之，大夫拎著藥箱到患者家中進行服務。隨著社會的發展，醫護上門服務被重新定義及再次細化，我們今天要說的上門護理就是其中一個極其重要的分支。
上門護理，顧名思義就是醫護工作人員上門給患者進行護理工作，包含會陰護理、母嬰護理、PICC護理等，主要服務物件就是高齡或者行動不便但又需要進行護理服務的患者。
隨著網際網路醫療的發展，網際網路+上門護理服務也越來越普及，現在市面上也有很多專做上門護理業務的公司和APP，比如醫護到家。
之前我自己就做過一版完整的上門護理，當時後端架構設計都已經完成，但因為某些原因停滯一直未完成上線，再後來在2020年底我司決定與第三方公司合作，只在我司患者使用的APP上接入上門護理的入口，其他工作均由第三方公司完成，相當於患者端我們只需要提供一個入口，後面的頁面全部是第三方的H5頁面，護士端我們不涉及。
雖然我自己做的上門護理並未上線，但由於之前做了詳細的調研，並且研發那邊也已經完成了研發，所以上門護理的構建上是沒有問題的，這篇部落格也就不算是紙上談兵了。
實現意義
患者想要獲得護理服務，有兩種方式，一種是去醫院獲得護理服務，一種是讓護理人員到家裡來進行服務，這兩種方式的服務場地、收費方式均有不同。
對於高齡或者行動不便的患者來說，上門護理服務大大解決了其不便出門的問題，對於子女來說也是省時省力。對於生活水平較高，寧願多花點錢也不願意去醫院排隊的患者來說，大大提升了護理體驗，節省了其在路上及醫院奔波的時間。
對於醫院來說，開展上門護理業務有助於緩解醫院門診壓力，提升醫院口碑，提升醫院收入。
對於護士來說，最大的好處就是能夠提升個人收入，但優勢與風險並存，相比於在醫院提供服務，上門的風險相對來說會更高一些。
對於公司來說，上門護理是一個能夠盈利的重要業務，相比於線上問診業務統一的定價（統一掛號費）來說，上門護理價格制定更加靈活，可操作性很強，這也是為什麼現在有公司上門護理業務作為主營業務能夠活下去的原因。
框架搭建
（一）調研
在進行框架搭建之前，首先需要對上門護理進行線上、線下的調研。
線上調研主要調研同型別APP是如何做的，有哪些需要注意的點並對一些重點進行分析。患者端一般我們正常註冊認證就能夠進行使用了，護士端則需要護士證件，最好找一下現有的資源幫忙認證一下，全流程跑通看一下，這樣調研也能夠深入一些。我在這裡選取的調研物件主要是醫護到家，也挑選了其他APP進行簡單對比，在這裡不再多說。
線下調研主要是對醫院護理部進行的調研，業務肯定是基於一家醫院上線試執行的，所以一定要結合實際，不能憑想象做一個用不了的東西。如果公司與多家醫院都有合作，在有條件的情況下可以多進行一些調研，這樣考慮的更周全，做出來的東西也會更通用。線下調研一個是護理部線下的基礎流程，另一個是開展這項業務護理部這邊的一些意願和要求，最後就是需要跟護理部談妥分賬對賬等。
完成調研之後，最好將自己的調研結果彙總輸出一個調研文件，這樣比較有利於理清思路，也便於他人查閱。
（二）角色分析
為什麼要進行角色分析？進行角色分析的目的是進一步明確上門護理業務的參與者及他們的使命，這樣有利於幫助我們抽象出具體的模組。上門護理的角色其實在前面實現意義裡面提到過，在這裡我們來再進行一次剖析。主要角色分為三個，如下圖所示：
① 患者
患者是消費者，是業務的發起者。患者需要下單，並在護士上門之後與護士共同完成訂單。
② 護士
護士是服務提供者，是業務的完成者。護士在接了患者的訂單後，
③ 平臺/醫院
護理業務的管理者，可以不參與具體訂單執行，但需要管理護理專案、監督護理訂單。
在對角色分析完之後，我們對需要做哪些端、哪些模組、大體流程心裡都有了一個概念和預期，這個時候可以簡單畫一個流程圖來說明一下大致業務走向。
（三）確立產品的實現端、實現方式
根據上面的調研結果、角色分析，再結合我司的具體情況，明確下來需要實現的端和每個端以什麼方式來進行實現。因為我們主要是做網際網路醫院的，涉及到的業務比較多，所以像上門護理這種可以獨立成一個APP的業務在我們的APP裡也只是作為一個比較大的功能來做的。
患者使用患者端APP實現；護士使用醫護端APP實現；
醫院和平臺的管理主要使用web管理平臺實現，考慮到醫院工作人員平時在工作當中可能不方便使用電腦，所以將稽核這一塊放在了小程式上，方便醫院工作人員操作。實際上我們給醫院運營人員的許多功能都是放在了小程式上，就是為了方便運營人員在醫院能夠使用手機隨時隨地的為患者解決問題。
（四）各個端基礎模組及流程搭建
在這一步中，可以使用框圖，也可以使用思維導圖來列出來。
① 患者端
患者端主要為兩個大的模組，一個是患者用來下上門護理訂單的模組，一個是下單後訂單的管理模組。
② 護士端
護士端主要分為三個模組，護士擅長模組、接單模組和個人訂單模組。護士擅長模組是智慧推薦的基礎。接單模組是護士自主在訂單池裡面去進行接單，而個人訂單模組則分為兩個部分，一部分是被指定需要處理的訂單，另一部分是自主接的需要處理的訂單。
③ 管理端
管理端根據實際情況決定以什麼形態呈現，比如在這裡我們計劃的是小程式和管理平臺都會做，但是最終結合工作量和實際使用效果進行評估，將訂單稽核模組和訂單管理模組放在了小程式上實現，護理專案管理模組和業務流程引數模組則放在了管理平臺（web）上實現。
（五）全流程詳細梳理
實際上，在進行第三步和第四步之前，我們的腦子裡面已經大體勾勒一個大致流程了，要不然也不能梳理出第三步和第四步的東西出來，只不過第三步跟第四步走完之後，上門護理的全流程更清晰了，現在也能夠將其詳細的梳理出來了。
一般在此時我會使用泳道圖來進行梳理，明確每個角色、每個端需要做的事情和整體流程是如何進行串聯的。
在這裡貼出圖的一部分進行演示說明。詳細的流程就不在此進行說明了，有興趣的同學可以根據前面列出的東西自己梳理出來一個詳細流程，這樣有助於理解，印象也會更加深刻。
詳細實現
前面我們已經將上門護理業務整個進行了一遍梳理，接下來就是根據整理出來的流程進行實現。在這一部分，我會貼出一些原型截圖，也會對我覺得需要注意的地方進行說明。接下來我們按照端來挨個講解。
（一）患者端
① 功能入口
功能入口一般放在APP首頁，同時也會根據業務需要放在其他業務裡面進行導流。
在這裡給一個建議，首頁功能區可以做成可配置的，同時可以加上黑白名單等邏輯，這樣方便上新功能的時候進行內測，也比較有利於進行後期維護。
② 服務條款
服務條款可以放在點選功能入口之後的第一個頁面，也可以放在下單的那個頁面上。
③ 護理類別、護理專案
每一個護理類別下面都會有一些護理專案，比如母嬰護理類別下面會包含 保胎針護理、會陰護理、新生兒護理等。
每一個護理專案包含顯示圖示、顯示名稱、價格、服務說明、溫馨提示等關鍵因素。
護理類別、護理專案包含的所有關鍵因素在管理端的護理專案管理裡面均可以進行配置。
④ 提交專案、選擇服務時間
如果規則為一次只能選擇一個護理專案，那麼在護理專案詳情裡面直接點選提交即可，提交後開始選擇上門服務的時間。一次只能選擇一個護理專案相對來說處理邏輯比較簡單，但為了滿足患者一次下單實現多項護理的需求，我們引入了購物車的概念。
購物車的好處在於，一次有多項護理需求的人只需要進行一次下單，交通費用等都只需要支付一次即可。
但加了購物車之後的複雜之處在於，首先是服務費用怎麼收取（收一項還是收多項），其次是護理時間怎麼決定（每個護理都有自己的服務時間排班，不同護理服務之間存在差異），最後是怎麼派單的問題（每個護士的擅長並不相同，上門護士需要），這些問題都需要考慮清楚才能夠做購物車，將購物車裡面的東西一次性進行下單。
④ 護理基本資料
在下單之前，需要填寫基礎的護理資料，以便於訂單稽核及護士接單。
⑤ 訂單狀態流轉
下單後支付，支付金額包含的收費類別由具體的業務情況決定，支付完成後生成待稽核的訂單，由於涉及稽核流程，所以訂單的狀態較為複雜，如下圖所示：
（二）管理端
小程式：小程式上主要完成訂單稽核、分配及跟蹤工作。
① 稽核
護士/管理人員進行訂單稽核的時候，可以做兩個操作：
Ⅰ 接單。接單表示會繼續處理該訂單
Ⅱ 拒單。拒單標識訂單稽核失敗，該訂單將不會被繼續處理，患者的訂單費用會原路全額進行退回。
② 派單
在接單之後，可以選擇將訂單派給具體的護士，也可以選擇將訂單放入訂單池，由護士自由進行接單。指定給護士的訂單，護士有權進行退單，退單後需要重新進行分配。
③ 訂單狀態流轉
Web管理端：web管理端主要做的是護理專案配置及業務流程引數配置。
① 護理專案配置
在護理類別下面配置護理專案。
② 業務流程引數
字典、業務流程引數等均在管理端進行配置，這裡要注意的是，要想業務通用性更高一些，那麼能配置的儘量採用配置的方式實現，不要寫死，這樣將該業務流程應用於不同的客戶上去，能夠以最小的改動實現客戶需要。
（三）護士端
① 功能入口
功能入口同患者端一樣，通常放在APP首頁的功能區。
② 接單
護士接單分為兩種，一種是指派給自己的訂單，護士可以選擇接單/退單，另一種是訂單池裡面的訂單，護士可以根據自己的實際情況進行接單。
③ 接單池
為了給護士更好的接單體驗，可以讓護士設定自己的個人擅長，接單池列表就根據護士擅長、距離等要素進行個性化推薦。
④ 上門服務
為了對服務過程完整記錄，在服務開始前、服務中、服務後都應當留存一些憑證，文字、圖片及位置等資訊。
⑤ 完成訂單
護士完成訂單分為兩種情況，一種是所有費用在患者下單時都已經明確計算好了，耗材收費按照一個合理的點進行收費，那麼不需要再計算整個過程中是否有多使用耗材的情況，直接完成訂單即可。
另一種情況是在患者下單的時候我們只收取了基礎耗材費用，具體耗材使用情況根據上門服務後的情況進行結算，這個時候護士需要計算耗材的額外情況，決定是否需要患者補交費用。這種情況建議在患者下單的時候收取一定的押金費用，多退少補會更方便一些。
⑥ 安全問題
醫護、患者的安全問題一直都是上門護理業務當中需要重點考慮的，尤其是順風車事件等為我們敲響了一個警鐘，我們可以從以下方面做一些能夠保障醫護及患者安全的措施。
Ⅰ 為使用者購買保險
Ⅱ 支援服務過程中便捷報警
Ⅲ 支援全程進行錄音、錄影
Ⅳ 支援對訂單全程跟蹤，服務時間異常的訂單自動報警
⑦ 訂單狀態流轉
以下為護士端的訂單狀態流轉：
到這裡，上門護理就基本上講完了，在這個裡面，我們講的還是比較粗糙，只有自己從頭到尾的做一遍，才知道里面到底有多少門道，這個業務是我做過的最複雜的業務之一。
寫在最後：這個業務成為了我最難忘的專案之一，除了其本身比較龐雜之外，還因為其歷程較為坎坷，用現實教會了我：以變化的心態擁抱世界，以樂觀的態度看待問題。即使做了這麼久的東西沒法上線，但我們通過與第三方合作的方式還是解決了這個問題，這就可以了，我們最終還是達成了目標。問題不重要，解決了問題達成了目的才是最重要的！