医療情報システム略語

あり程度実用的な医療情報システムを組むとき、電子カルテ・PACS だけではダメで、オーダリングシステムその他諸々が必要になってくる。英略語が多く出てくるので、忘れないようにメモ。

MWM…Modality Worklist Manager。モダリティワークリスト管理。予約管理システム・オーダリングシステムから受診者の情報を取得し、各種装置(CT や MRI)に通知する。小規模医療機関であれば、この機能を電子カルテに入れ込んだほうが便利かもしれない。

RIS…Radiology Information System。放射線科情報システム。放射線検査依頼管理・レポートの作成など。これも小規模医療機関ならばDICOM Viewer/PACS に入れ込んだ方が使いやすいと思う。

HIS…Hospital Information System。病院情報システム。電子カルテはもちろん PACS ・オーダリングシステムなどをまとめてこういうらしい。

 

にほんブログ村 病気ブログ 医者・医師へ

医療「AI」ソフト

昨今の一般社会に置ける「AI」の認知度や期待は、かなり高いレベルにあるようで、先日、スマフォの操作もままならない田舎の親戚の叔母さんから

「ところで、Ocean や HorliX には、いつになったらAI機能が搭載されるの?」

と真顔で聞かれ、吹きそうになった。まさか貴女の口から「エーアイ」という言葉が出る時代が来るとは….。

ちなみに、Ocean というのは、OpenOcean という電子カルテ。

 

HorliX というのは、「ホーリックス」という名前の医療用の画像ビューア。

暫定公式アイコンはペガサス(ユニコーン? 違いがよくわからない)をあしらった

 

という感じのもの。

両方とも、私が開発にタッチしている。

 

この問いには、こんな風にでも答えればよかったのだろうか?

「やっぱり、プレシンギュラリティの年、2025 年くらいかな。

今は、HorliX で画像自動診断を試しているところ。でも、これは放射線科医の読影に基づく教師あり学習なので放射線科医を超えられない可能性が高い。

時代は強化学習っていうやつなんだよ。

来年あたりには、HorliX-Ocean のシステムに独立したエージェントを持たせる。ORCA (という Ocean と連動する医事会計ソフト)や Ocean の患者転帰が「軽快→死亡」のように変更になったときには、エージェントはそれを見にいって、それを HorliX の AI に伝える。この情報で HorliX は、自分の診断ニューラルネットモデルを最適化していくんだ。

この方式だと放射線科医の読影を超えられる可能性があるね。まあまあ使えるようになるのが 2025 年くらいかな。HorliX が

HorliX
オマエノ読影ヨクマチガウ

ダカラ私ガオマエヲ排除スル

 

と放射線科医を排除と協力するようになるのは、やっぱりシンギュラリティの年、2045 年じゃないかな」

 

一般の人が好きそうな単語を散りばめてみました。

冗談はさておき、一番、実現が早そうな機能は、HorliX 上で稼働するオートセグメント ROI (Region Of Interest…ロイ)でしょうか。

HorliX の ROI に関しては、若干凝ってますので『ROI』をご参照ください。

オートセグメント ROI というのは、以前にさる精神科の先生といっしょに開発した臓器抽出ソフトが基になっている。

臨床の場面では、ある特定の臓器の大きさなどを知りたいということがしばしばある。従来までの方法だと、例えば、腹部 CT 写真の画像から人が手動で肝臓などの領域を切り抜いて(この領域のことを ROI という)画像ソフトに処理させていたのだが、この臓器抽出ソフトはそれを自動でやってしまう。

という写真では、肝臓は向かって左にある。この画像を、このソフトは「肝臓抽出」ボタン一発で

と抜いてしまうわけだ。

これを「AI」というのはちょっとどうかと思うのだが、某雑誌のレビュアーなどは絶賛してくれたので、見る人が見ればそれなりの発明なんでしょう、きっと。

今のところ、肝臓だとか大脳だとか特徴的な形状を持つ臓器ではかなりうまいこと抜いているので、もうちょっと普遍化して、HorliX 上で稼働させたいというのが私の意図。

なお、この機能に関しては、既に特許が成立しているアルゴリズムを使用するため(あるいは新規の特許取得もありうるため)、この機能にかかる部分や場合によっては HorliX 全体のソース公開を停止するということもありえます。(Ocean に関しても同様。ただし、本格的なテキストマイニング研究はやったことがないので、やったとしても当分先)

というか特許保有機関から、公開の「待った」がかかること必至。判断としても妥当なんじゃないかと思うんだが、いわゆる日本の「オープンソース信者」はこういう具体的なケースに関して何ら議論しないよね。謎です。

 

(追記)…臓器抽出ソフトには「機械学習」の手法はまったく使ってません。どちらかといえば古典的な「知識ベース」の AI です。ここらへんの違いをもっと知りたい方は

Reversi -AI の基本-

をどうぞ。リバーシで遊んだだけでも両者の違いが感覚的にわかってくるかと思います。この程度のゲームなら、慣れた人なら背後にあるアルゴリズムを推測できるんじゃないでしょうか。

私は、医療系の AI にはこれが重要だと思っています。

しばしば指摘されていることですが、最先端の機械学習(特にニューラルネットを用いたもの)は、その処理過程を説明するのが苦手です。最終結果は素晴らしいものの、途中で何をやっているのかわからない、という特性があります。一方、古典的な知識ベースの AI は、マックスの性能では機械学習にかなわないものの、その動作を人間が理解しやすいという特徴があります。

医療の説明責任性を考えた場合、古典的な手法も簡単には捨てられないと私は思っています。

air-h-128k-il

 

(追記)…HorliX のダウンロードページは、こちらです。

(追記)…HorliX は OsiriX (直接的には Horos )をベースにしたオープンソースのソフトです。OpenOcean は OpenDolphin をベースにしたオープンソースのソフトです。これ書いとかないと、最後、何言ってるかわからないよね。失礼しました。

 

 

にほんブログ村 病気ブログ 医者・医師へ

OpenDolphin2.7m → OpenOcean

電子カルテ OpenDolphin に関する話。

どうやら私は今まで勘違いしていたようなのだが、ドルフィンプロジェクトの開発元の LSC は、ドルフィン「亜種」には「ドルフィン」という名称は使ってほしくないようなのだ。

私なんかからすると、それぞれの特徴をいかした「〇×ドルフィン」があった方が多様性があって賑やかで良いように思うのだが、そこらへんは考え方の違いか。

細かな事情はよくわかりませんが、某先生からフォークした私の OpenDolphin-2.7m は、 OpenOcean と名前を変えますので、今後はこれでお願いします。

 

先ほど github のリポジトリ名を変えてきましたが、ある意味、気が楽かもしれませんね。ドルフィンの看板が外れるので。

 

これからは、ダイコムビューア HorliX ともども電子カルテ OpenOcean の方もよろしくお願いします。(大事なことなので2回言いました)

【追記】
開業されている先生からもメールをいただきました。

OpenOceanの自動でバックアップする機能は的を射てると思います。おかげで安心して電子カルテ化できます。

私もそう思います。自力で運用をはかる場合、この手の機能がないと使うのに心理的な抵抗が出るのではと思います。より完璧なデータ移行を目指すなら、データベースから直接データを抜いてくることもできます

自力運用を目指す開業医の方からはおおむね好意的な評価をいただいているようなのですがありが、OpenOcean 作り直すかもしれません。
経緯は、『OpenDolphin について』などをご参照ください。個人的には、テキストマイニングをがんばりたい。
HorliX に関してはこちらに解説記事があります

【ちょっと付け足し】
何かのときにLSCさんに聞いたのだが、現在では「OpenDolphinという名称は使っていただいてけっこうです」だそうです。実際、以前にサーバー上に残っていたけっこう物騒な警告文書も削除されたようです。

この辺の経緯は『医療システム』,オープンソースと知財権に関するちょっと小難しい話などをご参照ください。

方針が変わったということなんでしょう。じゃあ、なんで変える必要があったのか?という気がしないでもないですが、新規作り直しするなら、結果的にはよかったのかなと。

 

air-h-128k-il フェイザー合同会社

 

にほんブログ村 病気ブログ 医者・医師へ

オープンソースと知財権に関するちょっと小難しい話

前回の記事『電子カルテ Dolphin Evolution をテスト』で Dolphin Evolution™ などとわざわざ™つまりトレードマーク表記したのは、この開発元の会社と「本家」が商標をめぐって対立したことがあるからだ。

登録第5656156号商標の商標登録に対する登録異議の申立てについて

固い文章なので読みにくいが、かいつまんで言えば「 オープンドルフィン( openDolphin ) を商標登録していたのに ドルフィンやドルフィンエボリューションが商標登録されてしまった。これは、 openDolphin™ の周知性のただ乗りである」という異議申し立てである。

商標は、専用権と禁止権から構成され、この組み合わせのおかげでそれなりに強い排他的独占権を持つ。要するに有名ブランドの登録商標を紛らわしく使ってはいけないということだ。計算機プログラムは原則として著作権で保護されているが、著作権の排他的独占権は弱く(特に特許権に比べた場合、その差は顕著)、オープンソースのプロジェクトがそれなりに育ってくると同一性を維持するため商標を登録しておくことはよく使われる手法だ。

しかし、商標にはかなり実際的な効力の限界があり、この例のように一般的な名詞を持ってきた場合、商標としての機能は著しい制限を受ける。この言葉を一般的な使う場合にはまったく制限を受けないからだ。

これは、しごく当たり前の考え方で、日常的な場面で「ドルフィン」あるいは「dolphin」といった場合、これは海洋哺乳類の人気者「いるか」を思い浮かべることがほとんどで、そういった使用をいちいち禁止できないということを意味している。

だから、ドルフィンというかなり一般的な名詞を商標登録すること自体ちょっとどうか?と思う。

また、個人的には、それにいちいち噛みつくのもけっこう違和感がある。私の記憶に間違いがなければ、ドルフィンプロジェクト自体が国の公募事業として採択された経緯があり、一時的にせよ公的な資金が注入されたものに強い排他的独占権を持たせるという考え方には無条件に賛成するわけにはいかないからだ。そして、異議を受けた側の Dolphin Evolution のプロダクツには、UI を JavaFX で設計する、通信ライブラリをクラウド用に工夫するなどのそれなりの独自性を有しているように思えるからだ。

まあ、「Dolphin Evolution」中心に商標登録しておけばよかったのにね、と思わないでもないが、つい大っきめに権利を主張してしまったのだろう。

なお、この異議申し立ての最終的な判断は、

「登録第5656156号商標(エボリューションの方)の商標登録を維持する。」

というもの。

これは、けっこう妥当な判断ではなかろうか。要は、申し立てした側がやりすぎたということだろう。

また、この異議申し立てが教訓的なのは、新規に始めるにせよ、どこかのプロジェクトをフォークするにせよ、ある程度、独自性がでてきたら、そのプロジェクトには類似プロジェクトやフォーク元とは似ても似つかない独自の名前を持たせた方が良い、ということを教えてくれることだ。

こうしておけば、変な絡まれ方をされる可能性はぐっと減るように思う。

 

私が、オープンソースの世界に足を踏み入れて一番驚いたのは、この世界の人々が、こと知財権に関してはかなり素人っぽい考え方をしていることに気がついたことだ。

知財権に関する素人っぽい考え方とは、著作権に関することだ。主に二つ。

・行き過ぎた排他的独占権の主張

・著作物がすべて保護の対象になるという誤まった考え

前者は、「かくかくしかじかというソフトをつくったから、似たようなソフトはすべて私のソフトの剽窃あるいはパクリ。決して許されない行為だ」というような主張だ。なんかできの悪い小学生の図工の時間をみているようで嫌な気分になるのだが、こういう主張をする人は後を絶たない。著作権の場合、実際的には排他的独占は認められていない。意図的に模倣したならともかくたまたま似たような表現になった場合、どちらかの表現の自由を奪うというようなことはできない。このような主張をする人はおそらく著作権と特許権を混同している。

そして、そんなにオリジナリティや排他的独占権を主張したければ、最初からプロジェクトをクローズで作成し、アルゴリズムなりなんなりで特許申請すればいいと思うのだが、この手の主張をする人たちはなぜかそれをしない。

後者は、「私の制作物を使った場合、その使用権はもともとは私にあり、その権利はすべて保護されなければならない」というような考え方だ。これは主張だけをみれば、それなりに正しそうに見える。実際、商業的な音楽やアートはこの考え方に基づいて著作権使用料などを徴収している。だが、それはその著作物がある程度のオリジナリティを有していて他人がおいそれとは思いつかないような場合においてのみだ。著作物がすべて保護の対象になるかといえば、ならない。これは wiki で紹介されていた例だが

 

長い間ご愛読いただきましたBON TONは今月号(5月号)をもって休刊し、誌面を一新して7月発売で新雑誌としてデビューいたします。どうぞ、ご期待ください!!

という表現は、保護の対象にはならない。それはそうだろう。かなりよくある定型的な表現であり、こんなものまで保護の対象にしていたのでは誰もモノを喋れなくなってしまう。

ソフトの世界でここまであからさまな例はそう多くはないが、よくあるのが海外の有名なライブラリやフレームワークのサンプルコードをほぼそのまま組み込んで著作権を主張するような例だ。この手の有力プロジェクトは、他のプロジェクトに「使ってもらう」ことが前提になっていて、ドキュメントやサンプルプログラムが充実している場合が多い。よく「〇×を使って、ハローワールドを表示させてみた」という記事があるが、たいてい元になった〇×ライブラリのサンプルの場合が多い。解説記事の著作権は、それを書いた人にあるかもしれないが、サンプル丸パクリのソースコードには(保護の対象となるような)著作権はない。あるとすれば、それはそのライブラリを作成した人、元々のサンプルのソースを書いた人だろう。

 

これは個人的な意見だが、オープンソースの領域で上記のような子供じみた主張をする人たちの大半のアウトプットは、残念ながら、そこまで(=保護の対象となるような)高い思想性を有しているようには見えない(いわゆる当業者知識の範囲内)。高度な思想性を有していないがゆえに、逆に著作権にかこつけて自己承認欲求を満たそうとしているようにも思える。育ちが悪いというべきか。実際、標準的な工学教育を受けてない人も多いしね。

だからであろうか、一時的にけっこうな隆盛をほこったプロジェクトも分裂して減弱し、確かな基盤を持たないまま終わってしまうことが多い。

うーん。

ま、難しい話はともかく Horos のようなプロジェクトは、ちゃんと育ってほしいなあと思うのだった。

けっこうあやしいこともやっているので完全には信用できないんですけどね。

 

にほんブログ村 病気ブログ 医者・医師へ

電子カルテ Dolphin Evolution をテスト

JavaFX に若干興味があったので UI が JavaFX で書かれているという Dolphin Evolution™ (Karte Cloud ともいうらしい。開発元はエスアンドアイ株式会社)というオープンソースの電子カルテを試してみた。

 

ソースは github から落とす。

UI が知りたいだけなので今回は client のみコンパイル。

pom.xml を自分の環境に合わせ、適宜修正。NetBeans でビルド。実行すると…

ログインパネルはこっちの方が好みかもしれない。

ついでにサーバを立ち上げ、ログインを試みる。データ構造や通信プロトコル自体は本家と同じらしく、若干エラーは出たものの問題なくつながる。定番の徳川さんを表示。

初期設定は全画面表示だったので、けっこうびびる。

確かに画面構成は通常のドルフィンとは違う。ウィンドウをぱかぱか開くより一画面で操作を完結させたいという意図のようだ。

だが、結局使い慣れたサイズで使用(笑)。

そんなわけで操作上は JavaFX の有難みをそんなに感じることはなかったのだが、JavaFX ではこの手の UI のつくりこみが swing に比べ簡単になるという。

諸々の事情で Java で何かを新規につくるということはもうないかもしれないが、今後も横目でちらちらとチェックくらいはしていきたいものだ。

変更したコードはこちら

 

クラウド化した電子カルテサーバにオンライン診察向きのビデオチャットサーバをたててみる

前回の記事のためにひさびさにクラウド化したドルフィン(という電子カルテ)サーバを走らせたので、ついでで同じマシン上にオンライン診察を意識したビデオチャットサーバを立ててみた。

近年の通信技術の進歩は恐ろしい勢いで進んでいるようで、割と簡単に立てられました。

 

実際に使うとすると以下のような流れになると思います。

まず、自院サーバのどこかにチャットルームをつくり(下の例では http(s)://自院アドレス/test)、そこにブラウザで入室する。ルームの名称はなんでもOK。

 

 

患者さんには、そのアドレスを教え、ブラウザでそのアドレスを踏んでもらう。今回は Mac のクロームで入室。

患者役がいなかったので椅子で代用したのは大目に見て(笑)。

なお、今回の例では、映像・音声データはブラウザ間を流れ、サーバはあくまでそのアシストをしているのみ。とにかく高速でデータを流す。

つくりながらオンライン視察のガイドラインをちらちら眺めましたが、役所的にはこちらの仕様の方がいいようですね(下手にサーバにデータを蓄積させると漏洩のリスクがあるから)。

 

ところでこの手の新技術を取り込む際には、パッケージングというのが頭を悩ます問題。

メドレーのクリニクスというシステムは、電子カルテ+オルカ(というレセコン)+オンライン診察を一体化したそうだが、ガイドライン的なものを横においてもそういう「」なパッケージングがよいのかどうか?

ちなみに国のガイドラインはこの手の「密」なアプローチを推奨していないように思えます。
『オンライン診療の適切な実施に関する指針(案) – 厚生労働省』

この分野がまだ発展段階であることを考えると、各サブシステム同士は「」にゆるく結合させておいた方が将来的な拡張などを考えるといいように思うのだが、どうだろう?

また、実際的な利用場面を想定すると、患者さんの同一性をどう担保するかといった問題がある。

個人的な意見をいわせてもらえれば、

医療等IDの社会的・インフラ的確立→遠隔医療・医薬看介連携システムの整備

と進んだ方がすっきりしたはずだが、リアルポリティクスでは、なかなかそうは理想的にことが運ばなかったのでしょうね。

ところで、これに関連して電子処方箋のガイドラインもちらっと読みましたが、あのシステムのわかりにくさはいったいなんなんでしょうね?

『JAHIS 電子処方せん実装ガイド Ver.1.0 – 保健医療福祉情報システム

air-h-128k-il

 

にほんブログ村 IT技術ブログへ

電子カルテのなんちゃってクラウド化・多施設化

電子カルテはクラウドが流行っているので OpenDolphin でもできないか検討。
具体的には、マイクロソフトの Azure 上に OpenDolphin のサーバをデプロイし、複数のクライアントから通信を試みた。

デフォルトの 1.3.6.1.4.1.9414.70.1 のドルフィンクリニック(管理者 admin さん)の他に

追加で    1.3.6.1.4.1.9414.10.1 のイルカクリニックを登録(ついでに管理者 dolphin さんも登録しておく)。

クラウド上に設置したサーバに対して admin さんと dolphin さんが異なる場所から同時に接続を試みる。

するとサーバ側ではこんなログが取れる。

クライアント端末でもしっかりつながってました。

実運用では、セキュリティを高めるため VPN でつなぐなどやらなくてはいけないことはいろいろあるでしょうが、大きな修正なしにクラウド化・多施設化ができるというのは便利ですね。

 

医療機関情報が取得できませんでした。

ひさびさに日本医師会純正レセコン orca をいじってクライアントを立ち上げたらら、「医療機関情報が取得できませんでした。処理を終了してください」というメッセージが文字通り赤文字で表示され、ほとんどの操作をうけつけない。

「あれ、なんかおかしなことしたっけ?」と不安になったが、

sudo service jma-receipt restart

で再起動させたら、問題なくログインできた。

けっこうよく出る症状のようですね。

 

 

orca のソースコードを取得する

日本医師会はフリーのレセコンソフト orca を開発していて、かなり普及している(素晴らしい!)。これまでにもお仕事として構築支援をたびたびおこなってきたのだが、ソースコードを眺めたことは一度もなかった。

今後もご厄介になると思われるので、ソースコードの取得を試みた。 “orca のソースコードを取得する” の続きを読む

初めての HP

たまには仕事の話。

最近、小規模な医療・福祉施設向けの HP (ホームページ)の作成依頼が重なって、そちらの方に精を出していた。

ちょっと興味を持ってその手の分野を調べたのだが、費用の相場はたいてい 『初期の HP 作成料』(5万~程度)+『月々の管理料』(1万~程度)のようだ。

ある程度の規模の施設の場合、月々の管理料は問題ならないのだろうが、数名程度の施設の場合、この価格構成、特に月々の管理料が発注側の悩みの種となっているようだ。「効果があるのかどうかもわからない、使いこなせるかどうかもわからない情報発信媒体に少額とはいえ月々費用を投じていいものか?」というのはまあ納得できる話だ。 “初めての HP” の続きを読む