OpenDolphin日記

1. 概要

事務内で保険証OCR専用に使用しているマイナタッチにおいて、「今朝から保険証が読み取れない」という報告があった。調査の結果、OCR処理時に通信不良が発生している可能性が高いことが判明した。本件の経過および対応内容を以下にまとめる。

2. 事象の詳細

対象端末では、保険証を挿入すると「券面を読み取っています」という表示のまま処理が停止し、長時間経過後に「ALM2001 USB接続エラー」が発生した。なお、OCR操作前の段階ではマイナタッチ自体は正常に動作しており、通常のマイナンバーカード読み取りは問題なかった。したがって、OCR処理時に限定して通信エラーが発生している状態と考えられた。

3. 切り分けおよび対応経過

• メイン端末での動作確認
  メイン端末（apx-medical）につながっているマイナタッチでは、OCRは正常に動作した。
• 事務PCでの再試験
  メイン端末のマイナタッチを事務内PC（liva z3）に接続すると、再びOCRが停止。予備のマイナタッチに交換しても同様の不具合を再現。
  → 事務内PC側の環境に起因する可能性が浮上。
• PC交換
  事務PC（liva z3）を予備の liva に交換したところ、当初は数件正常に読み取りできたが、その後同じ症状が再発。
  → 再現性があり、恒常的な通信不良の疑い。
• ケーブル交換
  USBケーブルを交換したところ、同様に一時的に改善したが、再び停止。
  → ケーブル単体が原因ではないと判断。
• 新規PC導入による検証
  姑息対応はあきらめて、新規PC（N100）を調達し、オン資をインストールしたところ、問題なくOCRが動作。
  → ハードウェアまたは通信制御の相性要因の可能性が高い。

4. 追加検証

後日、liva z3 および予備 liva を用いて再度検証を実施。いずれの端末でもUSB接続エラーが再現した。調査の結果、マイナタッチとPC間はCOMポートを介したシリアル通信で動作しており、この通信設定に起因する可能性が考えられた。

Web上の情報を参考に、シリアル通信の bm設定値 をデフォルトの「16」から「1」に変更したところ、エラーが解消し正常にOCRを読み取ることができた。設定を元に戻して（bm=16）再試験してみたが、正常に動作しエラーは再現しなかった。

5. 考察

原因はシリアル通信まわりの不安定動作である可能性が高い。設定変更により通信ポートが再初期化され、一時的に安定化した可能性がある。 PC（特にLivaシリーズ）とマイナタッチ間のUSBシリアルドライバの相性、または一時的なポート不整合が疑われる。

6. 現状および今後の対応

現在、新規導入PC（N100）上では問題なくOCRが稼働中。 旧 Liva 端末については、シリアル通信環境の不安定要因を引き続き調査予定。 必要に応じて、bm設定変更の恒久化などを検討する。

7. まとめ

本件は、マイナタッチのハードウェア故障ではなく、特定PC環境におけるシリアル通信エラーが主因と推定される。設定変更による一時的な改善を確認したが、根本原因の特定には引き続き検証が必要である。

iMac の表示が乱れる

2023年11月から、最新の iMac M3 を診療で使用し始めたのだが、OpenDolphin を使い続けるうちに、ウインドウ内容が表示されなくなる現象が発生した。フレームは表示されるのだが、中身が表示されない。OpenDolphin を再起動すると直るが、しばらく使っていると再発する。その前に使っていた intel iMac では、見たことない現象であった。

さらに、この現象が起こっている際には、Safari の表示も乱れていることに気付いた。また、メモリ使用量も爆増していたが、それにしてはメモリプレッシャーは低いままで、矛盾している？ように思われた。

メモリ使用量の爆増はメモリリークの可能性がある。しかし、java の中にいる OpenDolphin が、Safari にまで影響を及ぼす可能性は考えにくいので、おそらくネイティブ側の問題かもしれないと考えて、OpenDolphin を時々再起動することで対応していた。その後、OS のアップデートが何回かあったが、この現象は解消されなかった。

Window#getOwnerlessWindows()

自前で何とかできないか検討するために、メモリ関連の数値をモニタしてみた。-Xmx は設定していなかったので、iMac のヒープはデフォルト値で、十分余裕がある状態であった。さらに調べていくうちに、Window#getOwnerlessWindows() というメソッドを見つけた。OwnerlessWindows というのは一体、ガベージコレクション (GC) される運命の Window ？なのかもしれない。試しにこの Window の数をモニタしてみたところ、数値がどんどん増えていって、値が 200を越えたくらいで、画面表示が乱れることがわかった。

Window 関連のリファクタリング

内部の方で OwnerlessWindows の GC がうまく行っていない可能性を考えて、Window 関連のコードをリファクタリングしてみた。GC にひっかかりやすくなるかと思って、使い終わったら、リスナの除去、dispose、null を代入というのを徹底した。どこが効いたのかよく分からないが、OnwerlessWindows の増加を大幅に減少させることができて、1日再起動しなくても診療終了できるようになった。

新環境に移行していろいろ動作チェックをしていたら、jma-receview が立ち上がらないのに気付いた。x-server の関係かなといろいろ設定をいじってみたが動かない。ふと思いついて xclock を動かしたらちゃんと表示された。つまり、x-server の問題ではなく、jma-receview の問題だ。

ここで「こういうのってなんだろう、こういうのって前にもあったぞ」と、ぼやっと記憶がよみがえってきた。OpenDolphin 日記で jma-receview を検索したらヒットした。これだ。.config/user-dirs.dirs ファイルを作って、無事に立ち上がるようになった。なんでも記録しておくことは大事だなと思った。

1月中旬に Ubuntu 18.04 + xen + ownCloud で運用していた自宅サーバ (mac mini 2011) で、いつもどおりレポジトリの更新をインストールしたら、dom-u の owncloud のネットワークがつながらなくなった。（＊）

振り返ってみると、自宅サーバは debian squeeze で運用開始して、その後 ubuntu 11.04 に移行し、代々 release-upgrade を繰り返して環境を引き継いできたものであった。その間、インターフェースの名前は predictable に代わり、ネットワーク設定が netplan になり、自宅サーバは時代の変化に取り残された化石マシンになってしまっていた。

それが原因だろうと思い、predictable interface name にしてみたり、netplan にしてみたりしたが、結局つながらない。dom-u ではネットワークが up しており、dom-0 では vif1.0 が見えている、でもつながってないので、bridge のところで何かおきているらしい。web 検索で見つけた echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables というのも試してみたがつながらない。

数日あれこれ試行錯誤したがだめで、かなり悩んだが、そういえば ubuntu 18.04 はまもなくサポート終了だし、環境を一新するいい機会だと考えることにした。

当院開業の時、サーバを仮想環境で動かすに当たって、準仮想化の Xen と、コンテナ型の Linux-VServer、 OpenVZ を比較検討して、xen を採用したという経緯があった。

今の状況だと、検討するとしたら準仮想化の kvm かコンテナ型の docker ということになると思う。今回は kvm で構築することにした。機会があれば docker も試してみたい気はする。

kvm のインストール

1. kvm はカーネルに組み込まれているので、xen の様に hypervisor を新たにインストールする必要はない。開業当時、kvm が linux カーネルに組み込まれることが決定してニュースになっていたのを思い出す。

   $ sudo apt install qemu qemu-kvm libvirt-daemon libvirt-clients bridge-utils virt-manager
   $ lsmod | grep kvm
   kvm_intel  282624  0
   kvm        663552  1 kvm_intel
   

2. 仮想マシンの管理には xl ではなく、libvirt (コマンドは virsh) を使う

   $ sudo systemctl enable --now libvirtd
   $ systemctl status libvirtd
   ● libvirtd.service - Virtualization daemon
        Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
              ：
   

3. br_netfilter を組み込んで無効にする。これをしておかないと、仮想マシンが外に出られない。(元々 xen の dom-u がつながらなくなった件もこれが原因かと思ったのだが、この設定をしてもつながらなかった)
   /etc/modules-load.d/modules.conf

   # /etc/modules: kernel modules to load at boot time.
   #
   # This file contains the names of kernel modules that should be loaded
   # at boot time, one per line. Lines beginning with "#" are ignored.
   br_netfilter
   

   /etc/sysctl.conf

   #added
   net.bridge.bridge-nf-call-iptables = 0
   

   $ cat /proc/sys/net/bridge/bridge-nf-call-iptables
   0
   

4. netplan でブリッジ br0 を作る

   network:
     ethernets:
       enp2s0f0:
         dhcp4: no
     bridges:
       br0:
         interfaces:
           - enp2s0f0
         dhcp4: no
         addresses:
           - 192.168.1.100/24
         nameservers:
           addresses:
           - 192.168.1.1
           search: []
         routes:
           - to: default
             via: 192.168.1.1
     version: 2
   

5. その br0 を使う network を定義する br0.xml を作って、virsh で kvm 用のネットワーク設定を作る。できた kvm 用のネットワーク設定は /etc/libvirt/qemu/networks/ に入る。

   $ cat br0.xml
   <network>
     <name>host-bridge</name>
     <forward mode="bridge"/>
     <bridge name="br0"/>
   </network>
   
   $ sudo virsh net-define br0.xml
   Network host-bridge defined from br0.xml
   
   $ sudo cat /etc/libvirt/qemu/networks/host-bridge.xml
   <!--
   WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
   OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
     virsh net-edit host-bridge
   or other application using the libvirt API.
   -->
   <network>
     <name>host-bridge</name>
     <uuid>c8b61fe1-7602-3028-15f3-2954207391fa</uuid>
     <forward mode='bridge'/>
     <bridge name='br0'/>
   </network>
   
   $ sudo virsh net-list --all
    Name          State      Autostart   Persistent
   --------------------------------------------------
    default       active     yes         yes
    host-bridge   inactive   no          yes
   

6. ブリッジの起動と、自動起動の設定

   $ sudo virsh net-start host-bridge
   Network host-bridge started
   $ sudo virsh net-autostart host-bridge
   Network host-bridge marked as autostarted
   $ sudo virsh net-list --all
    Name          State    Autostart   Persistent
   ------------------------------------------------
    default       active   yes         yes
    host-bridge   active   yes         yes
   

以上で、xen の dom-0 にあたる部分の設定が完了。

Hibernate 6 でデフォルトのプライマリキー採番方法が変更になって、hibernate_sequence からではなく、テーブル名_seq から採番するようになった。これまでの採番方式を維持するためには、persistent.xml に以下のように記載しなくてはならない。

<property name="hibernate.id.db_structure_naming_strategy" value="single" />

今回、これに気付かずに運用開始してやらかしてしまった。Hibernate 5 の時はテスト段階で警告が出てくれたので、hibernate.model.generator_name_as_sequence_name=false をセットして事なきを得たが、今回は警告も出ないし、テストでエラーも出なかったので、完全に油断していた。

木曜日から運用開始して、金曜日まで問題なし。そして土曜日、診療開始してしばらくしてからエラーが出るようになった。

2023-01-28 09:04:22,093 WARN  [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-80) SQL Error: 0, SQLState: 23505
2023-01-28 09:04:22,093 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-80) ERROR: duplicate key value violates unique constraint "d_module_pkey"
  詳細: Key (id)=(1070) already exists.

土曜日は患者さん多く、すぐに対応するのは不可能。全身から血の気が引いたが、何回か再送すると動くので、頑張って運用を続けた。再送2−3回で送らさったのが多かったが、最高10回再送でやっと通ったのもあった。そして、幸運にも何とか外来終了することができて、最後のカルテが保存できた時は、本当にほっとして力が抜けた。

トラブルの原因となったプライマリーキーの件は、土曜外来終了後に web 検索して判明した。多分、プライマリーキーの若い番号は ModuleModel には割当たってなかったので、最初の1000番くらいは空きがあったのだろう。それを食い尽くして、何とか隙間にねじ込むしかなくなったのが土曜日だったのだと思われる。次回はちゃんとマイグレーションマニュアル読もうと誓った週末であった。

ちなみに、Hibernate 6 の新しいデフォルトの採番は、テーブルごとにインクリメントしていくので、効率的に採番できてよい方法だと思う。当院のように hibernate_sequence を single で使ってしまっていると、bigint なので最大 9,223,372,036,854,775,807 までしか使えない。当院の hibernate_sequence は 15年で既に 2,725,392 に達しており、このままのペースで行くと 50,763,552,748,661年後には使い果たしてしまうことになる。

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

□対応範囲：ＡＰＩ
□管理番号：request20181010-001
□問い合わせ（不具合）及び改善内容
　ORCA APIを使い受付一覧を取得する機能がありますが，ORCA上で受付順変更を行っても，
　APIで返されるXMLには新しい順番の情報は無く，
　[Acceptlst_Information_child]の出力順も，もともとの順番と変わりがありません．
　受付変更の結果をなんらかの形で取得できるようにして下さい．
□対応内容
　API受付一覧（/api01rv2/acceptlstv2)にて受付順変更を反映するようにしました。
 ────────────────────────────────────
□対応範囲：ＡＰＩ
□管理番号：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 の間違いと考えられる。

土曜日の朝，いつものように 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 がこんな形で役に立つとは思わなかった。

どうも最近サーバのデータバックアップに以前より時間がかかっているように感じていた。こんなもんだったかなー，とそのままにしていたが，ふとハブのサーバとのリンクがオレンジ (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 ケーブルであった。サーバをいじったときに無理な力をかけて断線させてしまったのかもしれない。

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

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

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

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

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

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