OpenDolphin2.7m → OpenOcean

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

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

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

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

 

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

 

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

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

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

前回の記事『電子カルテ 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 – 保健医療福祉情報システム

 

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

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

電子カルテはクラウドが流行っているので dolphin でもできないか検討。

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

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

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

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

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

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