發布日期：2017-10-18

臨床科研要出成果、上檔次、高品質，離不開臨床數據的支持。

臨床科研數據庫區別于“醫囑系統”“電子病歷系統”等業務管理軟件的地方就是要把臨床資料從【入、找、看、出】四個方面靈活應用。病例收集的總量越多、信息越完整、描述越準確、時間跨度越大、分布范圍越廣、樣本采集密度越高，數據庫的價值就越高。

科研數據庫的建設，按理說應該是醫院管理層和信息科（或網絡中心、計算機中心）等負責的事情。然而，很多醫院都優先重視業務系統的構建，對科研數據庫的建設比較滯后，投入也非常少。主要原因是科研數據庫的建設產出不及時，不能立竿見影的出政績。即便是出了成果，一般也是歸屬于臨床研究者的，不參與課題研究的管理層很難從中得利。即便是有些醫院建立了科研數據庫系統，也只能基本滿足科室共性的需求，無法滿足臨床科室對自己學科研究的個性化需求。有些專科內部還分多個學組或亞學科，病例收集要求又有更多細致的差異。

既然等待醫院建立科研數據庫遙遙無期，而且醫院建立的科研數據庫不能滿足專科需要，那就只能科室想辦法建立自己需要的數據庫。

因為采購原本是管理層的職責范圍，科研數據庫的采購又可能涉及到多個部門協調。因此臨床科室在構建數據庫系統中會遇到各種各樣的問題：

1、立項審批和預算額度問題（經費問題）

行軍作戰，糧草先行。除非自己研發，否則采購數據庫總是需要費用。

自己研發分為兩種：一種是請醫院信息科的技術人員開發，一種是安排科里懂電腦的研究生研發。自己研發的問題在于不夠專業，而且積極性不高，動力不足，產出也就很呵呵，往往都會無疾而終。

采購數據庫就需要有資金來源。既然是科室行為，醫院很少為此單獨買單。幾乎沒有哪個科室主任愿意花“小金庫”的錢，雖然他們并不承認有“小金庫”。人脈廣泛的科室主任，往往能夠找到醫藥、器械、耗材廠家以及慈善機構等第三方合作公司解決費用問題。然而總是欠對方一個人情，并且不是每個廠家都有長遠眼光和奉獻情懷。

因此，最好的辦法就是立項申報課題，光明正大的解決費用問題。我們國家每年都有大量的科研經費預算，真正想做科研的臨床科室如果都不去爭取，就會便宜了那些投機取巧的人巧立名目把經費預算消耗掉。因此，申請立項既是對國家科研政策的積極響應，更是對科研經費的極大尊敬和最好回報。

雖然很多附屬醫院的優勢學科都有很多課題經費支持，然而他們大部分都側重于課題研究常規所需的小白鼠實驗，試劑、耗材、標本、設備、差旅等費用。沒有意識到數據庫的重要性，很少有在課題立項之初考慮數據庫的建設費用。事后要從經費中開銷數據庫技術服務費，幾乎不可能。

即便是有些研究者在立項申請的當初就考慮了技術服務費，但也會遇到“不懂行”的或者“太懂行”的某級領導對自己的否定或者大幅度削減。有些項目甚至根本就無法提交到審批階段，直接被其他更牛逼的“非上不可”的項目排擠掉。

其實，課題項目是否重要，有時候并不取決于課題本身，而取決于課題利益的分配。審批的人從臨床科室到醫務科，從院長到校長，從醫院到科委、衛生局等可能不止一個級別，那就要求課題利益至少要從長遠方面對他有利。最好是短期利益就與他高度有關，更能促使項目通過。

為此，我們建議在不影響課題的方向的前提下，盡可能的把想要利益相關的管理層納入課題組成員，級別越高越有分量。如果有院士、所長、學科組委委員、院長等頭銜的人可以爭取就不要錯過，本院沒有，其他醫院的也行。他們掛一個頭銜，做研究的還是自己。成果多一個署名沒有壞處，利益出讓的同時，也讓風險得到稀釋和均攤，更主要的是周期可能縮短、費用支持力度得到提高。我們為某地區建立某病種數據庫協作平臺，當時他們的基本預算只有60萬元，而且能否審批通過根本就沒底。后來我們幫忙把方案技術部分完善了一下，把數據建設的軟硬件費用以及協作單位上傳數據的勞務費用（每上傳1個病例支付10元錢勞務費）做到了預算中，費用就達到了100萬。然后把衛生局局長邀請到課題組成員中，結果不僅項目順利通過審批，而且預算提升到了120萬元。

2、數據庫和醫院系統接口問題（接口問題）

醫院的業務系統如電子病歷系統、臨床路徑系統、醫囑系統等一般來說都是信息科（或網絡中心）負責采購、搭建和維護。這是他們的職責，也是他們的權力范圍。因此，如果科室自己建立數據庫，那就避免了信息科的直接參與，減輕了他們的工作負擔和責任風險。然而，科研數據庫要達到海量，要考慮從臨床業務系統中導入自己科室的病例資料，就需要調試HIS接口。該接口首先需要信息科授權，然后還需要他們提供相關技術支持。信息科既沒有責任也沒有義務為臨床科室提供這方面的服務。于是會以網絡安全為由，拒絕提供授權和支持。有的醫院還把內網的電腦U盤口、光盤都卸載或禁用，確保網絡系統安全。

現在的醫院業務系統，很少由一家公司包攬。越來越多的系統（如LIS、PACS、EMRS、NIS等）被不同公司獨立開發，都需要通過接口來實現系統之間的數據交換。需要對接HIS的科研數據庫都在內網使用，并不對外，基本上不存在數據泄密、系統不穩定問題。因此，系統接口是非常常見的事情，信息科的專家都知道技術上不存在問題，只是要不要提供的問題。

臨床資料原本就是臨床醫生日常工作中產生的，本應為自己的研究服務。因為醫院業務系統不能夠支持科研需要，因此建立單獨的科研數據庫來重新整理和靈活利用成為必然。信息科等部門屬于輔助科室，職責是為臨床科室提供軟硬件技術服務。但因為角度不同，信息科不太關注臨床科研，也不可能非常了解臨床科研的細致需求。這種現象普遍存在，聰明的人會主動和信息科的人搞好關系。既要和信息科主任處理好關系，也要和技術員處理好關系。雖然這不是絕對管用的，但關系好總沒壞處。

HIS接口調試主要解決臨床資料導入問題。病案首頁欄目、診斷信息、手術信息、檢驗和檢查信息、醫囑和費用信息等都是海量，靠人工輸入既沒有必要，又勞民傷財，而且還存在錯誤數據的可能。而通過接口導入既可以提高效率，又有質量保證，更符合科研對數據的準確性和海量信息的基本要求。

最好的辦法還是找上級部門支持，爭取得到權威領導支持。好比上述經費審批，如果有重要人物支持，課題項目的發展確實對醫院的整體實力提升有幫助，那么信息科也就會更加支持和配合。“方法總比問題多”就是這個道理。領導非常重視，問題就很快解決；領導一般性重視，問題就慢慢解決；領導不重視，那么問題就得不到解決。這是國情。

3、數據庫的整理和維護問題（投入問題）

除了上述第一點提到的費用問題屬于經濟投入問題，精力的投入也是科研數據庫建設好的一個問題。

采購的數據庫不是買來就有價值，也不是靠HIS接口導入了臨床資料就具有很大價值。而是要靠持續不斷的精力投入、時間投入，才能日積月累，才能豐富起來，才能激活它的價值。“你不理財，財不理你”——科研數據庫也是如此。有許多的臨床資料因為來源限制、格式迥異或者破損丟失，需要靠人工來整理。比如：手術照片資料，業務系統中就不一定存在，靠手術者自己收集；隨訪資料，是病人出院后去做隨訪才能獲得；電子病歷文檔中的某些有價值的要素，也需要人工去整理，輸入專科指標信息中。

因為臨床醫生每天都忙于看病管床業務和與業務“有關”的事情，幾乎沒有太多時間靜下心來整理數據庫。因此，有條件的科室可以招聘或安排單獨的科秘來負責數據庫的使用。沒有單獨人力安排的科室，就只有醫生自己來整理了。對于新走上工作崗位的年輕醫生，精力其實不是問題，而是態度問題。意識到未來掌握數據就掌握話語權的人就會懂得數據庫的重要性。病例的收集不是一蹴而就，而是靠日積月累的。每天整理一點，每天花費的時間就不會太多，而產出就會與日彰顯。

4、多中心研究數據庫構建模式問題（模式問題）

許多學科都有大型課題、重要公關方向，往往需要多中心協作才能更好的完成。多中心研究首先就是數據的支持問題。

如何更好的收集協作單位的病例數據？技術上分為【單機版協作A】和【網絡版協作B】兩種模式。

單機版的協作A：就是為每個單位安裝單機版數據庫系統，對接各自醫院的HIS系統，導入和整理自己的臨床資料，然后通過導入導出，實現病例資料的交換和數據遷移。

網絡版的協作B：就是協作單位在線登記數據和在線上傳臨床資料。又分為客戶端軟件版【B1】和網頁版【B2】兩種模式。客戶端版本就好比QQ軟件，網頁版本好比在線電子郵件系統（126郵箱、QQ郵箱、新浪郵箱等）。

單機版協作【A】和網絡版協作【B】的區別在于：

1、單機版不依賴網絡，可以通過打包后U盤復制，郵件發送。網絡版依賴網絡，但可實現在線實時。

2、單機版可對接HIS導入資料，網絡版不支持對接HIS。

3、單機版可脫機輸入，分次輸入；網頁版需要在線輸入，不便于頻繁切換和分次輸入。

4、單機版適合于深度收集、網絡版適合于精簡收集。

5、單機版數據可異地存儲，本地留存。網絡版數據只存在中心數據庫。

6、遇到升級，單機版需要人工升級，網絡版可后臺升級。

7、單機版可幫助協作單位建立自己科室數據庫，網絡版只能貢獻數據。

8、單機版需要單獨付費，但可以團購。網絡版需要按終端授權，開通賬戶，也可隨時關閉。

9、【網絡版協作B】中的【客戶端軟件模式B1】相比【網頁模式B2】，具備【單機版協作A】的部分功能優勢。而區【B1】別于【A】的地方在于數據收集的深度和廣度。【A】模式因為可以對接到HIS，所以可以更深度和廣度的收集。而【B1】全靠手工輸入，因此收集的內容不宜太深度，越精簡越有效。

如何選擇呢？

需要深度收集病例資料的，選擇單機版A模式。因為協作單位都可以在內網安裝單機版軟件，可以對接HIS導入臨床資料。

需要快速收集（精簡到：人口學資料+專科指標資料），全手工錄入，不對接HIS，而且對協作單位需要控制上傳（超過100例不上傳就提醒，超過500例不上傳就限制登記等）。那么就選用網絡版B1模式。

只需要協作單位貢獻病例數據，不需要考慮協作單位自己存儲的多中心研究平臺，而且不對接HIS、全部依賴在線一次性填寫的，可以采用【網頁版B2模式】。

5、科研數據庫的版本劃分問題（版本問題）

根據研究的方向、階段目標、適用范圍和費用預算不同，可以劃分為：

科室單機版：采用桌面數據庫引擎構建單機應用。可以簡單收集，也可以深度收集臨床資料。可以對接HIS導入資料。

科室局域網版：數據庫安裝在局域網服務器上，工作站電腦聯網使用。可以對接HIS，集中存儲科研病例。服務器可以自己購買專用服務器，也可以采用臺式機做服務器，還可以申請信息科的服務器空間。

科室廣域網版：數據庫安裝在廣域網服務器上。可以租用服務器、云主機、主機托管等。工作站電腦必須上外網，不能連接內網。因此不能對接HIS，只能手工整理。收集內容需要精簡。

單中心協作廣域網版：和科室廣域網版相同部署。患者建立檔案后，可在任何一個協作單位登記就診信息。內容也不能太多，要聚焦到結構化信息。適合于持續跟蹤隨訪為目的的區域在線協作。比如：孕婦產檢、兒童保健、慢性病跟蹤隨訪等。

多中心協作廣域網版：發起單位建立網絡版數據庫，協作單位在外網電腦安裝客戶端軟件，手工登記，內容精簡，聚焦到結構化資料。登記完畢，批量上傳。可通過網頁或客戶端查看。支持客戶端下載自己的數據。適合于以病例收集為目標的單病種數據庫協作。

多中心協作單機版：發起單位建立網絡版或單機版數據庫，協作單位在內網電腦安裝客戶端軟件，可對接HIS導入，也可手工登記、追加補充，內容豐富，支持手術照片、影像資料等。定期導出，通過郵件發送給發起單位做數據遷移匯總。發起單位和協作單位都有自己的獨立數據庫。適合于需要深度收集病例資料的多中心協作。

6、如何保障病例收集的總量和品質（動力問題）

科室數據庫如果安排科秘負責，就需要考慮科秘的動力問題與責任問題。工資獎金是一個方面，引領科秘發表相關文章，出成果也是一個方面。

一般來說，多中心研究協作平臺都由學科優勢單位發起，邀請兄弟單位參加協作。協作單位給發起單位貢獻數據，首先是【看前景、給面子、出熱情】。但光靠面子是不夠的。尤其是答應參加協作的是主任，負責數據錄入的是醫生或者護士。涉及到日積月累，持之以恒的付出，就需要經濟利益來保障。因此在做課題立項經費預算中就要考慮該協作單位的勞務費用。這個勞務費是落實到輸入者身上，才能滿足動力問題。

可以根據研究的周期與病例收集范圍來預估協作單位的勞務費用。比如項目周期3年，按月計算就是36個月。預期每個協作單位每月收集100個病例，第一階段10個協作單位，那么數據總量就是：100例*36個月*10個單位=36000例。按照10元一例安排勞務費，需要36萬元。如果按照20元一例，那么就是72萬元。

7、數據庫軟件供應商選擇問題（選型問題）

既然是采購數據庫，除了費用問題需要考慮，供應商的選擇也是一個重要事情。有人認為大公司可靠。從公司實力來說，當然如此。但科研數據庫的項目除非上百萬上千萬。否則幾萬和十幾萬的項目到了大公司，往往也得不到太重視。任務安排下來，又歸到一兩個技術員來負責。即便是上百萬的大項目，大公司也不太可能安排整個公司來負責交付。既然是公司員工，穩定性值得質疑。員工辭職或中途換人，對項目總是有影響。而且員工以完成任務為主，對新需求的興趣不會太大。

專業很重要。對臨床需求能夠深度理解、積極配合臨床不斷升級研發的才是長久之策。

科研經費來之不易。建議拿成果說話，看成果下單。

來源：醫谷