本發(fā)明設計醫(yī)療技術領域，具體來說是一種在線醫(yī)療系統(tǒng)。

背景技術：

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

此外，大部分患者可能是很遠的外地來某一大醫(yī)院進行治療，可能經(jīng)過手術或其他治療后，余下的檢查就在當?shù)剡M行了，醫(yī)生就更加不易獲知其治療的效果了。

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

技術實現(xiàn)要素：

本發(fā)明的目的是為了解決現(xiàn)有技術中對于隨訪機制的欠缺，導致對各種病例數(shù)據(jù)缺失的缺陷，提供一種在線醫(yī)療系統(tǒng)來解決上述問題。

為了實現(xiàn)上述目的，本發(fā)明的技術方案如下：

一種在線醫(yī)療系統(tǒng)，包括服務器、在線復診交流平臺、患者用戶端、醫(yī)生用戶端、執(zhí)業(yè)藥師用戶端、藥店用戶端；所述服務器、在線復診交流平臺、患者用戶端、醫(yī)生用戶端、執(zhí)業(yè)藥師用戶端、藥店用戶端之間通過網(wǎng)絡互相通信；

所述服務器內(nèi)包括第一存儲模塊和第二存儲模塊；所述第一存儲模塊內(nèi)存儲有各科室病歷表，第二存儲模塊用于存儲與患者一一對應的病歷表；

患者、醫(yī)生均實名注冊，通過各自用戶端登錄并經(jīng)過身份確認后醫(yī)生和患者建立對應關系進入所述在線復診交流平臺；

執(zhí)業(yè)藥師、藥店均通過各自端口進行注冊登錄；

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

所述醫(yī)生客戶端包括患者病例建立模塊、在線處方模塊、數(shù)據(jù)查詢模塊；

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

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

所述患者病例建立模塊用于調(diào)取所述第一存儲模塊中相應科室的病歷表，醫(yī)生在病歷表中填入該患者的病歷信息，并與患者匹配形成一一對應關系；

醫(yī)生根據(jù)與患者在所述交流對話框內(nèi)的交流內(nèi)容，在該患者的病歷表中相應位置填入，并保存至所述第二存儲模塊中；

所述數(shù)據(jù)查詢模塊用于查詢第二存儲模塊中各種病歷表；

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

執(zhí)業(yè)藥師通過電子處方審核搶單模塊進行審核搶單動作；前多名搶單成功的執(zhí)業(yè)藥師對該電子處方進行審核，審核通過后的電子處方發(fā)送到電子處方顯示模塊；

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

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

優(yōu)選的，所述服務器中預存所有藥品明細；所述在線處方模塊包括電子處方單元、電子處方生成單元、審核請求單元、電子處方審核結果顯示單元；醫(yī)生在所述開電子處方元內(nèi)獲取服務器中的藥品名稱，并對該藥品服用注意事項進行標注，提交后所述電子處方生成單元獲取所選藥品及標注信息，并生成電子處方；該電子處方生成時簽有該醫(yī)生的電子簽名；電子處方生成后，所述審核請求單元獲取該電子處方信息。

優(yōu)選的，所述電子處方審核搶單模塊包括搶單單元、審核單元、增補單元；所述審核請求單元向系統(tǒng)發(fā)送請求審核請求，系統(tǒng)向所述搶單單元發(fā)送該電子處方的待審核信息，執(zhí)業(yè)藥師通過所述搶單單元對該電子處方進行搶單動作，搶單成功的執(zhí)業(yè)藥師進入審核單元對該電子處方進行審核，并將審核結構發(fā)送給所述審核結果判斷模塊。

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

優(yōu)選的，所述服務器還存儲有與各級別醫(yī)生、執(zhí)業(yè)藥師相對應的收費標準。

優(yōu)選的，所述醫(yī)生用戶端還包括診療收費模塊；所述患者用戶端還包括付費模塊；醫(yī)生對當次診療通過診療收費模塊向所述服務器發(fā)起收費請求；所述服務器根據(jù)該醫(yī)生注冊時所登記的職稱級別匹配當前費用并發(fā)送給所述付費模塊；患者確認付費，即付費成功。

優(yōu)選的，所述執(zhí)業(yè)藥師用戶端包括審核收費模塊；當執(zhí)業(yè)藥師審核無異常，則通過審核收費模塊向服務器發(fā)送收費請求，服務器根據(jù)該執(zhí)業(yè)藥師注冊時所登記的職稱級別匹配當前費用并發(fā)送給所述付費模塊，患者確認付費，即付費成功；當執(zhí)業(yè)藥師審核出現(xiàn)異常，則無法通過所述審核收費模塊向系統(tǒng)發(fā)送收費請求。

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

本發(fā)明與現(xiàn)有技術相比，具有以下有益效果：

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

將藥店、執(zhí)業(yè)藥師、醫(yī)生、患者四者通過互聯(lián)網(wǎng)連通，在線處方模塊、電子處方審核搶單模塊、二維碼識別模塊的協(xié)作下，即實現(xiàn)了電子處方的開具和審核及患者購藥方便，又能高效利用空閑人員的專業(yè)知識，通過適當?shù)氖召M機制，大大提高了醫(yī)生和執(zhí)業(yè)藥師的工作積極性，為患者帶來很大的便利。

附圖說明

圖1為本發(fā)明的結構框圖。

具體實施方式

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

如圖1所示，一種在線醫(yī)療系統(tǒng)，包括服務器、在線復診交流平臺、患者用戶端、醫(yī)生用戶端、執(zhí)業(yè)藥師用戶端、藥店用戶端。服務器、在線復診交流平臺、患者用戶端、醫(yī)生用戶端、執(zhí)業(yè)藥師用戶端、藥店用戶端之間通過網(wǎng)絡互相通信。

服務器內(nèi)包括第一存儲模塊、第二存儲模塊、第三存儲模塊、第四存儲模塊；第一存儲模塊內(nèi)存儲有各科室病歷表；第二存儲模塊用于存儲與患者一一對應的病歷表；第三存儲模塊存儲各級別職稱的醫(yī)生和執(zhí)業(yè)藥師的費用標準；第四存儲模塊內(nèi)存儲了各種藥品的明顯。

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

表1

患者、醫(yī)生均實名注冊，通過各自用戶端登錄，醫(yī)生和患者互相確認后可建立好友關系并可進入在線復診交流平臺（類似于微信交流平臺）；執(zhí)業(yè)藥師、藥店均通過各自端口進行注冊登錄。

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

醫(yī)生客戶端包括患者病例建立模塊、在線處方模塊、數(shù)據(jù)查詢模塊；

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

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

患者病例建立模塊用于調(diào)取第一存儲模塊中相應科室的病歷表，醫(yī)生在病歷表中填入該患者的病歷信息，并與患者匹配形成一一對應關系；

醫(yī)生根據(jù)與患者在交流對話框內(nèi)的交流內(nèi)容，在該患者的病歷表中相應位置填入，并保存至第二存儲模塊中；

數(shù)據(jù)查詢模塊用于查詢第二存儲模塊中各種病歷表；

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

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

為了保證審核結果的準確性，本實施例采用至少前3名搶單的執(zhí)業(yè)藥師對該電子賬單有審核權；至少3名執(zhí)業(yè)藥師審核結束后向審核結果判斷模塊提交結果；審核結果判斷模塊根據(jù)結果進行判斷，如至少3名職業(yè)藥師審核結果均為通過，那審核結果判斷模塊判斷此次審核通過，并將該電子處方發(fā)送給患者用戶端的電子處方顯示模塊；如至少3名職業(yè)藥師審核的結果中有一個或多個為不通過，即為異?，F(xiàn)象，那么審核結果判斷模塊將向醫(yī)生和所有參與審核的執(zhí)業(yè)藥師發(fā)送自檢提醒，醫(yī)生和執(zhí)業(yè)藥師分別對該電子處方以及審核結果進行檢查，如電子處方有錯誤，醫(yī)生修改后再次提交審核請求，如審核結果有錯誤，執(zhí)業(yè)藥師修改后再提交，再次提交的電子處方將增補一位執(zhí)業(yè)藥師進入審核；以此循環(huán)，直至審核通過；增補的執(zhí)業(yè)藥師的執(zhí)業(yè)年限在5年以上。

審核結果判斷模塊還審核出現(xiàn)錯誤的執(zhí)業(yè)藥師進行記錄，錯誤次數(shù)達到系統(tǒng)設置的上限時，將限制該執(zhí)業(yè)藥師的搶單權限。權限限制的時間預先在系統(tǒng)內(nèi)設置好。

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

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

同樣，執(zhí)業(yè)藥師用戶端包括審核收費模塊；當執(zhí)業(yè)藥師審核無異常，則通過審核收費模塊向服務器發(fā)送收費請求，服務器根據(jù)該執(zhí)業(yè)藥師注冊時所登記的職稱級別從第三存儲模塊中匹配當前費用并發(fā)送給付費模塊，患者確認付費，即付費成功。如果執(zhí)業(yè)藥師審核出現(xiàn)異常，則無法通過所述審核收費模塊向系統(tǒng)發(fā)送收費請求

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

該系統(tǒng)還可以包括普通門診在線咨詢平臺。該平臺為患者提供病情咨詢功能，為醫(yī)生提供回復搶答功能?；颊哂脩舳?、醫(yī)生用戶端、執(zhí)業(yè)藥師用戶端均包括申請進入普通門診在線咨詢平臺的申請模塊，醫(yī)生、患者、執(zhí)業(yè)藥師分別可通過各自客戶端的申請模塊向系統(tǒng)申請進入普通門診在線咨詢平臺。系統(tǒng)經(jīng)過核實后允許醫(yī)生、患者、執(zhí)業(yè)藥師進入普通門診在線咨詢平臺。在普通門診在線咨詢平臺內(nèi)，患者可向系統(tǒng)提出咨詢問題，醫(yī)生或執(zhí)業(yè)藥師可進行搶單回答。搶答成功的醫(yī)生或者執(zhí)業(yè)藥師與患者進入聊天模式，回答結束后，系統(tǒng)根據(jù)該醫(yī)生或者執(zhí)業(yè)藥師的職稱級別向患者進行收費。普通門診在線咨詢平臺還可以設置患者對咨詢服務的評價功能。

當然，該系統(tǒng)還可以包括在線預約門診功能、資訊共享模塊、論壇模塊?；颊呖稍诰€預約門診。醫(yī)生、患者、執(zhí)業(yè)藥師均可通過各自端口訪問資訊和論壇。系統(tǒng)還可以具有手術直播視頻模塊，該模塊僅有醫(yī)生可訪問。

上述所有模塊及模塊之間的通信技術，均可采用現(xiàn)有技術中的程序指令完成。

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

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