今回の職場のシステムの入れ替えを機に、今使っているPythonマクロをごっそり更新する予定です。 その前に大まかな方針を整理しておきます。
稼働環境と開発環境
これまでの環境
稼働環境
OS: Windows 7 Pro 32bit
LibreOffice 6.0.7
バンドルPython: 3.5
LibreOffice6.0まではLibreOfficeを終了してもプロセスが生きていて(Zombie process)、わざわざタスクマネージャでそれそのプロセスを殺さないとLibreOfficeが再起動できない問題がありました。LibreOffice6.4にしたらこの問題は改善されていました。
イントラネットのファイルサーバーにマクロを埋め込んだCalcファイルを置いていましたが、LibreOfficeをインストールしたマシンがイントラネット内の一台だけだったので、 そのマシンにWindowsのリモートデスクトップで接続してそのマシンでCalcファイルを開くという面倒なことをしていました。
開発環境
OS: linuxBean14.04
IDE: Eclipse 4.6 PyDev 5.4
LibreOffice 5.2 -> 6.0
バンドルPython: 3.5
Windows版ではインポートできるPythonモジュールが限られているので、同様の制約を再現するためにPPAからインストールできるLibreOfficeではなく、LibreOfficeのページからダウンロードしてインストールしたものを使います。
IDEは最初は補完機能の充実したPyCharmを使っていましたが、コーディングに慣れてくると補完機能は動作が重くて足手まといになったのと、pydevdが有料版でしか使えなくてリモートデバッグができないので、Eclipseに乗り換えました。PyCharmでもVScodeでもデバッグエンジンはPyDevを使っていて、根本的な機能はどのIDEでも同じようです。Eclipseは、PyCharmと比較して無料でPyDevのフル機能が使えること、VScodeと比較してGitFlowがGUIで使えることが気に入っています。Eclipseの難点は、Gitリポジトリの構成がプロジェクト単位ではなく、プロジェクトのグループ単位なのでGitHubでの見え方が特異になっていることです。
Gitflowはコンフリクトが生じることがないように、常に1つのFeatureブランチで開発を行い、複数のFeatureブランチで並行しての作業はしないようにしています。 なのでFeatureブランチ名は単純にブランチを切り出した年月日時分にしています。常に直近の日時のFeatureで作業をすればよいわけです。開発の終わったFeatureブランチはロールバックとして削除せずに残してあります。
ちなみにOSも最初はWindowsでしたが、Windowsはデフォルトパスにスペースや括弧が含まれている上にOS自体非常に動作が重いし、とくにWindows10になって定期強制アップデートで勝手にいろいろ構成が変わってもう学習するコストが高すぎて普段使いのマシンはすべてLinuxに乗り換えました。
これからの環境
稼働環境
OS: Windows 10 Pro 64bit
LibreOffice 6.4
バンドルPython: 3.7
システム更新の機会に根回ししてイントラネット内の100台ぐらいのすべてのマシンにLibreOfficeをプリインストールすることに成功しました。事務系部門は「表計算ソフト」とか「ワープロソフト」ではなく「エクセル」とか「ワード」が必要なので、MS Officeを追加インストールするみたいです。全マシンにLibreOfficeが入ることになったので、今後はイントラネット内の各マシンからファイルサーバーにあるマクロを埋め込んだCalcファイルを直接実行できるようになりました。今後の課題としてはLibreOfficeのバージョンアップをどうやるかという問題があります。これまでのように5年ごとのハードの入れ替え時にバージョンアップすればよいと思ったのですが、次期システムはクラウド版なので、末端端末の一斉更新の予定はないみたいです、、、まあ前回の更新時もレセコンとカルテを分離したからカルテのGUIは今後変わらないですと言われましたけどね！それが今回の更新ではカルテがクラウド版になって大幅にGUIが変わったのに、レセコンは変更なしという逆の結果になっています。たぶんWindows10のサポートが終了する頃に一斉更新になるかと思います。
開発環境
OS: Bodhi Linux 5.1
IDE: Eclipse 2020-06 PyDev 7.7
LibreOffice 6.4
linuxBean14.04はもうアップデートされていないので、Bodhi
Linux5.1上で開発を行います。LibreOfficeとは関係ありませんが、Bodhi
Linux5.1のFirefox上で日本語入力の挙動が不安定です。KDE neonもちょっとマシですが、Firefox上での日本語入力はやはり不安定です。
EclipseもLibreOfficeもバージョンが新しくなっていますが、使い方はそう変わりません。この環境は LibreOfficeで動くPythonスクリプトを書くためのツールのインストール-p--qで構築しました。
OSは職場ではノートPCにインストールしたもの、家ではVirtualBoxのゲストOSにしたものを使っています。
運用しているLibreOfficeのPythonマクロ
ガントチャート集
私の仕事は病棟医(外来患者は診ずに入院患者のみを専ら診る医師)なので、ガントチャートには、薬剤や検査について各患者ごとに1枚のシートでチャートにしていきます。チャートだけでは情報不足なので、チャートシートとペアで病歴などを記入するサマリシートを使います。このペアを管理する一覧表のシートをドキュメントの表紙として使って、その一覧とマクロでチャートシートやサマリシートと連動できるようになっています。マクロはすべてドキュメントイベントで起動するようにしています。
本来このようなチャート機能は電子カルテに備わっているべきものと思いますが、現状の電子カルテはリレーショナルデータベース出入力のフロントエンドの実装で精一杯のようで、データベースへのデータ入力以外の機能は、AIどころかコンピュータでは簡単にできそうな便利な機能の実装も一向に進んでいる感じがしません。電子カルテには紙カルテ時代から存在する「熱型表」というチャートは実装されていますが、必要な項目だけを呼び出したり、順番を並び替えたり、項目の値を元に足し算引き算するとかも全く何もできません。表示も1ページ1週間単位しかできず、無駄に呼び出している項目が多いので、ページをめくるのにもちんたら待たされたうえに、ページをめくるたびに必要な項目を上下にスクロールして探して記憶しないといけないという非現実的な作業をしないといけません。前の週はどうだったかな、とか、さらにその前の週はどうだったかな、とかみて、今週にもどる、とかいう操作が頻繁にあるのですが、もう時間がかかりすぎて思考が途切れて仕方ありません。これが紙カルテに比べて電子カルテが劣る欠点である「閲覧性の欠落」というものです。結局紙に印刷して見比べないとよくわからないという事態となって、紙カルテよりも遥かに劣る手間と時間がかかるので、自前のガントチャートの作成はとても有用です。次期システムはクラウド型の電子カルテに変わるのですが、閲覧性はさらに劣るものになっている感じがします。現在のシステムはマウススクロールでページめくりができるのですが、クラウド版ではそのセッションでクリックして呼び出したものの間でしかスクロールできないそうです。Chromeのエクステンションでは先読みとかできないのでしょうかね、患者の状態が悪くて早く対処しないといけない事態では深刻な問題です。
当院で採用している電子カルテ以外で熱型表をカスタマイズできるパッケージがあるのか「電子カルテ 熱型表 カスタマイズ」でGoogle検索してみると当院で採用している電子カルテが一番上にでてきました、、、他にも「カスタマイズ」ができることをウリにしている電子カルテはいくつもでてきますが、電子カルテのパンフレットにある「カスタマイズ可能」というのは、単に納入するパッケージの「変更」であって、ユーザー(パッケージを購入する病院のことではなく、実際にパッケージを使用する各個人)が「カスタマイズ」できるという意味ではないようです。そのパッケージの「カスタマイズ」もカスタマイズの要望を聞いてから一から作っているような感じで、10年前に一番最初に導入するときは、ベンダーの説明があまりに拙く、これは架空の製品を売りつけられようとしている、と考えてもう紙カルテで続行しようと医師の間で意見が固まって、電子カルテの導入がキャンセルになりそうになったことがあります。当院とは違うベンダーの電子カルテですが、近隣の病院では導入後に医師のオーダー(つまり真のユーザーの使い勝手が悪かってこと)が急減して経済的な問題で運用中止して本当に紙カルテに戻っていました。その後再導入してそこにはNECの電子カルテが入っていました。病院用の電子カルテではNECや富士通、ソフトウェアサービスがメジャーベンダーになるようです。当院の電子カルテはファルコバイオシステムズのものです。これを最初に導入したのは、既存のシステム(検査システムとか画像システムとか給食システムとかさらにそれらで使っていた端末も再利用)の併存に柔軟に対応してくれたのが経営的に大きなメリットがあったようです。メジャーベンダーの製品と比べて足りない機能があるかもしれませんが(費用が桁違いに違うらしいです。20年前に在籍していた大学病院ではSEが24時間常駐して月2000万円払っていると聞きました。)、導入してからもできること(できないことも多いですけど)には柔軟に対応してくれるので、継続して使用しています。おかげで、今回全端末にLibreOfficeが導入できましたし。
電子カルテとLibreOfficeとのデータの移動はいちいちコピペでデータを移しています。データベースからリードオンリーで直接データを呼び出せないか聞いたことがありますが、現行のシステムでは診断書作成管理システム(MEDI-Papyrus)とか画像管理システム(PACS)とかいう外部システムに患者名やIDなどの基礎情報は渡せるようになっているものの、それに紐付いた臨床情報は一切渡せないとのことでした。 次期システムはChromeエクステンションで動くものなので、データベースに接続させてくれなくても、Chromeで表示されている画面からスクレープできるんじゃないかと思いつきました。拡張機能に翻訳ツールもあるくらいなので、表示されている内容の取得はできそうです(URLから読んでいるだけ?)。データベースに接続するようChromeから取得したほうが、電子カルテのデータベースの仕様変更に追随しなくてよいので汎用性が高そうです。
Develop Extensions - Google Chrome
拡張機能のインストールが制限されていなければ、chrome.pageCaptureのコールバックで実装できちゃいそうですね。そのうちやってみようかと思います。
(2020.11.19追記。クラウド版電子カルテの試験運用が始まりました。ダブルクリックが排除されてすべてコンテクストメニューからいちいちちっちゃい文字列にマウスカーソルを乗せて選択しないといけなくて操作手順も増えて使いにくくなったような気がします。パッケージソフトのはずなのにどうも明らかに挙動がおかしなところがあってベータ版を使っているような感じもします。それでも来週から本運用なので今日中にこれで来週からのオーダーを全部入力しなくちゃいけない、、、)
計算表
これは主に輸液(点滴などの注射)について混合割合や成分の計算をしたり注入速度を算出したりするものです。 現在はシート関数で実装してますが、次回はこれをなんとか上記のガントチャートに含んでしまいたいと思っています。他に検査値を元に指数を計算するものとか参考文献へのリンク集を含んだシートもありますが、現在は手動で作成したもなので、マクロで更新できるようにする予定です。
褥瘡評価表
これは治療のためではなく、純粋に診療報酬のためのものです。
このPDFファイルの19ページ目にある褥瘡対策加算の算定要件になっている、褥瘡評価表(別紙様式46)を作成するためのシートです。あまりにも煩雑な作業なので、急遽マクロを書いて運用しています。バグだらけなので根本的なアルゴリズムの再考が必要です。
褥瘡評価表は、療養病棟で各褥瘡について毎日DESIGN-Rという方法で点数をつけてそれを過去3ヶ月分と比較したものです。この点数が悪いと病院がもらう治療代が1/3に減らされます。 このDESIGN-Rというのは日本褥瘡学会が編み出した独自の方法で、多数の褥瘡の要素を分析して各要素について重み付けして点数を定めたようですが、数学的な重み付けで算出された35種類もある点数を記憶するのは不可能です。事務作業はクラークに移行させるとかして減らしていこうとかいいながら、解析用の点数を臨床現場で毎日採点させて、合計とか最低点とか計算させるとか、何をしたいんだか。
当時電子カルテとか褥瘡管理ソフトとかの会社のいくつかあたってみましたが、この点数表を実装している製品がないどころか、その制度すら知ってる会社をみつけられなかったので、自作マクロで対応するしかありませんでした。 次に導入する電子カルテでもDESIGN-Rの入力まではできるのに、その値を使って計算ができないという仕様になっていて、入力作業が無駄骨になるのでその機能は使えません。なぜあとひと押しができないのか、、、
ちなみに、日本褥瘡学会の褥瘡予防・管理ガイドライン（第4版） にはDESIGN-Rで治療方法を選択・実施するって書いてありますが、どの点数で具体的にどうするかは書いてありません。そもそもDESIGN-Rの定義のページには急性期で使用するツールではないと書いてあって、褥瘡発生時からの指標には適していないようです。実際その通りと思います。
実際の治療方法の選択はこの色調分類を使います。皮膚科学会の褥瘡診療ガイドラインでは色調分類別の治療方法が具体的にいろいろ書いてありますが、現場ではシンプルにハサミとイソジンシュガーという、消毒液を砂糖に染み込ませた塗り薬だけで、黒から赤にもっていきます。
複式帳簿
これは私個人の会計のためのものです。1決算期1シートにして、行方向に日付、列方向に科目を入れて、単一シート上で貸方と借方を正負で区別して入力していくものを作りました。これで1シートにすべての会計データが載せられるので、決算時にそこからマクロで、仕訳日記帳、総勘定元帳、決算書を作成していました。しかし、データの元になる入力シートが横に長くて非常に入力しにくいし、スマホで入力できないので、今後入力はGnuCashを使うことにしました。GnuCashでは帳簿の作成機能が物足りないので、piecashを使ってGnuCashデータを読み取って、LibreOfficeに帳簿として書き出そうかと思います。piecashのためにバンドルPythonではなくシステムPythonを使わないといけません。これはWindowsでは無理なので、Linuxだけで使うようにします。
Pythonマクロ更新にあたっての課題
各マクロについていろいろ課題がありますが、すべてのマクロの共通する課題について列挙していおきます。
埋め込みマクロは一つのモジュールに統合する
ドキュメント内に埋め込んだpythonpathフォルダに.pyファイルを置いて、そのモジュール同士のインポートができるように、tdocimport.pyというツールを使っていましたが、異なるバージョンのマクロを埋め込んだドキュメントを同時に開くと先に開いたドキュメントのマクロだけが読み込まれるという問題が生じるので、複数のドキュメントを同時には操作できませんでした。
その対策としては、ドキュメントには一つのモジュールだけを埋め込んで、ドキュメント内のモジュールはインポートしなくていいようにします。コンテクストメニューからはCommandURLでマクロを呼び出さないといけないので、同じモジュール上の関数をマクロとして呼び出さないといけません。多分できると思いますけど。
「元に戻す」の実装
イベント駆動のマクロを駆使しているせいか、メニューから「元に戻す」を実行すると高頻度でクラッシュします。見て見ぬふりをしてきましたが、先週うっかり「元に戻す」をしてしまって、午前中に入力したデータをすべて飛ばしてしまったことがあったので、ちゃんと調べたらOOoBasic/Generic/Undo - ...?に UndoManager というのを見つけました。元に戻せないにしても「元に戻す」をしてもクラッシュしないように実装しようと思います。
ドキュメントを保存するタイミング
シートが70枚程度あるせいか、保存するのに結構待たされます。作業中に待たされると思考が途切れて嫌なので、自動回復情報の保存はオフにして、きりのいいところで手動で保存していましたが、保存を忘れてデータを飛ばしてしまうこともあるので、やっぱりどこかのタイミングで保存するコードを挿入しておきたいです。「操作を30秒以上する予定のないときに保存」とかしたいのですけど、そんな予測はできませんね、、、それこそディープラーニングの出番ですけど。sqlite3での保存のように入力しただけでさっと保存してくれる仕組みがほしいところです。
シートをアクティブにしたときは、そのシートに入力したいときなのでダメですし、保存中はシートは読めますがスクロールできないので、ガントチャートのシートを開くタイミングでもダメです。シートのデータをクリップボードにいれたあとは電子カルテにそれをペーストするので、保存するとしたらデータをクリップボードにいれたタイミングかもしれませんが、毎回そうする必要もないので、何回かに1回保存するようにしましょうか。
0 件のコメント:
コメントを投稿