投稿日:

PHAZOR.JP

ところで、本サイトのドメインは phazor.info で、そのトップページは英語表記になっている。

もともとは HorliX 案内用のサイトだったので、英語ページ作成が優先になったのは半ば必然なのだが、今の今までトップの日本語ページは存在していなかった。
日⇄英切り替え表示も考えなくもなかったのだが、一手間かかる。

その一方で、ここ数年、サーバープログラムも個人的には書いていて、ドメイン（hogehoge.org とか人間が認識しやすいサイト名）もまったくないサーバで実験みたいなことをたびたびおこなっていた。

この前、apache サーバを立てる機会があったのだが、「そういやこれ利用してウェブサイト作れるなあ」と思いつき、結局、ドメイン名も取得してこれを PHAZOR.INFO の日本語サイトとした。なお、ドメイン名は phazor.jp 。

具体的にはこちら https://phazor.jp/

もともとテスト用サーバだったのでサーバマシンのスペックはそれほどいいものではないし、今でもサーバプログラムなどを走らせていたりするので、それほど凝ったコンテンツは載せられないと思うが、デモ兼用のサイトとしてはちょうど良いと思う。しばらくは、そういった運用をしていくつもりだ。

本サイト同様、phazor.jp の方もよろしくお願いいたします。

 

 

猪股弘明
フェイザー合同会社代表

投稿日:

OHIF Viewer と Oviyam

Oviyam

HorliX 関係で dcm4chee-arc-light を触ったので（『HorliX と dcm4chee-arc-light を繋ぐ』参照）、ついでで dcm4che グループ？のブラウザ型 viewer Oiyam もインストール。

dcm4chee-arc-light とは別系統になり、独立して動作するということだったんですが、あれ？

ノーマルに tomcat にインストールしても、実運用するのに必要な設定画面とかは出てきませんね。

ソースコードも GitHub にはなくて、地味なサイトで SVN で管理されていたし、これは一体？？？

このままだと使い道ないかなあ。

OHIF Viewer

これではちょっと収まりつかないんで、最近、けっこう評判のいい OHIF Viewer も試してみる。

こちらは公式サイトのドキュメントもしっかりしているし、そこで示された手順通り作業を進めれば、しっかり「動く」ビューアーが立ち上がる。

今回は試さなかったが同包されている default.js あたりを修正すると、適当な PACS サーバーと通信できるらしい。

いわゆるサーバーサイド JavaScript の一つである node.js で構築されており、イマドキのウェブアプリって感じですね。

使用言語の統一性

じゃあ、今後は OHIF Viewer を何らかの形で使っていくのかといわれるとちょっと微妙ですね。

というのは、フリーで使える PACS やデスクトップ DICOM Viewer のほとんどが C++ か Java で書かれており、それらとの連動を考えた場合、node.js あたりで作成されたソフトとは相性が悪いんですよ。

改変前提で考えるとむしろ Oviyam の方が重要だったりします。

ここら辺は説明すると長くなりそうなので、またの機会に。

OsiriX/Horos/HorliX のデータ構造

ところで、今まで OsiriX のデータベース周りのソースコードをきちんと読んだことなかったですが、ちょっと時間があったんで覗いてみました。

内部的にはまだ 32bit のままですね。

これは要修正。

と思ってたのですが、データベースの内部を覗くと、現在では、このカラムは使われていません。

実際にレコードの id として使われているのは、coreData が自動生成する id （Z_PK）の方です。
おそらく、coreData を使わずにデータベースを管理していた頃の痕跡でしょう。

 

 

 

投稿日:

DolphORCA DICOM Server の準備

結局、ダイコム関係も AudioVisual Server から分離。

ところで、ダイコムファイルをアップロードする時、JavaScript 上でどのように指定していいかわからなかった。

jpeg や png あたりは image/* と指定しておけば、ダイアログで制限をかけてくれるのだが、ならダイコムは？ と思って、試しに application/dicom にしたら、制限かけてくれた。

なお、どんなファイルでも受け付ける場合は、’*/*’ ではなくて、「指定しない」のが正解らしい。

フロントにファイル送信機能を付け加えたら、お次はサーバの手直し。

一応、サーバにダイコムファイルを受け付ける API を設置した。

ダイコムファイルは大抵の場合、ファイルの先頭にタグ情報を埋め込んでいる。この情報をパースして、適当に保管しておくのが PACS サーバの役割なんだが、このときどういうデータ構造を採用するかは、本当に難しい問題。

この問題は、今の流れでやるのは得策ではないので（ちゃんと考えるのは次世代 HorliX に着手するときだと思っている）、とりあえず受け取ったファイルのタグ情報を解析するところまでやってみた。

なんとかできてますね。

それにしてもようやくダイコム関係と連絡がついた感じ。

 

投稿日:

dcm4che

前回の記事で触れた「画像サーバー」は、結局、DolphORCA AudioVisual Server として独立させた。

その時はあまり触れなかったが、独立させていい点はデータ構造がすっきりすること。

現状だと電カルの文書系と画像系は、データ構造の点で相性が悪い。
『なぜ全国統一カルテは無理筋なのか？』あたりを参照。

で、当然、視野に入ってくるのが、DICOM 系の画像をどうするか？ということ。

個人的には X-ray 程度の簡単なダイコムなら、電カル自体がパースして表示させてもいいんじゃないかと思っている。

参考にと dcm4che のリポジトリを漁る。

今までよくわからなかったのだが、arc-light が PACS サーバで他のリポジトリはツール群のようだ。

arc-light は現状だと JakartaEE には対応していないようなので、あまり参考にならず。

参考にするなら、ツール群の方かなあ。

 

 

投稿日:

DolphORCA AudioVisual Server

WYSIWYG な html のエディタを作成すると、やはり、画像などのアップロードと画面への挿入などの機能も欲しくなる。

P 欄を検討するとか言ってたが、結局、こちらを先に手をつけた。

現状だとこんな風になっている。

JavaScript などは「なんとなく」使う程度だったのだが、見様見真似でなんとか作成。

大半の「JavaScript でアップロード画面を作ろう！」的な記事は、本当にアップロード画面の作成のみですね (^^;)

たぶん、面倒なのは、それを適当なサーバーに投げて、永続化、さらにそこから（API を介して）復元・再利用できるようにするところじゃないかと思うんだが？

ところで、画像などのデータを通信するとき base64 でエンコードして送るか、そのままバイト列で送るかが悩ましいところ。

今回は、バイト列で通信させることとした。

クライアント（ブラウザ）からバイト列を投げた時、引き受けるサーバは、まずフロントエンドなのだが、これをバックエンドにそのまま送るか、あるいは、別に画像サーバのようなものを立てるかも考えどころ。

諸々の事情で画像サーバーを立てた。

だから例えば

http://localhost/DolphORCA-av/resources/image/1 にアクセスすると id=1 の画像を返してくれる。（実際はバイト列を返しているんだが）

 

なんでこのように画像を動的に生成する必要があるのかといえば、いわゆる一般のブログのように、表示させている html ファイルの同階層に img というフォルダを作り、そこから静的な画像ファイルを引っ張ってくる、みたいなやり方だと、原則、この画像は全世界に垂れ流しになってしまうから。

広報目的のブログならこれでいいが、医療情報系のシステムでこれはいかんでしょ。

以前に動画でごちゃごちゃ言ってたのは、このこと。

 

 

投稿日:

DolphORCA -intermission-

DolphORCA に遊びで病棟マップも追加。

むろん、患者名クリックでカルテ記載画面に遷移する。

在宅（訪問予定）のページも追加。

 

もちろん、これも患者名クリックでカルテ記載画面に遷移する。

思うに、カルテ自体に外来/入院/在宅の区別させる必要はなく、それを管理するクラスを設定すればいいだけだと思うのだが、なんか不都合あんのか？？？

 

猪股弘明