madpapa: 2007年6月アーカイブ

■プログラミング言語から考える「進化するアーキテクチャ」の要素

UNIX というオペレーティングシステム(以下、OS)は1968年にアメリカAT&T社のベル研究所で開発され、FreeBSD、Solaris、LINUXなどに商業的な理由や法律的理由などにより派生しているが基本的な思想はこれまで40年間続いている。C(1973年にAT&Tベル研究所で開発された)というハードウェアに依存しない移植性の高いプログラミング言語で記述され、多くのプラットフォームにへの移植が可能となった。このアーキテクチャは、今日においても最先端のコンピュータシステムでその設計概念が利用されている。インターネットサーバーや各種オンラインシステムあるいは最近の携帯電話やMACのOSとしてもLINUXが採用されている。なぜ、これだけ長い間利用され続けるのか、しかも陳腐化することなく最新の技術として利用できるのか、その鍵をとくことは「進化するアーキテクチャ」を考える上でのヒントになると考える。

Cの特徴は、IOを持たないことである。それまでのプログラム言語は、FORTRANやCOBOL(以下、既存言語)のようにプログラム言語内にIOを定義していた。コンピュータを動作させるにあたり、IOがなければ内部記憶の情報を演算するに過ぎず、そこへ期待する入力をすること、およびその結果を表現することもできないものとなってしまう。IOがなければコンピュータは何もできないに等しいくらいIOは重要なものである。既存言語はIOをプログラム言語に定義し、外部入出力装置との間で情報入出力をできるようにしたものである。しかし、技術が進化しこれまでの外部入出力装置以外の外部入出力装置が開発されたらどうか。新しい外部入出力装置により新しい入出力方法が必要となるならば、それまでのプログラム言語の入出力では利用できなくなる。新しい入出力装置に対応するためにはプログラム言語内に新しい入出力を定義する必要がある。その結果、プログラム言語が入出力に依存することになり、新しい入出力が開発される度に、言語自体の更新が必要となるのである。言い換えれば、新しい入出力を利用するためにはプログラム言語のバージョンアップを待たねばならないことになり、技術の進化の妨げになる恐れがある。
言語仕様としてIOを持たないCの場合では、既存言語のように入出力に影響されることはなく、どのような新しい入出力が開発されたとしてもCの言語仕様は変わらない。言語仕様からIOをなくすことにより30年以上もの長い期間、陳腐化されることなく利用されている。

言語仕様の範囲を「データ記述方法」と「プログラム実行制御」だけに制限する。しかし、その制限された記述方法の組み合わせにより自由なインタフェースを実現するのである。そして、そこから生産された資源はライブラリとして共有することであたかも言語自体が発展するように見えるのである。
「進化するアーキテクチャ」の要素として、「アーキテクチャを極限まで小さく固定化する」ことを提案したい。

HIMSS 07 リポート

user-pic
0

2007年にニューオーリンズで開催されたHIMSS'07
 
 現地レポートはこちらから。


HIMSS : Healthcare Information and Management Systems Society

秋山研究会

user-pic
0

本日、SFC秋山研究会にて生涯利用型パーソナル情報空間プラットフォームの研究について発表を行った。
本研究は、個人を中心とした情報を、「生まれたときから利用する」および「100年間以上継続利用する」を前提とし、実現可能とする情報空間プラットフォームを提案するものである。具体的には、パーソナル・ゲートウェイにより新たな情報空間および情報価値を創造できるプラットフォームのモデルを提案、母子手帳のように生まれる前から発生する情報や亡くなった後に残る情報を含め世代を越えた情報の共有、継承および保護について技術的および意味的に研究するものである。

発表へのフィードバックとして:
・医師モデル、看護師モデルに次いで市民モデルとしての医療の切り口で考えたらどうか。
・データだけでは意味がない、何を目的とするかでデータの意味や粒度も変わる。
 →情報の粒度を明確にすること。利用目的を明確にすること。
・データが揃えば、データ検索エンジンに搭載されているようなデータマイニング技術により
 アラートを発生させることも可能になるのではないか。
・普段の生活状況から、何を摂取しているからどのようなリスクがあるか分かる
・早く実装して利用してもらうのも良いアプローチかもしれない。

秋山さんからのフォロー:
・今回の発表に近い研究は既にされており、失敗例が多い。なぜ失敗したかを徹底的に調査し、今回のモデルはなぜ上手く行くかを説明できるように。 メディバ、東金病院、宮崎はにわネットなどが前例。最近では東京都も進めている。
・カルテを患者に開示できると良いというが、患者は本当にそれで満足するか
満足度調査ができると良い。(国領先生)
・公衆衛生の分野にあたるのでは。

背景の背景

user-pic
0

現在のコンピュータは使いづらいと感じている。パソコンを利用する際のスパムメールの多さ、ウィルスなどセキュリティへの脆弱性、ウィルスから保護するためのセキュリティソフトの更新の多さ、Windowsのセキュリティ更新の多さなど、本来はなくてよいものが当然のごとく行われており、多くの人たちは疑問すらもたなくなりつつある。これら劣悪な情報環境によりどれだけコンピュータ資源、ネットワーク資源、人々の時間やストレスなどに悪影響を及ぼしていることか、世界中でtremendousな浪費に違いない。

これら情報環境を改善するために
人に優しいコンピュータをかねてから作りたいと考えていた。

パソコンの利用シーンを考えると、一般的な人にはメールとウェブが安全に使えること、メディアプレーヤが使えることで十分だ。これら利用中のトラブルの多くはネットワーク接続に起因する。
携帯電話の場合では、同様にネットワークに接続されているにもかかわらず、パソコンほど多くのトラブルは発生しない。この差は、アーキテクチャの違いが考えられる。パソコンでも携帯電話程度に安全に利用できるようになれば相当ストレスは減るのではないか。

現在のウィルス対策の大部分はパターンをチェックすることである。ウィルスの情報を元にチェックパターンを作成しワクチンとしている。この場合、ウィルスのパターンが増加したらチェックパターンも応じて増加し、結果としてウィルス検出にかかるCPU利用時間は増加する。それはどこまで許容されるのか、いずれCPUの利用時間を食いつぶす恐れも否定できない。現在のウィルスへの対応方法は根本的な解決方法とはいえない。

根本的な解決は、アーキテクチャを変えなければできない。
先の携帯電話の例では、プログラムとデータを分離した構造となっている。パソコンではプログラムとデータが同一空間上にあるため、データ内にプログラムコードを書き実行することが可能である。一方携帯電話ではデータをプログラムとして実行できるような構造にない。プログラムのローディング方法が限定されおり、データをプログラムとして起動できないようにしているからである。

自身の研究は、コンピュータアーキテクチャを見直し、誰もが安心して利用できる情報環境を創り出そうというものである。

電子メール

user-pic
0

電子メールは最も利用するITのツールといえる。
何年もの間、電子メールは同様のユーザインタフェースで利用され続けている。日本においては、PCのみならず携帯電話においても利用の多くが電子メール利用だろう。

電子メールの特徴は:
・情報を通信目的で利用できる
・情報は個人にクローズドである
・情報のあて先情報はオープンである
・情報に方向性(送信、受信)を持たせて保存
・情報の日時を保存
・タイトルによるサマリー表示
・マルチパートによりテキストに加え画像その他ファイルを添付できる

医療分野の話になるが、
The eHealthTrust™ Path to Implementing Health Information Infrastructure, Virginia HIMSS
Williamsburg, VA, October 6, 2005 によるとeHealthTrust™ Advantages として以下をあげている。

Rapid Response Time
All patient information in one place
Works Regardless of Patient Location
Internet access: secure web portal
Patient has “ATM-like” mechanism that directs any provider to the complete record
No Complex Interfaces to Other Communities or eHealthTrusts™
Easily Integrated with
Patient-entered information
Patient education information
Patient reminders
Patient-provider electronic communication
Provides for Public Health and Research
Selective reporting to public health when new information received
Searchable database (with patient permission) for research
Cooperation Assured
Unifying; HIPAA mandates information on patient request
Complexity Minimized
Each information holder relates only to eHealthTrust™
Interoperability problems greatly reduced
Privacy/Confidentiality Addressed
Patient controls all access to his/her info
Complete Financial Model Defined
Source of funding clear
Low cost (1% of health care costs)
Promotes Gradual Standards Adoption
Initial standard enforced through patent
Reimbursement policy can improve standard over time (e.g. to increase coding)
Provides Transition from Paper Records
Fax images of paper records stored
Metadata facilitates some indexing
Simple IT Design
Greatly reduces costs
No new technology
Immediate Realization of Benefits
Each eHealthTrust™ member gets immediate benefit from complete records
Benefits not contingent on critical mass (except EHR incentives)

電子メールはこれらアドバンテージに多くの部分で匹敵する可能性を持つのではないか。
さらに電子メールを発展させたらどうなるか。
①IMAPを拡張し指定した人や機関がセキュアに閲覧できる
②DICOM等のオブジェクトビューワをプラグイン可能とする
③情報の改ざん防止
これら機能を持たせれば、個人中心の医療情報環境を実装するのは比較的容易である。
性能を重視する場合はPOP3のように端末に持たせることも可能であり、バックアップとしても使える。
メールを中心としたシステムであればグローバルな利用も可能である。

次回はシステム構成をデザインしてみよう。

本人性

user-pic
0

本人性確認は、多様な確認方法が考えられる。
従ってどのようなプロセスで本人確認をしたかで本人性の確かさの度合いは異なるはずである。何を目的とするかで求められる本人性確認の度合いも変わるのではないか。
認証局は本人性確認を第3者的に証明する機関であるが、そこの申請を悪意を持つものが何らかの手段で通過した場合には、本人に成りすますことができる。

マイクロソフトは性悪説を前提に社内システムを構築している。

キーワード
・住基カード(結構簡単にとれてしまうが大丈夫なのか)
・特定認証局
・ブリッジ認証局(省庁間をまたがる認証により個々のHPKI、GPKIなど個々の認証を統合的に可能とする)
・日本の住基カードの失敗は、ある1社のみが発行できるようにしたため、高価なシステムとなってしまった。

時間からの独立

user-pic
0

Q:なぜ時間から独立する必要があるの?
A:継続するため

Q:時間から独立すると何がおきるの?
A:異なるシステム間で違うタイミングで情報共有できる

メールシステムの返信を極限まで遅くしても
きっとメールは届くでしょう。

Q:なぜメール以外の情報システムは時間の経過と共利用できなくなるの?
A:リッチなコンテンツ表現するために情報要素を独自方法で組み合わせ
しているため、オーサリングツール、ビューワおよびドキュメントのバージョンが
異なると不整合が生じる

Q:テキストだけではだめ?
A:色をつけたい、レイアウトしたい、写真見せたい

Q:それではWEBと同じだよね?
A:だ。WEBでよいということだ

★WEBの特徴は、一つの画面に見えているものの実体は個別に存在するということだ
ドキュメントではなく、ドキュメント内のエレメント毎にセキュリティが制御できると良い

Let me go!!

user-pic
0

では、始めてみましょう。
きっと続かないブログを。。。

このアーカイブについて

このページには、madpapa2007年6月に書いたブログ記事が含まれています。

次のアーカイブはmadpapa: 2007年7月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。