dcm4chee-arc-light 5.29.2 のビルド

C++ 系の オープンソースの PACS は Orthanc が有名だが、Java 系では dcm4chee-arc-light が有名なようだ。

某先生も「arc-light は JakartaEE には対応していないので、手を出していないが、ライブラリの方はけっこう使えるようだ」と言っていた。

JavaEE 環境になってしまうがそこら辺は割り切って試してみますかね。

なお、ビルドはそれほど難しくありませんが、デプロイがとにかく手順がかかる。
よほどの事情がない限り、sourceforge で公開されているバイナリを使った方がいいでしょう。

ライブラリ dcm4che をビルド

dcm4che というのが dcm4chee-arc-light を構築するのに必要なライブラリ、arc-light は PACS サーバーそのもの、みたいです。

なので、先に dcm4che をビルド。

mvnw コマンドを使うらしいのですが、まずは maven をインストールしておきましょう。

git コマンドで

git clone git@github.com:dcm4che/dcm4che.git

として、dcm4che のソースをローカルマシンにもってくる。

リポジトリの教えにあるように

./mvnw install

としてビルドが始まりますが、mvnw コマンドは mvn の何かのラッパーのようでやや間があきます。

ビルドが始まってからは速い。

となれば、ビルドは成功。

dcm4chee-arc-light のビルド

これまでと同様にソースコードの準備。

git clone git@github.com:dcm4che/dcm4chee-arc-light.git

としてソースコードをローカルマシンに持ってくる。

ビルドにはオプションがあるので、お好みで。

とりあえず試すだけならセキュアな UI や API は要らないでしょうから、

mvn install -D db=psql

でいいと思います。

数分、かかりますが、ビルド成功。

dcm4chee-arc-light -> dcm4chee-arc-war -> target に war ファイルができているので、これをデプロイすればいいんでしょうか。

デプロイは面倒という記事が散見されるので、これは稿をあらためて。

 

JakartaEE と DolphORCA

おかげさまでネット上では『OpenDolphin -wikipedia 風解説-』がなぜか支持されているようだ。

元々は、ドルフィンのソースコードを眺めていた時に、(従来は)開発者認定されていない人の署名を見つけて、ちょっとびっくりしてそこらへんのことをまとめておいただけの記事だった。
が、その後も報告が断続的に集まり続け、その都度書き足していったら、現在の形態になったという経緯だ。

こういう斜めから入ったような記事でも、それなりに読まれたりするものなのですね。

意外な気もするが、納得できるところもある。

ところで、OpenDolphin の件で若い人から言われて印象に残っているのは、

現在の Java や JakartaEE の各仕様を使えば数行で処理できるところを、何でその十倍くらいのコードで(しかも)不自然に処理しているんですか?

という指摘だ。

正直、きっつ。。

まあ、一言で言えば、データ構造修正とコストとの兼ね合いの問題ですね(汗)。

データ構造の限界やその処理方法の古さは、われわれも認識はしていたが、ひとたび、データ構造に手を入れ始めると、それを内部的に処理している部分も変更せねばならず、そのコストが(修正した)利益に見合わないとみていた、というのが答えといえば答えになるでしょうか。

なんか、うまい説明になってないか。。。

ここら辺で興味深かったのは、某先生の判断と立ち回りだ。

ギリギリまで OpenDolphin 2.7 のデータ構造は維持し続け、変え時と見たら一気に変えてしまった。
(ここら辺の流れは、ここあたりから始まる一連のツィートを参照。)

この「変えて」しまったものが DolphORCA なんだが、設計の基本コンセプトからしてドルフィンとは大きく異なっている。

DolphORCA で採用された三層クラサバ構成に関しては『DolphORCA と三層クライアントサーバシステム』が良い案内になっている。

また、(直接、DolphORCA には触れられていないが)電子カルテ系と画像系のデータ構造の相性の悪さに関して

なぜ、全国統一カルテは無理筋なのか?
-カルテ系と画像系のデータ構造の本質的な相性の悪さ-
(EHR-DICOM data structure mismatch)』

という記事にかなりわかりやすく書かれている。
DolphORCA のデータ構造は、これらの考察を踏まえてかなりシンプルで使いやすいものになっている。
ここら辺の分野に興味のある方はぜひ一読をすすめる。

 

 

モヤっとしたことなど

ネット上を彷徨っていると、気になることやモヤっとすることも多い。

思いつくまま書き留めていく。

2022-2023 年越し

小山哲央(アーク情報システム所属)とかいう人のこれはさすがに不味いでしょ。

結構な人が指摘しているが、2019 にもなってこのツィートはないよなあ。

2019 といえば確か MIA も商用版をリリースしていて、MIA に至ってはソースコードの開示もしていない。LSC は明言していないが、実務的には GPL でもなんでもなくなっていた時期だ。もはや GPL でもなんでもなくなっているのに、「故意に」「GPL 違反」したってどういうこと?
そこらへんの事実確認もせず、悪意丸出しで出鱈目なツィートしたってこと?
誹謗中傷よりもタチが悪いし、人間性疑われるレベル。
FEM あたりを使って建築・土木系の構造解析(シミュレーション)やってるみたいなんだが、建築・土木系の FEM は、はっきりいってガチ FEM 勢から大して評価されてない。建築土木系の数学力が低いからだ。
さらに評判落としかねないようなことやってどうすんだ???
Python で FEM ねえ。悪いが、まったく興味持てない。

(追記)やはり、小山哲央のツィートは逆効果だったようです。「LSC からの依頼を契機にここら辺、コードを整理して、もう少しマシなコンバーターを作ろうという雰囲気はあった」そうなんですが、このツィートのせいでこの話はおじゃん。結果的に電子カルテの基準を満たせなくなったわけです。
なんとも皮肉な話ですね。

2022 夏頃

オープンソースの電子カルテに関する tweet

ここから始まる一連の tweet 。

そのときは「こういう意見もあるのか」と流していたのだが、いわゆる「大学人」のイヤらしさとかダメさ加減がそこはかとなく出ている感じなので、取り上げる。

まず、OpenDolphin がダメな理由が「現在の Java のバージョンより古い」としているところ。
間違いではないんだが、違和感ありまくり。

というのは、現行の Java 開発環境に対応させるための改変は大して難しくないし、改変して使っている人がけっこういるから。

実際、こんな動画も上がっている。

今、見直したが、サーバーの起動から実に丁寧に記録・提示されてますね。

こういう情報を(意図的に?)無視して「古い、古い」というのは、ちょっとおかしい。
というか、単純には「私には Java コードを改変できるだけの能力がない」というだけのことなので、本当に気になるようだったら、質問なり何なりすればいいだけの話。

 

で、持ち出してきたのが omcake というソフト。

紹介するのはけっこうだが、すかさず「ログイン認証の機能がないから電子カルテの要件を満たしていない」という突っ込みが入り、撃沈。

さらに某先生から「ログイン認証にはセッション使えばいいよ」とサジェスチョンされたにも関わらず、まるっきり反応できてない。

一体、何がやりたかったのか???

WebDolphORCA

逆になんか「得した」と思われる事柄。

omcake の時に、某先生がログイン機能を提示したのだが、ここから WebDophORCA に展開していく流れ。

ログイン認証の実装などは大して驚かなかったのだが、『OpenDolphin は「真正性」すら満たしていないかもしれない』という考察記事は興味深かった。

これ、ポイントは「OpenDolphin は記録の保存には hibernate を使って blob を操作しているが、hibernate を使っている限り、blob を直接操作してデータを書き換えると、OpenDolphin のシステム自体はデータ操作(改竄)されたことに気がつかない(=検知することすらできない)」というあたりです。

よくもまあこういうケースを思いつくもんだと。

現状での現実的な回避策も示唆しているので、こういったことに興味のある人は(難解かもしれないが)一読を勧める。

 

 

こういう人はプログラミングには向いていない

最近、内輪で話題になっていたのは、「プログラミングの適性」みたいなこと。

元々は、さる電子カルテの「開発者」を自称していた医師が実はそうではなかったというエピソードに端を発するのだが、この事例に限らず、割と IT 系の案件で実感することが多い事柄のようで、色んなエピソードが出るわ出るわ。

特定の誰、ということではなく、一般的に「こういう人はプログラミングには向いていない」という感じでまとめていく。

ロジックを読み取る能力・組み立てる能力が低い

IT 系の案件はプロジェクト単位で進行することが多い。場数踏んでいくとそれっぽいコードは書けるようにはなる。

特に歴史のある言語の場合、サンプルやスニペットはそこかしこに落ちている。

それらの切り貼りで何とかなる場合も多いんだが、稀に新規のロジックをおこさないといけない局面もある。

こういう時に使えないヤツは本当に使えない。

ロジックとして要件を満たしていないにも関わらず、エラー吐かないようにコンパイルだけは通そうとするタチの悪い輩もいたりする。

要注意だ。

手を動かさない

これは、プログラミング云々というより、社会人としてどーなの?と言いたくなるが、こういう人(↓)が IT 現場でも多数、観測されているw

 

 

(おそらく、続く)

 

ANN2b