無停電電源のバッテリー交換

　梅雨時となり、雨が多くなるといつも雷、停電は大丈夫かと心配になる。おまけに今年は節電のため計画停電があるかもしれず、電源周りにはいっそうの注意が必要となるだろう。

　先日ORCAサーバーあたりからピーピーと警報がなっていた。1分ほどで鳴り止んだが無停電電源Smart UPS-1000の表示を見ると右から2列目の一番下に赤いランプが点いていた。残念ながらその時デジカメで撮影し忘れた。説明書を見ると「バッテリー不良」とのこと。そういえば購入したのは4-5年前だったかなぁ。

　このUPSには写真下のようにバッテリーが2個搭載されている。日本製でHF12-12というタイプである。「天翔」という会社から購入したので今回もヤフオクで同社のものを探して手に入れた。結構な値段であるがデータがきえたりすると取り返しがつかないので良いものを選びたい。交換は説明書どおりにすればいとも簡単に終了した。これで3-5年は大丈夫。

　とここまで書いて前の記事を探してみたらありました。う～む、ちょうど5年めですな。しかも6月ときてる。もしかするとタイマーがセットされていて5年経ったら警報がなるようになっているのかな。でもまぁ、5年が寿命といわれているし交換すべきでしょうね。

ORCA 4.6 on ubuntu 10.04

　日レセサーバーをupgradeする際に最も困るのは、ORCA 4.6からクライアント（端末）がglclient2になり以前のバージョンと互換性がなくなってしまったことである。当院では受付に2台、診察室に1台端末があるため、サーバー2台、端末3台、つまり5台もubuntuのインストールをしなければならない。Windowsのmonsiaj(java版)最新版なら入力可能であることがわかったが、時々挙動不審になったりするのであまりお勧めできない。

　ということで忙しい診療終了後の体に鞭打ってなんとか5台プラス1台（予備サーバー）、つまり計6台のubuntuインストールを行った。細かいところが以前とはかなり変わっており、実際ほとんど忘れていてとても疲れた。特に主従サーバーの設定ではパスワード設定が必要で、他のマシンであるレセプトチェッカーや自作の診療情報提供書作成マクロからのアクセスができなくなったりしてほとほと困った。

　それでもやればできるもので、2月まるまる1ヶ月かけてなんとか作業を終え3月初めのレセプト提出も済んでホッとしたところである。これだけの労力を必要とするならいっそのこと業者に頼もうとも思ったが、ここまでくるともう意地の世界である。これで4月の診療報酬点数改訂もなんとか乗りきれるだろう。しかしこの作業、ベンダーさんに頼んだら幾らくらい請求されるのかなぁ。私なら数十万はほしい。実際、バージョンアップに伴い、以前の端末が使えなくなったことで料金を請求され、トラブルになった例もあるのではないかと思うのだが…。

コンピュータメモリーの寿命

　２０１０年の6月にメモリーの不具合でORCAサーバーが動かなくなったという記事を書いた。おそらく落雷のためであろうという考察までつけた。ところが、どうやらそれは間違いだったらしい。

　2月に入りいつものようにチェック用のレセプリントを終えた日の午後、受付嬢がORCAの不調を訴えた。受付の端末が2台ともフリーズしているというのである。syslogをチェックするとどうやらまたメモリーエラーらしい。とりあえず従サーバーへつなぎ替えて業務を継続した。診療終了後にmemtestでチェックしてみると確かにメモリーが原因であった。

　前回故障との共通点は、「レセ打ち出し後」である。原因は落雷ではなく、たぶん過負荷によるメモリ障害だろう。RDRAM(RIMM)は稼働中かなり熱くなるため放熱板で被われている。レセ作成にはかなりのパワーが必要なので大型FANでも追いつかなかったらしい。RIMMが市場から消えてしまった理由はこの辺かもしれない。

　調べてみると、ハードディスク、USBばかりではなくコンピュータメモリーにも寿命があるそうな。前触れなく突然壊れるそうである。大方の寿命は１０年位らしい。発熱が多いRIMMの寿命はもっと短いだろう。だとするとこのままEtchサーバーを使いつづけるのは極めて危険なことである。4月の改訂も近いことだし作業を急がなければ…。

ORCAとFCRの連携、その(1)

　ORCAの患者情報をFCRに読み込ませるには2つの工程が必要である。まず一つはORCAに保存されている患者情報を取り出して変換しFCRサーバーに読み込ませること。もう一つは新患者登録時に作成されるxmlファイルをFCRサーバーに読み込ませることである。

　まず業務メニューから「71 データ出力」を選択し、PTINFテーブルを右カラムへ移動させる。この時右カラム上の「患者IDを患者番号へ置換する」をチェックしておくこと。「確定」をクリックすると次のメニューが現れる。

　テーブル列項目からPTID, KANANAME, NAME, SEX, BIRTHDAYを選択し右カラムへ移動させる。「確定」をクリックすると「/tmp/PTINF.TXT」へテキストファイルが作成される。当院登録患者は1万人以上あるが、2-3分で作業が終了した。

　デフォルトではEUCで出力されるためnkfでShift-JISへ変換しておくこと。
　　　nkf -s PTINF.TXT > PTINF_SJ.TXT

　以下次号

レントゲン写真のデジタル化

　開業以来、レントゲン写真の枚数も増え整理だなが手狭になってきた。開業当時デジタル化レントゲン写真の導入を勧められたが、とても高価で従来型のレントゲン装置と現像機にせざるを得なかったのである。聞くところによるとレントゲンフィルムを製造するメーカーが減ってきているそうで、デジタル化の勢いは止まりそうにない。

　そういうわけで我がクリニックも導入に踏み切った。PRIMAという読取ユニットとDELLの画像処理サーバー、それと撮影室横に設置したタブレット型端末で構成されている。使ってみた感触は上々で現像の手間がほとんどないし一々名前のシールを貼らなくても良いのでかなりの時間短縮になった。こういうことならもっと早く導入すべきだったと思った程である。

　ORCAには1万人超の患者情報が保存されているのでデータ連携が課題であった。Fujiの担当者に聞いたところ、ORCAとの連携実績はあるが契約ベンダーが設定しているので詳細は不明とのこと。ちなみに別売の連携用ソフトがあって、参考までに見積もりをとったら○十万円とのことであった。ORCAは患者情報をcsv形式で出力できるしclaim接続で電子カルテとの連携もできるので、なんとかなるだろうと思い購入は見合わせた。

　しかし自分で調べてみると意外に情報が少ないのである。こういう時自力導入派はつらい。連携できなければ宝の持ち腐れであろう。文字列操作なら昔から得意なので頭の体操がてらトライしてみることにした。連携については後日報告。

USBメモリは3年でダメになる？！

　先日、上京した折に飛行機の中での時間つぶしに日経PC21を購入した。ちょっと衝撃的なことが書いてあったのでご紹介をば…。

　デジタルデータは永遠に保存できる、というのはウソらしい。最近は2GB, 4GBというUSBメモリも珍しくないのでUSBにバックアップをとるという作業はよく行っている。記事によるとUSBやSDカードは衝撃には強いが長期保存には向かず、毎日使うデータの持ち運びに限るべきという。なんでも絶縁体の劣化により電子が漏れ出してしまうのがフラッシュメモリの宿命とか。データ保持期間は5-10年以内という。

　ハードディスクが衝撃に弱いのは知っていたが、衝撃、熱、結露に注意が必要。データ書き込み中に衝撃があるとデータが破壊されやすく、特にノートパソコンには要注意。列車移動中の使用などは避けたほうが良い。データ保持期間はせいぜい5年とのこと。

　では何に保存したら一番よいかというと、CDもしくはDVDなのだそうである。しかしファイル式、不織布ケースに保管してはいけないらしい。出し入れの際に傷がつきやすくデータ読み取りが困難になることがあるという。一番良いのはプラスチックケースとのこと。いままでCD-Rをすべて不織布ケースに入れていたので深く反省。早速プラスチックケースを購入した。とにかくデータが消失してしまってからでは遅いのでこまめにバックアップをとることにしよう。

　ところで支払い基金や国保ではフロッピーディスクで提出されたレセ電データをどのようにして保存しているのだろうか?　まさかそのまま書庫に入れているのではあるまい。ちゃんとCDもしくはDVDに焼いてくれているのかしらんと余計な想像をしてみた。

アトムにも体調不良はあるのか？

　○ーザイがアトムを使った逆流性食道炎のキャンペーンCMを流している。さすがにアトムに逆食はないだろう。しかしメモリートラブルなら起こるかもしれない、というお話。

　最近のORCAは安定しており、ほとんど手を入れる必要はなかった。6月1日、いつものように5月分の点検用レセを打ち出し夕方に業務終了。終了時に「主従のデータベース不整合」のメッセージが出現。久しぶりのメッセージであるが大量に印刷した後なので妙に納得してしまった。主サーバーのデータダンプを作成し従サーバーへ転送してリストア、という手馴れた作業で復旧させた。ところが…。

　翌朝の外来で受付嬢が「ORCAの調子がおかしい」というのである。とりあえず jma-receipt を再起動させたら復旧したので続行とした。しかし1時間後「やはりおかしい」とのこと。セット検査、薬剤コードを呼び出せない。しかたがないので主サーバーを停止させ従サーバーにて業務継続とした。

　その日の業務終了後にいろいろとチェックしてみた。/var/log/syslog には「他のサーバーが停止している」「書き込めない」など初めて見るようなエラーメッセージがぞろぞろ。今までORCA-usersMLで紹介されたトラブルをチェックしてみたが該当しない。orcalogの肥大化、vacuum処理エラーでもなさそうだった。

　途方に暮れていたところ、受付嬢が「そういえば夕方にカミナリが鳴って翌日から調子が悪くなりましたよね」とすばらしいヒントをくれた。さっそく memtest86+ をダウンロードし調べてみるとエラーがゾロゾロ。落雷があったわけではないので疑いもしなかったが、どうやらカミナリがらみの異常電流が悪さをしたらしい。

　3台目のサーバーからメモリ（2GB）を移植して事なきを得た。レセプト点検時期だったので一歩間違えると大事故になっていたかもしれない。やはりサーバーは3台必要であると実感。自力導入は大変だがこういうことを乗り越えつつ成長していくのである。

平成22年度診療報酬改定前夜

　4月1日からいよいよ新しい診療報酬体制が施行される。いつものことながら、どうして2年ごとに大きな改定を行うのだろうと疑問に思っている。表向きはプラスとされているが実情は診療所を経営する開業医にとって大きなマイナス改定である。これでは医療の質は落ちていくばかりだ。厚労省は医療崩壊の責任をとっていないばかりかとどめをさそうとしている。

　それはそうと、改定に際してORCAにも準備をしてあげないといけない。自力導入派はマシンの更新からセット項目の確認まですべて自分でやっている。4月からレセコンがうまく動くだろうかと常に心配している。一応プログラムはetch4.5版に更新済み、パッチ適用済み、マスター更新済みの状態（3月30日現在）。

　例えばエックス線撮影について撮影料がアナログ60点、デジタル68点と区別されるようになるため、セットの組み直しが必要かと診療コードを開いてみたら4月1日より自動的に60点へ移行するように設定されていた。さすがである（当院は未だにアナログ ToT）。

　施設基準の変更も必要で、マスタ登録の1006施設基準情報より、0755明細書発行体制等加算のフラグを0から1へ変更すれば終了。たった10円で明細書を発行して説明もしろという厚労省のお達しだが、これは施設基準であり、明細書なんかいらないという患者さんにも算定されることになるため不満が出るだろう。厚労省もしくは地方厚生局は納得のいく説明をしてほしいものだ。

　地域医療貢献加算は見合わせることにした。たった30円の加算で24時間対応しろというのは絶対無理。開業医も人間なのである。充分に休養しないと良い医療は提供できない。

データベース不具合を発見する工夫

　最近のORCA MLで、データベース不具合のため復旧困難となりベンダーさんに助けてもらったという自力導入先生の事例が報告された。

　いつのまにかデータエラーが混入し、それを知らずにバックアップしていたため復旧できなかったという恐ろしいことがおこったのである。オリジナルのORCAでは主従のサーバーに同一のデータをリアルタイムで保持するようになっている。バックアップの状態は /var/log/syslog に保存されるので監視のための簡単なスクリプトを作成してみた。名付けてdbred.sh。内容は以下のとおり。なんのことはない、grepでdbredirectorを含む行を抽出しているだけである。主サーバーにsshでログインしてスクリプトを走らせれば上の画像のような内容が表示される。少しは役にたつかな？

　dbred.shの内容
　　　#! /bin/sh
　　　sudo grep dbredirect /var/log/syslog.0
　　　sudo grep dbredirect /var/log/syslog

ubuntu 9.10 on X30 その後

　ThinkPad X30 にインストールしたubuntuは一見うまく動いていたが、時々起動時にフリーズすることがあった。再起動すると回復するためそのまま使用していたがなんとも気持ちが悪い。ググってみたらubuntu 9.10とX30 (intel 830) は相性が悪いという情報があった。

　回避策はgrubのカーネルコマンドラインにオプションを付記せよとのこと。実際には

　$sudo gedit /etc/default/grubとやって
　GRUB_CMDLINE_LINUXの行に i915.modeset=0 を追加。
　保存した後 $sudo update-grub とするとOK。

　今は快調に使用できている。