-- 医療法人土屋小児病院 -- Tsuchiya Children's Hospital -- 獨協医科大学連携病院  日本アレルギー学会認定教育施設 --

土屋小児病院の院内診療支援システム

 

○土屋喬義１）２）　田中千恵子１）　駒田智彦１）　滝口善美１）　木村一元３）

１） 土屋小児病院　２）獨協医科大学小児科　３）獨協医科大学医学情報センター

 

医療法人　土屋小児病院

〒346-0003 埼玉県久喜市中央１－６－７

TEL 0480-21-0766   FAX 0480-21-2230

e-mail 

 

はじめに

　土屋小児病院では医事システムとしてU-MUMPS上で動作する住友電工のアクセルを採用している。　これを中心にMSMとDDP接続し、医事システムよりリアルタイムに得られる情報を活用している。

これまでに手掛けたシステムはMSM社のDos ベースで動作するM（MSM-386）を使用し、マルチチャンネルのシリアルI/Oを使用することにより複数の検査機器を接続した院内検査システムそしてMSMで作成した職員出退勤システムがある。これらはMSMのI/Oハンドリングの良さが助けになったとともにＭという高速なデータベースのおかげで現在でも十分な性能を発揮している。　また住友電工のU-MUMPS上で動作する外来患者名簿作成プログラムを作成している。

その後GUI環境の発展は目覚しく当院でもVB, MSM for Windows NT(Ver4.4.0), MSM－Activateを利用したGUI環境を取り入れたプログラムの製作を行っている。　今回Windows端末よりリアルタイムでの患者数、医師稼働率の表示、薬剤情報の自動発行、入院治療計画書の自動発行、カルテ表書き発行時に病歴、入院歴、予防接種歴などの自動印字を行っているシステムについて述べると共に、現在運用されているシステムとメーカー製のオーダリングシステムの考え方を比較した。

 

システム紹介

 

Mサーバー

 

①　SUN　Ultra5　上で動作する　U-MUMPS　アプリケーションとして住友電工ACCELが動作。

②　Windows NT 上で動作するMSM　for Windows NT（Ver4.4.0）レセプト情報以外の情報を保持MSM　Activate を介し各Windows クライアントにサービスを行う。

③　MS-DOS 上で動作するMSM-PC/PLUS　検査データ収集用のサーバーとして動作。

④　Windows NT 上で動作するMSM　for Windows NT（Ver4.3.2）勤怠処理等院内事務処理用。

 

Windows　クライアント

 

Windows　NT　Workstation、　Windows　98、　など6台を診察室、ナースステーション、外来受付などに配置している。（図１）

 

 

使用したMSMについて

MSMを開発したMSM社は1998年にInterSystems社に買収され、現在InterSystemsによりメンテナンスされ、日本MSM社がMSM for Windows NT、MSM-PC/Plus の販売を行っている。

テキスト ボックス: 図２　MSMのインターフェイス MコマンドウインドウでのCUI（キャラクタ　ユーザ　インターフェース）インターフェイス以外ではではMSM　ActivateによるCOMオブジェクトを介してのウインドウズプログラムとの通信、MSM　PｄｑWeb　によるWeｂサーバーとの通信がサポートされ、GUI（グラフィカル　ユーザ　インターフェイス）の使用が可能である（図２）。　またMSMは住友電工のU-MUMPSのソースベンダでありU-MUMPUSを基に作られている住友電工の医事システムアクセルとの親和性が高く簡単にシステム間の通信が可能である。

 

プログラム技法の比較

CUIによるプログラム開発はBasic　から連続した手続き型のプログラミング手法が使えるため理解がしやすく、初心者でもすぐにプログラムの作成が可能、しかし画面設計に労力の大部分が費やされれ、少しでも凝った画面設計を行うと非常に大変である。

テキスト ボックス: ' 患者の薬剤アレルギーを Input して Form Karte1 に表示する。 '--------------------------------------------------------------------------     Dim i As Integer, buf As String     If IsNull(LID) Then Exit Sub     For i = 1 To 2         DAName(i - 1).Text = "“; DACom(i - 1).Text = ""           mcd = "W $D(^[" & """" & StrPubUci & "," & StrPubVol & """" & "]TMKARTE(" & CStr(LID) & "," & _"""DA""" & "," & CStr(i) & "))"         res = Space(256)         rc = msm_xecute(IntPubSocet, mcd, res, 256)           res = Trim$(res)         If rc = 0 And IsNumeric(res) Then             If CInt(res) = 1 Then                   mcd = "W ^[" & """" & StrPubUci & "," & StrPubVol & """" & "]TMKARTE(" &  CStr(LID) & "," & _"""DA""" & "," & CStr(i) & ")"                 res = Space(256)                 rc = msm_xecute(IntPubSocet, mcd, res, 256)                   res = Trim$(res)                 MCode.Text = mcd                 MRes.Text = res                 If rc = 0 Then                     If Right$(res, 1) = Chr(0) Then                         res = Mid$(res, 1, Len(res) - 1)                     End If                     buf = Piece(res, ";", 2)    '薬剤名                     DAName(i - 1).Text = buf                     buf = Piece(res, ";", 3)    'ｺﾒﾝﾄ                     DACom(i - 1).Text = buf                 End If             End If         End If     Next i                     End Sub     GUIによるプログラム開発は過去にBasicなどのプログラミングを行ってきた者にはイベント駆動型のプログラミングを理解するのに時間がかかる。しかし一度理解すると画面設計の自由度が増しコーディング速度が上がる利点がある。VB（Microsoft Bisual Basic）をGUIフロントエンドに選んだ理由は使用できるオブジェクトが市販されているものを含め圧倒的に多い。画面設計の自由度が高い。慣れたBasic言語である。しかし欠点としてはMコマンドを発行する手続きが煩雑であることがあげられます（図３）。

 

　コンピュターの管理者がたまに使うようなプログラムはCUIでまた一般ユーザが使用するプログラムはGUIで作成するのが見てくれも良くまた開発効率も良いと考えられる。

 

テキスト ボックス: 図３　VBによるMコマンドの発行例

　
 　

 


　

プログラム上の成果

医事システムの改造は行わず、U-MUMPS上で新たに作られるファイルを監視して動作するように設計したため、作成したプログラムは医事システムのアドオンソフトとして安全に動作させることが出来た。

VBで作られた入力部分よりMSM－Activateを介してTCP/IP接続でMSMサーバーにアクセスするためサーバーのライセンスさえあればクライアントに対するライセンス料がかからないためコストの削減に役立った。

今までのCUIプログラミングでは入出力部分の作成の多くの時間を費やして来たが、VBを使ったGUIで作成するマン・マシンインターフェイス部分は、はるかに直感的、直接的でかつコード量が少なく開発時間の削減に役立った。

　VBに入出力部分を任せることにより英語版MSMの2バイトコード取り扱いに関する制限をかなり回避することが出来、英語版MSM　Ver.4.40　のより完成された機能を日本語環境で使うことが可能であった。

 

運用上の成果

　患者数、医師の診療数の表示　

　各医師に対し報酬の一部出来高制を採用、また他の自己の診療数と他の医師との診療数の比較も行える事により労働配分の不満の減少につながった。（図４）

 

服薬指導箋

　処方箋出力時に作成した各薬品別の服薬指導データベースを参照することにより、全く人手を介さず発行している。（図５）

 

入院診療計画書

　患者番号を入力し、病名を入力することにより、病名から治療計画データベース、看護計画データベース、症状データベースを参照し、入院計画書が自動生成される。　（図６、図７）

 

カルテ表書の発行

当病院では診療録が厚くなるのを防ぐため、毎年診療録を更新している。　診療録の表書も更新する必要がある。　この時表書きにレセプト情報のみでなく、病歴、予防接種歴、入院歴、アレルギー、禁忌薬などの情報を転記することに多くの時間が使われていた。　これらの情報は日常のレセプト情報より自動的にファイルに書き込まれ、必要があれば診療の時に編集している。　自動化することにより多大な労力の節約と転記のミスの減少が期待される。

可能な限り入力作業を回避し、診療の妨げにならない様配慮した設計により事務量の削減と医師の負担を軽減する効果を得た。　今後バーコード等を使用してさらに作業の合理化と入力の省力化を図って行く予定である。

 


　

図４　医師稼働率表示画面

図５　服薬指導箋印刷画面

 

図６　入院治療計画書作成画面

図７　病名治療データベース入力画面

 

 


　

 

おわりに

 

診療支援システム、オーダリングシステム、電子カルテシステムは大学付属病院などの大病院で普及し始めてきている。　しかしこれら多くのシステムは発生源入力を行い、事務職の負担の軽減、人員削減を行うことに力を入れている。　発生源入力（検査機器より発生するデータも含めて）の考えにより検体検査、診察予約の部門では成果が上がっている。　おそらくそこには診療に当たる医師と看護婦がいれば他は誰も不要の病院が究極のHA（ホスピタルオートメーション）化の進んだ病院としてあると思われる。　

実際オーダリングシステムを操作し、診療に当たると思いのほかコンピュータの操作に時間が取られ、患者とのコミュニケーションが妨げられる事に気づかされる。いかに入力環境が改善されても、元来医師は患者の予約や、処方箋の記載、検査の予約などの多くの仕事を補助者に依頼していた。　現在の多くのシステムはこれらの仕事を医師が代行させている事になる。

職員を減らして人件費を削減することは重要な事であるが、診療速度が低下するのは経営上大きなマイナスとなる事は明らかであり、患者は待ち時間より診療の質や的確性の方を重要視しているため単なるコンピュータ化によるスピードアップのみでは患者数の増加には限界があることが示されてきている。　この様なアプローチでの患者満足度の向上には限界があることが明白である。

診療の質、経営品質を上げ、職員のやる気を引き出し、病院職員全体のスキルを上げることが重視されており、今後の医療情報システムは情報の効率化のみでなく医療従事者の共同作業、労働環境を考慮した職場全体の環境改善のツールとして活用できるようアプローチがなされる事が必要である。