ORCAのアーキテクチャ(Linux)

久しく間が飛んでしまったのだが、まだまだORCAをよく知らない人にとっては謎な部分は残っている。ということで再開。初めての人は(序)から読んで欲しい。

ORCAにはDebianを使っている。この辺もよくつっこまれるところだ。

そもそも、なぜORCAはLinux上かということについても説明が必要だろうと思う。これには

  • 技術的理由
  • 政治的理由
  • 営業的理由

がある。

技術的理由

当時、少なくとも構想の上では、かなり大規模なネットワークが想定されていた。元々、当時想定していた医療機関は「内科の開業医」だった。これは「内科の開業医」が日本で一番多い医療機関だからだ。ボリュームゾーンを攻めるのは、この手のリソースに限りがあるプロジェクトでは当然のことだ。とは言え、医師会員は様々な専門科があり、医療機関の規模も小さなビル内診療所から大病院まである。このプロジェクトがコケない限り、そういったものを全てカバーするという話になるであろうことは、容易に想像出来た。

また、ORCAは「タダのレセコンプロジェクト」ではない。元々がネットワーク化のためのプロジェクトであり、その構想も「全医療機関のネットワーク化」という壮大なものだった。「全医療機関」が現実か妄想に過ぎないかは我々の知るところではなかったが、つまりはそれくらいの規模のことを考えなければならないということだった。仮に1割の医療機関を対象にしても、5000ユーザのネットワークだ。

そういったものをローコストに実装するには、何らかのOSSなUNIX系のOSでなければ、原因不明の障害の調査が難しかったり、対処が困難だったりということを予見した。当時のLinuxは、今と違っていろいろな点でイマイチではあったのだが、ちょうど大手メーカがいろいろな形で参入し始めた頃でもあったので、そういった「商用」的な部分でBSD系に対してアドバンテージがあった。

政治的理由

元々、医療機関はITに疎いところが多かった。そのため、事実上の必需品であるレセコンはわりとメーカのいいようにされて来た。一番酷いのはリプレースをする時のデータの移行について、リプレース元のメーカ(ベンダ)は非協力的で、うっかりリプレースでもしようものなら、手作業でデータ移行させられたものだった。

そもそも、そういった大袈裟なことでなくても、自分のところのデータを自分たちで好きに加工したり見ることが出来なくされていたということで、ちょっとITのわかる医師にとっては

自分の持ってる医療情報が使えない

というのは、不快を通り越して怒りを感じるものだったらしい。そういったことで、「メーカ」に対する恨みはハンパなかった。と同時に「プロプライエタリ」に対する警戒感も強かった。

時代はちょうど「Linuxバブル」なることが言われる時代でもあったので、「反プロプライエタリ」の代表であるLinuxに対する期待は大だったし、また説明も楽だった。「インストールした環境をまるっと渡してもライセンス違反にならない」というのも、いろんな意味で好都合だったのだ。

営業的理由

これについて私はあまり細かいことを知らない。なぜなら、以前にも書いているように、私は政治家や営業というより「技術者」としてのみタッチしていたからだ。

とは言え、その時の私の紹介のされ方は「日本Linux協会会長の」という枕詞がついていたので、営業をしていた人達は「そんな人を押えてるんだぞ」と言いたかったようだ。また、ドットコム・バブルの最中でもあったので、(今はなき)VA Linuxや(今はなき)Linux Careのように

Linuxをネタに子会社上場

とか考えていたフシもあって、「Linuxにポジションを持つ我々がLinuxで大規模システム開発」ということで売りたかった(実績を作りたかった)ということもあったようだ。

まぁそんなことで、諸々の背景を持ってORCAはLinux上のシステムということになった。

このことには、いまだに賛否ある。特にインストールするのにそれなりのスキルを要求されるということに対してはネガティブな意見を持っている人が多いようだ。これについては、現在ではますますナンセンスな主張であると思う。

そもそも、「レセコンシステム」という点だけを取っても、そうそう気楽に入れて欲しいものではない。なぜなら、レセコンシステムというのは

医療機関の基幹情報システム

であるからだ。つまり、止まるとか壊れるとかということは、原則的に許されないシステムだということだ。もちろん導入前には手作業でやっていた業務なのだが、一度システム化してしまえばもう手作業に戻ることは困難だ。「レセコンやめて手作業にします」と決定をした上であれば、マスタを紙に落として… という準備期間が設けられるが、止まったとか壊れたとかいうことだと、そういった情報には一切アクセス出来ない。だから、止まるということは許されない。

となれば、それなりに覚悟をして入れる必要がある。そういったことを考えれば、高々「インストールが簡単」というようなことは、全体の手間から見れば誤差のうちでしかない。事前準備、移行作業、運用開始などに係る手間の方がずっと大きい。下手にインストールのハードルを下げてしまうと、そういった覚悟なしに入れられてしまう。いや、入れるのは親しんでもらうという意味で良いことなのだが、そのまま運用に入られて後からギャーということになってもらっても困るわけだ。いやいや、別に後で困ることになっても、

Your own risk

ということでやってもらっていれば良いのだが、医師会員にしてみれば「自分たちの会費で開発したシステムなんだから」ということで、「保証」を求めて来る(*1)。というような実際上の問題もひっくるめて考えると、覚悟のない人には入れられない程度のハードルは必要だと考えている。今となっては、技術的ハードルは仮想化とか使えばいくらでも下げられるし、実験的にはMacやWindowsの上でも動くのだが、優先順位の低い課題になっている。本当は「つぶクリ」のことも考えれば、もっとハードルを低くしたいという気持ちはあるのだが、サポートセンターやスレの状況とかを見る限りでは、これ以上ハードルを下げることは、マクロ的には

百害あって一利なし

になってしまう。

長くなってしまったので、Debianを選択した事情はまた次の機会に。

*1 いわゆる「オプソ業界」な人達からは信じられないことであるが、ORCAは保証が要求されてしまうシステムなのだ。確かに「基幹業務システム」であるから、無保証というのは言いにくい。我々の常識から言えば、「OSSで保証が欲しけりゃ業者を使え」ということになるのだが、なぜだかORCAの世界ではそれが通用しない。また、妙に「いい格好しい」の人がいるため、「日医が出すからには保証が必要」みたいなことを言ってしまう人が少なくない。そういったこともあるため、レセプトシステムのアプリケーションに関しては、「OSD準拠でない」ライセンスになってしまっている。

あくまでも私見ではあるが、この手のソフトウェアにOSD準拠なライセンスを適用するのは、運用的に難しい。何らかの「責任」の所在を求めてしまうと、OSDの想定を外れてしまうのだ。本当は「ソフトウェアはフリーだけど無保証」と言い切ってしまって、サポートは金を取るようにするべきだと思うのだが、「いい格好しい」の人達が我田引水な論理を展開してくれるので、それも難しい。