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 の存在意義わかってないと何やっているかわからないと思うんだけどなー。

Fラン私立理系大卒

 Fランク大学叩きはネット界の鉄板ネタの一つ。

彼らのおバカな言動はいわゆるDQNに近いものがあり、ネット民たちはその香ばしい言動をネタにして楽しんでいるわけだ。

だが、この場合の「Fラン」とは私立文系を暗黙の前提としているように思う。

でも、地方にある私立理系大学は低偏差値のところが多い。

だが、こちらの方はさしてネタにならない。

ああいう大学の世間的な評判というのはどういうものなんだろう？

ちょっと興味を持ったので、地方出身の方々に聞いてみた。

「私の出身は新潟だけど、例えば新潟工科大なんかは偏差値的には F ラン私立理系大になると思う。

設立は 1990 年代だと思った（注：調べた。正確には1994年）。

新潟県はもともと、・大学が少ない、・大学進学率が低い、ということもあって、設立時には地元の期待は相当高かった。

新潟は農業県と思われているかもしれないが、長岡にはそこそこ著名な企業もあるし、燕は金属加工が盛んだ。さらに系列企業もあるわけだから、地元出身のエンジニア候補は必要。

国立の新潟大卒業生はそんなところはいかないので、こういった大学が必要とされたのはわかるし、設立当初はおかしな評判も聞かなかった。

ただ、現在はどうだろう。いくらなんでも基礎学力が低すぎる。卒業生に頼れないと思う。今から思えば、企業の成長戦略としては、こういった大学に頼るのではなく、自社育成を貫いた方が良かったのかもしれない。

高度経済成長期を夢見ていたのか、バブルで浮かれていたのか、理由はわからないが、大学に過度に期待しすぎていたことは確かだと思う。」

他の方にも聞いたが「卒業生の（急激な）質の低下を予想していなかったのでは？」という意見は同様に口にしていた。

「こんな時代だから、地元企業の雇用状況も安定していない。

ニートになるのもいるし、就職しても適応できずに独立するものもいる。
都市圏では使い物にならなくても、地方では周囲では技術方面に明るいってことで、そこまで悲惨なことにはならない。

ただ、トラブルは多いね。地元に戻るとこの手の話は無茶苦茶耳に入ってくる。
「俺はすごいことやったー」って言っても大抵の場合、全然すごくない。
抑圧されている分、自己顕示欲がすごく強いってのもある。

マスコミやネットのネタになることはないが、状況はいろんな意味でよくない。
目立たないだけ余計タチが悪いかも。

能登地震の時に、米山さんが「棄村」みたいなことを主張して物議を醸したが、そういう背景がわかってないとあの真意は汲み取れないと思う。

マッチポンプみたいなことをやっている連中の生活を保障するって意味あると思う？

地方でも「地元のエース」みたいになる人って、大抵、都市圏からのUターン組でしょ」

ざっくりまとめると「Fラン私立理系大卒は、ネット上で派手にネタになるようなことはそう多くないが、局地的に実利を伴うようなトラブルを起こすことが多い」という傾向はあるようだ。

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形式でローカルに持ってこれたりだとか、格好いい機能を入れてくれたりしています。けれども、ひと昔前はデータ移行だけでも何百万も取られたり、下請け構造があるものだから、本社の人間がデータ構造を把握していないということもあった。開発元ならば、データベースを見れば、データベース単体からでもある程度データ抽出はできないとおかしいはずなのに、それができないみたいな奇妙な状況があったと思います。そこら辺をすっきりさせながら、標準型電子カルテをつくっていってもらえたらいいと思っています。

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