周昊林，王 梅

(東華大學計算機科學與技術學院，上海 201620)

0 引言

隨著社會經(jīng)濟的發(fā)展，在生活水平與質量不斷提高的同時，人們也越來越關注自身的健康，并且希望能夠獲得便捷且高質量的醫(yī)療服務[1]。伴隨著移動醫(yī)療技術的快速發(fā)展，一定程度上也促進了社會醫(yī)療體系的進步[2]，同時移動設備的便攜性也成為了移動醫(yī)療推廣和發(fā)展的重要抓手，患者通過移動設備能夠快速的完成掛號、智能導診等需求，使得就診效率大幅度提升[3]。

從患者的角度而言，雖然醫(yī)師會給予患者如何用藥的醫(yī)囑，然而由于患者依從性較低所導致治療失敗或者療效不盡人意的情況仍然時有發(fā)生?；颊哂盟幍牟灰缽男灾饕憩F(xiàn)為：用藥時間錯誤、漏服、過早停藥、服藥劑量錯誤、隨意換藥等。產生不依從性的首要原因就是在患者自主用藥的過程中沒有得到及時的提示或指導。而相對于醫(yī)生以及研究者而言，聯(lián)合用藥分析對于保證醫(yī)療質量有著重要意義[4]。然而，患者的實際用藥信息對于醫(yī)院來說很難跟蹤獲取。在醫(yī)院一方開完處方藥之后，病人在回去之后堅持服用多久、服用時間是否合理、如何去吃、是否同時服用別的途徑獲取的別的藥物，上述信息對于醫(yī)院都難以準確獲得，從而為聯(lián)合用藥分析帶來難度。而若能夠將移動醫(yī)療的便攜性和以上問題結合，則既能夠協(xié)助患者規(guī)范用藥，提高患者的用藥依從性；又能夠對用藥信息進行采集，為醫(yī)生和研究者打下用藥分析的基礎。

針對上述問題，本文提出并實現(xiàn)了集用藥信息采集、規(guī)范患者用藥于一體的原型 App，包括對于患者處方信息的錄入、用藥提醒、用藥信息的采集與上傳等功能，并且在用藥提醒功能中，為了解決沖突藥品之間的安全服用時間規(guī)劃問題，本文提出了一種基于貪心和分治思想的安全時間段規(guī)劃算法。從而實現(xiàn)了以規(guī)范和監(jiān)督的方式提高患者的用藥依從性，同時為聯(lián)合用藥分析提供了有效的數(shù)據(jù)采集渠道。

1 相關工作

近年來，AI診療模型結合智慧醫(yī)療、移動醫(yī)療的應用形式日漸多樣化，例如針對臨床決策支持的輔助診療系統(tǒng)、針對臨床診療數(shù)據(jù)分析的醫(yī)療服務平臺等。Stoner等人[5]對76名參與者進行隨機對照實驗，評估移動醫(yī)療應用程序的干預對于酒精濫用者的納曲酮藥物依從性的影響，發(fā)現(xiàn)移動醫(yī)療能夠一定程度上提高患者的藥物依從性。張世宇等人[6]在 Android平臺開發(fā)的輔助診療系統(tǒng)則主要通過藥品相關信息查詢結合醫(yī)院信息管理系統(tǒng)的掛號、電子病歷閱讀、查看檢驗報告等功能實現(xiàn)了移動平臺和醫(yī)院信息管理系統(tǒng)的結合?，F(xiàn)有工作主要關注于輔助決策或是診療相關服務，而對于患者用藥的監(jiān)督與規(guī)范的相關工作較少。

移動醫(yī)療，指通過移動便攜設備為診療提供服務與支持，實現(xiàn)的主要形式為基于Android、IOS等系統(tǒng)的手機應用APP，是傳統(tǒng)醫(yī)療技術的補充與延伸[7]。在系統(tǒng)實現(xiàn)上，本文基于 Android采用 MVP架構模式[8]進行開發(fā)，設計并實現(xiàn)原型APP，從而實現(xiàn)對患者的用藥信息采集以及規(guī)范監(jiān)督用藥。

2 App系統(tǒng)框架

系統(tǒng)總體框架圖如圖 1所示。系統(tǒng)采用 C/S模式進行通信，服務器端保存知識圖譜，并維護服務器數(shù)據(jù)庫。客戶端包括處方錄入模塊、用藥提醒模塊以及信息管理模塊。同時，在客戶端維護本地SQLite數(shù)據(jù)庫，保存當前患者的處方及藥品信息等。

圖1 系統(tǒng)框架圖Fig.1 Sy stem framework diagram

為滿足用藥信息采集、規(guī)范患者用藥的目標，App客戶端通過處方單拍照或是手動輸入的形式添加處方，處方錄入模塊借助OCR對處方圖片的內容進行識別，通過對識別結果中帶有相對位置信息的文字進行解析，篩選出處方中包含的藥品信息，并對藥品信息進行保存。用藥提醒模塊包括用藥成分分析和安全時間段規(guī)劃兩部分。用藥成分分析，通過調用知識圖譜，發(fā)現(xiàn)已錄入藥品成分之間的藥物過量或相互作用關系，對上述問題進行自動檢測并提醒。根據(jù)提醒并確認后的藥物信息更新待規(guī)劃藥品集。安全時間段規(guī)劃，根據(jù)待規(guī)劃藥品集中各藥物的服用約束條件，建立規(guī)劃算法，對所有用藥時間段進行規(guī)劃，得到可行的安全用藥時間段，并設置用藥提醒。同時，系統(tǒng)設計了用藥反饋功能，采集用戶在安全時間段內是否用藥的信息。信息管理模塊提供信息上傳服務器功能。服務端，主要提供知識圖譜的存儲以及用于保存用藥反饋信息的數(shù)據(jù)庫，便于后期進行聯(lián)合用藥分析，并提供外部訪問數(shù)據(jù)接口。

2.1 知識圖譜模塊

本文知識圖譜主要用于分析藥品成分及建立服藥約束，接下來將對圖譜的構建流程進行介紹。

本文選擇基于藥品的說明書對所需信息進行抽取以構建圖譜。考慮到網(wǎng)站的爬取難度、藥品種類是否齊全以及網(wǎng)站布局的復雜性等等，本文選擇對“藥智網(wǎng)”的藥品說明書數(shù)據(jù)庫、藥物相互作用數(shù)據(jù)庫進行爬取。對爬取的結果以表格標簽的形式使用Xpath進行遍歷，可得到結構化數(shù)據(jù)并保存于關系型數(shù)據(jù)庫中，共包含27380條藥品說明書數(shù)據(jù)、3984條相互作用數(shù)據(jù)。

進一步使用漢語言處理工具HanLP結合正則表達式來對其中的藥品名、藥品成分、適應癥，相互作用關系進行實體抽取以及關系抽取[9]。實體包括：藥品、疾病、成分，這些實體即為知識圖譜中的結點。關系則包括：適用于、包含、有相互作用，這些關系則作為圖譜中的邊，從而連接各個實體結點。用于藥品實體結點的描述信息的屬性包括：用法用量、注意事項、禁忌、不良反應、孕婦及老年人用藥。

由于來自不同廠家生產的同一種藥品可能采取不同命名，如：“康多寧米氮平片”、“米氮平片”，導致數(shù)據(jù)庫中的藥品實體存在冗余，因此本文通過遍歷同一個疾病適用的所有藥品，判斷兩兩藥品實體的藥品名字符串是否為二者其一的子集來確定是否是同一種藥品，根據(jù)經(jīng)過篩選后的藥品建立最終的藥品實體。圖譜的結構示意圖如圖 2所示。

圖2 知識圖譜結構圖Fig.2 Knowledge graph structure diagram

2.2 處方錄入模塊

用戶可以選擇直接對處方進行拍照或者是從相冊選擇處方照片進行識別，或是選擇手動填表的方式完成表單中藥品的添加。文中使用的OCR識別技術來自于百度提供的 OCR通用票據(jù)識別Api。通過對返回的 json數(shù)據(jù)進行解析，能夠獲得圖片中所有文字信息的文本內容，內容所占的大小，以及內容在整張圖片的相對坐標位置。然而，由于實際拍取的處方照片可能存在照片方向與文字內容不能保證水平的問題，由按行生成的絕對位置坐標關聯(lián)表中字段內容實際會導致字段錯位等問題。

為解決上述問題，本文選擇建立相對參照點的方式，分別選取了處方左上和右下對角線處的兩個標志性文字作為參照點，根據(jù)兩個參照點的坐標計算矩形區(qū)域，將識別結果中的所有元素在矩形區(qū)域中的相對坐標進行篩選，從而使得識別范圍僅限定在包含藥品信息的部分，同時關聯(lián)得到的藥品名、服藥信息等字段保證一致性。

2.3 用藥提醒模塊

2.3.1 用藥合理性分析

由于患者可能會通過多種渠道獲取藥品，如從不同醫(yī)院獲取或自購，此時可能會出現(xiàn)不同藥品中含有的相同成分超標或發(fā)生相互作用。為此，在進行服藥規(guī)劃和提醒前，首先要進行用藥合理性審查。主要包括兩部分：會發(fā)生相互作用的藥品、含有相同成分的藥品。通過 Neo4j所支持的Cypher語句查詢此前構建的藥品知識圖譜，能夠快速地查詢到所需要的藥品關系，例如：

（1）查詢兩個藥品 A、B之間是否存在沖突關系：

（2）查詢兩個藥品A、B之間含有的相同成分：

上述查詢方式能夠快速定位到指定的兩個藥品之間是否存在相互作用或是藥物成分過量的情況。因此，依次遍歷新添加的藥品和處方表中已有藥品，并依次對相互作用和過量的查詢結果進行判斷，并生成待規(guī)劃藥品集。沒有相互作用和過量的則無需規(guī)劃。

2.3.2 安全時間段規(guī)劃算法

通常而言，對于給定單一藥品，患者每次服藥在一個時間段內均是合理的。例如，一日兩次與一日三次的藥品常見時間段為：

然而，若這兩種藥物同時服用，且服用的兩種藥之間存在沖突，則其服用時間需滿足間隔至少兩小時的約束條件。此時，按照單一藥品服用的常見時間段進行服用就可能出現(xiàn)問題，很明顯，其服用時間段存在重合，不滿足約束條件。因此，需要對可服用藥品集中的藥品時間根據(jù)約束條件進行規(guī)劃。具體方法如下所示。

首先，定義如下變量：

T：表示時間段，以Ts，Te來表示時間段的起始時間點和結束時間點，則一個時間段T可以表示為：[Ts,Te]；給定患者的待規(guī)劃藥品集合D=｛d1,d2,d3,…,dw｝。藥品集合D對應的時間段集合記作M=｛m1,m2,m3,…,mw｝，mi為第i個藥品常見時間段的集合。mi的大小和藥品的服用方式相關，若第i個藥品為一日三次的藥品，則mi包含3個時間段。令mi={mi1,mi2,mij,…}，其中mij代表第i個藥品的第j個服用時間段，則有mij=[Ts,Te]，也可以表示為mij=[Tijs,Tije]。

對于藥品集合中的多個沖突藥品進行時間段的生成，本文采用歸并調整的方法，先將各藥品默認服藥時間段存入列表 TimePartList中，進而進行遞歸劃分，劃分為每個集合僅包含一個藥品的服用時間段后開始從下而上兩兩調整。

首先進行算法開始前準備。對M集合中每個時間段mij進行封裝。為每個mij添加其與藥品對應的標記、類型標記后建立TimePart結構。其中藥品信息標記用于在經(jīng)過算法調整過后的新時間段能夠對應到藥品信息；臨時類型標記用于標識該時間段與其他時間段是否沖突，生成 TimePart結構。初始化TimePartArray為單個藥品對應的所有TimePart。將所有的TimePartArray存入待歸并列表TimePartList結構變量T_list，調用MergeList算法開始自上而下遞歸調整。Mergelist算法如算法1所示。

算法1：MergeList

Input:TimepartList T_list

Output:TimePartList result_list

TimeResize對沖突的時間段進行具體調整，其算法過程如下所示。

（1）將輸入的兩個 TimePartArray中的所有TimePart變量置入同一個臨時Array；

（2）對臨時Array中的所有TimePart元素進行排序，排序的規(guī)則是優(yōu)先判斷TimePart起始時間的先后，若起始時間相同再判斷結束時間的先后，最終得到一個有序的臨時Array，此時這個臨時集合中包含，兩種不同的臨時標記 Temp的時間段；

（3）對臨時 Array從前向后進行遍歷，步長為1，循環(huán)過程中依次對Array中位置相鄰的左右兩個 TimePart的 Temp標記進行判斷，若 Temp相同，則不進行進一步操作，跳過；若 Temp相同，則對這兩個TimePart進行調整，通過縮短沖突藥品服藥的可行時間段，使兩個時間段之間的間隙達到約束條件，即 Tijs與Ti-1js的時間相差 2小時；具體調整時，若沖突時間段有重合，則分別縮短；若無重合，則優(yōu)先縮短較長的時間段；

（4）最終臨時Array經(jīng)過一遍循環(huán)后，Array中的所有 TimePart均被調整為不會沖突的時間段，并在TimeResize過程結束后將Temp標記統(tǒng)一為相同值。

其中TimeResize的具體算法如算法2所示。

算法2：TimeResize

輸入：TimePartArray A，TimePartArray B

輸出：TimePartArray T

2.3.3 用藥提醒

在安全時間段規(guī)劃算法得到各藥品的安全時間段后，首先對各藥品所對應的時間段進行持久化存儲，再進一步通過AlarmManager服務設定廣播時間點，通過指定時間的廣播來喚醒指定的提醒頁面，同時每一次更新服用提醒時間都保證在其對應的安全時間段內，從而完成自動設置提醒；而每次提醒時提供給用戶兩個選項：完成用藥和推遲10分鐘提醒，同時在當前時間未到達設定時間段或是當前時間不足以在設定時間段內推遲10分鐘時，均會將對應選項變灰且不可選中，并給與相應的警告提示。

用藥反饋的記錄即為通過判斷用戶每次用藥的完成時間點是否仍然處于設定的安全時間段內，若處于則記錄為一次安全用藥，反之則記作一次不安全用藥，并保存至用藥反饋表中，當療程結束后，就能夠得到所使用藥品的用藥反饋時間序列數(shù)據(jù)，以用于研究人員的用藥分析。

2.4 信息管理模塊

信息管理模塊主要提供用戶上傳、刪除所記錄的用戶用藥信息的功能。App通過對服務端的指定接口進行網(wǎng)絡請求，將用戶的藥品信息數(shù)據(jù)、用藥反饋數(shù)據(jù)組織為json類型的數(shù)據(jù)，并以網(wǎng)絡請求的方式傳遞數(shù)據(jù)來實現(xiàn)上傳、刪除功能。

3 實現(xiàn)與驗證

3.1 技術架構

本文的原型App為基于Android7.0編寫的原生Android應用，采用MVP架構進行開發(fā)，涉及的主要組件和相關技術包括 Retrofit2[10]、ButterKnife、LitePal、以及百度OCR識別Api等。下圖為本文原型 App的總體架構設計圖，其中MVP架構即為如下View、Model、Presenter的分層結構。

View層的內容即為用戶可見的界面，包括處方管理、用藥提醒、信息管理模塊的各個頁面的Activity，當用戶在這些界面中進行添加處方、查看提醒等操作時，會通過其對應的Presenter實例執(zhí)行相應的業(yè)務邏輯，由 Presenter層作為 View層和Model層溝通的中介，承載應用的業(yè)務邏輯；View層的更新也通過 Presenter來通知，Model層只負責和數(shù)據(jù)獲取相關的邏輯。除此之外，對于服務端數(shù)據(jù)的操作與訪問，也由Presenter層對應的對象來負責向服務端傳輸、請求數(shù)據(jù)；而服務端返回的數(shù)據(jù)則交由Model層進行處理。

圖3 系統(tǒng)總體架構設計Fig.3 Overall system architecture design

3.2 模型驗證

假設給定的藥品均為相互沖突的藥品，表 1總結了實驗中出現(xiàn)的所有藥品類型，它們包含的服用方式以及常見的服用時段如表2所示。

表1 一日兩次與一日三次藥品的常見用藥時間段Tab.1 Common dosing periods for twice-daily versus thrice-daily medicines

表2 藥品服用方式與其默認常見時間段Tab.2 Medication administration methods and default time periods

對于實驗場景的設置，本文將以數(shù)字組合指代所設計場景中給出的藥品服用方式，即以數(shù)字1、2、3代表三種服用方式，同時數(shù)字的排列方式為升序，例如場景[223]表示待規(guī)劃的藥品包括{一日兩次、一日兩次、一日三次}。

由于實際臨床診療中的同一位患者在安排用藥時的沖突藥品不會過多，因此在實驗中本文僅對同時包含四種沖突藥品以內的場景進行規(guī)劃，則在將四種藥品經(jīng)過排列組合并且去重后分別得到所有的場景，并分為三類場景，如表3所示。

表3 所有無重復的用藥場景Tab.3 All unduplicated medication scenarios

在排除掉不可能保證兩小時間隔的條件的場景以及過于簡單后，本文在表中每一類場景均選出2個在復雜性和實用性上均較為典型的場景進行展示與分析。

3.3 實驗結果分析

將 6個用藥場景使用本文的規(guī)劃算法獲取安全時間段，6個場景的規(guī)劃前以及規(guī)劃后時間段如圖4所示。

圖4 六種實驗設置的初始時間段與結果Fig.4 Initial time periods and results for the six experimental setups

在測試中，本文從運行時間以及占用內存對算法進行評估，其中對同一個場景進行多次實驗并將統(tǒng)計結果取平均值，得到的統(tǒng)計結果如表4所示。

表4 實驗運行時間以及內存消耗的統(tǒng)計Tab.4 Experimental runtime and memory consumption statistics

從測試結果中可以看出，以上場景的實驗中算法的運行時間均在22 ms～26 ms之間，并且內存消耗也僅在67 mb～70 mb之間波動，能夠取得較快的運行速度以及較低的資源消耗。上述實驗結果表明，本文提出的算法結合移動平臺App能夠對患者的用藥規(guī)范提供監(jiān)督作用，具有一定的實用意義。

4 結論

本文提出并實現(xiàn)了集用藥信息采集、規(guī)范患者用藥于一體的原型 App，包括對于患者處方信息的錄入、用藥提醒、用藥信息的采集與上傳等功能，并在用藥提醒功能中，為了解決沖突藥品之間的安全服用時間規(guī)劃問題，提出了一種基于貪心和分治思想的安全時間段規(guī)劃算法。從而以規(guī)范和監(jiān)督的方式提高了患者的用藥依從性，為臨床治療效果提供保障；同時為聯(lián)合用藥分析提供了有效的數(shù)據(jù)采集渠道。目前，本文提出的原型系統(tǒng)與算法仍尚有不足，如系統(tǒng)尚未對用藥采集后續(xù)的聯(lián)合用藥分析提供相關功能，安全時間段規(guī)劃算法的效率和流程還存在改進的空間。接下來的研究中，將會關注聯(lián)合用藥的分析和安全時間段規(guī)劃的改進，并進一步優(yōu)化系統(tǒng)的功能與性能。