系統的導入與運用

資訊系統有企劃與採購→導入→營運→評估→下一代更新的生命週期，把營運期間的評估反映到下一代系統的計畫十分重要。它不是導入一次就結束，也不是僅指硬體耐用年數的用語。不反映評估結果的選項也違反生命週期的思維。

RFP（Request for Proposal）是醫療機構提出需求要件與採購條件，請廠商提交提案書的文件。請廠商提供產品與技術資訊的文件是RFI（資訊提供邀請書），用於確定要件之前的階段。僅提示估價或契約後的詳細設計書都不是RFP。

採購時首先明確化採購要件，接著檢討採購實施方式並制定廠商評選基準，再製作與發出RFP，評估提案後選定採購對象並簽約。RFP的發出不可能先於要件的明確化，簽約也不可能排在最前面。重點是在發出RFP之前就先制定好評選基準。

需求規格書是醫療機構方把對系統的需求要件明確化，在採購時傳達給廠商的文件，內容包括基本需求要件、硬體與軟體的技術要件、系統間的介接要件等。交付時的完成報告書、原始碼、故障因應程序書都不是需求規格書。

在發出RFP之前先制定評選基準，就能以相同的尺度公平且客觀地比較提案內容。看過提案之後才制定基準，容易流於恣意的評估。只以金額評選會欠缺功能與維護體制等的評估，只向特定廠商提供資訊則損害公平性，都不適當。

租賃 (リース, lease) 是長期借用由租賃公司購入之設備的型態，原則上不能中途解約。租借 (レンタル, rental) 以短期使用為對象、可以中途解約，這一點與租賃不同。在租賃方式下購買設備並列為資產的是租賃公司而非醫療機構。購買雖成為自院的資產，但無法避免因技術進步而過時的風險。

業務委外是受託方以自己的責任與指揮命令執行業務的契約，作為發包方的醫療機構不能直接對受託方的作業人員下達指揮命令。人力派遣則由派遣目的地的醫療機構對派遣勞工下達指揮命令。指揮命令權的歸屬是區分兩者的本質差異，不是只有名稱不同。

軟體維護的對象是上線後發現的缺陷（bug）修正與程式修正的因應等。伺服器本體的零件更換與修理屬於硬體維護的對象。LAN纜線的鋪設工程與終端機的搬遷是建置與工程作業，不在軟體維護契約的範圍內。

要連接電子病歷與部門系統等多個系統，必須在需求規格書中明確記載介接對象、交換資訊的種類、介接方式（含標準規格的使用），並釐清責任的範圍。上線後再決定、全交給廠商、同一廠商就不需要的做法，會導致介接不良與責任歸屬不明。

醫院資訊系統的導入是依據經營策略之資訊化策略的一環，經營層的參與和對系統導入的共識形成不可或缺，醫療領域的最高資訊長（醫療CIO）擔任策略制定與推動的核心。只由資訊部門決定會欠缺共識形成。導入目的已朝提升醫療品質與合作等多樣化，策略也要反覆評估與檢討修正。

藥品、病名、檢驗項目、使用者等主檔有許多內容取決於採用藥品與作業規則等院內的實情，必須由醫療機構方主動參與整備。不能全交給廠商，若未在上線前整備完成，系統就無法正確運作。主檔在上線後也需要配合藥價修訂等持續管理。

導入階段依序是作業與規格的細部化、開發設定與系統建置、主檔製作、系統測試、資料轉移、使用者教育，在上線前進行營運測試（預演），驗收之後正式上線。驗收或預演排在規格細部化與主檔製作之前的順序是不成立的。

資料轉移時，要決定病人基本資料與診療資料之中轉移哪個範圍，檢討轉移方式後實施，並在轉移後驗證資料是否被正確接續，這一點很重要。為保持診療的連續性，必須在上線前有計畫地進行；省略驗證、或不接續診療資料而銷毀，都是不適當的做法。

驗收是作為發包方的醫療機構確認交付的系統依需求規格正常運作並予以接受的行為，完成驗收即完成交付。廠商內部的單元測試是系統測試的一部分，操作研習是使用者教育，故障的原因分析是營運階段的活動，都不是驗收。

營運測試（預演）是沿著從掛號、診察、檢查到結帳的實際業務流程，如同正式環境般使用系統，在上線前找出營運上的問題。原始碼的確認是開發方的測試，開發工時的估算是採購與契約階段的作業，空調能力的測定是設備的議題，都不是營運測試的目的。

工作小組由醫師、護理師、技師、行政人員等現場代表參加，細部化各部門的作業與規格、協調需求，以推進院內的共識形成。目的不是隱匿契約金額，也不是取代經營層的決策（委員會等），更不是削減人力的手段。

廠商方會以專案經理為中心，組成由設計、開發、導入支援等負責人構成的專案體制，與醫療機構方的體制對應進行協調。不是由1位業務負責人承擔全部工程。體制會透過提案書等向醫療機構展示，為明確協調窗口也必須事先指定負責人。

在電子病歷與部門系統等多家廠商參與的導入中，除了醫療機構內的組織間協調、醫療機構與廠商間的協調，預先建立廠商之間協調用的會議體等機制十分重要。問題發生後才臨時因應、或不共享介接規格的做法會導致介接不良。協調的結果要留下紀錄並共享。

正式上線後不久，操作詢問與缺陷容易集中出現，因此廠商與資訊部門的人員要在現場駐點並立即回應（上線後駐點支援）。不回應故障、上線後立即停用帳號、立刻刪除舊系統資料等做法，會損害診療業務的持續與資料的保全，並不適當。

醫院資訊系統的導入目的不僅是行政效率化與診療報酬申報，還包括提升醫療品質與安全、活用於經營管理、因應區域醫療合作等，日趨多樣化。明確導入目的是製作需求規格與導入後評估的前提；不定目的的導入或僅限特定目的的理解都不適當。

營運規則以三層整備：揭示基本方針的Policy（政策）、將其具體化的營運管理規章即Standard（標準）、規定日常作業步驟的Procedure（實施程序）。Procedure是程序書的層級、Standard是規章的層級，都不是基本方針。Manifesto不是這個三層結構的用語。

營運管理規章要規定管理對象與管理體制、管理者與負責人及使用者的責任義務、伺服器終端機與網路的使用、資料的處理與保管、教育訓練的實施、業務委外相關的安全措施、罰則規定等。個別病人的診斷名一覽是診療紀錄的內容，不是規定營運規則的規章應記載的事項。

使用者管理的基本是讓帳號的登錄與停用和人事資訊連動，離職者的帳號要迅速停用。共用ID會使誰做了操作的紀錄（稽核軌跡）失去意義，放置離職者ID或張貼密碼是不當存取的原因，都不適當。

職務分離（segregation）原則是不把權限與職務集中於1人，而是加以分離，例如登錄與核准由不同的人執行，使相互檢核得以運作，以防止舞弊與錯誤。給全員管理者權限或統一密碼反而違反安全管理。終端機的顏色區分與職務的分離無關。

刪除主檔項目後，參照該項目的過去交易資料（處方紀錄等）將無法正確顯示。因此為保持主檔與交易資料的一致性，應以無效化（停用）而非刪除來處理。改寫名稱會改變過去紀錄的意義，放置不管則會成為錯誤醫囑的原因。

系統故障時要掌握影響範圍、迅速聯絡使用部門，並切換到預先訂定的紙本作業等替代作業以持續診療；復原後將替代作業期間的紀錄補登。中止全部診療會損害醫療的連續性，不聯絡而只做復原作業會讓現場無法判斷狀況、招致混亂。

IT-BCP作為醫療機構事業持續管理的一環，是在災害或故障時也能持續並及早恢復重要業務的計畫；災難復原（disaster recovery）指受災資訊系統的復原與還原。計畫不只要制定，平時就進行因應災害與故障的演練也很重要；它不是採購程序，也不是廣告宣傳的議題。

營運階段代表性的系統改修是因應診療報酬修訂。每次修訂都需要改修醫事會計系統與醫囑輸入系統的主檔及計算邏輯。為醫療安全所做的改修也是代表例。標誌、餐廳菜單、停車場費用都稱不上醫院資訊系統的代表性改修。

持續改善從測量對象的定義與可測量性的確認開始，經資料蒐集、資料處理與分析、資訊的彙整與活用，連結到矯正活動。矯正活動不會排在最前面，不分析蒐集的資料就得不到改善的依據。以維持現狀為優先的態度違反持續改善的思維。

資訊化的副作用包括隔著畫面互動增加造成的部分溝通減少、工作流程改變造成的混亂、故障時作業的混亂、範本化造成診療的不當定型化等。電子化反而提升可判讀性、減少手寫文件。用電量的減半與副作用的討論無關。