かんたんレセ電送信プログラム

わりとご無沙汰になってしまったので、近年弊社で開発したプログラムやら何やらの紹介を数回に渡って行いたいと思います。

まずはオンライン請求の操作が煩雑であるという声から生まれた「かんたんレセ電送信プログラム」です。おもに2つのプログラムから成り立っています。

レセ電ファイル(RECEIPTC.UKE)を所定のフォルダーに置くと、1行目を読み取って自動的に年月と国保/社保のフォルダーを作成します。これは常駐プログラム（スタートアップに登録）になっており、「自動レセプトコピー」と呼んでいます。



近年返戻や再請求もオンライン化されたので、これらのファイル(RECEPTC.HENとRECEIPTC.SAH)も同様の処理を施すようにしました。

レセ電ファイルを送信する場合に使用するのが「かんたんレセ電送信プログラム」で、社保に送信するか国保に送信するかを選択すると、実行した年月と先ほど選択した国保または社保フォルダーにあるレセ電ファイルを所定のフォルダーにコピーします。こうすることによって送信時にファイルないしフォルダーを選択する手間を省いています。



「自動レセプトコピー」はWindowsとUbuntuで同じプログラムですが、「かんたんレセ電送信プログラム」は異なるプログラムで、UbuntuではIP-VPNに接続するために必要なPPPoE接続も自動的に行っています。すなわちオンライン請求のマニュアルにあるPPPoE接続方法とは違った方法を採っています。

オンライン資格確認とORCA

オンライン資格確認は日本全国の医療機関のうち半数以上が申し込んでいるものの、実運用しているのは6000件程度となっています（10月上旬現在）。

オンライン資格確認の導入について（医療機関・薬局、システムベンダ向け）より引用
全医療機関の3%にも満たないというのは衝撃的です。

理由はいろいろとあるのでしょうが、システムベンダーから見た場合は設定設置作業の難易度が著しく高いというのは指摘できるのではないかと思います。

技術要素として、ORCAの場合は

• ネットワーク（特にIPv6、IPoE）
• Windows
• Ubuntu
• ORCA

の高度な知識が求められます。これらのすべてをカバーするのはなかなか困難です。二の足を踏むには充分な理由です。

弊社のお客様もオンライン資格確認の導入を希望され、納入したところが数件ですがあります。その（今のところの）知見を公開していきたいと思います。

IPoEのブリッジルーター

IPoEに関する知識は『徹底解説 v6プラス』がとても参考になります。
前提知識を得た上でIPoEのブリッジルーターにふさわしい機種を選定したところ（各社のマニュアルを片っ端から読んでいったところ）、BuffaloのWiFiルーターはIPv6関連の機能が充実していることがわかり、実際にWSR-1166DHPL2を採用することにしました。WiFi機能は無効にするため、安いモデルでいいと思います。

メトリック

オンライン資格確認端末には多くの場合NICが2つあり、かつIPv4とIPv6で合計4つのゲートウェイを指定することになります。となると自動メトリックだと意図したとおりにはならないため、手動で設定せざるを得ません。
こんな感じで設定することにしました。

• 支払基金に接続するネットワークのIPv6…10
• 院内ネットワークのIPv6…20
• 支払基金に接続するネットワークのIPv4…30
• 院内ネットワークのIPv4…40

ただし院内ネットワークのIPv6は通常使用しないため、そもそも無効にしていることが多いです。

資格確認データ置き場

マイナンバーカードで患者登録または保険確認する場合と登録されている保険の資格確認をするのとでデータの流れは違いますが、いずれにせよ『日レセオンライン資格確認の環境構築』を読むと資格確認データは資格確認端末に置き、そのフォルダーをマウントするようになっています。
ORCAサーバー（正確にはpush-exchangerとonshi-toolsを動かすPC）と資格確認端末は電源を切らずに運用する場合はこれでもいいかもしれませんが、いささか非現実的にように思います。かといって/etc/fstabに書くマウントの方式を工夫してもORCAにデータを取り込まない事態となり、結局onshi-receiverを再起動することになってあまり嬉しくありません。
ORCAサーバーにSambaをインストールし、共有フォルダーの設定をしてもWindowsからは見えるようになりません。理由がさっぱりわからなかったので徹底的に調査をすると、セキュリティ上の都合でWindowsがそのような設定になっているということでした。具体的にはSMB2 および SMB3 のゲスト アクセスは、既定では無効になっていますの指示に従って[セキュリティで保護されていないゲスト ログオンを有効にする]を有効にします。
セキュリティレベルとしては低下しますが、非常に限定されたネットワークで限定された用途であり、特に問題ないと考えています。
資格確認端末から共有フォルダーにアクセスするように設定変更する方法は『連携アプリケーション導入手順書』と『顔認証 DLL 定義説明書』に書かれています。

push-exchangerとonshi-toolsのバグ

バグというほどのものでもありませんが、push-exchangerとonshi-toolsのパッケージを慎重に見ていくと、/etc/cron.d/push-exchangerと/etc/cron.d/onshi-toolsで朝3時に自動的に再起動しようとしているように見えるのですが、実際には再起動はされません。というのもserviceコマンドにパスが通っていないからで、/usr/sbin/serviceとフルパスに変更すれば再起動するようになります。
push-exchangerを再起動しなければいけない機会はよくわかりませんが、onshi-receiverはわりと再起動したい機会もあるので、この修正を行った上で自動的に再起動したい時間を追加するといいかもしれません。

ルーターを1台で済ませたい

医療機関・薬局への導入におけるオンライン資格確認等システムとの接続に係るネットワーク連携のパターンの参考例を見てもわかるとおり、ルーターは（ホームゲートウェイも含めて）2台必要ということになります。LANの配線の都合上どうしても1台でやりたいという場合には、NVR510またはそれ以上(RTX830とか)を使用すればいいのではないかと思います。実際うまく行きましたが、なぜかIPv4で名前が引けなかったので「中継先DNSサーバー」によく知られた1.1.1.1とか8.8.8.8とかを登録してやるとうまく行くようになりました。

そもそもポータルサイトの申請からしてトラップが多いのですが、技術的にハマったところとその（暫定的な）対策方法としては以上のとおりです。何かの参考になりますと幸いです。

ORCA用プリンターとしてのRICOH SP 3700

RICOH SP 3700を納入することになり、ORCAでの動作を検証しました。
廉価モデルであるにもかかわらずPostScript互換機能が付いているのは嬉しいところです。

Linux用ドライバーも配布されていますが、B5が印刷できなければ用紙トレイの指定もできないという何とも残念なシロモノです。検証したところ高速ではあったので、レセプトを印刷するような用途にはいいかもしれません。

PS互換機能のPPDはOpen Printingにて配布されており、これを使用するとB5 JISにも対応していて全く問題ありません。しかし速度は控えめです。

トナーは最近珍しいドラム一体型で、これはなかなかに評価が高いです。別々に購入したりするの面倒ですものね。

用途は限定されるものの、ORCAのプリンターとしてしっかり動作しそうで安心しました。

NEC MultiWriter 5300とUbuntu 18.04 LTS以降

MultiWriter 5300はUbuntuで動作するPDFプリンタードライバーがありますが、Ubuntu 16.04 LTSではこのドライバーで印刷できていたものの、18.04 LTS以降は印刷できなくなっていました。しかたなくPCL6用の汎用PPDを少しカスタマイズして使用していましたが、プリンターのエラーが多く、困っていました。

久しぶりにドライバーの配布ページを見ると、新プリンター(7200)が対応機種に入っているばかりか（5350が入っていないのが少し不思議ですが）、Ubuntu 20.04 LTSでも動作確認しているというではありませんか。

手元でも試してみましたが当然印刷できず、動作確認せずに情報だけ書き換えたのかな？ とは思ったものの、試しにファームウェアを最新にしてみたらどうだろうと思ってやってみたら、これがビンゴでした。

すなわち、今までUbuntu 18.04 LTS以降で印刷できなかったのはドライバーの問題ではなく、プリンターの問題だったのです。

しばし脱力しましたが、プリンターのエラーがなくなったという社内での評価もあったので、結果オーライではないでしょうか。

追記(2021/09/17)
と書いておりましたが、ファームウェアをアップデートしても印刷できない事態が頻発していました。
どうも6月に新しいドライバー(1.1.3-4)がリリースされており、これでまた挙動が変わるかもしれません。

Ubuntu 20.04 LTSのデスクトップにフォルダーのショートカットを置きたい

内容としてはタイトルのとおりですが、18.04 LTSまでのファイルマネージャー(Files、旧名Nautilus)ではデスクトップフォルダーも他のフォルダーと同じように扱うことができていました。
しかし、20.04 LTSでは（正確にはもう少し前から）この機能がなくなり、デスクトップに置いたファイルやフォルダーを表示することができなくなったものの、GNOME Shellの拡張機能(gnome-shell-extension-desktop-icons)をあらかじめインストールすることによってこの機能を再現しようとしています。
とはいえ前と全く同じというわけにはいかず、いろいろと制限があります。今回はとあるフォルダーのショートカットをデスクトップに置きたいという場合の解説です。

当然シンボリックリンクを作るようなことはできず（正確にはシンボリックリンクは作れるけれどもデスクトップに表示されない）、このような場合には.desktopファイルを作ることになります。仕様書を読むと"Type=Link"とすればよさそうですが、残念ながら非対応です。

例えば/home/appcel/testというフォルダーのリンクを作りたい場合は、デスクトップに次の内容でテキストファイルを作成します。
[Desktop Entry]
Name=Test
Type=Application
Icon=org.gnome.Nautilus
Exec=gio open /home/appcel/test
作成後、デスクトップでこのファイルを右クリックすると「起動を許可する」というメニューがあるので、これをクリックすると有効になります。

関連付けしてあるアプリケーションを自動的に選別してくれるxdg-openというコマンドがあり、最初はこれを使用しようとしましたが、現在はdeprecatedでgio openを使うのが正しいのだそうです。

20.04 LTSではデスクトップの扱いが従来とは全然違うため、他にもいろいろとハマりどころがあるのではないかと考えています。

追記:
全く同じものが18.04 LTSでも機能しました。

Ubuntu 18.04 LTSと日レセクラウド�D ソフトウェアVPNからTLS 1.2へ

Ubuntu 18.04 LTSと日レセクラウド�@ L2TP/IPsec
Ubuntu 18.04 LTSと日レセクラウド�A 印刷ができない！
Ubuntu 18.04 LTSと日レセクラウド�B 用紙サイズがA4になってしまう！
Ubuntu 18.04 LTSと日レセクラウド�C push-exchangerの使用は有料

このように印刷の問題が解決されたため、L2TP/IPsecによるソフトウェアVPNからTLS 1.2に変更しました。
今まではWebサイトの閲覧すらもできなかったのが、TLS 1.2に変更することによってWebサイトが見られるようになりました。「ユーザURL設定」で設定したWebサイト（弊社の場合はこれ）も特別に用意したものでなくてもよくなったのもいいところです。

解決が難しいこともありますが（具体的には、レスポンスタイムはどうしてもオンプレミスに比べると遅くなります）、今のところはおおむね問題なく運用できているため、日レセクラウドもようやく普通に使えるようになったというのが今のところの雑感です。

特に日レセクラウドをUbuntuクライアントで運用してみたい場合は、（地域にもよりますが）弊社にご相談ください。

Ubuntu 18.04 LTSと日レセクラウド�C push-exchangerの使用は有料

報告後半年経っても�Bの不具合が修正されないので、push-exchangerの使用を検討することにしました。
帳票データ取得APIを使用すると、クライアントアプリケーションとは無関係に印刷できるようになるので、この問題を回避することができます。

以前より基本的な挙動については検証済みだったのですが、より本格的に使用するべく検証を重ねていきました。A5の帳票は主に処方箋・領収書・明細書ですが、明細書に関しては帳票プラグインにはA4のサンプルしかないものの、A5になるように改変し、うまく印刷できることまでは確認しました。ただし網掛けには非対応なので（そもそもAPIで返ってこないのでどうしようもない）実用性があるかどうかは確認が必要です。

デモ環境ではひととおりうまく動くようになったで、本番環境でも実際に適用しないにせよpush-exchangerの接続テストくらいはできるので、やってみるとどうもAPIの使用が必要そうに見えます。
そこで確認を取ってみると、やはりpush-exchangerでの印刷はAPIの使用が必須で、現在は無料のプランを使用しているのでAPIを使用しないプランになっています。ということは有料のプランに変更する必要があるとのことでした。

もともとglclient2の不具合からpush-exchangerの使用を画策したものの、それが有料というのはいくらなんでもあんまりではないかと強く抗議をしたら、優先して不具合の修正をしていただけるというご連絡をいただきました。そして、先日修正されました。

Ubuntu 18.04 LTSとオンライン請求のIP-VPN接続

Ubuntu 18.04 LTSでの納入も増えてきて、オンライン請求を同OSから行うこともまた増えてきました。

オンライン請求のOS変更届を提出し、送られてきたCD−ROMにあるIP-VPNの設定マニュアルを読むと、pppoeconfを使用するのが前提になっています。
Ubuntu 16.04 LTSではNetwork Managerを使用するのが前提になっているので、ユーザビリティが大幅に低下しています。

理由がよくわからなかったので調査してみると、Ubuntu 18.04 LTSのNetwork ManagerではIP-VPNに必要なPPPoE接続の設定はGNOMEの設定画面からはできないがnm-connection-managerを使用するとできるものの、接続や切断に関してはGUIから行えないということがわかりました。

ただしnmcliコマンドからは接続や切断ができます。ということでpppoeconfよりはいいだろうということで、シェルスクリプトを用意してnmcliコマンドを叩いてIP-VPNに接続できるようにしました。

現在PPPoEを使用しているかどうかはわかりにくいため、YADを使用してPPPoEの接続中はステータス欄にアイコンを表示するようにしました。

ほかにもいろいろと工夫をしてより簡単かつ確実にオンライン請求を行っていただけるようにしましたが、それはまた別の話です。

Ubuntu 18.04 LTSと日レセクラウド�B 用紙サイズがA4になってしまう！

これですべての問題が解決したのかと思っていたら、そうではありませんでした。
クライアント印刷をすると用紙サイズが必ずA4になります。すなわち処方箋や領収書などA5の帳票を印刷してもA4になってしまいます。

これは困りました。特にワークアラウンドも思いつかなかったので（OSCより提示されたものもありますが現実的に運用が不可能でした）、monsiajと併用していただくことになりました。ご存知のとおりUbuntuでmonsiajを使用するのは非常に強い制限があり、正直かなり使いにくいです。
即座に現象の報告を行い、バグ登録されたようですが、その後進捗はないようです。

これはクライアント印刷の問題であり、日レセクラウド云々は無関係なので、今まで誰もglclientでクライアント印刷を行った人はいないということなのでしょう。
オンプレミスであればそれで問題ありませんが、クラウドだとクライアント印刷必須なので、修正されないのはすごく困ります。いよいよとなったら帳票データ取得APIを使用して印刷することも検討しなくはいけないのでしょうか。こちらはクライアント印刷ではないので影響を受けないことはわかっています。

一刻も早い修正を望んでいます。

Ubuntu 18.04 LTSと日レセクラウド�A 印刷ができない！

時期的に日レセクラウドのクライアントをUbuntu 18.04 LTSにすることにし、検証していくと印刷（クライアント印刷）が全くできないことに気づきました。

ログを見てみると、どうもSSLで通信できていなさそうだったので、関連ライブラリというかpanda一式をビルドし、検証してみたものの特に動作に変わりなく、これはUbuntu 18.04 LTSのライブラリによるものだなと判断してOSCに報告しました。

するとほぼ見立てどおりで、4月8日にアップデートがリリースされました。迅速な対応でありがたかったです。

同時に、他にはUbuntu 18.04 LTSで日レセクラウドを納品したところはないのだなということを知ったのです。

Ubuntu 18.04 LTSと日レセクラウド�@ L2TP/IPsec

しばらく放置していましたが（そして読んでいる方がいるとは思えないのですが）、よーーーやく少し時間ができたので、表題の件に関して数回に分けてお届けします。なお一部フィクションも交えていますがおおむね実際に体験したことで、ありがたいことに現在日レセクラウドをお使いのお客様をサポートしております。

日レセクラウドのセキュリティは過剰とも思えるほどに強固で、VPN+SSL認証となっています。VPNはルーターとソフトウェアから選択でき、後者は技術的にはL2TP/IPsecです。

L2TP/IPsecは広く普及しているVPNでお使いの方も多いでしょう。Ubuntuでももちろんサポートされているのですが日レセクラウドのUbuntu用設定マニュアルを読むとstrongswanとxl2tpdを直接使う方法が紹介されており、もうこの時点で心が折れてしまうような気がしています。

GUIのフロントエンドとしてNetworkMananger-l2tpがあり、Ubuntuのリポジトリにもパッケージがあります。

これで設定や運用が格段に楽になり、またNetworkManagerがフロントエンドになるということはnmcliコマンドも使用できるようになり、スクリプトを書けばログイン後自動的にVPNに接続してglclient2を起動する、なんてことができるようにもなります。

設定にコツがいるのと、過去に一度だけよくわからない動きをした（設定があるにもかかわらず接続できない）ことがあることが懸念事項でしょうか。ちなみに設定を削除して再設定すれば接続できるようになり、以後は起きていません。

あとNetworkManagerにバグがあり、VPNに接続して切断すると名前が解決できなくなります。この回避策が有効です。

SSL化

遅すぎる気もしますが、appcel.jpのSSL化を行いました。
ただし一部外部リンクを使用しているページもあり、そちらは不完全なものになっております。

さくらのレンタルサーバだと簡単にLet's Encryptを設定できるということで、そちらを使用させていただいてます。
企業サイトならSSLの証明書を買ったほうがいい気もしますが、ひとまずということで……。

フレッツ光プレミアムファミリータイプからフレッツ光ネクストマンションタイプに変更

この度、社内のインターネット回線をフレッツ光プレミアムファミリータイプからフレッツ光ネクストマンションタイプに変更に変更しました。
弊社の状況の特異な点としては、まずビル内で唯一外から回線を引いていたことです。理由は非常に単純な話で、入居した際はビル内にインターネット回線は引かれておらず、入居後に敷設されました。
あとはISP（ぷらら）で固定IPアドレスオプションを契約していることです。弊社はリモート接続にSSHを使用しており、セキュリティを保つためにTCP Wrapper（いつまで使えるのかわかりませんが）を使用してSSHデーモンへのアクセス元を制限しています。
ぷららが独特なのかどうかは知りませんが、固定IPドレスオプションで割り当てられているIPアドレスはちょっとしたことで変わってしまいます。一度ファミリータイプからマンションタイプへの切り替えを大家に打診されたことがありますが、ぷららに問い合わせたところ、そのプラン変更でも割り当てられるIPアドレスは変わってしまうということでその話は流れました。

現在NTT西日本はフレッツ光プレミアムからフレッツ光ネクストへの移行を進めており、弊社もこの流れに乗らないわけには行きません。最初はフレッツ光プレミアムファミリータイプからフレッツ光ネクストファミリータイプへの移行であれば固定IPアドレスが変わらないと認識していましたが、ぷららに問い合わせると変わるということだったので、では一念発起してフレッツ光ファミリータイプからフレッツ光ネクストマンションタイプに切り替えるということになりました。

問題はいかにスムーズに移行するかで、弊社でサポートしている殆どのお客様のところにログインし、固定IPアドレスを変更する必要があります。しかし、切り替え後だと新しい固定IPアドレスはわかるものの古い固定IPアドレスは失われてしまうため、リモート接続できなくなってしまいます。よって、ここで一計を案じることにしました。

新規にアカウントを取得すると事前に固定IPアドレスがわかります。そしてぷららは申し込み月は無料なため、月初に申し込みをして回線切替日までに殆どのお客様のところにログインしてTCP Wrapperの設定を変更し、回線切替日に新しいアカウントで接続し、古いアカウントを解約することにしました。また運がいいことに、キャンペーンで現在のアカウントが有効なうちはずっと月額800円（税抜）割引になります。

これだと古いアカウントの解約を忘れなければぷららの料金は1アカウント分のみかかることになります。フレッツ光ネクストはマンションタイプにするだけで月額料金が下がります。もちろん古いアカウントが生きているうちにTCP Wrapperの設定を追加しておけば新しいアカウントになっても引き続きリモート接続が行えます。すなわち余裕を持って移行作業ができ、余計な費用は一切かからないどころか、来月から固定費用の削減が可能になりました。

今月25日に切り替え工事が行われましたが、これといった問題はありませんでした。ヤマハのルーターの機能でVPN接続しているお客様のところへは即座には繋がりませんでしたが、工事完了後4時間ほどで自動的に再接続したようです。事前にリモート接続できなかったお客様も1件だけありましたが、それは全く別の理由でした。

というわけで、回線の大幅な変更であってもスムーズに行えるケースはあるというお話でした。

NEC MultiWriter 5300の検証

NEC MultiWriter 5300をお借りすることができたので、検証してみました。Ubuntu用のドライバーは存在するばかりか、ソースコードも公開されており、自分でビルドすることもできます。

機種的には富士ゼロックスDocuPrint P350 dのOEM版です。

検証してみたところ上位モデルの給紙枚数を少なくしただけで、それ以外は同一のハードウェアのようでした。なお5500に512MBのメモリーを増設し、PostScript 3をサポートするためのドーターボードを載せると5500Pになるものと思われます。

というわけで、安価ながらも上位モデルに匹敵する高速印字が可能で、しかもドライバーのソースコードは公開されているというかなりいいプリンターだという印象です。欠点はトナーの容量が小さいところでしょうか。

シェルスクリプトから日医標準レセプトソフトAPIを叩く

先日ORCAカンファレンス2016に参加してきたのですが、今後はデータベースから直接データを取得するのではなく、APIから取得してくださいと言われたので、シェルスクリプトからでもできるのか挑戦してみました。

ここでの例は、ORCAサーバーのホストがlocalhost、ポートが8000、ユーザー名がormaster、パスワードがpassword、患者番号は000001です。

APIはGETメソッドで取得できるため、curlコマンドが使えそうです。また、結果はXMLで返ってくるため、xmllintコマンドで必要なデータを抽出できそうです。xmllitコマンドはlibxml2-utilsパッケージに含まれているため、最初にインストールしてください。

まずはHTTPヘッダーを確認します。次のコマンドを実行します。

$ curl -X GET 'http://localhost:8000/api01rv2/patientgetv2?id=000001' -I -u ormaster:password

次の結果が返ってくれば成功です。

HTTP/1.1 200 OK
Date: Tue, 05 Jul 2016 05:46:43 GMT
Server: glserver/1.4.9
Content-Type: application/xml
Content-Length: 2500

HTTPのステータスの意味を解説したりはしません。

いよいよ患者情報のXMLを取得します。

$ curl -X GET 'http://localhost:8000/api01rv2/patientgetv2?id=000001' -u ormaster:password -o patient.xml

取得したXMLをpatient.xmlとして保存しています。

patient.xmlの中身を確認します。

$ xmllint --shell patient.xml

シェルの使い方はman xmllintで確認してください。

いよいよ患者氏名を取得します。

$ xmllint --xpath "/xmlio2/patientinfores/Patient_Information/WholeName/text()" patient.xml |nkf -w80 --numchar-input

何故か結果がUnicode文字参照で返ってくるため、nkfコマンドでUTF-8に変換しています。nkfコマンドはjma-receiptがセットアップされている環境であればインストールされているはずです。

UbuntuでBrother HL-5450DNを使用する場合の設定について

Brother HL-5450DNは安価でPostScript互換のPDL(ページ記述言語)にも対応しており、Ubuntuでも使用しやすいプリンターです。

しかし、印刷システム(CUPS)には決まったPPDが存在せず、デフォルトではPCLを選択しますが、これにするとトレイの切り替えができないなど非常に不便です。

かといってGeneric Postscript PPDでは印刷できず、Generic PDF PPDでは用紙いっぱいに印刷されず縮小されてしまいます。

いろいろ検証した結果、HL-5250DNのBR-Script3がベストであるということがわかりました。他にもBR-Script3のPPDはあるのですが、日本で使われるB5サイズに対応していないなどの問題があります。

設定方法は[新しいプリンター]で[AppSocket/HP JetDirec]を選択し、HL-5450DNのIPアドレスを入力します。[DNS-SD経由]だと名前の解決ができないことがあるため、IPアドレスを入力するのが無難です。



入力後[進む]をクリックして[ドライバーを選択]に移り、選択されている[Generic]を無視して[Brother]を選択し、[進む]をクリックします。



[モデル]を[HL-5250DN]にし、[Brother HL-5250DN BR-Script3]が選択されていることを確認して[進む]をクリックしてください。



あとは任意に設定すれば、HL-5450DNから印刷できるようになります。

Ubuntu 14.04 での日本語入力の問題を解決

……したつもりです。

Ubuntu 14.04での日本語入力システム（インプットメソッド）はIBusとFcitxの両方をサポートしています。

そしてFcitxで納入したところ、タイミングによっては英語キーボードになってしまうという問題が起こりました。Fcitxで解決を試みたものの、どうやっても14.04では無理ということになり、IBusでなんとかできないか検討することにしました。

IBusの問題はなんといってもプロパティパネルで、前述の指示に従って常に表示すると見にくく、また鬱陶しくてしょうがありません。

というわけで、IBusを1.5.10までアップデートし、いくつかのパッチをcherry-pickし、更にソースコードを改変することによって以下の表示になりました。

ポイントは、
1. プロパティパネルは常時表示
2. ただし右下に表示
3. 左側のハンドルの色を濃くし、どこをつかめばいいのかわかりやすく
4. 表示位置は解像度1024x768でいい感じの位置に表示するように
の4点です。

まだ納入はしていませんが、これで万事うまく行けばいいのですが。

RICOH SP 3610検証

リコージャパンさんからRICOH SP 3610をお借りすることができたので、検証してみました。

スペックをよく読むとわかるのですが、出力形式(PDL)が「PCL6、PCL5e」という汎用的な形式なので、Ubuntuでも印刷できるのではないかと思ったのがきっかけです。

結論から言えばGenericなPPDで印刷できたのですが、それはA4とB5だけであり、A5ではどうやっても印字できませんでした。
しかし、とあるところから入手したPPDを使用すると、何事もなかったかのようにA5でも印字できました。

どこから入手したPPDなのかは道義的に秘密にしておきますが、ライセンス自体はGPL2なので再配布はできます。が、やはり道義的にやめておくことにします。

ファーストプリントも速く、61枚のレセプトを3分かからず印刷してしまうため、速度的にも問題ありません。トナーや保守料も安く、2000枚/月ぐらいの印刷枚数であれば充分に実用に達するのではないかと思いました。
リコーの当日出張修理サービスが受けられるのも魅力的です。

リコーオフィシャルPPDがリリースされるといいのですが、現状OS Xにも非対応のようなので難しいかもしれません。

jma-receipt 4.8.0にバージョンアップしているけど自動化できなくて辛い話

jma-receipt 4.7のバージョンが9月でサポート終了ということなので、4.8へのバージョンアップ作業を進めていますが、これまでのバージョンアップだとわりとシェルスクリプトを書いてバージョンアップ作業を自動化することができていましたが、4.8ではそれが難しいという話です。

まずはCLAIM関連のアップデートですが、これは本来4.8.1などをリリースして対応するべき問題であり、どうしてそうしなかったのかがよくわかりません。考えて30秒でわかることをしないというのは何らかの理由があるのでしょうけど、せっかくの強力なパッケージングシステムが非常にもったいないです。
ただ、これは自動化できないこともないです。

続きましては薬剤情報の画像をデータベース内に持つための操作ですが、これは
$ sudo -u orca psql -At -c "select count(*) from tbl_yakujyo;" orca
で確認しています。/usr/lib/jma-receipt/bin/medphoto_store.shでもやっていることですが、0が返ってきた場合はスキップしています。

定点調査設定ファイルも同様で、これは/etc/jma-receipt/das-upload.dがあるかないかを確認しています。/usr/lib/jma-receipt/bin/dasconf_store.shでやっていることとはちょっと違いますが。

診療会計テーブルのデータ整合はどうにもならないので手作業でやっていますが、当然作業漏れもあります。
作業漏れ無しで作業するのはとても難しいことなので、漏れても致命的にならないように対策することにしましたが、やはりスクリプト化して一律の作業になるようにしたいなというのが個人的な願望です。

社内の検証用PCを刷新しました

弊社のORCA検証環境は、実は創業前から一貫して同じでした。
mini-ITXなどという規格ができる前の小さなマザーボードを搭載し、5インチベイが複数あるキューブ型PCにハードウェアRAIDであるARAIDを使用していました。
なにせ古いものなので、HDDは80GBクラスのIDE HDDでした。ただ、トレイごとHDDを交換できるので、検証用としてはとても便利でした。近年はRAID機能を使うことはほぼありませんでした。

流石に古くなりすぎまして、CPUはなんとかAMD64対応だったものの、メモリが1GBしか積めないのでUbuntu 12.04の動作すらおぼつかなかったのです。

そこで検証用PCを新調することになったのですが、仮想マシンとして複数の検証環境を同時に動かすのが今時ですし、であれば大容量のSSDを積めばディスクIOを気にしなくても良くなりますし、2.5インチSSDが入ればいいので筐体も小さくできますし、値は張るもののメモリも16GBくらいなら積めます。
というわけで、以下の構成になりました。
・ベアボーン…Mini PC Intel NUC Kit NUC5i5RYH
・メモリ…W3N1600Q-L8G
・SSD…CT500MX200SSD1
・ミニHDMI変換…AD-HD07M

検証環境は今まで使用していたものをVirtualBoxのVDI形式に変換し、zerofreeコマンドを実行してから"VBoxManage modifyhd hogehoge.vdi --compact"を実行するとファイルサイズが劇的に小さくなりました。おおむね1/3以下です。
仮想マシンのメモリの割当は2GBになり、またCPUのコアの割当も2個になったので今までよりも格段にパフォーマンスが向上したうえ、5個くらいであれば余裕で同時起動できるので、検証環境をガチャガチャ切り替える必要もなくなり、とても便利になりました。