投稿日:

OpenDolphin HTML/PDF Viewer プロジェクト

 

はじめに

以前に Save the DolphinS というプロジェクトをやっていた。

OpenDolphin という電子カルテは、データ構造に癖があり、カルテ記載内容の抽出ですら、それなりに難しい。
そのため Save the DolphinS では、データベースに直接アクセスしてデータの抽出を行うソフトの作成を行なっていた。ソフトは -味も素っ気もない言い方だが-「データ移行ツール」と呼んでいた。

「データ移行ツール」は dolphin データベースに直接アクセスして、一応

・カルテ記載内容全履歴→プレーンテキスト（画像などの特殊タグ付き）＋画像など

・カルテ記載内容全履歴→ rtf 形式ファイル（画像などの特殊タグ付き）＋画像など

に抽出するところまではできていた。（どういうものだったかは『電子カルテからの患者データの吸い出し』あたりを参照してください）

OpenDolphin 本体はおろかアプリケーションサーバである WildFly がなくてもデータベースさえ活きていれば、このソフト単体で動作してデータ抽出が行えるのでそれなりに重宝していた。

ただ、これだと、データを他のシステムに移行する場合には便利でも、たとえば保管はしておきたいが閲覧だけでいいという場合、視認性の面で今ひとつの感は拭えない。

何かうまい解決方法はないかなと思っていたのだが、ひょんなことから移行ツールの出力を html 形式で書きだせばいいことに気がついて、ソースコードを改変して試してみたところ、まずまずうまく動いた。

細かいところでさらに修正したいところはあるのだが、例えば、以下のカルテ画面（↓）

を、html 形式で書き出すとこんな感じになる。

 

２号用紙風のレイアウトやフォントの属性、画像の添付位置までほぼ完全に再現されていると思う。

データ抽出というコンセプトは同じでも、（移行を考慮して）データをテキストと画像などに分離させて出力するのと（閲覧性を重視して）それらをを html にまとめるのは、使用目的の点で微妙に異なる。

また、この機能を移行ツール内に同居させておくのは、ソースコード管理の面でも何かと不便だ。

そこで、この機能を分離させ、単独のソフトとして独立させることにした。

今後はこちらを

OpenDolphin Viewer
OpenDolphin HTML Viewer
OpenDolphin HTML/PDF Viewer （PDF 出力にも対応したため改名）

と呼ぶことにする。

 

開発グループを代表して
猪股弘明

背景色を変更

実務的にはまるで意味がないのだが、白背景は味気ない気がするので背景色を OpenDolphin 特有の薄い緑（ dolphin’s green というのだそうだ）に変更。

ドルフィン感が強くなった。

 

レスポンシブ対応

最近のウェブデザインは凝っていて、ブラウザの横幅を変更するとレイアウトを自動で調整してくれる。レスポンシブデザインなどというようだ。
この仕組みのおかげでPCのブラウザでもスマフォのブラウザでも、それなりに「見れる」レイアウトになっている。
これを狙って CSS を若干修正。

通常時がこうだとすると

ブラウザの横幅を縮小させるとある値（ブレークポイント）を境に右のいわゆる P 欄が左（SOA欄）の下に回り込む。

スマフォで閲覧することなどないかもしれないが。

 

P 欄（カルテ右半分）の検討

これまで、カルテの右半分（P 欄）は文字情報だけ抜いてきたが、実は処置・薬剤のレセ電コードも抜ける。

まだ、うまくまとめきれてないのだが、かなり雑にデータを書き出すとこんな具合になる。

赤枠で囲んだ部分が処置や薬剤の識別子（コード）で、その多くはレセ電コードと同一なはずだ。

実運用としては、ドルフィンから処置内容を ORCA に送った際に、この情報を受け取った ORCA はこれらコード番号に基づいて保険点数や窓口負担額を計算し、最終的にはレセプトに反映させている。

病院のシステムを入れ替えた際に、このコードが引き継げなくて処方内容を一から打ち込むことがよくある。とても負担だ。

本プロジェクトはデータの「閲覧」を強く意識しているが、上記の点に留意し P 欄に関しては若干レイアウトを崩してもこれらコードが表示できるようにしたいと考えている。

P 欄（カルテ右半分）の検討（続き）

通常 P 欄に記載される内容は、診断料や処方のほか各種検査のオーダーなどもある。
だから、まずドルフィン元カルテをこんな風にした。

カルテ左の SOA 領域よりも難しいのは、項目毎に処理を変えなくてはいけない点。

ここら辺、工夫してコードを修正。
現状だとこのようになっている。

プロトタイプとしては、十分な出来だろう。
なお、レセ電コードは、某所で聞いて見たところ「あったほうがいい」ということだったので、多少元カルテの表示と異なってくるが、表示させることにした。

また、この改変を機に元の OpenDolphin のコードは全て削ぎ落とした。
単純に表示させるだけなら、

dolphin データベース >> 読み込み >> オブジェクトの生成 >>
適当に修正して html 用に変換 >> 書き出し

とやった方が楽なのだが、P 欄に関してはレセ電コードを打ち出せるようには構成されていないので、結局、ここら辺のコードは全て廃棄した。
（SOA 欄は特殊タグを表示させる関係上、移行ツールの頃から使っていない）

html → PDF 変換

ところで、OpenDolphin の標準のカルテ画面の PDF 文書作成機能は、文字などもベクトルデータに変換していわば「画像」として PDF を生成しているようだ。
Mac の場合、フォントの関係（物理フォントと論理フォントというものがある）でデフォルトでは文字化けしてしまう。

そちらの修正はひとまずおいて、html → PDF 作成ができないか検討。

あれこれやっていたら、以下のように
フォント埋め込み形式の PDF が生成できた。

データ移行に関する厚労省の見解

実は、公式な文書はない。

ガイドラインの要請からして

・カルテ記載の文字情報や診断の根拠となったような画像の類

・処置内容の文字情報

・修正履歴や途中経過版

は最低でも移行しなければならないでしょう。

口頭でもそれっぽいことは言っていた。

現在、問い合わせ中です。→結局、明確な回答は得られず。

「最近、安全管理に関するガイドラインを公開したので、そちらを見ていただいて・・・」というような感じでお茶を濁そうとする。

「これだから、日本の医療 IT は」と思わないでもないが、文句を言っても始まらないので、ガイドラインに目を通す。

『医療情報システムの安全管理に関するガイドライン 5.2 版』というのがそれのようだ。

んー、しかし、これ、（例の半田病院の件を受けてだろうが）従来の電子カルテの３要件などの基本的要件に加えて、さらにシステムには医療記録のバックアップの仕組みを付け加えなさいよ、と言っているだけのような？

本当に知りたいのはバックアップ時に書き出す情報の種類や質といったことなのだが。

ただ、以前に比べれば、要求は具体的にはなってきた。

ポイントとなりそうなところを抜き出しておく。

1.バックアップサーバ
システムが停止した場合でも、バックアップサーバと汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読できるようにすること。

2.見読性確保のための外部出力
システムが停止した場合でも、見読目的に該当する患者の一連の診療録等を汎用のブラウザ等で見読ができるように、見読性を確保した形式で外部ファイルへ出力できるようにすること。

3.遠隔地のデータバックアップを使用した見読機能
大規模火災等の災害対策として、遠隔地に電子保存記録をバックアップするとともに、そのバックアップデータ等と汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読できるようにすること。 

(p. 61)

今回の HTML/PDF Viewer に絡めて言えば、このソフトを使って定期的にデータベースからバックアップを取っておけば、上記の条件を満たしているのは自明だろう。
「汎用のブラウザを使って」とあるが、html を表示できないブラウザはあり得ないので、お釣りがくるくらい（なにしろ画像や処方薬の薬剤コードまで表示してくれる）条件をクリアしている。

一応、バックアップは取っておいた方がいいとは思うが、データベースさえ生きていれば、サーバが停止してもこの条件は満たしている。

ところで、なんで厚労省の役人がお茶を濁そうとしたのかわかるような気もする。
商用の電子カルテでも上記の条件を満たしているシステムは（現時点では）そうは多くないからだ。

病院の電カル・HIS の場合、半田病院や大阪急性期総合医療センターの件で明るみに出されたが、ガイドラインで推奨されている基準でバックアップシステムを稼働している施設はほとんどない。

開業医さん向けの電カルは、この点はかなり改善されてきて、

・CLIUS

・owel

などは、この機能が公式に提供されている。
いわゆる商用の電子カルテとは一線をかくすが、

・ダイナミクス

・OpenDolphin-2.7m （系列。今回、説明したバージョン。他の派生物に関しては完全に把握しているわけではないが、おそらくない）

も、こういった機能が充実している。

 

投稿日:

次世代型 HorliX

現行の HorliX を Mac AppStore からリリースしたのは、2018 年のことだから、かれこれ 5 年前のことになる。

売れ行きも評判も上々で気を良くしていたんだが、すぐに今も続く懸案事項が持ち上がる。

それは当時のアップルが打ち出した

OpenGL の廃止・Metal への移行

という方針だった。

HorliX に限らず、画像系のアプリはほとんど OpenGL に依存していたから、それなりの騒ぎになったことは覚えている。

幸い？すぐに廃止ということにはならなかったが（ちなみに、今でも OpenGL は使えている）、Metal が普及するにつれ、そのパフォーマンスの良さに「移行はやむなし」という雰囲気に変わってきたように思う。

私も、この方針が打ち出された直後、次期バージョンのことを思い浮かべた。

当初は、まずプラットフォームを Qt に移そうかと考えていた。
Qt はかなり早い段階から、Metal 対応を進めていたので、構想としては悪くなかったと思う。実際、試験的にプロトタイプも作成したりした。

ただ、どうしても本気になれなかったのは、HorliX を構成する膨大なライブラリ群もまとめて Qt で面倒をみなくてはならなくなることだった。

何か本質的でない気がした。

Metal への移行が思っていたより緩やかなことがわかってくると、アプリの Metal 対応は次第に考えなくなっていった。

ここ数年はそんな感じだった。

ところが、別件で画像処理関係で Metal を触ってみると、意外に扱いやすいことがわかってきて、HorliX 云々は別にしていくつか試験的なコードを書いてみた。

例えば、2D ビューア。

3D ビューア。

機能を豊富に盛っているわけではないが、最低限のラインはできているんじゃないかと思う。

当初は何かに使うという予定はなかったが、Metal による 2D や 3D 画像の取り扱いに慣れてくると、「これらを使って、次期 HorliX （PHORLIX と呼んでいる）できるのでは？」と思うようになった。

ここからの話は長くなりそうなので、いったん切ります。

 

投稿日:

Metal 関係覚書

たまにしか使わないので基本概念が抜けがち。

シェーダー

具体的には ***.metal ファイルがそれ。
頂点データと色の処理を決めているファイル。これだけだと有り難みがピンとこないが、実際にはこれが（並列処理可能な） GPU で処理される、というのがミソ。
このおかげで、頂点が増えれば増えるほど、効率的な処理ができるようになる。

なお、この時、使用される言語が MSL (Matal Shading Language)。

Metal は OpenGL とは違い、***.metal ファイルはビルド時にプリコンパイルされれる（.metallib というファイルが生成される）。OpenGL では実行時にコンパイルされるので、この点も高速化に貢献してそう。

 

投稿日:

Metal 公式サンプル

アップルが公開している Metal の公式サンプルで気になったプロジェクトなど。

CAMetalLayer 関係

CA というのがわからなかったが、Core Animation のことらしい。
興味深くはあるが、私はあまり使わないかな。

Ray Tracing と InterSection を組み合わせたプロジェクト

綺麗だ。。。

が、ここら辺までくると文字ベースの解説は一切なし。
動画はあるけど。

2D texture 関係

特にサンプルは挙げられていないが、取り扱うデータによって何を採用したらいいのか？みたいなことがこの記事に書いてある。

具体的なサンプルとしては、とりあえず

https://developer.apple.com/documentation/metal/onscreen_presentation/reading_pixel_data_from_a_drawable_texture?language=objc

https://developer.apple.com/documentation/metal/textures/creating_and_sampling_textures?language=objc

の二つをチェック。

前者は、ビルドするとこんなウィンドウが表示される。

ドラッグすると、ドラッグした領域をデスクトップ上にファイルの形で切り出してくれる。
MTKView 上でマウスの位置に応じてちょっと工夫した処理を行いたい、なんてときに使えるかもしれない。

後者は、これ。

 

かなり以前からある基本的なプロジェクトでした。

が、今から思うとこれはこれで使い道ありそう。

（続く）

 

投稿日:

Metal がよくわからんという人は公式サンプルから入るといいと思う

以前に「Metal 入門」という記事を書いたことがあるのだが、Metal 関係の情報は乏しいせいかネット上ではかなり参照されているようだ。

放置するのもなんなので、先日、Metal を仕様する際に出てくる「コマンド」に関して追記した。

そこで提示したサンプルは Objective-C にするのか Swift にするのか迷ったのだが、結局、Swift にした。

じゃあ、Objective-C ではどうやるのってのが本記事。

Objective-C で書かれたサンプルは本当に少ないが、Objective-C から Metal を使いたい人は公式にあるサンプルあたりから入るといいと思う。

お馴染みの三角形を描くサンプルもある。

ただし、同一プロジェクトに iOS と tvOS のターゲットも同包されているので、MacOS だけ取り出しておいた方がわかりやすい。

こんな感じになる。

以下、このサンプルに関して注意点などメモ。

MTKView の設定

View は MTKView にする必要があるが、Xcode の操作性がイマイチで、手動で MTKView に設定する必要がある。

ViewPort

ところで、今回のサンプルでは、ウィンドウのサイズを変えても描画される三角形の大きさは変わらない。

これは ViewPort を使うことで以下のように実現している。

内部的には、ウィンドウに何らかの変化が起こると delegate の以下のメソッドが呼び出されている。

/// Called whenever view changes orientation or is resized
- (void)mtkView:(nonnull MTKView *)view drawableSizeWillChange:(CGSize)size
{
    // Save the size of the drawable to pass to the vertex shader.
    _viewportSize.x = size.width;
    _viewportSize.y = size.height;
}

要するに実際のウインドウのサイズを ViewPort のサイズとして引き渡しているわけですね。

この情報はシェーダーで以下のように処理されている。

    out.position.xy = pixelSpacePosition / (viewportSize / 2.0);

Metal の使用する座標系を実際のウィンドウの大きさで割ることで、描画する図形の大きさを一定に保っているという理屈です。

単純に三角形を描画させたいだけであれば、頂点のデータは

    static const PHVertex triangleVertices[] =
    {
        // 2D positions,    RGBA colors
        { {  1.0,  -1.0 }, { 1, 0, 0, 1 } },
        { { -1.0,  -1.0 }, { 0, 1, 0, 1 } },
        { {    0,   1.0 }, { 0, 0, 1, 1 } },
    };

などと Metal 本来の座標系に準じて設定。
シェーダーも

    //out.position.xy = pixelSpacePosition / (viewportSize / 2.0);
    out.position.xy = pixelSpacePosition;

としてしまえば、三角形はウィンドウの大きさに従って変化します。

描画色に変化をつけてみる

私は試してないが、『シェーダーにランダムな値を送って動きをつける』あたりを参照して、改変するといいと思う。

ソースコードはこちらで。

回転させる、遠近処理をつける

詳しい解説はしないが、それなりの改変を加えると回転や遠近処理もできる。

その入り口くらいまではこちらの記事で軽く説明しています。
よろしければご一読ください。