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