Dell XPS 13 の弱点・HP Spectre x360 の魅力

Dell XPS 13

私はちょっとしたことであれば、XPS 13 というノートパソで諸々の用事をすませて重宝しているのだが、この XPS 13 、長期使用すると弱点が見えてくる。

 

フレームにガタがくる

北米系の youtuber がよく報告している。

水平が出ていない机の上などで長期使用しているとそれに応じて筐体のフレームが歪む。

機能的には問題ないのでいいといえばいいのだが、以降、使用にあたって強度的な不安を覚えるようになる。

やはり、アルミ削り出し+カーボンファイバー張り合わせ、という合わせ技が響いたか。こういう体験をすると Mac 系ノートのアルミ削り出し一体成型の筐体としての優秀さが納得できるようになる。

 

電源はオンなのに画面は真っ暗、キー入力などを受け付けなくなる

使用期間が1年を過ぎたあたりからこの現象が出るようになった。

前面にあるインジケーターも橙色に点滅し、不安を覚えたが、これには解消方法がある。

電源ボタンを長時間(15 秒以上)押して再起動をかける

と何事もなかったかのように立ち上がる。数秒ではダメで15秒以上というのがコツでしょうか。

 

ただ、だからといって XPS 13 がダメダメかというとそんなことはなく、ディスプレイの美しさやフットプリントの小ささなど、他のノートに負けない強みがある。発表からしばらく経ちましたが、いまだに普段使いにちょうど良い機種だと思います。

基本的に win 系ノートは数年で買い換えるものだと考えておいた方がいいのではと思います。

実際、XPS13 は、分解・修理しやすい設計になっていて、SSD の換装などはよく記事化されてます。

使用済みの XPS13 から、SSD のみ取り出して外付け SSD として使う方法を
 さらば XPS13! でも SSD は救うよ 1
 さらば XPS13! でも SSD は救うよ 2
として書きましたので、よかったらどうぞ。

 

HP Spectre x360

次に買い換えるとすれば、もう一回 XPS 13 でもいいのだが、流石に芸がない。

HP の Spectre x360 が候補でしょうか。XPS 13 の弱点だった筐体強度も十分にありそうだし、何よりデザインが美しい。プログラミングにも使うようなら、4K ディスプレイは必要になってくるので、パフォーマンスモデルの一択になりますかね。

色は当然アッシュブラック。 これはかっこいい。

★使用後レビュー

実際に使ってみた感想だが、XPS13 とは直接比較対象にはならないような気がしてきた。

まず、フットプリントが XPS13 より若干大きい。Mac に例えるなら、MacBookPro 13 とほぼ同サイズだ。XPS13 の方が手軽に持ち運べる。

だが、筐体の剛性感はこちらの方が遥かにありそう。

だから、外出時にしっかり使うなんて場合は、Spectre の方が向いてそうだ。

タッチパッドはもうちょっと改善の余地があるでしょうか。



air-h-128k-il

 

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

医療「AI」ソフト

以下の記事は 2018 年に公開されたものです。
AI の進歩は凄まじいものがあり、これを書いた時とは状況が変わってますので、最後に 2025 年現在の状況を書いておきます。


昨今の一般社会に置ける「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 をベースにしたオープンソースのソフトです。これ書いとかないと、最後、何言ってるかわからないよね。失礼しました。

(追記)…日本語によるテキストマイニング、ようやく着手。

(追記 2025 年暮れ)
OpenDolphin は最近はそれほどは関与しておらず、新規に OceanMini というプロジェクトを起こしてます。
OceanMini は最初から AI (特に LLM)と連携することを前提に設計されており、実際、ollama というインターフェースソフトを介して AI モデルに文書の作成などを依頼することができます。
実例は『OceanMini の AI 文書作成機能』などをご参照ください。
このレベルのサマリーを作成してくれれば、臨床的にも使えると思います。
日本語の分かち書きがどうしたこうしたと言っていたのが、馬鹿馬鹿しくなるくらい、この分野の技術は進ました。
その一方で、意外に本質的な変化が起こっていないなと思える分野があり、それは画像系です。特に医療画像系で臨床的にも使えそうなAI系の技術は、それほどありません。
医療画像系はこの記事書いた頃は HorliX に執心してましたが、こちらもやはり 新規の PhorliX 系(PhorliX, phorlix lite)に移行しています。
ある程度意味のある自動診断を実現するためには、

テキスト+画像+検査

を総合的に判断する AI が必要で、現在のところこれはまだ実現できていないように思えます。

 

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

奇跡のコード

先日、IT 関係に詳しい出版関係の方とお話していたとき、私が「ああ、あのプロジェクトは、奇跡のソフトで…」と発言したとき、その方から「奇跡とはどういう意味なんですか?」とより詳しい説明を求められた。

その方は、IT に詳しいとはいえ、実際にプログラマや SE として働いたことはなく、その点に関しては一般の人と変わらない。そのとき「一般の人の感覚ってこんなもんなんだ」と認識を新たにしたので、そのことに関して書く。

あるソフトが「動くには動いているのだが、度重なるソースの改変で、もはや常人にはロジックを追うことすら難しく、たとえプロジェクトマネージャーであっても、なんで正常に動いているのかよくわからない」とき、半ば揶揄の意味を込めて「奇跡のソフト」とか「奇跡のコード」とかという言い方をする。

「でも、そういうのはアマチュアや日曜プログラマが作ったソフトで、メーカーが作るソフトにそういうのはないでしょう」という声が聞こえてきそうだが、これもちょっと違う。最近は諸々の事情もあって、かなり有名なメーカーがリリースしたソフトでも、「奇跡のコード」が含まれている可能性はあると思う。

これに関しては、あまり一般的なことを言ってもしょうがないような気がするので、昔、関わったプロジェクトを例に語りたい。

 

分類:創薬支援ソフト

特徴:薬剤候補化合物を Web 画面から投入、官能基を変化させた類似化合物などを自動的に表示、また、その物理化学的性質をシミュレーションした上で表示

経緯:某大学計算化学研究室で開発→某化学系業界団体が支援→大手N社が Web アプリに改変して販売→某大手製薬企業が購入→バグ発覚→支払いでトラブル→両者膠着状態

 

もう10年以上も前の話なので、より詳しく書いても問題ないと思うが、念のため、かなりぼかして書いた。

たぶん、業界に通じている方なら、「某大学計算化学研究室で開発」あたりで危険な香りを感じていると思う。大学研究室は、一般の人が考えるほど研究の継続性はそれほど高くなく、担当院生が卒業してしまうとその部分に精通した人間が一人もいなくなってしまうということはザラだ。実際、このケースでも(後でわかったことだが)原因はそれであった。

上のように経緯をはっきり書いてしまうとわかると思うのだが、N社はこのソフトに関して Web アプリ化したのみで基本的な部分にはいっさい関わっていない。というか、製品全体に渡って一貫して関わっている技術者は一人もいない。大手リリースの製品であっても「奇跡のソフト」が生まれる余地があると書いたのはこういった事情による。

また、上記案件では、Web アプリといっても企業内 LAN 使用が前提のため、tom…ナントカ あたりでことがすんでいたのだが、N 社の経営陣が気まぐれで「これからはネット社会。どうせ Web アプリ化するなら、外部公開も前提に REST も実装しておいてくれ。VPN もお忘れなく(にっこり)」などと言った場合、もっと悲惨なことになっていたことは想像に難くない。(まあ、この時点では REST はなかったわけだが)このとき N 社プロダクトマネージャー(PM)が、例えば、その仕事を外注に出したとしても、また、それが原因で、その後、REST 周りが奇跡のコード化しようとも、私には、この PM を単純に責める気になれない。現代にあって、有償のソフトを限られた時間内でリリースするのは、相当、プレッシャーがかかることなのだ。

なお、上記プロジェクトは、その後、デバッグ作業が外注に出され

  • 大学教養〜学部レベルの化学の知識のあるもの
  • 医学・薬学に関して実務経験かそれに相当する知識のあるもの
  • 一般的なプログラミングのスキルがあるもの
  • 計算化学特有のロジック・アルゴリズムを追える能力のあるもの
  • 主要開発言語である Fortran の経験があるか短期間で習得可能なもの

といった選抜条件の下、東欧系やインド系の会社とのバトルを勝ち抜いた国内某ソフトハウスが受注。紆余曲折を経て、当時、フリーであった私がデバッグ作業を担当することになった、という次第だ。

なお、デバッグ自体は、まあまあ上手くいき、ごまかしごまかし動くといった程度までには回復した。が、完全に狙った動作を実現する実装ができたかというと、そこまでは至らなかった。奇跡のコードはどこまでいっても奇跡のコードなのだ。

 

開発元がバグを認識していても、なかなか改善されない、とか、自称「開発者」がバグを直したつもりになっても、全然直っていない、とかといった現象を目の当たりすると、一般の人は、不思議に思うかもしれない。が、背景にある国際分業化とか業務の外注化といった状況を考慮すると、しごく真っ当な事情があったりするのだ。

以上、デバッグだとかバグフィックスだとかに関する IT 業界の昔話でした。

air-h-128k-il

 

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

設計図共有サイト

日経新聞が、github のことを「設計図共有サイト」と紹介して、そのネーミングセンスが一時期ネットで話題になった。

「これだから日本のマスコミの IT リテラシーは….」とかなり揶揄っぽい意見が多かったが、確かに github 的な文化が日本に完全に定着しているとは思えない。

私もいくつかのプロジェクトに参加させてもらっているが、やはり海外の有力プロジェクトは参加がしやすい。

例えば、リポジトリのブランチ構成にしても、「本流」ブランチと「開発者用」ブランチを分けていて、どこにプルリクエストを送ればいいのかわかりやすい。

一方、日本のプロジェクトは、本流ブランチ一つだけ、過去の履歴は一切なし、更新するときは、いったんリポジトリを全消去して、ローカルファイル強制プッシュ、みたいなものが多い。

オープンソースかもしれないが、「共有」する気はいっさいないよね(笑)。

ポーズで「github にソースは公開してます。オープンソースです」ってアピールしてるだけ。

 

また、github は github.jp のようなサイトがないことからわかるように(→その後、github.co.jp というのが開設されたようです。周囲で使っている人見たことないけど)、国際的な地域差を意識する機会が少なく、国際化の文脈で語られることも多い。しかし、日本産のプロジェクトは、これもアピール的な要素として利用されることが多く、例えば、外国の方が issue 欄に書き込んでいるにもかかわらず、ガン無視をきめこんでいるプロジェクトがけっこうある。国内にとどまっている限りにおいては、これでもいいのかもしれないが、その後、他言語リソースが欲しいとか外国の参加者を増やしたいという時に、こういった態度はブーメランのように自分に返ってくる。

なので、私は、外国の方が書き込んでくれた場合には、精一杯のおもてなし精神を発揮するようにしている。

Wow…your idea is great!

とか、なんか無理めのレスをつける。日常生活で ’Wow’ なんて言ったことは生まれてこのかた一度もないが。

github は便利な環境だが、上記のようなアピール的な使い方をしていたのでは、少々、もったいないような気がするのだ。

air-h-128k-il

 

OpenDolphin2.7m → OpenOcean

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

どうやら私は今まで勘違いしていたようなのだが、ドルフィンプロジェクトの開発元の LSC(現在は運営権などもメドレーに移管) は、ドルフィン「亜種」には「ドルフィン」という名称は使ってほしくないようなのだ。

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

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

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

 

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

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

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

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

データ移行ツール。データベースに直接アクセスしてカルテ記載内容その他諸々を外部に取り出します。

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

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

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

方針が変わったということなんでしょう。じゃあ、なんで変える必要があったのか?という気がしないでもないですが、新規作り直しするなら、結果的にはよかったのかなと。
OpenOcaen に関してはこことかこととか『OpenOcean 2.0』サイトでまったりと議論が進んでいます。

 

【その他】

開業時のポイント 電子カルテ

地方中核都市で密かに開業計画をたてている医師の記録

でご紹介いただきました。あざーす。

【ソースコード】
https://github.com/Hiroaki-Inomata/OpenDolphin-2.7m

【インストール方法】
OpenDolphin 2.70b を windows10 にインストールしてみた
OpenDolphin-2.7(m) を Mac OSX にインストールする
OpenDolphin-2.7m を M1 Mac にインストールする

【小林慎治の誹謗中傷について】
経緯などはこちらで。
OpenOcean に PR 送ってマージされなかったものだから、逆ギレってのが真相かと。
2020年6月 – 2023年9月 厚生労働省 国立保健医療科学院
2018年4月 – 2020年5月 京都大学 EHR 共同研究講座 特定准教授
・・・
転職回数多すぎやしないか?
同じ職場に 2,3 年しかいれないって何か問題あるんじゃなかろうか。
専門医も持ってないのに「血液内科医」名乗るのも相当恥ずかしい。

 

air-h-128k-il

 

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

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

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

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

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

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

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

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

だから、ドルフィンというかなり一般的な名詞を商標登録すること自体ちょっと無理があったのではないか?と思う。

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

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

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

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

というもの。

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

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

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

 

私が、オープンソースの世界に足を踏み入れて一番驚いたのは、この世界の人々が、こと知財権に関してはかなり素人っぽい考え方をしていることに気がついたことだ(ちなみに私は、若い頃、知財関係の業務は経験してます。専門を極めているということはないですが、通りいっぺんの知識は持っていると思います)。

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

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

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

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

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

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

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

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

ソフトの世界でここまであからさまな例はそう多くはないが、よくあるのが海外の有名なライブラリやフレームワークのサンプルコードをほぼそのまま組み込んで著作権を主張するような例だ。この手の有力プロジェクトは、他のプロジェクトに「使ってもらう」ことが前提になっていて、ドキュメントやサンプルプログラムが充実している場合が多い。よく「〇×を使って、ハローワールドを表示させてみた」という記事があるが、たいてい元になった〇×ライブラリのサンプルの場合が多い。解説記事の著作権は、それを書いた人にあるかもしれないが、サンプル丸パクリのソースコードには(保護の対象となるような)著作権はない。あるとすれば、それはそのライブラリを作成した人、元々のサンプルのソースを書いた人だろう。
実際たびたび指摘されていることだが、オープンソースの電子カルテ LSC 版 OpenDolphinn には、一部の機能に oracle のサンプルコードなどがそのまま流用されている(→『OpenDolphin -wiki 風解説-』)。別にこれ自体は悪くないのだが、ちょっと問題なのは、(経営陣が変わる前の)LSC は、この事実を積極的にはアナウンスせず、特定の人のみで作ったと言い張っていたことだ。

 

これは個人的な意見だが、オープンソースの領域で上記のような子供じみた主張をする人たちの大半のアウトプットは、残念ながら、そこまで(=保護の対象となるような)高い思想性を有しているようには見えない(いわゆる当業者知識の範囲内)。私でも気がつくくらいだから、プロ(メーカーの技術者など)はもっとキビしい見方をしている人もいる。実際、NEC の姉崎さんあたりも同様の主張をしている。
実際の判例を示しながら「(計算機プログラムの)著作物がすべて保護の対象になる」わけではないことを解説している。

https://userdisk.webry.biglobe.ne.jp/000/470/51/N000/000/000/158952642450223506035.pdf より

※・・ただし、私が姉崎さんの主張をすべて認めているかというとそんなことはないです。おおむね、もっともなことは言っているとは思いますが。理由は単純に姉崎さん自体が法的な資格(弁護士・弁理士など)を持っていないから。
GPL などのライセンスは(米国の)弁護士のチェックは受けている。それでも人によって解釈が異なることはしばしばある。法的資格を持っていれば信用できるかといえばそんなことはないが(特に日本の場合)、実際の判例などの細かな解釈ではその分野の専門家ほどには知識も経験も及ばないでしょう。

過剰なまでに著作権を主張するような人たちは、そのプログラムが保護の対象になるような思想性を有していないがゆえに、逆に著作権にかこつけて自己承認欲求を満たそうとしているようにも思える(最近では、小山哲央とかいう人が、出鱈目な主張をして、周囲に迷惑をかけている)。
育ちが悪いというべきか。
実際、標準的な工学教育を受けてない人も多いしね。知財権の基本的な考え方は重要で、これが疎かになっていると、ひどく初歩的なところで間違えてしまう。結果、関与している人たちに迷惑をかけることになる。

著作権法違反が疑われるコメントの掲載はできかねます


自戒の意味も込めて。

 

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

うーん。

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

けっこうあやしいこともやっているので私も完全には信用していないんですけどね。
例えば、メーリングリストでの運営側の恣意的な削除。

great soft! (もちろん HorliX が、ってことです)という投稿は、ものの見事に削除されてますね。今だと HorliX のメーリングリストの方がトラフィックはアクティブでしょう。
他には、こういった手抜き処理など。
ほとんどの医師が、「Horos のコンセプトはいいが、ガチの臨床で使うのには躊躇する」くらいに思っていると思う。

結局、Horos に関しては、ユーザー ML にも「Is Horos abandoned?」というスレが立つ始末
そこでも度々触れられているが、pureView が contributor へのケアを十分にしていなかったから、というのは理由の一つではあるでしょう。
私も contributor の一人なので、他の contributor とはたまに連絡取ってたりしますが、「現状の開発体制なら参加する意義が乏しい」みたいなコンセンサスになってます。

 

(追記)本稿では、主に商標権に関して述べた。
OpenDolphin 自体の著作権に関しては、以前は「皆川和史がプロダクツとしての著作権を保有し、部分的にソースコードを提供した増田茂および松村哲理がその部分に関する著作権を保有している」という説明がなされていた。
が、LSC の経営陣が変わった時点で当の LSC が皆川の関与をほぼ否定、メドレーへの譲渡がなされた時点でメドレーは増田松村の関与を否定している(少なくとも著作権を認めていない)。
詳しい理由は述べませんが、日本のプログラムに関する著作権では、「開発した人」=「著作権者」にはならないため、こういったことはおこりえます。

(追記2)著作権に関しては LICENSE 文書自体を皆川が改竄したことがわかっており(以前から一部では知られていたが、広く認識されるようになったのは 2025 後半)、今後も権利が復活することはないと思います。
皆川は単に GitHub リポジトリの管理権限を持っていただけという理解でいいと思います。

(追記3)当方はあまり変な主張はしていないと思いますが、小林が言いたかったのは「保護されない内容を含む著作物であってもひとたびオープンソースライセンスを付与したら、それは OSS として全ての内容が保護されなければならない」ということだったようです。論理性もへったくれもない。
オープンソースライセンスといえどもその法的な基礎を各国の著作権法においている以上、例えば GPL でライセンスされていても、保護されないものは保護されません。

上は、かなり「気持ち悪い」という評判のついた当ブログに対する小林慎治のコメント。

「不安定なのはお前の知財権に関する理解の方だろ!」

とツッコミ入れたくなる。
彼にとって、知的財産権の論理性のようなものは二の次なのだろう。
医クラ界隈で「小林慎治の思想は独特」と言われる理由が納得できました。
ただ、「OpenDolphin は皆川和史の個人著作です」と解釈するのは自由なので、そう考える人は皆川和史氏の OpenMARS の使用をお勧めします。

 

OpenOcean dev team
air-h-128k-il

 

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

電子カルテ 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 でつなぐなどやらなくてはいけないことはいろいろあるでしょうが、大きな修正なしにクラウド化・多施設化ができるというのは便利ですね。