醫(yī)院信息系統(tǒng)不是一個(gè)獨(dú)立運(yùn)行的系統(tǒng)，而是由很多子系統(tǒng)(歸屬不同開(kāi)發(fā)商)集成協(xié)同工作的大系統(tǒng)。子系統(tǒng)之間的數(shù)據(jù)交互，不管是通過(guò)集成平臺(tái)總線(xiàn)還是點(diǎn)對(duì)點(diǎn)對(duì)接，都存在大量接口集成開(kāi)發(fā)工作量，甚至有的子系統(tǒng)全部的字典接口與業(yè)務(wù)接口的總數(shù)量超過(guò)100個(gè)。由于各子系統(tǒng)開(kāi)發(fā)商的技術(shù)水平不平衡，有的子系統(tǒng)開(kāi)發(fā)商經(jīng)驗(yàn)不足、項(xiàng)目交付進(jìn)度緊迫、對(duì)業(yè)務(wù)流程的理解不夠深入、開(kāi)發(fā)技術(shù)路線(xiàn)不能適應(yīng)項(xiàng)目建設(shè)等原因，造成接口開(kāi)發(fā)周期長(zhǎng)、文檔不完整、運(yùn)行穩(wěn)定性欠缺、故障排查時(shí)間長(zhǎng)，是影響醫(yī)院信息子系統(tǒng)交付與運(yùn)維的重要原因之一，筆者經(jīng)歷過(guò)多家開(kāi)發(fā)商的多個(gè)子系統(tǒng)及集成平臺(tái)交付的實(shí)踐，在接口開(kāi)發(fā)過(guò)程管理方面積累了一定的經(jīng)驗(yàn)，現(xiàn)總結(jié)分享如下。
首先要根據(jù)合同的內(nèi)容，確定項(xiàng)目交付的范圍，根據(jù)項(xiàng)目范圍確定項(xiàng)目需要上線(xiàn)哪些業(yè)務(wù)模塊，與客戶(hù)溝通這些業(yè)務(wù)模塊的業(yè)務(wù)流程、規(guī)則，整理成需求調(diào)研文檔，然后針對(duì)客戶(hù)的需求，給出相應(yīng)的解決方案，與客戶(hù)溝通確認(rèn)，形成最終的項(xiàng)目需求文檔。在這個(gè)環(huán)節(jié)，最重要的是要給出解決方案并由客戶(hù)確認(rèn)，讓各方對(duì)需求實(shí)現(xiàn)的方式達(dá)成一致意見(jiàn)。少了這部分的內(nèi)容，項(xiàng)目很難落地交付。概要時(shí)序圖是定義接口調(diào)用觸發(fā)的時(shí)機(jī)(如建檔時(shí)、修改檔案時(shí)、分診時(shí)、接診時(shí)、定時(shí)調(diào)用等)及調(diào)用的接口名稱(chēng)和返回的結(jié)果，概要時(shí)序圖是項(xiàng)目接口全集的總覽，一看就明白項(xiàng)目有哪些接口及各個(gè)接口的作用，概要時(shí)序圖是接口清單內(nèi)容的組成部分，編寫(xiě)完成后，插入到接口清單文檔。詳細(xì)時(shí)序圖是每個(gè)接口調(diào)用的詳細(xì)交互過(guò)程，比如：某子系統(tǒng)產(chǎn)品埋點(diǎn)->中間工程接口->院方接口->醫(yī)保接口-->院方接口-->中間工程接口-->某子系統(tǒng)產(chǎn)品埋點(diǎn)(->是調(diào)用，-->是返回結(jié)果)，詳細(xì)時(shí)序圖是接口明細(xì)內(nèi)容的組成部分，編寫(xiě)完成后，插入到接口明細(xì)文檔。接口清單是以表格的形式提供，內(nèi)容包括接口編號(hào)、接口英文名稱(chēng)、接口中文名稱(chēng)、接口簡(jiǎn)要內(nèi)容描述、埋點(diǎn)名稱(chēng)、調(diào)用時(shí)機(jī)、院方接口英文名稱(chēng)、院方接口中文名稱(chēng)、接口的提供方和調(diào)用方等，是概要交互時(shí)序圖的補(bǔ)充說(shuō)明。接口明細(xì)定義了接口調(diào)用的協(xié)議、URL、入?yún)⒑头祬⒌臄?shù)據(jù)結(jié)構(gòu)，入?yún)⒑头祬⑼ǔＪ荴ML或JSON格式，是樹(shù)型結(jié)構(gòu)，有些結(jié)點(diǎn)會(huì)有多個(gè)，可用子結(jié)點(diǎn)列表來(lái)定義，接口明細(xì)是詳細(xì)時(shí)序圖的補(bǔ)充說(shuō)明，兩者相互相承。接口明細(xì)的字段定義包括了英文名稱(chēng)、中文名稱(chēng)、內(nèi)容描述、字段對(duì)照、轉(zhuǎn)換規(guī)則等內(nèi)容，在很多項(xiàng)目中，字段對(duì)照和轉(zhuǎn)換規(guī)則是不太重視編寫(xiě)的，這部分內(nèi)容的缺失，對(duì)后續(xù)接口開(kāi)發(fā)與維護(hù)、故障排查帶來(lái)困難。1. 理解業(yè)務(wù)流程與數(shù)據(jù)轉(zhuǎn)換規(guī)則接口開(kāi)發(fā)工程師必須理解業(yè)務(wù)流程與數(shù)據(jù)轉(zhuǎn)換規(guī)則才能編寫(xiě)出符合業(yè)務(wù)的接口，比如：處方分方，某子系統(tǒng)是按住院醫(yī)囑的方式下達(dá)的，沒(méi)有門(mén)診處方的概念，不需要考慮處方的分方規(guī)則，分方是由中間工程(接口)根據(jù)HIS的分方規(guī)則自動(dòng)做分方處理的；另一種情況是字典雙向影射，比如：醫(yī)囑頻率字典，有專(zhuān)業(yè)子系統(tǒng)的頻率字典和HIS的頻率字典，專(zhuān)業(yè)子系統(tǒng)頻率字典是穩(wěn)定的，HIS頻率字典是跟項(xiàng)目走的，拉取藥品字典時(shí)，頻率的默認(rèn)值要轉(zhuǎn)換成專(zhuān)業(yè)子系統(tǒng)的頻率，醫(yī)囑提交時(shí)，要將頻率轉(zhuǎn)換成HIS的頻率。每一次接口調(diào)用，都必須記錄4個(gè)日志：1) 產(chǎn)品埋點(diǎn)調(diào)用中間工程入?yún)?/span>2) 中間工程調(diào)用院方接口入?yún)?/span>4) 中間工程給產(chǎn)品埋點(diǎn)返參日志的結(jié)構(gòu)要格式化、標(biāo)準(zhǔn)化，內(nèi)容包括日志時(shí)間、日志級(jí)別、記錄時(shí)機(jī)、日志詳細(xì)內(nèi)容，日志詳細(xì)內(nèi)容可用XML或JSON，格式化與標(biāo)準(zhǔn)化方便日志的查找，加快故障的排查。日志也是出現(xiàn)故障時(shí)，界定責(zé)任的重要依據(jù)，由于接口是雙方或多方交互調(diào)用，很多情況下，各方的日志記錄有的完整有的不完整，由于日志記錄的不完整，造成兩個(gè)或多個(gè)子系統(tǒng)交付實(shí)施人員之間相互推諉扯皮、故障排查時(shí)間長(zhǎng)，甚至造成系統(tǒng)帶病運(yùn)行，長(zhǎng)期運(yùn)行不穩(wěn)定，最終影響項(xiàng)目交付與運(yùn)維，給系統(tǒng)建設(shè)方(醫(yī)院)帶來(lái)?yè)p失，開(kāi)發(fā)商的聲譽(yù)也受到影響。由于日志內(nèi)容比較龐大，一般分為四個(gè)級(jí)別：調(diào)試、信息、警告、錯(cuò)誤，根據(jù)系統(tǒng)配置參數(shù)，控制每個(gè)接口的日志輸出級(jí)別，以免輸出的日志信息過(guò)多或過(guò)少，影響問(wèn)題的排查。對(duì)于日志保留的時(shí)間，應(yīng)根據(jù)日志的輸出量、存儲(chǔ)空間大小、日志的重要程度等方面的要求，綜合考慮日志的保留時(shí)間。過(guò)期的日志要自動(dòng)清除，以免日志信息占用空間過(guò)大，造成系統(tǒng)崩潰或影響系統(tǒng)的性能。
(五) 接口測(cè)試
接口測(cè)試，最重要的是測(cè)試環(huán)境的建立及測(cè)試用例的編寫(xiě)，有的開(kāi)發(fā)商內(nèi)部缺乏測(cè)試環(huán)境，接口難以測(cè)試，而以現(xiàn)場(chǎng)測(cè)試為主，造成測(cè)試效率不高、開(kāi)發(fā)周期長(zhǎng)、運(yùn)行不穩(wěn)定等問(wèn)題。通過(guò)在開(kāi)發(fā)商內(nèi)部建立院方接口仿真環(huán)境，在開(kāi)發(fā)商內(nèi)部即可進(jìn)行接口的正常流程測(cè)試和模擬故障的測(cè)試，接口開(kāi)發(fā)效率、交付質(zhì)量也大大提升。測(cè)試用例編寫(xiě)與接口開(kāi)發(fā)同樣需要理解業(yè)務(wù)流程和數(shù)據(jù)轉(zhuǎn)換規(guī)則，才能編寫(xiě)出高質(zhì)量的測(cè)試用例。筆者在這方面的經(jīng)驗(yàn)，是由需求調(diào)研人員、接口開(kāi)發(fā)人員、測(cè)試人員組成接口開(kāi)發(fā)小組，充分分析討論業(yè)務(wù)流程、業(yè)務(wù)規(guī)則及解決方案。接口涉及承建方(開(kāi)發(fā)商)和建設(shè)方(院方)，完整的日志記錄是故障監(jiān)控與排查關(guān)鍵，日志記錄不完整、格式不標(biāo)準(zhǔn)，將無(wú)法做到接口自動(dòng)監(jiān)控和快速故障排查，有的子系統(tǒng)日志記錄是文件方式，不方便自動(dòng)化監(jiān)控與查找定位，遷移到數(shù)據(jù)庫(kù)，可以利用數(shù)據(jù)庫(kù)強(qiáng)大的查找和統(tǒng)計(jì)功能，做到自動(dòng)化監(jiān)控、預(yù)警、統(tǒng)計(jì)分析等。在產(chǎn)品的生命周期內(nèi)，接口會(huì)有需求調(diào)整、BUG修復(fù)等，需要有一套完整的管理工具來(lái)管理。以往交付人員直接與接口開(kāi)發(fā)人員溝通，文檔及過(guò)程記錄不完整，造成接口開(kāi)發(fā)質(zhì)量不保證、交付時(shí)間不保證等問(wèn)題，通過(guò)建立完善過(guò)程管理制度，交付人員提交完整的需求文檔或bug登記文檔到需求管理系統(tǒng)，需求管理系統(tǒng)指派給相應(yīng)的開(kāi)發(fā)人員及測(cè)試人員，每個(gè)環(huán)節(jié)均有相應(yīng)的文檔及時(shí)間記錄，這樣形成了接口開(kāi)發(fā)維護(hù)過(guò)程的閉環(huán)管理，提高了接口開(kāi)發(fā)的效率和交付的質(zhì)量，也為開(kāi)發(fā)商積累接口開(kāi)發(fā)的經(jīng)驗(yàn)。
綜上所述，通過(guò)上述各個(gè)方面的過(guò)程管理，規(guī)范接口開(kāi)發(fā)過(guò)程，健全接口開(kāi)發(fā)文檔，能夠極大的減少接口開(kāi)發(fā)過(guò)程的返工，真正縮短開(kāi)發(fā)周期，對(duì)開(kāi)發(fā)人員的技術(shù)水平要求也有所降低，綜合開(kāi)發(fā)成本也節(jié)省了不少，醫(yī)院信息系統(tǒng)交互的整體效果得到保證，并且也符合CMMI認(rèn)證的宗旨。
