当院では，2008年の開業以来，電子カルテとしてオープンソースの OpenDolphin 1.3.0（デジタルグローブ社）を使用させていただいています。素晴らしいソフトをオープンソースで公開されているデジタルグローブ社には，とても感謝しています。
どんなに優れた電子カルテも，実際に運用するには個々の医院に合わせたカスタマイズが必要だと思います。その場合，オープンソースなら，自院のためだけに自由にカスタマイズすることができます。このブログでは，OpenDolphin を当院で運用するにあたって，色々カスタマイズした内容を中心に公開しています。
2023年11月から、最新の iMac M3 を診療で使用し始めたのだが、OpenDolphin を使い続けるうちに、ウインドウ内容が表示されなくなる現象が発生した。フレームは表示されるのだが、中身が表示されない。OpenDolphin を再起動すると直るが、しばらく使っていると再発する。その前に使っていた intel iMac では、見たことない現象であった。
さらに、この現象が起こっている際には、Safari の表示も乱れていることに気付いた。また、メモリ使用量も爆増していたが、それにしてはメモリプレッシャーは低いままで、矛盾している？ように思われた。
メモリ使用量の爆増はメモリリークの可能性がある。しかし、java の中にいる OpenDolphin が、Safari にまで影響を及ぼす可能性は考えにくいので、おそらくネイティブ側の問題かもしれないと考えて、OpenDolphin を時々再起動することで対応していた。その後、OS のアップデートが何回かあったが、この現象は解消されなかった。
自前で何とかできないか検討するために、メモリ関連の数値をモニタしてみた。-Xmx は設定していなかったので、iMac のヒープはデフォルト値で、十分余裕がある状態であった。さらに調べていくうちに、Window#getOwnerlessWindows() というメソッドを見つけた。OwnerlessWindows というのは一体、ガベージコレクション (GC) される運命の Window ？なのかもしれない。試しにこの Window の数をモニタしてみたところ、数値がどんどん増えていって、値が 200を越えたくらいで、画面表示が乱れることがわかった。
内部の方で OwnerlessWindows の GC がうまく行っていない可能性を考えて、Window 関連のコードをリファクタリングしてみた。GC にひっかかりやすくなるかと思って、使い終わったら、リスナの除去、dispose、null を代入というのを徹底した。どこが効いたのかよく分からないが、OnwerlessWindows の増加を大幅に減少させることができて、1日再起動しなくても診療終了できるようになった。
入力フィールドに応じて、ime が on/off される機能を mac で実現するのは結構大変で、これまで色々苦労してきた。ここしばらくは、ATOK の入力モードを、使っていないファンクションキーで切り替えられるように設定して、OpenDolphin からそのキーを robot で出力することで対応していた。
最近、weborca への移行準備を進めていて、mac クライアントを試していたところ、なんと、当たり前のようにフィールドごとに「ひらがな・カタカナ・英数」の切換ができていた。ただ、monsiaj と違って、weborca クライアントはソースが公開されていないので、実際どうやっているかは謎である。
しかし、できるらしいことは分かったので、色々 web 検索してみたところ、im-select なるものを見つけた。内部の方法が weborca と同じなのかどうかは不明だが、OpenDolphin からこれを呼び出して試してみたところ、ime の切換ができるようになった。
マイナンバーカードになってから、「ショウジ」さんが「シヨウジ」さんで読み込まれている場合はどうしたらよいかと、事務から相談を受けた。拗音促音は、結構適当に登録されているようだ。マイナンバーカードが「シヨウジ」さんになっているのであれば、それを勝手に「ショウジ」さんに変えるわけにもいかないので、そのまま登録してもらうことにした。
そうすると問題になるのが、OpenDolphin での検索である。「ショウジ ショウタ」さんを検索したとき、「シヨウジ シヨウタ」さんも、「ショウジ シヨウタ」さんも、「シヨウジ ショウタ」さんもヒットするようにしなければならない。つまり、促音拗音があった場合、それぞれ大きい場合、小さい場合の全ての組合せを数え上げて検索する必要がある。どうしようか考えていた時、ふと、ChatGPT に相談したらいいのではと思いついた。
相談してみたところ、全ての場合の総数を計算して、総数まで２進数でインクリメントしながら、ビットのありなしで全ての場合を数え上げる java プログラムを教えてくれた。それを元に、プログラムしてうまくいった (swapSmallKana) 。ChatGPT 恐るべし。
新環境に移行していろいろ動作チェックをしていたら、jma-receview が立ち上がらないのに気付いた。x-server の関係かなといろいろ設定をいじってみたが動かない。ふと思いついて xclock を動かしたらちゃんと表示された。つまり、x-server の問題ではなく、jma-receview の問題だ。
ここで「こういうのってなんだろう、こういうのって前にもあったぞ」と、ぼやっと記憶がよみがえってきた。OpenDolphin 日記で jma-receview を検索したらヒットした。これだ。.config/user-dirs.dirs ファイルを作って、無事に立ち上がるようになった。なんでも記録しておくことは大事だなと思った。
環境一新に合わせて、ついでに新サーバを組もうと思って CPU を物色していたら、i5-12400F という CPU が、一体安かったので買ってしまった。マザーボードは ASUS PRIME/B660M-A/D4。この CPU はプロセッサーグラフィックスの付いていない CPU で、オンボードグラフィックは使えず、別にグラフィックボードを用意しないと画面表示ができないものだった。最初知らなくて、画面が表示されずに焦ったが、古い GeForce 7300 LE が院長室のがらくた箱で眠っていたので、それを刺して無事使えるようになった。GeForce 7300 LE も、まさか自分が再び使われる日がくるとは思ってなかっただろう。
早速、レセプト処理速度でベンチマークをしてみたら、開業以来最速と言われた 2019年の i9-9900 を上回る爆速であった。これは CPU の威力もさることながら、M.2 NVMe の進歩が大きいと思われる。
| CPU | データチェック | レセプト作成 |
|---|---|---|
| i7-3770@3.4G SSD |
6.2 | 4.7 |
| i9-9900K@3.6G NVMe |
17.0 | 13.2 |
| i5-12400F@2.5GHz NVMe |
26.7 | 25.3 |
自宅サーバに続いて、業務用マシンも ubuntu 20.04 の kvm 仮想マシンに移行した。そもそも、自宅サーバの ubuntu 18.04 + xen が、apt-get upgrade 後にネットワークがつながらなくなってしまったのがことの始まりであった。つまり、同じ構成で運用している業務用マシンも、次にレポジトリアップデートしたが最後、一体使えなくなるであろうということである。自宅サーバは、復活まで２週間を要しており、業務用マシンをアップデートする前に事態に気付いたのは不幸中の幸いであった。
当院の業務用サーバでは、orca サーバ、dolphin サーバ、文書を保存するファイルサーバの3台のサーバを仮想マシンで運用している。今回のインストールは完全リフレッシュしようと思って、全て新規に ubuntu 20.04 をインストールした。
文書サーバは samba で共有している。samba サーバの設定は、いつもつながらなくて苦しむ印象がある。今回もつながらなくて、かなりの時間苦しんだ。原因は単純に共有の大元のディレクトリの所有権の設定ミスだった。orz。このサーバでは、dzd100.rb も動いているので、設定を忘れてはいけない。
orca サーバはずっと release-upgrade でつないできたので、de novo でインストールしたのはほぼ10年ぶりである。インストールマニュアルと首っ引きでインストールした。標準インストールに続いて、pusher インストール、オン資インストールと進んだ。
orca はプリンタ設定が一体鬼門であると思う。以前インストールしていたBrother HL-5250DN Foomatic/pxlmonoはメニューに出なくなっていた。代わりにbrother-cups-wrapper-laserパッケージをインストールして、Brother HL5250DN for CUPSを選択した。さらに当院ではプリンタ関連で特殊な操作を行っていて、これも設定し直した。
オン資関連では、almex の保険証 OCR データを横取りして修正する自作スクリプトを導入していて、その設定も必要だった。
あと、MaxJobs 関連で rc.local を使っていたが、新規インストールの ubuntu 20.04 では rc.local はなくなっていた。ファイルを作れば呼ばれることは呼ばれるらしいが、cron の @reboot に設定を移した。OpenDolphin との連携で、orca にアクセスするために orca 側で postgresql.conf の listen_address と pg_hba.conf の設定が必要。これもすっかり忘れていて、OpenDolphin が立ち上がらなくて気付いた。
ubuntu 20.04 の orca 5.2 は 2025年 3月までサポート。またしばらくいじらなくてすみそう。
de novo インストールで、一番楽だったのは dolphin サーバだった。wildfly は dolphin ホームディレクトリで走っているので、postgres と java をインストールして、ホームディレクトリをコピーすれば、基本的に移行完了。
ゲストを作成するのには virt-install コマンドを使う。その際、--os-variant=ubuntu20.04 を指定すると、自動的に準仮想化で設定してくれる。--os-variant のパラメータは、libosinfo-bin をインストールして、osinfo-query で確認できる。
$ sudo aptitude install libosinfo-bin $ osinfo-query os | grep -i ubuntu
virt-install コマンドを入力後、vnc でアクセスしてインストールを進める。
$ sudo virt-install --name=template \ --os-variant=ubuntu20.04 --vcpu=2 --ram=2048 \ --graphics vnc,listen=0.0.0.0,port=5900,keymap=ja,password=pass \ --cdrom=/home/pinus/ubuntu-20.04.5-live-server-amd64.iso \ --network network=host-bridge --disk /dev/sda3,device=disk \ --check path_in_use=off WARNING グラフィックスが要求されていますが DISPLAY 変数が設定されていません。virt-viewer を起動できません 。 WARNING ゲストのコンソールがないため、デフォルト値 --wait -1 を適用します。 インストールの開始中... Domain installation still in progress. Waiting for installation to complete. --- ここで vnc でインストール作業 --- ドメインがシャットダウンしました。続けています。 仮想マシンの作成が完了しました。 ゲストを再起動しています。
ずっと自宅サーバーで ownCloud を運用していたが、今回環境変更にあたって、話題の Nextcloud をインストールしてみた。snap というのを使って簡単にインストールできる。
$ sudo snap install nextcloud nextcloud 25.0.2snap1 from Nextcloud✓ installed
インストール終了後、apache 設定しようと思ったら apache がなかった。service にないし /etc/apache2 もない。きつねに包まれたような気分になった。調べてみると、snap パッケージの場合、Nextcloud が使う専用の apache を snap 内で使っているらしい。時代は進んでいる。
/snap/nextcloud/current/conf/httpd.conf /snap/nextcloud/current/conf/ssl.conf /var/snap/nextcloud/common/nextcloud/data/user/files/ /var/snap/nextcloud/current/nextcloud/config/config.php
これでやっと自宅サーバが復活した。トラブル発生から復活まで2週間かかった。
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 も試してみたい気はする。
$ 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
$ sudo systemctl enable --now libvirtd
$ systemctl status libvirtd
● libvirtd.service - Virtualization daemon
Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
：
# /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
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
$ 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
$ 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 にあたる部分の設定が完了。
-----2020年9月にクラウドファンディングで手に入れた天体望遠鏡 eVscope が届いてから、天体観測が面白すぎてプログラムコードにほとんど触れていなかった。2年ぶりの運用まとめ。
dolphin=# select count(*) from d_patient; count ------- 38302 (1 row)
dolphin=# select count(*) from d_module; count --------- 1542061 (1 row)
Filesystem Size Used Avail Use% Mounted on udev 961M 0 961M 0% /dev tmpfs 199M 464K 199M 1% /run /dev/xvda1 46G 23G 21G 53% / tmpfs 993M 16K 993M 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 993M 0 993M 0% /sys/fs/cgroup tmpfs 199M 0 199M 0% /run/user/1001
Filesystem Size Used Avail Use% Mounted on udev 3.0G 0 3.0G 0% /dev tmpfs 606M 1.2M 605M 1% /run /dev/xvda1 46G 20G 24G 46% / tmpfs 3.0G 16K 3.0G 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 3.0G 0 3.0G 0% /sys/fs/cgroup ：
dolphin_db.dump.gpg 2,908,582,533 orca_db.dump.gpg 330,190,797
$ grep -c stampInfo stamp.xml 2168
Java 17 への完全移行が完了し、これで来るべき apple silicon 時代にも対応できるようになったと思う。
