トラブル

2019年7月 2日 (火)

orca パッチ後の受付トラブル〜原因

土曜日の orca パッチ後のトラブルであるが,原因は api のアップデートであった。

□対応範囲:API
□管理番号:request20181010-001
□問い合わせ(不具合)及び改善内容
 ORCA APIを使い受付一覧を取得する機能がありますが,ORCA上で受付順変更を行っても,
 APIで返されるXMLには新しい順番の情報は無く,
 [Acceptlst_Information_child]の出力順も,もともとの順番と変わりがありません.
 受付変更の結果をなんらかの形で取得できるようにして下さい.
□対応内容
 API受付一覧(/api01rv2/acceptlstv2)にて受付順変更を反映するようにしました。
 ────────────────────────────────────
□対応範囲:API
□管理番号:request20181121-001 request20190115-001
□問い合わせ(不具合)及び改善内容
 ・「患者基本情報の取得(patientgetv2)」で取得できる割引、状態、入金
 方法等について、「API患者登録(patientmodv2)」で登録できるようにしてほしい
 ・「API患者登録(patientmodv2)」で登録できる保険の資格取得日を
 「患者基本情報の取得(patientgetv2)」で取得できるようにしてほしい
 患者基本情報API(/api01rv2/patientgetv2)で、公費単独の保険確認日
 を取得できるようにしてほしい。
□対応内容
 API患者情報取得(/api01rv2/patientgetv2)の返却に保険の資格取得日、公費の確認日を追加しました。
 API患者保険組合せ取得(/api01rv2/patientlst6v2)の返却に公費の確認日を追加しました。
 API患者情報一括取得(/orca51/patientbasisallv3)の返却に公費の確認日を追加しました。
 API患者登録(/orca12/patientmodev2)に減免事由、割引率、入金方法を追加しました。

公費がある場合,api で返ってくる json property に追加があったため,dolphin 側で受付時に公費情報を取りに行ったタイミングで,jackson がデシリアライズに失敗して exception を吐いていた。

dolphin サーバの open.dolphin.orca パッケージを修正して,さらに,unknown property があっても jackson が無視するように設定した。これで今後知らないうちに property が追加されることがあったとしても止まらないで済むはず。

mapper.disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES);

ちなみに,/orca51/patientbasisallv3 というのは現状非公開の拡張 api とのこと (by サポート)。また,patientmodev2 は patientmodv2 の間違いと考えられる。

2019年7月 1日 (月)

orca パッチ後の受付トラブル

土曜日の朝,いつものように orca を立ち上げたところ,「2019-06-25 パッチ提供(第46回)◆日医標準レセプトソフト ver 5.0.0 全17件」というのが目に付いたので,何気なくプログラム更新した。診療もいつも通り始まり,普通に6人目まで診療終了。しかしその後,7人目と8人目の受付で,orca で受付しても dolphin のリストに出ないとの連絡あり。確認してみると,サーバーログに以下のような exception が出ていた。

ERROR [stderr] (XNIO-1 task-5) com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "Certificate_CheckDate" (class open.dolphin.orca.orcaapi.bean.PublicinsuranceInformation), not marked as ignorable

すぐに何とかなるエラーではなさそうだったので,バックアップマシンに切り替えて対応することにした。当院のサーバは xen の dom-U で構築しており,毎日診療終了後にメインからバックアップに丸ごとコピーされるようになっている。つまり,メインの dom-U をシャットダウンしてバックアップの dom-U を立ち上げると,今朝の診療開始前 (orca にパッチを当てる前) の状態でサーバが立ち上がる。バックアップに切り替えて,既に診療済みだった 6人のデータは失われたが,その後の診療は無事終了した。

トラブルシューティングは後に回すとして,バックアップに切り替える前に診療終了している6人分のカルテをどうするか。ここで,以前作っておいた Autosave が使えるのではないかと思いついた。

バックアップマシンの dom-U をシャットダウンして,メインの dom-U を立ち上げると,トラブル発生前に診療終了していた 6人分のカルテが現れた。これらを全てエディタで開いて,開いたまま OpenDolphin を kill した。 しかる後に,メインの dom-U をシャットダウンしてバックアップの dom-U を立ち上げ,6人分の受付をしてカルテを開けると「保存されていない編集中のカルテが見つかりました」のダイアログが出て,カルテを復活させることができた。

診療中にバックアップに切り替えるのは初めての経験であったが,データロスなく乗り切ることができた。Autosave がこんな形で役に立つとは思わなかった。

2019年6月17日 (月)

ネットワークが遅くなる

どうも最近サーバのデータバックアップに以前より時間がかかっているように感じていた。こんなもんだったかなー,とそのままにしていたが,ふとハブのサーバとのリンクがオレンジ (100Mb/s) に光っているのが目にとまった。ethtool でリンク速度をチェックしてみると,やはり 100Mb/s になってしまっていた。

Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair

新サーバの ether ドライバを標準的でない方法でインストールしていたことが頭をよぎったが,まずは,バックアップ機につながっている LAN ケーブルに差し替えて調べてみた。

Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair

すると 1000Mb/s でリンクし,ハブの LED はグリーンに光った。さらに,元々サーバにつながっていたケーブルをバックアップ機につないでみたところ 100Mb/s に落ちてしまった。つまり,原因はドライバではなく LAN ケーブルであった。サーバをいじったときに無理な力をかけて断線させてしまったのかもしれない。

2019年3月16日 (土)

複合機の蝶番修理

受付から,コピー機として使っている複合機のあたりからすごい音がして,蓋が開きにくくなったとの連絡あり。確認したところ,プラスチックの蝶番が折れていた。こういう力のかかるところにプラスチックの部品は無理なんじゃないんだろうか。というわけで,板金加工で修理した。

22 2

2018年9月23日 (日)

地震で iMac のディスプレー割れる

9月6日午前3時7分,北海道胆振東部地震が発生し,当院のある札幌市東区は震度6弱に見舞われた。 停電のため地下鉄が動かず,信号機も消えてしまって道路も混乱,夜が明けてから歩いて医院に状況確認に行ったところ,iMac が全部画面を下に倒れてしまっており,1台 (iMac Late 2015) でディスプレーのガラスが割れてしまっていた。

Inchoroom Img_7893 Img_7891

停電のため診療どころか掃除機すら使えない状態であったが,7日午後までには電気が回復,バックアップマシン (iMac Mid 2010) を立ち上げ,卸さんに電話して冷蔵の薬品を注文,8日から診療を再開した。停電の影響で物流は大混乱,食料の入手にも一苦労の状態だったが,薬品はちゃんと8日朝に届いた。ありがたいことである。

当初,壊れた iMac はガラスが割れただけに見えたので,ガラスだけ買って交換すればいいと考えていた。しかし,調べてみると,最近の iMac は薄くするために表面のガラスと LCD が一体化しているらしく,ガラスだけ交換というわけにはいかないようだった。おとなしくアップルに修理に出すことにした。

Chat1 Chat2

アップルの修理サポートはチャットでアクセスできるようになっていて便利だった。チャットで見積と配送の手配をしてくれて,14日にヤマトさんが回収,20日には修理完了して戻ってきた。痛い出費ではあったが,3年使った LCD が新品になったと考えて納得することにする。

今回のことに懲りて,耐震ジェルを iMac に装着したので,次は大丈夫と思われる。

2017年12月 8日 (金)

java 1.8.0_152 で NetBeans フリーズ

NetBeans のリファクタリングで Class の名前変更をしようとしたところ,「名前変更クラスxxx」のダイアログが出た時点でレインボーカーソルになってフリーズするようになった。設定ファイル (~/Library/Application Support/NetBeans/8.2/) を削除したり,キャッシュ (~/Library/Caches/NetBeans/8.2/) を消去したりしてみたが改善しなかった。

ふと思いついて,java の古いバージョンで立ち上げてみたところ症状が消失した。最新の java 1.8.0_152 ではなく,java 1.8.0_151 の方で試してみたら,これも大丈夫だった。

調べてみたら,奇数番号のアップデートは Critical Patch Update (CPU),偶数は Patch Set Update (PSU) と呼ばれるアップデートで,PSU は CPU の変更+次バージョン用のバグフィックスが含まれているようだ。今回は,PSU のバグフィックスの副作用で NetBeans に影響が出たと考えられる。


1.8.0_161, 1.8.0_162 でも直っていなかった。bugzilla に報告されていた

2017年6月19日 (月)

Windows 10 マシンが突然再起動する

今月から突然事務で使っている Windows 10 マシンが勝手に再起動するようになった。事務からの報告によると,しばらく問題なく動いていても,突然入力を受け付けなくなって,その後画面が乱れて再起動してしまうとのことであった。Windows 10 マシン3台が同じ症状であったことから,ソフトウェアの問題と考えられた。

まずは,何が起きているかを確認するために,再起動時にエラーメッセージを残すように設定し,問題が起きたときに見せてもらうことにした。「起動と回復」の「自動的に再起動する」のチェックを外すと,再起動の前にエラーメッセージを表示して止まるようになる。

Reboot

その結果,ブルースクリーンで以下のエラーが確認できた。
VIDEO_TDR_FAILURE (igdkmd64.sys)

当院の Windows マシンはオンボードグラフィック (インテル) を使っている。システムアップデートの時点で,インテルチップセットのビデオドライバがコンフリクトするようになったようだ。 ドライバのアップデートを捜してみたが,古いマシンなので,既にドライバは古いまま放置状態。仕方がないので,Microsoft 基本ドライバを使うことにした。

  • ドライバを外すと画面が真っ黒になるので,あらかじめ電源スイッチで電源オフできるようにしておく。
  • ビデオドライバを外す。

    0003

  • 画面が真っ黒になるので,少し待ってからスイッチオフ,その後スイッチオン。
  • 再起動後,自動的に元のドライバに更新されてしまうが,「ドライバーを元に戻す」が選択できるようになる。

    0004

  • ドライバーを元に戻すと,Microsoft 基本ディスプレイアダプターがインストールされる。

    0006

これにて症状は再現しなくなった。ビデオパフォーマンスについても,業務用に使うのであれば,基本ドライバで十分なようだ

2017年4月28日 (金)

ATOK29 関連フリーズ

診察室の iMac が,4月初めの 10.12.14 アップデートの後くらいから,1日に1回〜数日に1回程度,レインボーカーソルを出してフリーズするようになった。再現頻度が低いので,なかなか原因がつかめなかったが,top コマンドの監視でついに ATOK29 が CPU を食い尽くしている現場をつかまえた。

Atok29freeze

うすうす予想はついていたが,やっぱりまたおまえかー!という感じである。その後は,とりあえず cputhrottle で ATOK の動きを制御して対応していた。

$ sudo ./cputhrottle ${atokのpid} 10

いろいろ Web を検索してみたところ,「ATOKインサイト」のトラブルが結構報告されていたため,試しに切ってみた。環境設定の「変換補助>一時文書学習候補を表示する」を外すことでATOKインサイトが常駐しなくなる。

Atokenviron

その後10日くらい運用してみたが,フリーズは再現しなかった。試しに ATOKインサイトを再び ON にしてみたところ,その日の夕方にフリーズが再現したため,どうやら ATOK インサイトが関係している可能性が高い。ATOKインサイトは切って運用することにした。


追記) その後 ATOK30 にアップデートして,ATOKインサイトを入れても全く問題なく使えている。

2017年3月11日 (土)

受付のキーボード壊れる

受付で使っていたキーボード (Justy JKB-109B)が朝から入力を受け付けなくなった。15年前くらいに買ったキーボードで,開業当時から受付で酷使を続けてきたものである。ここまでよくがんばってくれたと思う。Do夢さんに行って,同じキーボードを買おうと思ったら,Justyさんはもう倒産してしまっているらしく,代わりに AOTECH のキーボード(AOK-112UPW)を購入した。

2016年7月 7日 (木)

診療中に ORCA の印刷止まる

午後の診療開始直後,受付から処方箋,領収書,診療明細が印刷されなくなったという連絡あり。orca サーバを再起動してみたが症状は変わらず。処方箋を印刷しようとすると syslog にわけの分からない dump が出てくる。患者さんが結構待っていたのでかなり焦ったが,ここは冷静に頭を医者モードからコンピュータ管理者モードに切り替えてトラブルシューティングを開始した。

まずは orca の cups にブラウザでアクセス,プリンタにテストプリントを送ってみたところ正常にプリントされた。当院では,処方箋等は cups のバックエンドに送って,バックアップマシンにカーボンコピーを残しつつプリンタに送る様に設定している。そこで,orca のプリント出力先を,ダイレクトにプリンタに送るようにしてみたところ,プリントされるようになった。とりあえずこれで診療を乗り切った。

患者さんが切れてから cups のログを見てみた。

E [14:06:50 +0900] Unable to fork /usr/lib/cups/filter/foomatic-rip - Cannot allocate memory.
E [14:06:50 +0900] [Job 224056] Unable to start filter "foomatic-rip" - Success.
E [14:06:50 +0900] [Job 224056] Stopping job because the scheduler could not execute a filter.
E [14:06:51 +0900] Unable to fork /usr/lib/cups/backend/socket - Cannot allocate memory.
E [14:06:51 +0900] [Job 224059] Stopping job because the sheduler could not execute the backend.
E [14:06:52 +0900] Unable to fork /usr/lib/cups/backend/pdf - Cannot allocate memory.
E [14:06:52 +0900] [Job 224058] Stopping job because the sheduler could not execute the backend.
cups がメモリ不足で止まっていたようだった。そこで,メモリを調べてみると。
$ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0 911564  23084  13584 165496   17  106   124   134   77   67  1  0 99  0  0
$ free -t
             total       used       free     shared    buffers     cached
Mem:       1013348     991528      21820      39876      13628     166520
-/+ buffers/cache:     811380     201968
Swap:      1048572     911536     137036
Total:     2061920    1903064     158856
血の気が引いた。慌てて最新 orca の必要メモリを調べてみたら,4GB 以上,最低 2GB となっていた。以前から orca には 1GB しか割り当てていなかったため,スワップ領域を食い尽くして,ギリギリの状態で動いていたようだ。

緊急に容量を工面して,orca のために 3GB 用意した。これでプリンタ出力先をバックエンドに戻しても問題なく印刷されるようになり,その後の業務も問題なく終了。

$ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 404244 124896 528624    0    0    23    23   63   56  1  0 99  0  0
$ free -t
             total       used       free     shared    buffers     cached
Mem:       3069452    2665032     404420      64548     124904     528628
-/+ buffers/cache:    2011500    1057952
Swap:      1048572          0    1048572
Total:     4118024    2665032    1452992

業務終了後,メモリを買ってきて造設 (DDR3メモリずいぶん安くなってた)。余裕をもってトータル 16G にして,orca には推奨の 4GB を割り当てた。メモリ増設後の1日業務終了後,かなりの余裕。

$ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 1148244 147516 679468    0    0     4    21   77   68  1  0 99  0  0 
$ free -t
             total       used       free     shared    buffers     cached
Mem:       4097504    2949632    1147872     141864     147524     679532
-/+ buffers/cache:    2122576    1974928
Swap:      1048572          0    1048572
Total:     5146076    2949632    2196444
2010年には 4GB で湯水のようにメモリが使えると喜んでいたのに,今や orca だけで 4GB である。