Just another PHAZOR Blog
前回の記事で触れた「画像サーバー」は、結局、DolphORCA AudioVisual Server として独立させた。
その時はあまり触れなかったが、独立させていい点はデータ構造がすっきりすること。
現状だと電カルの文書系と画像系は、データ構造の点で相性が悪い。
『なぜ全国統一カルテは無理筋なのか？』あたりを参照。
で、当然、視野に入ってくるのが、DICOM 系の画像をどうするか？ということ。
個人的には X-ray 程度の簡単なダイコムなら、電カル自体がパースして表示させてもいいんじゃないかと思っている。
参考にと dcm4che のリポジトリを漁る。
今までよくわからなかったのだが、arc-light が PACS サーバで他のリポジトリはツール群のようだ。
arc-light は現状だと JakartaEE には対応していないようなので、あまり参考にならず。
参考にするなら、ツール群の方かなあ。
WYSIWYG な html のエディタを作成すると、やはり、画像などのアップロードと画面への挿入などの機能も欲しくなる。
P 欄を検討するとか言ってたが、結局、こちらを先に手をつけた。
現状だとこんな風になっている。
JavaScript などは「なんとなく」使う程度だったのだが、見様見真似でなんとか作成。
大半の「JavaScript でアップロード画面を作ろう！」的な記事は、本当にアップロード画面の作成のみですね (^^;)
たぶん、面倒なのは、それを適当なサーバーに投げて、永続化、さらにそこから（API を介して）復元・再利用できるようにするところじゃないかと思うんだが？
ところで、画像などのデータを通信するとき base64 でエンコードして送るか、そのままバイト列で送るかが悩ましいところ。
今回は、バイト列で通信させることとした。
クライアント（ブラウザ）からバイト列を投げた時、引き受けるサーバは、まずフロントエンドなのだが、これをバックエンドにそのまま送るか、あるいは、別に画像サーバのようなものを立てるかも考えどころ。
諸々の事情で画像サーバーを立てた。
だから例えば
http://localhost/DolphORCA-av/resources/image/1 にアクセスすると id=1 の画像を返してくれる。（実際はバイト列を返しているんだが）
なんでこのように画像を動的に生成する必要があるのかといえば、いわゆる一般のブログのように、表示させている html ファイルの同階層に img というフォルダを作り、そこから静的な画像ファイルを引っ張ってくる、みたいなやり方だと、原則、この画像は全世界に垂れ流しになってしまうから。
広報目的のブログならこれでいいが、医療情報系のシステムでこれはいかんでしょ。
以前に動画でごちゃごちゃ言ってたのは、このこと。
DolphORCA に遊びで病棟マップも追加。
むろん、患者名クリックでカルテ記載画面に遷移する。
在宅（訪問予定）のページも追加。
もちろん、これも患者名クリックでカルテ記載画面に遷移する。
思うに、カルテ自体に外来/入院/在宅の区別させる必要はなく、それを管理するクラスを設定すればいいだけだと思うのだが、なんか不都合あんのか？？？
猪股弘明
関係者の怒り方が半端なかったため、やむなく投下。
まあ、ちゃんとソースコードにあたって検証していれば、間違えないところですからね。
にもかかわらず、あたかも自分がオープンソースの代表者のように振る舞うのはどうなんだろう？
オープンソースに関わられている方には一読をおすすめします。
本日の外来は２人、粛々と診療。。
ということではなく、ORCA というレセコンから受付情報を取得、サーバプログラムで扱えるか試してみた。
第一、私は内科医でもなんでもないし、スマフォでカルテ入力する医者がいたら怖い。
最近のウェブ周りの技術の進歩は著しく、適当なライブラリを組み込むだけで、各種情報をスマフォらしく表示してくれる。
「スマフォらしく」とは書いたが、いったん組み込んでおくとタブレットでもPCでもその画面幅に応じて適宜デザインをよしなに調整してくれる。例えば、外来待受画面の「秋場 太郎」さん（もちろんテスト患者）をクリックするとカルテ記載画面に遷移するが、そのPC表示は以下のようになる。
メニューバーが変化しているのがわかるだろうか？
こういった細工がライブラリを組み込んでおくだけで実現できるので、とても便利だ。
実際、コーディングに要した時間は、２-３時間程度。
少々、脱線したが、こういった便利な道具があるおかげで、どちらかといえば、どういうデータ構造にしたらいいか？と考えを巡らせていた時間の方が遥かに長い。
今回は時間が取れたせいか、シンプルで使いやすい設計になったような気がする。
この手の設計で、おそらく、一番簡単なのは、国民一人一人に ID を振り。。。ということなんだろうが（将来的には国もそうしたいんだろうけど）、現状だとそれではやり過ぎなので、従来通りの施設 id とその施設が用いる患者 id の組み合わせでユニークな識別子とした。
具体的には、
施設 A( 施設id=10000) で 患者id=00001 に秋場さん
施設 B( 施設id=10001) で 患者id=00001 に秋場さん
がいた場合、このままだと患者id だけでは両者を識別できないので、通常、複合キーという手法を使う。
施設 A の方の秋場さんを表現するのに 10000:00001 という表記を採用すると、これは 10001:00001 と区別できるのでユニークな識別子となるわけです。
この複合 ID から、再度、元の二つの id を取り出したければ、
String[] cid = ID.split(":");//ID: 複合 ID
String facilityid = cid[0];// 施設id
String patientid = cid[1];// 患者id
などとするわけです（上は Java で書いた場合）。ちなみに OpenDolphin もこの方式を採用してました。
レセコンが単施設にしか対応していなくても、電カルの方で多施設対応にできているのは、こういう小ワザを使っているからです。
でも、将来的にはどうなるんでしょうね？
興味深いところです。
猪股弘明
精神科医
OpenDolphin-2.7m 開発者