PHORLIX Lite -Lite だが、凝ってます-

 PHORLIX Lite が Mac App Store で公開された。

ものは、MacOS 向けのアプリで、「PHORLIX からのスピンオフ。ストレージ機能を省いて閲覧機能だけに絞った DICOM Viewer」と関係者も言っているのだが、私から見れば、少々不正確。

特徴としては「Metal でいわゆる Texture Rendering を実用的なレベルで達成したビューアー」で、PHORLIX でもこの方式は採用はしていたのだが、十分に生かしてきれていなかった。

どういうことかというと・・・

公開されている教育的なサンプルコードなどでは、縦・横・深さの画素数が 1:1:1、画素の長さも同様に 1:1:1 なのだが、もちろん、実用的なボリューミックなデータでは、こんな理想的な場合はほぼない。
例えば、画素数が 512:512:256 の場合、奥行方向の画素数は他の方向の 1/2 になっているので、これを教科書的なやり方でそのまま３次元構築してしまうと、（GPU は、0-255 を 0-1 と解釈するので）奥行方向に 2 倍間延びした像が描画されてしまう。
また、斜めから見るとテクスチャレンダリングの性質ゆえ歪んでしまう。←なんで歪むかはテクスチャレンダリングの原理を考えてみてください。
だから、違和感なく描画するためには、異方性を考慮した補正が必要なのだが、どこでどうやって補正すればいいかというノウハウはもちろんない。
試行錯誤で「コツ」を身につけていくしかないのだ。

当人たちはどう思っているかわからないが、PHORLIX とはほとんど別物のアプリと言っていいように思う。

（追記）普及速度もまずまず。

この段階（配信から１週間も経っていない）で、これはなかなかのもの。

Horos などの「本格的」ビューアが、次々と姿を消していくなか、特徴のある軽量ビューアはニーズにあっていたのかもしれない。

OPENSAUCE/OPENSOURCE

 X(twitter)の投稿はそんなに頻繁にしておらず、だから、バズるみたいな現象とは無縁なのだが、例外的にこのポストにはちらほら反応があった。

要するに
「OPENSAUCE 社が公開レシピのプラットフォームとして OPENSAUCE を商標登録しようとしたが、OPENSOURCE が既に登録されていたため、拒絶された。
が、OPENSOURCE の使用実態がなかったため、不使用取消審判を請求した。
しかし、この件を OPENSOURCE 商標を保持している OSDN 社及び同社代表佐渡秀治が、誤解を招くようにアナウンスしている」
というものだ。

詳しく知りたい方は、リンク先の OPENSAUCE 社のこのページからどうぞ。

これを見つけた時の私の第一感は、（ポストにもそのニュアンスは出しているが）「うわぁ、またやっているよ」というもの。

以下、ちょっとした感想。

松尾研究室オープンソースAI事件とその副産物

また、というのは、ちょっと前に（時系列的には、これより後なんだが）生成AIで有名な松尾研究室が、同研究室開発のソフトを「オープンソース」と広報したときに、オープンソースな方々が「Creative Commons ライセンスは OSI 基準のオープンソースライセンスに当てはまらないので、この AI はオープンソースではない」と騒ぎを起こしたことがあったから。

ちなみにこの騒ぎは松尾研究室が「オープンソース」の旗を下ろすことで幕が降りた。

個人的には、（この手の論争はよく起こることなので一定の結論を出すという意味で）もっとやり合って欲しかったのだが、そこまでには至らず、松尾研究室が大人の対応をすることでこの件はクローズとなってしまったのだった。

だが、論争相手が現在勢いのある松尾研究室であったため、いくつかの副産物が生まれた。
X(twitter)を漁ればわかると思うが、かなり優秀な人々がこの件に関してコメントしている。この点はいつもの「オープンソース」論争とは一味違っていたのだ。

副産物の一つは、「open source という単語は、OSI などオープンソース関連団体が特別な意味を付与する以前から、「ソースコードが公開されている」程度の意味合いで普通に使われていた」という事実が発覚したことだ。

open も source もごく一般的な名詞にすぎない。
「ソースコードが公開されている」程度の意味で「open source」という一般単語組み合わせワードを使うことは、商標が成立する以前から使われていたわけだから、仮に商標があったとしても、禁じることはできない、というように解釈するのが普通だろう。

もう一つの大きな副産物は
「そもそも、プログラム領域では商標自体が成立していなかった」
というかなり身も蓋もないもの。

拒絶された理由も、わかりやすく書けば

「open も source も一般的に使われている。それらを組み合わせた open source は特別な知識なしでも「ソースコードが公開されている」という意味に解釈できるよね。なんでそんなものに特別な権利を与えなきゃならんの？」

とかなり明快だ。

佐渡秀治氏の立ち回りが政治的すぎて生理的に受け付けない

松尾事件勃発直後の末端オープンソース信者のおおよその反応は
「オープンソースTM の商標は我らが教祖様が保有しているのだから、松尾研究室のネーミングは法的にも許されない」
というような感じだった。

しかし、これは色んな意味で間違えている。
教祖様はプログラム領域では商標は保持していない。

私が佐渡氏に生理的な嫌悪感を持つのは、こういうときに「それは誤解であって、私は、プログラム領域では、商標保有者ではないんだよ」と直接信者には語らないから。
実際、そのことに触れた書き物は公開されていたりもするのだが、佐渡氏はこの存在にほとんど言及しない。

ある程度の誠実さがあるのなら、「商標的には成立していないが、ライセンス限定という意味でなら、オープンソースライセンスはその定義が広く普及しているのだから、その観点から松尾研のネーミングを検討してみてほしい」と言えばいいだけではないか？

なお、見出しは「佐渡、キモっ」という意味ではないので、念の為。

（続く、かも）

ORCA 再び - WebORCA サーバは arm Mac では動かない-

 周囲の人々がまた医療情報系の活動を再開したこともあって、私も ORCA の環境構築を試みた。

ORCA という名称はソフトのプロジェクトでよく使われるが、医療情報領域で言えば、日本医師会が直々に開発を推進したレセコン（レセプトコンピュータ）ソフトのことだ。

このソフトの歴史的意義は、これまでにもいろんな人が述べているが、実用ソフトとしてみても現在でも現役、しかもレセコンに限って言えば国内でシェア２位という影響力のあるソフトなのだ。

影響がありすぎるが故に、いわゆる「商用ベンダー」からは微妙な扱いを受けていたりする。
ORCA+連動電子カルテの組み合わせが強力で、リリース直後から同種ソフトの価格破壊が生じ、市場から撤退を余儀なくされたレセコンや電子カルテはけっこうあったりする。

某先生が電子カルテ系の某会議で

大抵のクリニックはORCAを使っているところが多くて、ORCAはAPIもほぼ完全に開放されているし、データベースの構造も何ならわかるので、直接データを抜いてきたりもできます。すごく便利だと思います。私は使ったことがないのですけれども、カルテとつなげないようなレセコンは、現在あるのですか。私、現状がよく分からないです。APIの開放もできないようなベンダーのレセコンの面倒を見る必要があるのか疑問だと思います。

と発言したとき、周囲（ベンダー＋官僚）は微妙な雰囲気に包まれたそうだ。
これの意味については、どこかで触れるかもしれない。

脱線はさておき、本題に戻ろう。

ORCA 、そう ORCA が使える環境を構築するのだった。

ORCA の中でも WebORCA というやつだ。これを Ubnutu 22 上で動かしたい。

本来ならば Linux マシンにインストールするのが作法なのだろうが、継続的に使うことはなさそうだし、まずは Mac の Linux 仮想環境にインストを試みる。

マック好きの私はパラレルもたまに使う。
パラレルはそれほど古くないバージョンであれば、windows OS であってもそれなりの速さで動く。
実際、Ubuntu のインスト自体はあっけなくできた。iso ファイルから立ち上げ、あとは指示に従うだけ。

なのだが・・・

結論から書くと、このアプローチはうまくいかない。

なぜなら、パラレルには Ubuntu の arm バージョンしか入れられず、現在（2024/2月時点）ORCA は arm アーキテクチャには対応していないからだ。

Horos と Falcon

Horos

Horos という医療画像ビューアがある。

オープンソースの dicom ビューアでしばらく開発が止まっていたのだが、今度 FDA 承認のバージョンが apple App Store からリリースされるらしい。メーリングリストに流れていた。

ただ、これ、イギリスの iCat という会社が独自カスタマイズしたもので、そのソースコードが公開されるかというと疑問だ。

また、horlix 開発陣が言うには
「horos の描画エンジンには、VTK という OpenGL 依存のライブラリが使われており、現行バージョンそのままだとアップルの審査に通るか疑問。OpenGL 外して再構成して使うこともできなくはないが、パフォーマンス悪くなる。FDA の認証通すだけなら、3D 機能はいらないので、そうしたのかも。
長期的に延命させるなら、VTK を Metal か Vulkan に対応にする必要があるが、そこまではやってないと思う」
だそうだ。

実際、別系統のビューアの告知もしていて、どうも本線はそちらじゃないかという気がする。

よく言われることであるが、ニッチな分野でオープンソース開発方式を維持するのは難しい。

Falcon

上で言っていた「FDA 承認のバージョン」というのはどうやら Falcon MDというアプリらしい。他に Falcon Mx というアプリもあるのだが、ここでは Falcon MD に集中。

最初に結論を書いておくと、この Falcon MD は Horos とはなんの関係もなさそう。

それは置いておいて、まずは使用レビュー。

Apple App Store にも上がっていた。

ダウンロードして手元の適当なダイコムを import しようとしたら、課金しないと使えないよ的なアラートが出てきて、断念。

ただ、ネット上にある CT のサンプルは試せる。

２Dビューアは、こんな感じ(↓)

ここから３D表示させるには、図のように右上のプルダウンメニューから表示方法を選択する。

ここでは「Volume Rendering」。

確かに Volume Rendering はできているのだが、これをずっと続けたいかと言われると正直微妙。

スクショでは、使いやすそうに見えるかもしれないが、んー。

うまく言語化できないのだが

・画像自体がそれほど綺麗でない（ピンボケのように見える）

・マウス操作（タッチパッド操作）で任意の回転・拡大・縮小ができない

は不満。

PHORLIX 開発陣に聞いたところ、まず「ピンボケ」問題に関しては

「ピンボケになるのは、３次元を再構成するときの計算を手抜いてる可能性が高い。

より精細にすることは可能だろうが、計算量の関係（計算させると表示が遅くなるからなど）でそうしてないのかもしれない」

なんだそうだ。

操作性に関しては

「まず、ボリュームレンダリングを含む３D表示では、計算機内では物体ではなくてカメラ位置を動かしている。これが原則。

だから、マウス位置を取得してカメラ位置情報に反映させれば、任意の空間移動は可能になる。それができていないとなると、そうじゃないアルゴリズムになっている。
VTK は使っていない（上記コメント参照）。
新規のロジックを導入したんだろうけど、よくわからずに組み込んでいて、回転量などがうまく指定できていないからじゃないかな」

という推測をしていた。ちょっと難しい。。。が、この手の表示に基礎になる Ray Cast がうまく扱えていないということのようだ。

まあ、事前予測と大きくは外れていないということでしょう。

では、それそろ結論めいたことなども。

課金してまで使いたいかというと・・・NO でしょう。

確かに FDA cleared ではあるのだが

日本の薬機法は、通っているわけではないので、国内の臨床場面での使用は制限を受ける。

制限受けてもカスタマイズして使えれば、臨床以外での使い道も出てきそう。
が、開発陣曰く「Horos とは別系統でしょう。ソースコードの流用もほとんどなさそう。だから、Falcon のソースコードが開示されることは未来永劫なさそう」だそうだ。残念。。。

そして・・・大事なことなので繰り返しますが、

Falcon は horos とは技術的には何の関係もない

ようです。

フロントエンド/バックエンド

 ちょっと前に例の議事録が公開されたとき、ネット上でマニアックながらちょっぴり話題になった。

ただ、医療関係者で面白がってくれた人はある程度の現代のITに詳しい人に限定されていたようだ。

例えば

3-tierのクライアントサーバーシステムを提案させていただきました。施設特有のカスタマイズを入れたい場合、クラウドにフロントエンドサーバーとバックエンドサーバーの両方を入れるぐらいだったら、思い切ってフロントエンドサーバーを施設内に置いてしまって、例えばそこでバックアップを取るとか、大抵の場合、既存のオーダリングシステムとレセコンがあるので、それらとフロントエンドサーバーをつないでしまえば、施設特有のカスタマイズはシンプルにできるとすごく単純に考えていました。全部の機能をクラウドに上げるのは前提なのですか。そこがよく分からなかったです。

という発言はフロントエンド/バックエンドの区別がついていないと何を言っているかわからないのではないかと推測する。

医療人のITに関する知識はそこまで高くない。むしろ、世間一般の社会人より低いくらいだと私は思っている。

いまだに JavaScript がブラウザ画面の賑やかし程度のものだという認識で止まっている（主として）年配の先生は本当に多い。

ウェブサイトを利用しているだけだったら、クラウドの向こう側で何がおこなわれ、それがどういう構成になっているかなんて興味も持たないだろう。きっとサーバは一枚岩のようになっていると考えているんではなかろうか。

逆にここら辺わかっている人は、次世代の電子カルテのアーキテクチャに関することだから、楽しんでいたようだ。
小説のようだとエンタメ性を感じ取っていた人もいたくらいだ。
（まあ、発言者もそれ狙ってあのような言い方をしたと思うが）

厚労省が関与したウェブシステムがイマイチなのは周知のことだし、それを批判するだけなら簡単だ。

しかし、本当に使いやすいシステムを得たいと願うなら、不満を口にしているだけでは実現には遠く及ばないだろう。必要なのは、ある程度の知識に基づいた建設的な批判なのではないかと思う。

 最近、フロンエンド開発に関してエントリを書いた理由にはそういった背景がある。

イジって覚える Nuxt.js

 では、いきなりだが、Nuxt.js を触ってみよう。

『ゼロからしっかり理解したい人向けのNuxt.js入門』あたりを参考に。

すごくしっかり書かれた記事だと思うが、「ちょっと触ってみたい」程度の初学者には通読がキツいかもしれません。
また、今後は Nuxt3 が主流になっていくと思われるので、雰囲気掴む程度でいいのではと思います。

雛形を作ってもらう

まず、アプリのスケルトンを作ってもらいましょう。

  npx create-nuxt-app sample

としました。

ちなみに、Nuxt3 では npx nuxi init sample になります。
「フレームワークにプロジェクトを作ってもらうときは、専用のコマンドがある」という理解でいいのではないかと思います。雰囲気掴むというのはそういうことかと。

色々と聞かれますが、今回は以下のように答えた。

質問が終了するとモジュールなどを持ってきて何やら作業が始まる。

  npm run dev
して、ブラウザで http://localhost:3000 にアクセスすると以下のような画面が立ち上がる。

まずは第一歩終了。

イジり開始 レイアウトを設定する

ところで、質問に上のように答えると（この手の解説記事でよく出てくる） layouts というフォルダはできない。
Nuxt3 にいたっては pages というフォルダもできない。複数フレームワークを使う場合、細かいことにこだわるのはナンセンスだと個人的には思ってます。

ならどうするかといえば、手動でつくる。
普通に
  mkdir layouts
でいいです。

ヘッダー・フッターを設定する

初期画面で言われているように components/Tutorial.vue は削除しましょう。

その代わりに、ヘッダー・フッターを vue の形で入れます。




--SimpleHeader.vue--

<template>

 <div class="header"> サンプルヘッダ </div>

</template>

<style>

 .footer { background-color: #139ed5; }

</style>




--SimpleFooter.vue--

<template>

 <div class="footer"> サンプルフッタ </div>

</template>

<style>

 .footer { background-color: #139ed5; }
</style>

このままでは、Nuxt はこのコンポーネントをどこに表示していいかわかりません。
そこで、先ほど先ほど作成した layouts フォルダに default.vue ファイルを置きます。

--layouts/default.vue--
<template>
    <div>
      <ex-header />
      <nuxt />
      <ex-footer />
    </div>
  </template>
  
  <script>
  // ヘッダ＆フッタをインポート
  import ExHeader from '../components/SimpleHeader.vue'
  import ExFooter from '../components/SimpleFooter.vue'
  
  export default {
    name: 'sample',	// テンプレート名
    components: {
      ExHeader,		// <ex-header>に対応
      ExFooter		// <ex-footer>に対応
    }
  }
  </script>

pages/index.vue も以下のように改変。

--pages/index.vue
<template>
  <section class="container">
    <h2>改変</h2>
      <div>layouts フォルダを作成。default.vue でレイアウトを決めています</div>
  </section>
</template>

<script>
export default {
  layout: 'sample',		// レイアウトファイルを指定
  head: {
    title: 'TOP',
    meta: [
      {
        hid: 'description', name: 'description', content: 'トップページです。'
      }
    ]
  },
}
</script>

これで再度 npm run dev してみてください。

上のようにヘッダー・フッターありのインデックスページが出現すれば成功です。

個人的メモ
『Nuxt3 + bootstrap5』

node + TypeScript

で、TypeScript の話。

これも『TypeScript で始める Node.js 入門』という良い記事がある。

おおよそ手順通りやって問題ないかな。

ちょっと気になったところは・・・・

コンパイルオプションは CommonJS の他に

{ "compilerOptions": { 

  "module": "ES6", 

  "strict": true }

 }

と ES6 などを指定してもいい。

また、元記事では実行コマンドとして ts-node としているが、パス関係を設定していなければ  node_modules/.bin にある ts-node コマンドにはもちろん辿り着けないので ./node_modules/.bin/ts-node ./src/app.ts などと絶対指定する必要がある。

ここら辺が初学者には不親切。

しかし、サンプルが TypeScript っぽくないかなー。

JavaScript の module や class の話 -js と mjs-

 自分の勉強がてら TypeScript の話でもしようかなと思っていたのだが、その前に ES6 あたりで導入されたオブジェクト指向の文法のことなどを説明しておかないと話の流れ悪いよなあと我にかえる。

「Java と JavaScript の立場が逆転した」と言われる背景には、

・node という「使う場所を選ばない」実行環境が整備されたこと

・文法の仕様がオブジェクト指向に振られたこと

が大きいと考えているが、腑に落ちる説明が意外になかったりする。

フロント系は人材不足なのかなあと思ったり。

前置きはこれくらいにして本題に入ろう。

と言っても文法上の部分的な解説なら、良い記事はまあまあ見つかる。

class に関しては『JavaScriptのclassを理解する』がよくまとまっていた。

が、気になったのは node 環境下でそのまま実行したのではエラーが出るサンプルコードがあったこと。

具体的には、

class Person {
name;
age; 
setName(name)
{ this.name = name; }
setAge(age) { this.age = age; }
introduce() { console.log(`My name is ${this.name} and I'm ${this.age} years old.`); }
}

export default Person;

というクラス Person (person.mjs) があった時、これを他のファイル（test.mjs）から利用するには

import Person from './Person.mjs';

const person1 = new Person();
person1.setName("Alice");
person1.setAge(25);
person1.introduce();

としないと Cannot use import statement outside a module などのエラーが出る。

なんでこんなことが起こるかは、この記事あたりを読んでください。

要するに「環境によっては、一連の機能が単なる JavaScript なのか、それともモジュールなのか区別できないため、モジュールとして使う場合はそのファイルの拡張子を .mjs にせよ」ということのようです。

（適宜加筆）

イマドキのフロントエンド開発

以前に bootstrap に関して書いたが、その時は bootstrap を「手動」で導入した。

だが、イマドキのフロンエンド開発ならば、こんなことはせず、npm を使ってパッケージとして組み込むだろう。

ネットで探しても良い参考記事が見つからなかったのだが、

『入門者/初心者必見 npmでパッケージ管理するための基礎』

が、ほぼドンピシャの内容。

こちらでも解説記事書くかも。

→ 某先生がサンプルを github にあげてくれました。感謝！
bootstrap は導入していませんが、実用的に webpack も組み込まれています。

node-npm-webpack の最小限の構成なので、何をやっているかわかりやすい（はず）。

【アバウトな解説】

プロジェクトフォルダ、index.html などの準備

まず、プロジェクトフォルダ sample を作成し、そこに最終的に表示させたい index.html を用意する（後でもいいが何やっているかわからなくなると思うので、最初に用意しておきましょう）。

index.html の中身は何でもいいですが、例えば以下の内容。
jquery などをまとめあげた js ファイルを dist/bundle.js としたいので、script タグで指定しておく。

<!doctype html>

<html lang="ja">

  <head>

    <meta charset="utf-8" />

    <meta name="viewport" content="width=device-width" />

    <title>npm node</title>

    <script src="dist/bundle.js"></script>

  </head>

  <body>

    <h1>Hello node</h1>

  </body>

</html>

エントリポイントとして使用する index.js も用意。

import $ from "jquery";

$(function () {

  console.log("jquery");

  console.log("jquery2");

});

パッケージを利用するので "jquery" で持ってこれます。
今、何やっているかわからなければオマジナイだと思って import 〜 としておきましょう。

npm コマンド操作
コマンドラインから
$ npm init -y

として、初期化。この時点で package.json ができます。

使いたいパッケージをインストール。

$ npm install jquery
今回は webpack も使うので

$npm install --save-dev webpack
$npm install --save-dev webpack-cli
$npm install --save-dev webpack-dev-server

も忘れずに。（サーバーは他にも立て方はありますが、今回はこれで）

webpack.config.js と package.json の準備

設定ファイル webpack.config.js は手動で作成します。

const path = require('path')

module.exports = {

    entry: path.resolve(__dirname, "index.js"),  //エントリポイントであるファイルのパスを指定

    output: {

        path: path.resolve(__dirname, 'dist'),  //バンドルしたファイルの出力先のパスを指定

        filename: 'bundle.js' //出力時のファイル名の指定

    },

    devServer: {

        static: {

            directory: path.join(__dirname, './'),

          }

        //contentBase: path.join(__dirname, './')

      }

}

ここで dist/bundle.js を作成させていることに注意。

ビルド・テストしやすいように package.json に以下のような scripts を追加。

  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "dev": "webpack --mode development",
    "build": "webpack --mode production",
    "start": "webpack serve --port 3000 --mode development --open "
  },

ビルド・テスト
これで準備は整いました。

＄npm run build

で bundle.js を生成。

＄ npm run start

で、サーバーが立ち上がり、Hello node が表示されます。
コンソールに
jquery1
jquery2
と表示されれば、OKです。

参考
『webpack入門（Node.jsの導入からjsファイルのバンドルまで）』バンドルがキモ。

『node.js 習うより慣れろ』内容薄い・・・。もうちょっとがんがれ。

ところで、フロントエンド開発というと Nuxt や React という話にはなると思うが、node や TypeScript の存在意義わかってないと何やっているかわからないと思うんだけどなー。

OpenDolphin

OpenDolphin というオープンソースの電子カルテに関して、私どもの記事やかつておこなった活動などが再評価されているようなんでちょっと書いてみよう。

まず、OpenDolphin とはなんぞや？って方は『OpenDolphin -wikipedia 風解説-』を読んでほしい。

よく「オープンソースの」とか「開業医の先生が開発に関与した」と広報されていたが、実態はそんなものではなかったかなり問題のあるプロジェクトだったことがわかると思う。

実際、現役で稼働しているドルフィンはそう多くないと思う。

しかしながら私たちが関与している OpenDolphin-2.7m および関連ソフトの類に限っては再評価されてきていると思う。

例えば、グーグルあたりで「OpenDolphin」を検索すると関係者の書いた記事がいくつも引っかかる。

なんで今さら？と思われるかもしれないが、歴史的評価ともいうべき段階に入って、われわれが主張してきたことが受け入れられる土壌が出来上がっていたからだと思われる。
ようやく、という感じはするが。

『標準型電子カルテ』でも触れたが、うちの代表が厚労省の班会議でこんな発言をした。

”あと、すみ分けと言っているのですけれども、今となってはいにしえのオーパーツみたいなものですが、オープンドルフィンという経産省が旗振りをしたオープンソースの電子カルテがありました。あれは、商用化は、LSCというところがある程度やっていましたが、結局売れなくて、現在はメドレーが引き取ったような形になっています。オープンドルフィンは自力運用している施設が多くて、多分その次ぐらいに私がカスタマイズしたバージョンが普及していたようですが、私は対価は一銭ももらっていませんし、サポートもできる限り無料で答えていました。 　これは国がやる事業ですから、収支とか、そこら辺は私は疎くてよく分からないですけれども、過度に意識する必要はないのではないかと思います。私はクライアントソフトは、無料で配布しましたが、１日十数件ぐらいダウンロードされていました。商用化を意識したからといってそれが必ずしも普及に結びつくわけではないので、やり方は様々だと思います。”

一昔前なら、このような発言が重視されることはなかっただろう。

では、どこら辺が評価されているのだろう？

私でも思いあたることをいくつか。

一つは、動作原理の解析・ソースコードの読解を通じて、それまで言われていたことがかなりおかしいことを明らかにしたことだろう。

他には、電子カルテとしての基準を満たすために各種ユーティリティソフトを独自に開発したことも評価されているようだ。

（適宜加筆予定）

参考：

『開いたいるかの都市伝説は本当だったか』現代的なドルフィンプロジェクトへの批判はこの記事から始まったと言っても過言ではないでしょう。

『ソースコード嫁』彼にしては珍しく推測も入れてます。しかし、誰しもが思っていたことでしょう。歴史的な評価が必要になったことを踏まえてようやく記事にしてくれました。

『@masudanaika による個人情報流出ツィート』動画の方で「ドルフィンをある意味象徴するような人」と増田内科（当時）増田茂医師を評しています。こういう記事を書く人ではないのですが、うやむやにするわけにはいかないということでしょう。

『Dolphin プロジェクトと皆川和史』混乱を来した原因を具体的なエピソードを挙げながら解説しています。動画も（わかる人には）刺さる内容でしょう。

ミリタリー界のPコート

 秋葉ちゃんが『ヲタ、冬を乗り越える』で私が密かに「ミリタリー界隈のPコート」と呼んでいる N-3B に関して触れていた。

おおー、そこに注目するようになったじゃん、成長するする

とお姉さんとしては、喜んだ。というのは、このコートはこれまで過小評価であったと思う。

ミリタリー系のコートといえば、モッズコートがそれなりの地位をしめている。

が、これはヲタ系の男子が着ると「ぼわっとしてカッコ悪い」、「着こなしが難しいのに雑に着ている」、「正直ダサい」と女子ウケはかんばしいものではなかった。

（なお、女子がモッズコート着るときはそれなりに気を使ってます。街中で見かける女子はみんな可愛く着てるでしょ）

なんで、N-3B 行かないんだよっ！

と心の中で叫んでいたのだが、通じたか？

N-3B のいい点を挙げておく。

・組み立てて使うことを前提にデザインされているモッズコートと比較して作りがしっかりしている。（極寒での使用が前提なので当たり前）

・防風性＆防寒性ともに高いレベルにある

・着丈的にはハーフコートなので取り回しが楽

・（AVIREX VINTAGE は特に）セージグリーンの発色がキレイ

いいことづくめ（笑）。

つか、服としての完成度高いから、羽織っただけでも様になるんよ。

カジュアルおしゃれめに振れば

　N-3B ＋ ベージュ系のチノパン/カーペンターズパンツ ＋ 赤系のスニーカー/ブーツ

は、鉄板。例えヲタ系であってもこの着こなしでサマにならない男子はもう素材自体に難があると言っていい。

ちなみに、女子でも大柄な人は着こなせると思う。

標準型電子カルテ

国が進めている医療DXの一環として標準型電子カルテというものの開発が予定されている。 

厚労省が主催した標準型電子カルテの第一回技術作業班にうちの代表も出席したのだが、その議事録が公開されている。

X(twitter)の医療情報クラスタは結構盛り上がっていた模様。

で、彼は議事録上では４回発言している。
（追記）彼がコメントしたことなども追記した。

① 自己紹介〜システム提案

○PHAZOR　PHAZORと申します。
　私は、精神科の医師なのですけれども、一般医療人の意見でもいいのかと勘違いしてアンケートを出して、参加させていただきました。ありがとうございます。一応、会社も持っていますが。
　資料を見ていて、私は精神科医ですから、そう思うのかもしれませんが、一般病院と精神科病院は区別されていると感じます。厚労省の先生もおっしゃられたと思うのですけれども、電子カルテの普及率は、200床未満の一般病院で５割程度ですが、精神科病院はもっと少なくて、民間の調べだとトータルで40％ぐらいです。そして、その操作性や完成度にみんな満足しているかというと、そうではなくて、ほとんど満足していないと思います。
　今日は幸いにもいろいろなメーカーの皆様が来られているので、お願いしますが、精神科病院用の電子カルテだとか、あるいは汎用電子カルテに精神科病院に求められる特有の機能、例えば隔離拘束診察の記載機能などを付け加えた電子カルテは、その分コストがかかると思いますが、そういうものをつくっていただければ、より普及が進むと思いますので、ぜひとも検討していただければと思います。
　それと、私はもう一つ完全に勘違いをしていたことがあります。私がクリニックなどで外来診療をやる場合、ブラウザータイプのクラウドのカルテを使わせてもらっています。ただ、ほとんどの臨床医はこの形態がベストだとは思っていなくて、通信障害が起こった場合、一時的に診療がストップします。東日本大震災のときは、通信障害に加えて端末も駄目になりましたから、以前の処方内容がまるっきり分かりません。医学的にはいいことではないのですが、やむなく、臨床的な感で薬を出したことがあります。
　そこで、3-tierのクライアントサーバーシステムを提案させていただきました。施設特有のカスタマイズを入れたい場合、クラウドにフロントエンドサーバーとバックエンドサーバーの両方を入れるぐらいだったら、思い切ってフロントエンドサーバーを施設内に置いてしまって、例えばそこでバックアップを取るとか、大抵の場合、既存のオーダリングシステムとレセコンがあるので、それらとフロントエンドサーバーをつないでしまえば、施設特有のカスタマイズはシンプルにできるとすごく単純に考えていました。全部の機能をクラウドに上げるのは前提なのですか。そこがよく分からなかったです。

コメント
いわゆるベンダーの人間ではないため、どういう経緯・意図で出席したかまず説明する必要があると考えた。その際に、電子カルテの開発に医師目線が必要だと考えたため、東日本大震災時のエピソードを披露した。そこから望ましいアーキテクチャの話に繋げた。
ちなみに能登半島地震が起こったのはこの後。医師であれば災害時の堅牢性みたいなことは考えるが、ベンダーはこの視点が抜けがち。その点は意識してもらうように工夫した。

② ORCAやオープンドルフィン

○PHAZOR　度々すみません。
　大抵のクリニックはORCAを使っているところが多くて、ORCAはAPIもほぼ完全に開放されているし、データベースの構造も何ならわかるので、直接データを抜いてきたりもできます。すごく便利だと思います。私は使ったことがないのですけれども、カルテとつなげないようなレセコンは、現在あるのですか。私、現状がよく分からないです。APIの開放もできないようなベンダーのレセコンの面倒を見る必要があるのか疑問だと思います。
　あと、すみ分けと言っているのですけれども、今となってはいにしえのオーパーツみたいなものですが、オープンドルフィンという経産省が旗振りをしたオープンソースの電子カルテがありました。あれは、商用化は、LSCというところがある程度やっていましたが、結局売れなくて、現在はメドレーが引き取ったような形になっています。オープンドルフィンは自力運用している施設が多くて、多分その次ぐらいに私がカスタマイズしたバージョンが普及していたようですが、私は対価は一銭ももらっていませんし、サポートもできる限り無料で答えていました。
　これは国がやる事業ですから、収支とか、そこら辺は私は疎くてよく分からないですけれども、過度に意識する必要はないのではないかと思います。私はクライアントソフトは、無料で配布しましたが、１日十数件ぐらいダウンロードされていました。商用化を意識したからといってそれが必ずしも普及に結びつくわけではないので、やり方は様々だと思います。

コメント
システム・アーキテクチャの軽めの提案ができればいいくらいに考えていたが、「レセコンまでは導入しているが、電子カルテまでは導入していない施設が多い」という状況が提示されたため、これは ORCA のことを言っているのだろうと補足的な意味を込めて発言した。
ORCA と日本医師会の関係が特異であるため、触れにくいという雰囲気はあった。
だが、そこをスルーしたのでは、このプロジェクト自体が失敗すると考えた。
ドルフィン（OpenDolphin）に言及したのもほぼ似たような意図。民間ベンダー独自のプロダクツではない場合（ドルフィンプロジェクトには行政も関与している）、どういうことが起こりうるのか提起しておく必要があると考えた上での発言。

③ 医療画像の取り扱い

○PHAZOR　度々すみません。
　今、画像の話が出ていたので、えっと思ったのですけれども、今すぐ画像をクラウドに上げる必要はないでしょうね。そこまで求められていないと思うし、DICOMなど医療画像を保管するPACSサーバーのクラウド型があるのは知っていますが、DICOMの仕様的に多施設で使うことはあまり前提とされていないので、データ量の問題からいって、PACSサーバーは大抵院内に置いていると思います。
　富士通Japan様がおっしゃった軽量なプログラムとか、アプリケーションティア、フロントエンドサーバー、呼び方はなんでもいいのですけれども、そういったものを院内に置いてしまったほうが画像を引っ張ってくるときは楽です。ご存知だと思いますが、例えばDICOMをブラウザ上でJPEGやPNGなどで描画させるのであれば、PACSサーバーに患者IDを問いかけて、これこれのスタディーを持ってこいという命令を出して、DICOM-汎用画像変換サーバーで、DICOMからJPEG変換、DICOMからPNG変換などをすれば、ブラウザ上で表示はできます。それをクラウドでやろうとすると、かなり難しいと思います。院内にDICOM-汎用画像変換サーバーまではいかなくても、専用の軽量なプログラムを置いてしまえばできますので、画像ということであれば、いきなりクラウドに上げるということを考えるのはあまり現実的ではなくて、院内でケアしたほうがうまくいくと思います。
　私は、OsiriXのオープンソースバージョンのコントリビューターをやっていました。その程度の素人の意見ですが、ご高配のほどよろしくお願いします。

④ シメの言葉

○PHAZOR　度々すみません。
　この班会議に出るに当たって、仲間内で必ずしも出席できるかわからないけれど、アンケートを出してみないことには始まらないみたいな感じでアンケートを出しました。そのときに、周囲のお医者さん連中から言われたのは、今まで例えば国がやったHER-SYSであるとか、G-MISやVRSなどは、開業医の人からするとすごく使いづらい、出席した場合にはそのことを主張してほしいと言われました。東京都医師会の某先生はかなりお怒りの様子でした。リリース前に試用させてくれないと。今回はα版があるから大丈夫だと思うのですが、突然ぽんと出てきて使ってくださいというのが今まででした。コロナのときはしようがなかった気もするのですけれども、そういうことは結構言われました。
　標準型電子カルテではアジャイルなどを意識したほうがいいと思います。ITに関して、割と意識が高めの開業医の先生などもいらっしゃいますから、そういったところにベータテストみたいなことをやってもらって、なるべく早くフィードバックを得る。プロトタイプを早くつくってユーザーに使わせて、フィードバックをもらう。私などが言うよりも、ベンダーの皆様方のほうがよく御存じだと思いますが、特にウェブシステムの場合、みんなが使うということを目指していますから、そちらのほうが有効だと思います。
　私は基幹病院などに勤めたことがあります。基幹病院クラスの電子カルテ導入時には、ウォーターフォール開発方式でおこなわれ要件定義などですごく時間がかかる。標準型電子カルテでは、開業医も含めて、中小の病院、精神科病院も今後使うみたいなことになると、そういったユーザーにいきなりぽんと渡して、はい、使ってくださいと言っても、多分使わないと思う。アジャイル開発方式も意識してやっていかれるといいと思います。
　あと、これは私もよく分からないのですけれども、COCOAのとき、多重下請けなどが問題になりました。別の質問になってしまいますが、再々委託みたいなものは禁止とか、そういうことはできるのですか。可能であれば、後で答えてほしいです。
　多くの医者は、データを人質に取られることをすごく嫌っています。最近はベンダーさんもその点を意識してくれて、ネット経由でクラウド上にあるカルテの記載内容をJSON形式でローカルに持ってこれたりだとか、格好いい機能を入れてくれたりしています。けれども、ひと昔前はデータ移行だけでも何百万も取られたり、下請け構造があるものだから、本社の人間がデータ構造を把握していないということもあった。開発元ならば、データベースを見れば、データベース単体からでもある程度データ抽出はできないとおかしいはずなのに、それができないみたいな奇妙な状況があったと思います。そこら辺をすっきりさせながら、標準型電子カルテをつくっていってもらえたらいいと思っています。

最初と最後をキメて、あとは流れにそって個別事項を答えるとか・・・やるなあ。

究極のアジャイル

 

超アジャイルというワードに引っかかったので、久しぶりにエントリ。

『君は超アジャイルという開発方式を知っているか？』あたりを参考に。

おそらくこの言葉は某氏の某SNSでの投稿が初出。

『（注：アジャイルとは）大雑把に言えば「素早くプロトタイプを作成、ユーザーにテストしてもらい、そのフィードバックを開発に反映。このプロセスを繰り返しながら完成に近づけていく」みたいなやり方だと思う。
（略）
今の時代なら、
　東大出身血液内科→google（リリアンさん）
とか
　オリンパスで内視鏡（開発）屋→医師（後輩でいた）
とか普通にいるわけだから、そこらへん適当に何人か集めて超高速でプロトタイプ作ればいいだけでは？と思わないでもない。
業者に頼むより安いだろうし、ユーザーテストもやりながらコーディングするっていう超アジャイルだと思うんだが。』

完全に勢いで言っていることがわかる（笑）

PHORLIX [004]

 アノテーション文字も入れ込めたらしい。

PHORLIX [003]

 PHORLIX さらに開発が進んで、もう一般公開。

MacOS のアプリの開発ってこんなに早く進むものでしたっけ？？？

なお、アプリ自体はこちらからも落とせます。

PHORLIX [002]

 開発速度、はやっ。

まだ、読めるファイルは限られているが、重要なのはそこではなくて、読み込んだファイルがデータベースに格納され、表示できていること。

メイン開発者は、「貴重な GW の１日費やしたが、まあまあのデキ」と軽めの評価をしているが、周囲はびっくりしてる。

PHORLIX

アプリ 

アプリっぽくなってきました。

github リポジトリはこちら。

タグ解析

これの準備として dicom ファイルのタグ解析も検討。

かなりわかりやすいサンプルを ANN2b 先生が『DCMTK を Mac で使う』で提示している。

「コマンドラインツールを Xcode 上でビルドしても引数渡せないんじゃ・・・」と思ってましたが、スキーマエディタから渡せるそうな。

これは知らなかった。

まあ、テストするだけなら、argc や argv を適当に与えてもいいわけですが。

（追記）ポインタがわかってない人は上の「argc や argv を適当に与えてもいい」の意味がわからないらしいです。

int main(int argc, char *argv[])

と書いた時、argc はこのアプリに与える（アプリ名も含めた）引数の数、*argv[] は文字列の配列です。正確には文字列配列へのポインタですが。

一つの引数を渡したければ

argc=2;

char dummyfile[] = "PathToDICOMfile";

argv[1] = dummyfile;

とすればいいわけですね。

こうするとデバッガ・アウトプットに指定したファイルの内容が json 形式で表示されます。

意識していませんでしたが、ポインタの意味がわかっているか試す意味ではいい例ですね。

まるっきり本題と関係ありませんが。

M2 Mac Book Air を使ってみる

 PC に関して言えば、私は Mac 派なのだが、近年は iPhone や iPad あたりで済ませてきた。

しかし、もう Intel の時代でもないしなー、ストレージもいっぱいだし、ということで apple のノート PC を物色。

結論から先に言うと、M2 Mac Book Air を購入した。

軽くレビュー。

なお、会社では M1 Mac Book Pro はよく使っているので、機能面では主にそれとの比較になる。

筐体のデザインは従来の Air のくさび形より今回のフラットな方が好き。

キータッチは M1 Mac Book Pro よりストロークありそう。割としっかり打鍵する方なのでこちらの方が「押した」感があって好印象。

スクリーンは素晴らしい。ベゼルが細くなって洗練している。

全体的な印象としては、「よくまとまっている。完成度はそれなりに高い」というもの。

だから、購入したわけなんだが。

ちょっと気になった点を書いておくと、サウンド周り。

空間音響みたいなのを導入した、って話なんだけど、好みじゃないかな。

なんというか高音がシャカシャカしているだけって感じ。エイジングで変わるかもしれないが、今のところこの点は不満。

air でしっかり音楽を聴くという機会はそう多くないと思うので、M1 時代のスピーカーで良かったんじゃないかと思う。

それだけ初代 M1 Mac Book Pro の完成度が高いってことではある。

なお、ちょっぴり開発機としての性質もあるため、初期設定は『Mac を新調したらやること』を参考にした。

DolphORCA に BootStrap 5 を導入する

 まだ開発途上だが、DolphORCA という電子カルテがある。

そのバックエンドサーバーはフリーで公開されている。

これだけだと見栄えがしないので、ANN2b 氏がメインで作成したフロントエンドサーバーに BootStrap 5 を導入してみた。

ここら辺はおそらくウェブ系の良い勉強になると思うので、忘備録的にメモ。

BootStarp でレスポンシブデザイン

まず、単純に組み込んでカラムをいじる。

bootstrap はブラウザ画面を12分割して管理しているのだが、今回は 2:4:4:2 の配分比とした。

コードの基本骨格を示すなら、↓のようななる。

<section class="text-black">

      <div class="container py-3">

            <div class="row align-items-center g-4”>

                <div class="col-md-2">・・・</div>

                <div class="col-md-4">・・・</div>

                <div class="col-md-4">・・・</div>

                <div class="col-md-2">・・・</div>

            </div>

         </div>

</div>

これでスピリットデザインが実現できてしまうのは便利としか言いようがない。

4:4 のところに SOA と P を配置すると、こうなる↓

ところで、bootstrap はレスポンシブを意識して設計されている。

ブラウザ幅を狭めていくと、まず、画面上部のメニューがハンバーガーメニューに変化する。

画面右上にメニューに注目。

さらに狭めていくと、レイアウト自体が変化する。

画面の右半分が、下に回り込んでいるのがわかるだろうか？

なお、ハンバーガーメニューは、クリックすると以下のようにメニュー項目が展開される。

BootStrap の良い点は、レスポンシブデザインが少ないコーディング量でお手軽に実現できる点だ。

注意点

ただし、BootStrap は 4 → 5 の変化で微妙に変化があったようで、例えば、今までであれば

data-toggle

だったところが、

data-bs-toggle

のように改変されていた。

ここを修正しておかないと、従来のハンバーガーメニューは正常動作しないのだが、言及された記事は全く見かけなかった。

有名な割にちゃんと使っている人は少ないのかな？

DolphORCA → PHORLIX

ところで、なぜ、DolphORCA の開発が進んだかといえば、医師会の WebORCA （オンプレミス版）のリリースが迫っていたから。

WebORCA 自体は、先日、公開されたが、これで開発に弾みがついたかといえば、そうはならなかった。

むしろ逆。

思っていた感じではなくて、なんか落胆した感じになってしまった。

別に、WebORCA 自体が悪いというわけではなく、ORCA がどんどん進化していっている時期を知っている人が多く、そこと比べると致し方ないかなあ？

確かに、ワクワク感はないですね。

ただ、持て余した熱意は、捌け口を求める。

今回は、それが画像関係に向かった。

具体的には PHORLIX 。

なんで、Metal に着手して１週間かそこらで、こんなの作れちゃうかなあ？

存在自体、忘れていた

 数年ぶりにここにきた（笑）