2024年1月22日月曜日

ミリタリー界のPコート

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

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

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


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

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

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

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

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

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

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

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

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

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

いいことづくめ(笑)。

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

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

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

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


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


2024年1月19日金曜日

標準型電子カルテ

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

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


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

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

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

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

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

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

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

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

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



2023年11月23日木曜日

究極のアジャイル

 


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

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

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

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

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


2023年5月18日木曜日

2023年5月14日日曜日

PHORLIX [003]

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


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

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




2023年5月2日火曜日

PHORLIX [002]

 開発速度、はやっ。


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

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



2023年4月30日日曜日

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 形式で表示されます。



意識していませんでしたが、ポインタの意味がわかっているか試す意味ではいい例ですね。
まるっきり本題と関係ありませんが。