一種在線醫療系統的製作方法

2023-08-06 16:28:31

本發明設計醫療技術領域，具體來說是一種在線醫療系統。

背景技術：

現在既有的隨訪形式很是隨意，不系統。沒有了治療後的有效隨訪，經治醫生自然也就不知道所治療過的患者到底愈後如何。沒有對比，經治醫生也自然不能了解現有的各種治療手段中哪種手段是最優的。雖然現在大部分醫院都設有多學科診療中心，其目的是經多學科討論給複雜患者提供一個最佳方案，然而，同樣面臨的問題是：參加討論的學科在疾病的研究方面大都是僅停留在自己的專業領域，那些某一學科的專家無法了解別的學科方法的確切效果，而且多學科診療中心會診後大都沒有相應的隨訪機構。

此外，大部分患者可能是很遠的外地來某一大醫院進行治療，可能經過手術或其他治療後，餘下的檢查就在當地進行了，醫生就更加不易獲知其治療的效果了。

綜上所述，無論是醫生個人自主隨訪，還是單位或部門對特殊病情的研討，其數據的採集過程漫長，且不便於其他醫生查詢。所以，對病患疾病療效的臨床數據採集機制的欠缺，導致臨床有效數據採集不完整，從單個醫生角度來說，經治醫生不能全面了解現有的各種治療手段中哪種手段是最優；從整個醫療體系角度來說，各科的醫生無法對相關病例進行橫向、縱向的比較和分析，極大程度的限制了醫療技術的發展。

技術實現要素：

本發明的目的是為了解決現有技術中對於隨訪機制的欠缺，導致對各種病例數據缺失的缺陷，提供一種在線醫療系統來解決上述問題。

為了實現上述目的，本發明的技術方案如下：

一種在線醫療系統，包括伺服器、在線複診交流平臺、患者用戶端、醫生用戶端、執業藥師用戶端、藥店用戶端；所述伺服器、在線複診交流平臺、患者用戶端、醫生用戶端、執業藥師用戶端、藥店用戶端之間通過網絡互相通信；

所述伺服器內包括第一存儲模塊和第二存儲模塊；所述第一存儲模塊內存儲有各科室病歷表，第二存儲模塊用於存儲與患者一一對應的病歷表；

患者、醫生均實名註冊，通過各自用戶端登錄並經過身份確認後醫生和患者建立對應關係進入所述在線複診交流平臺；

執業藥師、藥店均通過各自埠進行註冊登錄；

所述患者用戶端包括電子處方顯示模塊；

所述醫生客戶端包括患者病例建立模塊、在線處方模塊、數據查詢模塊；

所述執業藥師用戶端包括電子處方審核搶單模塊；審核結果判斷模塊；

所述藥店用戶端包括二維碼識別模塊、銷售記錄模塊、患者回執模塊；

所述患者病例建立模塊用於調取所述第一存儲模塊中相應科室的病歷表，醫生在病歷表中填入該患者的病歷信息，並與患者匹配形成一一對應關係；

醫生根據與患者在所述交流對話框內的交流內容，在該患者的病歷表中相應位置填入，並保存至所述第二存儲模塊中；

所述數據查詢模塊用於查詢第二存儲模塊中各種病歷表；

所述在線處方模塊用於醫生對該患者開具藥方並生成電子處方，生成該電子處方的同時生成與該電子處方一一對應的二維碼，並將該電子處方發送至電子處方審核搶單模塊；

執業藥師通過電子處方審核搶單模塊進行審核搶單動作；前多名搶單成功的執業藥師對該電子處方進行審核，審核通過後的電子處方發送到電子處方顯示模塊；

患者向藥店出示二維碼，藥店通過二維碼識別模塊識別該二維碼，並顯示與該二維碼相對應的電子處方，當電子處方中的全部藥品或部分藥品銷售完成後，對已銷售的藥品進行確認，且銷售記錄記載在銷售記錄模塊中並存入伺服器，同時患者回執模塊獲取銷售記錄，所述患者回執模塊與印表機連接。

優選的，所述病歷表包括必要信息和附加信息；所述必要信息包括患者姓名、病灶、首發時間、治療手段；醫生根據當前患者情況可在所述附加信息中增加相關信息。

優選的，所述伺服器中預存所有藥品明細；所述在線處方模塊包括電子處方單元、電子處方生成單元、審核請求單元、電子處方審核結果顯示單元；醫生在所述開電子處方元內獲取伺服器中的藥品名稱，並對該藥品服用注意事項進行標註，提交後所述電子處方生成單元獲取所選藥品及標註信息，並生成電子處方；該電子處方生成時籤有該醫生的電子籤名；電子處方生成後，所述審核請求單元獲取該電子處方信息。

優選的，所述電子處方審核搶單模塊包括搶單單元、審核單元、增補單元；所述審核請求單元向系統發送請求審核請求，系統向所述搶單單元發送該電子處方的待審核信息，執業藥師通過所述搶單單元對該電子處方進行搶單動作，搶單成功的執業藥師進入審核單元對該電子處方進行審核，並將審核結構發送給所述審核結果判斷模塊。

優選的，前至少3名搶單的執業藥師對該電子帳單有審核權；至少3名執業藥師審核結束後向所述審核結果判斷模塊提交結果；各執業藥師的審核內容均顯示在電子處方內；所述審核結果判斷模塊根據結果進行判斷，如通過，則將電子處方發送給患者用戶端的電子處方顯示模塊；如出現異常，則將向醫生和相應執業藥師發送自檢提醒，醫生和執業藥師分別對該電子處方以及審核結果進行檢查，如電子處方有錯誤，醫生修改後再次提交審核請求，如審核結果有錯誤，執業藥師修改後再提交；再次提交的電子處方將增補一位執業藥師進入審核；以此循環，直至審核通過；增補的執業藥師的執業年限在5年以上。

優選的，所述伺服器還存儲有與各級別醫生、執業藥師相對應的收費標準。

優選的，所述醫生用戶端還包括診療收費模塊；所述患者用戶端還包括付費模塊；醫生對當次診療通過診療收費模塊向所述伺服器發起收費請求；所述伺服器根據該醫生註冊時所登記的職稱級別匹配當前費用並發送給所述付費模塊；患者確認付費，即付費成功。

優選的，所述執業藥師用戶端包括審核收費模塊；當執業藥師審核無異常，則通過審核收費模塊向伺服器發送收費請求，伺服器根據該執業藥師註冊時所登記的職稱級別匹配當前費用並發送給所述付費模塊，患者確認付費，即付費成功；當執業藥師審核出現異常，則無法通過所述審核收費模塊向系統發送收費請求。

優選的，的所述患者用戶端還包括藥店導航模塊；所述藥店導航模塊向電子處方顯示模塊獲取藥品名稱，並向患者顯示最近哪些藥店有該藥品，患者根據導航顯示結果就近購藥。

本發明與現有技術相比，具有以下有益效果：

通過患者病例建立模塊，醫生將該患者從開始就診到最後的有效數據均匯總到與該患者對應的病例表中，並存入伺服器，方便形成對比，而且可以做到多學科之間橫向對比，對於一些生存期短或是少見的疾病可以在短期內收集到一個樣本較大的數據供臨床醫生參考，便於給患者提供最佳方案或指明最佳治療地點，從而避免一些位於邊遠地區患者的病情治療延誤，同時也節省了醫院針對某項疾病治療手段相關科研投入。

將藥店、執業藥師、醫生、患者四者通過網際網路連通，在線處方模塊、電子處方審核搶單模塊、二維碼識別模塊的協作下，即實現了電子處方的開具和審核及患者購藥方便，又能高效利用空閒人員的專業知識，通過適當的收費機制，大大提高了醫生和執業藥師的工作積極性，為患者帶來很大的便利。

附圖說明

圖1為本發明的結構框圖。

具體實施方式

為使對本發明的結構特徵及所達成的功效有更進一步的了解與認識，用以較佳的實施例及附圖配合詳細的說明，說明如下：

如圖1所示，一種在線醫療系統，包括伺服器、在線複診交流平臺、患者用戶端、醫生用戶端、執業藥師用戶端、藥店用戶端。伺服器、在線複診交流平臺、患者用戶端、醫生用戶端、執業藥師用戶端、藥店用戶端之間通過網絡互相通信。

伺服器內包括第一存儲模塊、第二存儲模塊、第三存儲模塊、第四存儲模塊；第一存儲模塊內存儲有各科室病歷表；第二存儲模塊用於存儲與患者一一對應的病歷表；第三存儲模塊存儲各級別職稱的醫生和執業藥師的費用標準；第四存儲模塊內存儲了各種藥品的明顯。

其中各科病歷表根據各科病情情況，事先在病歷表內錄入針對某種疾病的各種信息，如表1(表1中的關鍵詞不局限於此)：

表1

患者、醫生均實名註冊，通過各自用戶端登錄，醫生和患者互相確認後可建立好友關係並可進入在線複診交流平臺（類似於微信交流平臺）；執業藥師、藥店均通過各自埠進行註冊登錄。

患者用戶端包括電子處方顯示模塊、付費模塊。

醫生客戶端包括患者病例建立模塊、在線處方模塊、數據查詢模塊；

執業藥師用戶端包括電子處方審核搶單模塊；審核結果判斷模塊；

藥店用戶端包括二維碼識別模塊、銷售記錄模塊、患者回執模塊；

患者病例建立模塊用於調取第一存儲模塊中相應科室的病歷表，醫生在病歷表中填入該患者的病歷信息，並與患者匹配形成一一對應關係；

醫生根據與患者在交流對話框內的交流內容，在該患者的病歷表中相應位置填入，並保存至第二存儲模塊中；

數據查詢模塊用於查詢第二存儲模塊中各種病歷表；

在線處方模塊用於醫生對該患者開具藥方並生成電子處方，生成該電子處方的同時生成與該電子處方一一對應的二維碼。具體為：伺服器中預存所有藥品明細；在線處方模塊包括電子處方單元、電子處方生成單元、審核請求單元、電子處方審核結果顯示單元；醫生在開電子處方元內獲取伺服器中的藥品名稱，並對該藥品服用注意事項進行標註，提交後電子處方生成單元獲取所選藥品及標註信息，並生成電子處方；該電子處方生成時籤有該醫生的電子籤名；電子處方生成後，審核請求單元獲取該電子處方信息，並將該電子處方發送至電子處方審核搶單模塊。

執業藥師通過電子處方審核搶單模塊進行審核搶單動作。電子處方審核搶單模塊包括搶單單元、審核單元、增補單元；審核請求單元向系統發送請求審核請求，系統向搶單單元發送該電子處方的待審核信息，執業藥師通過搶單單元對該電子處方進行搶單動作，搶單成功的執業藥師進入審核單元對該電子處方進行審核，並將審核結構發送給審核結果判斷模塊。

為了保證審核結果的準確性，本實施例採用至少前3名搶單的執業藥師對該電子帳單有審核權；至少3名執業藥師審核結束後向審核結果判斷模塊提交結果；審核結果判斷模塊根據結果進行判斷，如至少3名職業藥師審核結果均為通過，那審核結果判斷模塊判斷此次審核通過，並將該電子處方發送給患者用戶端的電子處方顯示模塊；如至少3名職業藥師審核的結果中有一個或多個為不通過，即為異常現象，那麼審核結果判斷模塊將向醫生和所有參與審核的執業藥師發送自檢提醒，醫生和執業藥師分別對該電子處方以及審核結果進行檢查，如電子處方有錯誤，醫生修改後再次提交審核請求，如審核結果有錯誤，執業藥師修改後再提交，再次提交的電子處方將增補一位執業藥師進入審核；以此循環，直至審核通過；增補的執業藥師的執業年限在5年以上。

審核結果判斷模塊還審核出現錯誤的執業藥師進行記錄，錯誤次數達到系統設置的上限時，將限制該執業藥師的搶單權限。權限限制的時間預先在系統內設置好。

患者向藥店出示二維碼，藥店通過二維碼識別模塊識別該二維碼，並顯示與該二維碼相對應的電子處方，當電子處方中的全部藥品或部分藥品銷售完成後，對已銷售的藥品進行確認，且銷售記錄記載在銷售記錄模塊中並存入伺服器，同時患者回執模塊獲取銷售記錄，患者回執模塊與印表機連接。所述患者用戶端還包括藥店導航模塊；所述藥店導航模塊向電子處方顯示模塊獲取藥品名稱，並向患者顯示最近哪些藥店有該藥品，患者根據導航顯示結果就近購藥。

醫生用戶端還包括診療收費模塊；患者用戶端還包括付費模塊；醫生對當次診療通過診療收費模塊向伺服器發起收費請求；伺服器根據該醫生註冊時所登記的職稱級別從第三存儲模塊中匹配當前費用並發送給付費模塊；患者確認付費，即付費成功。

同樣，執業藥師用戶端包括審核收費模塊；當執業藥師審核無異常，則通過審核收費模塊向伺服器發送收費請求，伺服器根據該執業藥師註冊時所登記的職稱級別從第三存儲模塊中匹配當前費用並發送給付費模塊，患者確認付費，即付費成功。如果執業藥師審核出現異常，則無法通過所述審核收費模塊向系統發送收費請求

為了拓展醫生對新的手術方案或治療手段的學習途徑，本發明提供的醫生客戶端還包括自助科研模塊。醫生可在自助科研模塊針對某個新型疾病的治療方案發起群聊請求，邀請所有註冊在系統內的醫生，如若看到群聊邀請的醫生對此感興趣，可加入此群。在此群中，可上傳特殊病例，群員可隨意訪問下載和諮詢交流。

該系統還可以包括普通門診在線諮詢平臺。該平臺為患者提供病情諮詢功能，為醫生提供回復搶答功能。患者用戶端、醫生用戶端、執業藥師用戶端均包括申請進入普通門診在線諮詢平臺的申請模塊，醫生、患者、執業藥師分別可通過各自客戶端的申請模塊向系統申請進入普通門診在線諮詢平臺。系統經過核實後允許醫生、患者、執業藥師進入普通門診在線諮詢平臺。在普通門診在線諮詢平臺內，患者可向系統提出諮詢問題，醫生或執業藥師可進行搶單回答。搶答成功的醫生或者執業藥師與患者進入聊天模式，回答結束後，系統根據該醫生或者執業藥師的職稱級別向患者進行收費。普通門診在線諮詢平臺還可以設置患者對諮詢服務的評價功能。

當然，該系統還可以包括在線預約門診功能、資訊共享模塊、論壇模塊。患者可在線預約門診。醫生、患者、執業藥師均可通過各自埠訪問資訊和論壇。系統還可以具有手術直播視頻模塊，該模塊僅有醫生可訪問。

上述所有模塊及模塊之間的通信技術，均可採用現有技術中的程序指令完成。

本發明的設計原理是提供一個比較方便的醫患複診平臺，因就診的雙方都是相互熟知的，一方面方便患者複診諮詢方便，通過手機或電腦即可解決，免去了大老遠趕回治療醫院排隊複診的諸多不便，同時也免去了換一家醫院複診時所需要重複做的一些檢查負擔，電子處方功能使醫生和患者開藥和拿藥都更加便捷。更重要的是對醫生來說，它能讓醫生對所有診療過的患者都留下記錄，讓醫生清楚地認識到對於某種疾病，哪種治療效果是最佳的。既給了患者最佳的治療方案，也讓醫生自己得到快速的提高。所有的醫生採集的數據都可最終匯總查詢，也可形成數據表格，方便形成對比，而且可以做到多學科之間橫向對比，對於一些生存期短或是少見的疾病可以在短期內收集到一個樣本較大的數據供臨床醫生參考，便於給患者提供最佳方案或指明最佳治療地點，從而避免一些位於邊遠地區患者的病情治療延誤。同時也節省了醫院針對某項疾病治療手段相關科研投入。因為使用該平臺費用便宜，研究樣本數據收集簡單，患者諮詢及醫生主動隨訪相結合可讓隨訪無死角且記錄簡單，而且隨著時間的推移，樣本會越來越大，其參考意義更加顯著，甚至某一天可替代多學科診療中心的某些功能，由某一專科醫生通過查詢便可了解最佳治療方案，縮短患者診療方案指定時間，縮短住院日。此外，結合在線處方功能，可以大大節省患者開藥及買藥過程，同時也充分利用了部分空閒醫療資源。如：某位腫瘤患者需要開去止痛藥物，可能在高峰期取某個醫院排隊掛靠或劃價再取藥等可能會很繁瑣，醫院工作人員也增加了很大的工作量，利用這種在線處方功能一方面避免及節省了患者花大量時間經歷買藥時間，另一方面充分利用處於空閒狀態的相關專業人員，同時也減輕醫院不必要的工作負擔，優化了流程。多方有益。

以上顯示和描述了本發明的基本原理、主要特徵和本發明的優點。本行業的技術人員應該了解，本發明不受上述實施例的限制，上述實施例和說明書中描述的只是本發明的原理，在不脫離本發明精神和範圍的前提下本發明還會有各種變化和改進，這些變化和改進都落入要求保護的本發明的範圍內。本發明要求的保護範圍由所附的權利要求書及其等同物界定。