2008.05 複雑なものを簡潔に

わーくすてーしょんのあるくらし ( 183 )

2008-5 大橋克洋

日本らしい季節の飾りをみつけ

コラムの表紙としてカメラにおさめました

< 2008.04 春はあけぼの | 2008.06 Seagaia meeting 2008 in KYOTO あれこれ >

○ 複雑なものを簡潔に

差別用語などという(おかしな逆差別)風潮に逆って言えば、 次のような2つの区別ができるかと思います。

頭の良いひと: 複雑なものを簡潔にしてしまう

頭の悪いひと: 簡潔なものを複雑にしてしまう

3月に「弱者切り捨て、、特定健診」で 「特定健診の結果を XML 形式での提出が義務付けられたが 実用面から CSV 形式にすべきだった」と書きました。 ことほど左様に、日本では「簡単なものをわざわざ複雑にしようとする」 傾向があり、 それにより「無駄な経費」と「無駄な人的パワー」が費やされています。

私が学生の頃、名講義で有名な教授が何人かおられました。 生理学教室の阿部正和先生の講義 もそのひとつです(まだ教授ではありませんでした)。 小学生に教えるようなやさしい講義で、 考えてみると その日教わったことは たった3つ位です。 名講義は皆、メリハリを利かせ要点を絞ったものでした。 つまり相手に「要点を簡潔・明快に伝えられる人間が 本当に頭の良いひと」なのだと思います。 そこを目指してはいても、さして頭の良くない私には なかなか難しいことです。

阿部正和先生は、すべての学校でトップを通した秀才で、 後日、慈恵医大学長を務められました。卒業後20年ほど経て 何かの懇親会で阿部学長とお話する機会がありました。 「大橋君は何年卒?」と聞かれるので、 「昭和41年卒です」と答えると、 「ああ、君のお父さんは医師会長をしていたでしょう」と言われ、 ひっくり返りそうにびっくりしました。 阿部先生とお話したのは、その時が初めてだったのです。 どうして父のことをご存知だったかわかりませんが、 数多い卒業生を正確に記憶されているのには、ただただ感服でした。

もうひとり例を挙げると、 初代 Apple コンピュータを創った Steve Wozniak があります。 彼は Apple II に接続する Hard Disk Drive を 従来から考えると信じられないほど僅かな部品で作り上げました。

さらには私が最も尊敬するプログラマー、 HyperCard を創った Bill Atokinson がいます。 HyperCard は現在考えても素晴らしいソフトウエアです。 非常に洗練されたシンプルな仕様でありながら、 ありとあらゆることを簡単に実にスマートに実現できるものでした。 こんな洗練されたものを、 ほんの僅かな期間で一気に創り上げてしまった Atokinson は、 レオナルド・ダヴィンチにも匹敵する天才と思っています。 現在のマシーンパワーと、 ネットワークやデータベースがあれば、 無敵を誇るソフトウエアに違いないはずですが、 誰も後を継ぐことなく Atokinson も今では写真家になってしまいました。

私が Apple を好きで MS を好きでないのは、 両者にまさにこのような違いがあるからなのです。 MS にも頭の良いひとは沢山いるはずですが、 組織が巨大すぎて簡潔にすることが不可能な状況なのではないかと推測しています。 やはり組織も「見通しが良い」状態でないとね、、

○ 最近のビル建築

2004年12月、近所のビル解体をレポートしました。今度はビルを作る方です。 私の住むマンションが建ったのは 1982年7月のことです。 当時すでに近所にはいくつかマンションが建っていましたが、 13Fのこのマンションはこの辺りでは高い方で 四方がよく見えました。

新宿副都心、東京タワー、東京湾の船の科学館、横浜ランドマーク・タワーや その隣の三日月型のコンチネンタル・ホテル、そして正面には富士山。 ところが現在ではどうでしょう。これらの中でまだ見えているのは、 副都心と富士山だけになりました。周囲に高いビルがどんどん建ってしまったのです。

このたび寝室の目の前に、衝立てのようにそびえるビルが建ちました。 前回のレポートでは、ビルの屋上に乗ったユンボが ビルを解体しながら、どうやって下の階へ降りてゆくのか、 ついに解明できず終わってしまいました。 その後 気になっていたのは、 高層ビル建設でよく見かけるタワー・クレーンです。

一本の円柱の上にクレーンが載っているやつで、 円柱は竹の節のような構造になっています。あの円柱をどうやって増設しながら、 クレーンが立上がって行くのでしょう。解体はどうやるのでしょう。 クレーン自身で円柱をつり上げ作業するのだと思いますが、 自分を支える円柱をどのように繋ぎ合わせて、 伸びたり縮んだりするのかが 気になっていました。 そしてついに それを目撃できました。

2006年11月のこと、目の前にあった 工場 兼 事務所のような建物の解体作業が 始まりました。

右手前の赤いのがタワークレーンです。円筒を竹の節のように繋ぎ合わせ、 その上にクレーンが載っています。しっかりした土台を築くのでしょうが、 それにしてもたった一本の円筒だけで よく横方向の剛性が保たれるものと感心します。

これは2007年12月31日、水平線見納めの写真。 年が明けて、あと1フロアー組み上がれば、 横浜方面の景観はまったく閉ざされて見えなくなります。

あれから5ヶ月目、いよいよビルは完成に近づきました。 周囲の足場も取り払われ、タワークレーンの解体を目撃することができました。 ちょうど5月の GW とあって、自分の部屋から窓に張り付いてウオッチしました。 巨大なクレーンが たった一人か二人の手で解体されて行くのを見て、 「凄いなあ」と思ってしまいました。

仕組みはこうでした。円柱頂上に四角い鉄わくが見えますね。 あそこから、クレーン本体の床にかけて滑車が繋がれています。 その滑車を操作して、まずクレーン本体を1節分ゆっくりと下降させます。 下の円柱上端には排気口のように見える縦溝が周囲ににグルリと刻んであり、 そこへ本体から生えている4本の爪が食い込んでストッパーになります。 写真では鳶職が爪を固定しています。ストッパーで固定したら、 滑車は外してしまいます。

こうしてクレーン本体が一節分 降がったところで、 作業中に円柱が倒れないよう 円柱のてっぺんにクレーンのワイアーを接続しておきます。 次に円柱と円柱を接続した部分の接続ボルトを、 鳶職が手作業で1本ずつはずしていきます。 ボルトが全部はずれたところで、 円柱はクレーンに釣られて下に待ち構えたトラックの荷台へ降ろされます。

私の部屋の目の前のビルなので、 「醜悪な外観のビル(この辺りにはそういうのが多い)だと嫌だなあ」 と思っていたのですが、 白いタイルで構造も非常にシンプルな私好みのデザインでした。 本当に良かったです。

ビルの外観は自分だけのものではありません。 このように 他人に嫌な印象を与えない、街の景観を壊さないようにしたいものですね。 それにしても考えてみると、 あの竹の節をつなぎ合わせるボルトは、 よほど特殊な丈夫な合金なんでしょうね。 台風などの横風があれば かなりの応力がかかるはずで、 それにたった数本のボルトだけで耐えるのも凄いと思いました。

○ 電子カルテ未完成版をむりやり現場投入

今月、このコラムのアップデートが滞っていたのは、 以下のような理由からです。

5月1日を期して、1年前から開発してきたまったく新しい 電子カルテ Web 版 NOA を、診療の現場に投入しました。 今年の正月から現場投入するつもりだったのですが、 以前のデータのコンバートその他、 やっておかなければならないことが幾つかあることに気づき 遅れてしまったのです。

とはいえ、この電子カルテはまだまだ開発途上のもので、 最低限の機能がようやく動き出した程度の代物です。 当然ながら実際に使ってみると、ボロボロ不具合が出て、 いやあ、額に青筋立てて診療をすることになりました。 特に5月は特定健診などという、 やたら事務量の多いものが始まったのでさらに大変です (この非能率的な特定健診のようなものこそ、 今後は新しい電子カルテで快適に診療できるようになるはずです)。

なぜ、このように未完成品を現場投入したかというと、 自分の尻にムチ打つにはこれが一番だからです。 現場投入となると 何が何でも使えなければ困るわけで、 「火事場の馬鹿力」も出ます。 もうひとつ、電子カルテを開発し使ってきて20年を経てもなお、 「机上で考えていたことと現実とは違う」ことが沢山あり、 現場投入のリスクを補って余りあるものなのです。

こういう荒技のできるところが、 ユーザを持たない一匹狼の最大の強みですね。 さて、大変な思いをして1週間ほどで 多くの致命的問題をクリアし、 順調な歩みを始められそうになってきました。

○ Seagaia meeting 2008 in KYOTO

さて恒例の Seagaia meeting が京都で開催されました。 京都は2度目となります。今年は例年になく中身の濃い meeting となり、大変充実した思いで帰ってきました。 一度に全部は書けそうにありませんので まず概略を紹介し、 後から枝葉をつけていきたいと思います。

  • 22日(木)Programmer's Camp @京大芝蘭会館別館

      • 13:00 openEHR の理解と MML の今後

        • まず MedXMLコンソーシアム技術委員長の中島裕生さんから openEHR の基盤となる ArcheType の概説

          • 欧州を中心に開発されてきた EHR:Electoronic Health Record を背景とした標準規格 CEN13606 が今年1月に ISOTC225 委員会で承認。 その実装をオープンソースとして提供している openEHR プロジェクト。 そして CEN13606 の特徴である ArcheType(アーキタイプ)技術について解説がされました。

          • ArcheType については、 先日の東京で行われた Leslie 夫妻の講演でようやく概要が見えてきました。 私の理解したところについては、後でまとめて書きたいと思います。

        • 次に小林慎治先生から、オープン・ソースの話と ArcheType の技術的解説

          • わかってくれば、かなり前からある概念ではあるのですが、 さすがオープン・ソースをうたう人達の創るものだけあり、 非常に柔軟性があり実戦的なところが私は非常に気に入っています。

          • 興味のある方は小林先生がやっておられる openEHR のサイト をご覧ください。

        • 18:00 懇親会@ホテルフジタ京都 B1「桂花林」

      • 23日(金)Seagaia Meeting @芝蘭会館本館

          • 13:00 openEHR とは何か( Dr.Heather Leslie, Dr. Hugh Leslie 夫妻)

            • Dr. Hugh Leslie & Dr.Heather Leslie 夫妻

              • 前半は奥さんの Heaher Leslie から、ArcheType の構造と臨床モデルの解説。 彼女は産婦人科医で私と同業の方でした。 大変熱心に ArcheType の構築を行われているようです。 産婦人科関係の ArcheType が充実していそうで楽しみです。

              • 後半はご主人の Hugh Leslie から、 ArcheType のエディターなどのデモを交えた解説がありました。 冒頭で「ArcheType はアプリケーションではない」ことが強調されました。 アプリケーションの下で、 データをサービスするための仕組みということです。 先日の東京セミナーでもそうでしたが、それにもかかわらず 「そのようなもので病院の電子カルテに使えるのか」という、 本質を理解しない質問が見られました。

          • アプリケーションの面からしか見られない エンドユーザにとっては わかりにくいと思いますが、 長年電子カルテの実装を行ってきた人間にとって、 このようにしっかりした柔軟に運用できる容れ物があると、 実装が非常に楽になり嬉しいところです (頭の固いソフト屋さん達は決して理解しようとしないでしょうが)。

          • 本家 openEHR のサイトは こちら 。 オープンなので、ArcheType のエディターなどを自由に download できます。MacOSX でも Java 版がそのまま動くのは嬉しい。

          • 芝蘭会館で行われた懇親会の後の2次会@極楽とんぼ

          • この店は 2004-6 のコラムに書いたことがあります

          • 偶然ですが今回宿泊したホテルのすぐ裏にありました

      • 24日(土)Seagaia Meeting @芝蘭会館本館

          • 09:30 サイバー・ラボの新パラダイム

            • 加藤康之 氏による ひさびさの「カトー・ワールド」

              • 長年育ててきた Cyber Framework を Web アプリケーションへ移行したという話です。 「Cyber の技術を世の中に安く提供するには Web アプリとするのが良い」という発想とのこと。 後述するように「あっ、また加藤さんも私と同じことを考えている」と、 大きな そして嬉しい感動を受けました。 Flash を使ったスムースな操作性は、 まさに「KATO's World」を彷彿とさせるものです。

              • 加藤さんは Leslie 夫妻の講演は聴かれなかったようですが、 奇しくも中味は ArcheType を実装したアプリの話と言ってもよいようにも 思えました。「ArcheType を使って現実に使えるのか?」という質問への 回答とも言えるな、と個人的には思いました。

            • サイバーラボ加藤さんのデモを初めて見たのは、 10年前の Seagaia meeting でした。 あの頃、実現をめざした電子カルテ用パーツのアイ デアがありましたが、 実現が大変で投げだしていました。 ところが加藤さんは私のアイデアと同じものを、 とてもエレガントに実現しているではないですか。 カルチャーショックと共に「やればできるんだ」という自信を得て、 私もついに実現することができた経緯があります。

            • 5年ほど前から「電子カルテの周辺ツールは 世の中の人々とシェアできるべき」と考えるようになり 「それには電子カルテを Web アプリにするのが良い」ということで、 Web 版電子カルテに取り組みはじめました。 今回もまさに同じような展開です。

            • さすが天才加藤さん、私とは実現するレベルが違います。 加藤さんは、Flash を使ったエレガントな実装ですが、 私は しばらくは Javascript により 機能実現を図って行きたいと考えています。 画面の中で複数のペーンを使い分けるのは 私と同じ発想ですが、 その手法が私とはまた違ったやり方で、 「同じことを実現するにも 個性がでて面白いところだな」と思いました。

          • 13:40 裁判の証拠として「電子カルテ」はどう対応すればよいか(大橋克洋)

              • 先日、東京都医師会の顧問弁護士さんから 「裁判官が電子カルテの勉強をしたいということで 勉強会を開いてくれないか」との希望があり、 東京都医師会で勉強会を開催。 東京地方裁判所医療集中部から、10数名の若手裁判官の方々が参加しました。

              • 私は過去に「電子カルテ記録の保存に関する三原則」を決めることとなった 厚生省の委員会のメンバーでもありましたが、 今後の裁判における電子カルテの扱いを左右することともなり、 大変重い責任を感じつつ対応させて頂きました。

              • 事前に頂いた山のような質問に時間内に答えることは無理で、 Q & A としてペーパーにしたものを用意し、 プレゼンは「医療の世界の実情」「電子カルテの仕組み」などを前振りとして、 事前の質問への回答となる内容としました。 私が最も危惧することは「医療現場の実情にそぐわない規制がかかること」です。 セキュリティーはいくらやってもきりがなく とてつもないコストがかかりますし、 医療の現場に本質とはまったく無関係の負担を強いられるのも困ります。

              • 結論として「医師や看護師にとっての電子カルテとは、 コンピュータの中の磁気記憶ではなく、あくまで画面に見えているもの」 「従って証拠保全はコンピュータ画面のハードコピーが最も現実的」 ということを強調しました。聞いてみると実際に裁判所では証拠として 「紙」媒体を基本にしており、証拠保全も画面のハードコピーで 行ってきているとのこと。双方の結論が一致したのは何よりでした。

            • というようなことを Seagaia meeting で レポートとしてお話しました。

          • 14:00 EHR の今後と進化

            1. Google の基盤技術

                1. Google Japan テクニカルアカウントマネジャー

                2. Tommy Kan 氏

                  1. 今もっとも旬なのは、数日前にリリースされた Google Health や android です。残念ながら Google Japan では、 まだこれらについてお話する状況ではないということで、 Google のいろいろなサービスを支える「Google の基盤技術」についての話でした。

                  2. Google のサービスを支える技術は、 基本的に Google 自前(独自開発)のものであること。 そしてハードはというと、安価な PC を沢山接続していること。 これらを並行動作させ、ダウンするマシーンがあればシステムを稼働させたまま、 新しいマシーンにすげ替えられる。そのため専用の OS まで自前だそうです。

                3. つまり従来のコンピュータ会社の概念とは違った 新しいパラダイムでシステムを構築し運用しているようです。 これは想像に難くなかったところですが、 とても興味深く拝聴しました。

            1. 地域医療連携の問題点と未来

              1. 会場風景(最後のセッションとあって、ちょっと少なめ)

                  1. 吉原博幸@京大 先生からは、Dolphin Project における中国をも含めた 広い地域を接続した地域医療連携システムの構想。 京都「まいこネット」における受診者への医療情報サービスの話。 そして携帯電話サービスの構想などが話されました。

                  2. 荒木賢二@宮崎大 先生からは、宮崎における「はにわネット」の現状と将来。

                  3. 有田憲司さんからは、携帯電話を使った受診者向け医療情報サービス uDolphin についての話や、その画面サンプルのデモ。

            1. 札幌生協プロジェクト

              1. 日本トレーサビリティー協会 大松重尚 氏

                  1. 「日本の食べ物の世界で何が起きているか?」というタイトルの講演です。 今回の Google への講演依頼に伴い、Google Japan の村上社長から「システム的にやっていることは EHR と似たようなことなので、 面白いのではないか」と紹介頂きました。

                  2. 食品界では「食品カルテ」と呼ぶものを使い、 その食品がどこで作られ、どんな原料を用いているか、などをトレースしている。 食品の種類・組成などは日々変わり その種類や数は膨大なので、 粒度を細かくしたデータベースなどでは運用の面から管理不可能である。

                  3. 試行錯誤の結果、食品名や組成などほとんどを平文で記録し、 検索エンジンで全文検索する方がはるかに効率的なことがわかった。 膨大な数を解析していると面白いことがわかる。 同じ成分名でも会社ごとに微妙にネーミングが異なったりする。 これら細かい特徴を解析することにより、 全文検索で十分実用的な検索・運用ができるようになった。

                1. これも同感ですね。私もかねがね電子カルテの記述内容を細かい粒度に分けて DB に格納することに疑問を感じてきました。 「ハード・ソフトが格段に進歩した現在では、 シンプル・イズ・ベストで全文検索の方が実用的なのではないか」と。 現在、開発中の Web 版電子カルテ NOA も、 以前からの流れで細かい粒度の部分も持っていますが、 診療記述などの本体部分は そのような方向へ持って行こうかと考えていたところです。

○ 現時点で私の理解する ArcheType

Leslie 夫妻による openEHR と、それを支える基盤技術 ArcheType の話を 東京セミナーと Seagaia と2度聞いて、それまでわからなかった ArcheType の概念がおぼろげながら分かってきたような気がします。 現時点における私の理解するところを書き留めておきます。 まだ正しく理解していない部分もあるかも知れませんが、 概略は間違っていないと思っています。

  1. ArcheType はアプリケーションではない

    1. 前述のように ArcheType は「医療情報を格納する容器」です。 エンドユーザは別途アプリケーションにより、 これら容器に入った情報を使います。 これまで私はよく「宅急便の段ボール箱と上に貼るラベル」の例えを使ってきました。 ArcheType はこれをさらに目的別にしたものです。

  2. ArcheType は容れ物

    1. Heather さんは臨床モデルの分かりやすい例として「血圧」を使っていました。 「血圧」という容器を作ります。その中には、収縮期血圧、拡張期血圧が入ります。 さらには血圧の基準値、測定は立位か臥位かあるいは何度の角度で寝て測定したか、 その他、血圧に関して考えうるあらゆる項目を入れられます。

      1. 血圧という容器には「仕切り」を作って、 必要なものを分別収納できるようになっています。 お子様ランチや弁当箱のようなものですね。

  1. ArcheType は誰でも使い回しできる

    1. openEHR ではこれらの標準容器を集積し、 誰でも使えるようにします。つまり共有ですね。これがひとつのキモです。

  1. ArcheType は誰でも拡張できる

    1. とはいえ私が使おうとする時、まず日本語が使えないのは不便です。 大丈夫、不便を感じたユーザが自由に拡張できるのです。 つまり私が日本語の仕切りを増やしてやればよいのです。 これがまた集積され使い回しされます。 つまり皆で便利に拡張・改良してゆくわけですね。

  1. ArcheType は混沌を招かないか

    1. 誰でも勝手に拡張できるということは、 「ぐちゃぐちゃなものになる」ということでもありますね。 そこで「拡張を管理する組織」を置きます。そこで常識的な拡張ということが認められれば、 集積される仕組みです。

  1. ArcheType は巨大なものにならないか

    1. そうして管理されたとしても、雪だるま式に膨らんで巨大なものになりそうですね。

      1. そこで ArcheType の上位のテンプレートという概念の出番です。 ArcheType はそのまま使うものではありません。 まず用途ごとのテンプレートを作り、 その要素として目的にあった ArcheType を組み込みます。 ArcheType の中の沢山ある属性(弁当箱の仕切り)の中から、 自分に必要なもののみを選んでテンプレートへ組み込みば良いのです。

      2. このようにすることによって、 実装面に大きな負荷を与えることがありません。 かつ、容器は万国共通で使い回しできます。

  1. ArcheType の もうひとつ嬉しいこと

    1. そのようにアプリに組み込むテンプレート、すなわち ArcheType の集合は 必要最小限のものにすることができますが、 かつ ArcheType の属性を利用することができます。 つまり、カルテのデータとしては収縮期血圧と拡張期血圧だけ しか記録していなかったとしても、 基準値などは集積所の ArcheType が覚えているので、 そちらを利用できます。アプリケーション側に余計なものを背負込む必要がないわけですね。

  1. ArcheType の さらに嬉しいこと

    1. 医療情報記述の標準規格として HL7、MML その他色々なものがあり、 統合できないため医療情報交換に支障をきたしてきました。 そのようなことから、それぞれ好きな基準を使いつつ、必要に応じて相互翻訳 (データ・マッピング)してしまえば良いではないか、 というのが私の主張してきたところです。

      1. しかし ArcheType を使えば、その必要性も少ないかも知れません。 一つの容器に各国語が記述されていれば、 どの国とでもやりとりできるわけですよね。 ArcheType には「意味づけ」がされる という特徴もあります。

このような概念は目新しいものでもありませんが、 運用に非常に柔軟性を持たせたところなどが、新鮮で魅力的に映ります。 私の開発中の Web 電子カルテにも、 単純ですが似たような実装を進めている部分があり、 いずれは下位層のハンドリングに ArcheType を使うようにしていきたいと考えています。

○ Apple タブレット型Mac を秋に発表か?

標記のようなニュースがありました。まあ「うわさ」なので 実現するかどうかは別ですが。

iPod touch や MacBook Air を手にするとともに、 いずれ Apple はこれらの技術を統合したもの つまり Air の液晶部分のみのタブレット型で iPod touch の使い勝手を実現するのではないかと 私も思っていました。

結構、実現するかもね。そうなると、結局 買ってしまうんだろうなあ、、 Apple さん、この頃、商売上手過ぎる。 日本では相変わらず Windows が大勢を占めていますが、 USA では かなりの勢いで Apple がシェアを伸ばしているようです。

< 2008.04 春はあけぼの | 2008.06 Seagaia meeting 2008 in KYOTO あれこれ >

これは日々の生活で感じたことを書きとどめる私の備忘録です