大橋克洋（大橋産科婦人科）
高橋究（佐藤病院）
Katsuhiro Ohashi*, Kiwamu Takahashi**
Ohashi Gyne/Obst clinic*
Satou Hospital**
We think the computerized medical record system is very usefull in our daily medical works. It must be build on a `server and client system'. And It must be developed in valious idea and valious aproach at many medical institutions. These systems must be available on any hardware and any OS, and at the same time, any systems must be communicate to each other systems.
So, most important thing is the standardization of It's transport format. Our attempt is to make the `Medical Markup Language', this is like the SGML or HTML.
Keywords: Computerized medical record, Electronic patient record, SGML, HTML
色々な施設で「電子カルテ」への本格的取組がはじまろうとしている。
発達段階において、「電子カルテ」自体は各施設ごとに独自の発想によるユニークな開発が行われるべきである。しかし、もっとも重要な点は色々な「電子カルテ」が統一したフォーマットで相互にデータを交換できることにある。
このような考えのもとに、電子カルテの標準転送フォーマットについて個人的に取り組んできたが、本演題提出後に本学会「電子カルテ研究会」において本格的な研究が開始された。
現状における統一的見解は今回他のセッションで発表される予定である。著者らもこのプロジェクトに参加しており著者らの意見も盛り込まれているので、以下では主としてこの見解に至った理由などについて述べる。
コンピュータのスタンドアローンでの利用は、持てる能力のごく一部しか使っていない。色々なスタッフが緊密な共同作業を行わねばならない医療の場にネットワークは必須であり、「電子カルテ」はサーバ・クライアントの形で利用されるべきである。
ネットワークを利用すれば、NFS(Network Filing System) などを利用して、他のマシーンのファイルをあたかも自分のマシーンのファイルであるかのように利用することができる。即ち一つのファイルを複数の人間が共有することができるが、この方法では同時書き込み時のデータの整合性やセキュリテイーなどへの対応はかなり大変である。
しかし、サーバ・クライアント方式を採用することにより、これらの問題の解決はかなり容易となり、システム開発の面でもメリットは大きい。
すなわち「電子カルテ」はクライアントとして実現され、「データベース・サーバ」からデータを供給され読み書きする。サーバはネットワーク上に「診療録サーバ」「会計サーバ」「検査データ・サーバ」など複数あっても良い。必要なら広域ネットワークを介して他施設のサーバを利用することも可能で、これはいわゆる分散型データベースの概念となる。
医療は色々な面で極めて多様性が高いのが特徴であるが、このような方式をとることによって、「電子カルテ」の様式すなわち外観や使い勝手などは様々であっても、それぞれが共通のサーバのデータを利用しながら読み書きをすることができる。
この考えを更に進めれば、「データベース・サーバ」さえも施設ごとにいろいろなものがあってよい。小規模施設ではパソコンで動くサーバ、大規模施設では従来からのメインフレームによるサーバの利用がありうる。
重要なことは「どのようなサーバ」に対して「どのようなクライアント」がアクセスしても「まったく同じ様に読み書きできること」である。サーバ、クライアントともにハードウエア、OS などに依存しない。どんなシステムを使うのも自由である。 このような柔軟なシステムは、実はすでに地球規模で広く使われてはじめている。World Wide Web がそれである。
異なるサーバ・クライアントで同じデータを扱える一方で、「自由な発想とユニークな考えによるサーバやクライアントの開発を妨げない」ことが重要である。 患者データが広域ネットワーク上を流れるには暗号化などの処理を上にかぶせる必要があり、将来においても患者紹介など限られた用途が主体となろう。患者のプライバシーの問題があるからである。それよりも、むしろ実際には以下のような点に大きなメリットがある。
自由な発想とユニークな考えによるシステム開発が促進される。
フォーマットが共通であるため、「電子カルテ」に付随する色々な周辺ツールを共通に使える。
同様に「電子カルテ」を中心とした診療支援情報サービスなどが出現すれば、これらを皆で共通に使える。
ツールの共通化や開発効率の向上などにより、「電子カルテ」や周辺ツールが比較的低い価格で流通するようになるであろう。
このような自由競争と資源の共有化を経て、自然に良いものが生き残り使われるようになる。
規格を決めるにあたり大切なことは、「すでに世の中に広く使われているものがあれば、なるべくそれを利用する」ことである。また標準化とは「決まった枠内へすべてを押し込んで規制する」ことではなく、「基本的には個々に自由な使い方を尊重するが、最低限必要な部分のみを共通化」することであると考える。「自由度のない標準化は結局誰も使わなくなる」ことは目に見えている。
そのような考えから「電子カルテ研究会」では検討の結果、SGML (Web のドキュメントを記述する HTML の母体となったシステム)をベースにすることで意見がまとまり、これを MML(Medical Markup Language) と呼んでいる。
これは「ドキュメントの構造化」「ドキュメント中の文字と他のドキュメントとのリンク」「画像イメージなどの標準的な埋め込み」など、カルテに必要な多くの機能を満たしている。MML の仕様の詳細については、今回「電子カルテ研究会」メンバーによる発表があるので、そちらも参照されたい。
MML の書式は (Fig.1) のようなもので < と > の間に囲まれた部分が書式などを規定するタグである。MML ではタグを文章中に埋め込むことにより、文章を構造化したり、HyperText 的なリンクなどを張ることができる。現在急速に普及しつつある World Wide Web の記述言語 HTML そのものを使うことも検討された。HTML であれば既存の Web ブラウザーにより電子カルテを読むことができるので大変便利であるが、医療に特化されたデータを扱うため HTML の母体となった SGML を基礎とした MML を作成することになった。
MML の目的は異なる施設間における診療データの共通化であるが、自施設内での利用については一切規定していない。従って、自施設内ではまったく異なる方法で診療データを扱うことも自由である。
しかし他の施設とデータあるいはツールなどを共有する場合は必ず MML に変換して渡すものとする(ネットワークではなくフロッピーデイスクなどのメデイアに入れて渡しても構わない)。同様に受け取った MML を自施設内のデータ様式に変換して取り込む機能も必要となる。
MML へ変換することは比較的容易であるが、MML からの取り込みにはそれを考慮したシステム設計が必要になる可能性がある。
SGML の場合は DTD(Document Type Definition) という形式で、文書構文フォーマットを規定することにより、一定の構造を持った書式でドキュメントを記述することができるようになる。従って MML の仕様 も DTD で扱える範囲内にとどめることが望ましいであろう。
MML は(Fig.1)のようにタグでくくられ構造化することができるが、(Fig.2)のようにタグでくくられた中へ再びタグでくくったものを入れ子にすることも可能である。
検査伝票や紹介状、手術録、分娩録などは定型フォーマットをとることが多いので、そのようなものはテンプレートとして用意しておき、それをはめ込む方式が柔軟性もあり実用的と思われる。
テンプレートの形式には通常の MML とは異なる HL7(米国で使用されている医療用データ記述様式)や、コロンなどの単純なデリミターで区切られた文字列のようなものも用途によっては便利と思われる。
ただし、いずれの形式をとった場合でも原則としてそれを解釈し、変換するのは MML のパーサーとなるので、なるべく簡略なものを必要最小限きめる必要があろう。 検査センターなどから転送されるデータや紹介状などが、このテンプレート形式になっていれば直ちに自分のカルテのデータとして取り込むことができる。
「電子カルテ」は以下のような手順で転送されることになろう。
MML マネージャー
広域ネットワーク(WAN)を介したクライアントとデータベース・サーバの間に介在して両者の意思疎通を図る。
データベース・サーバ
MML マネージャーからのリクエストに応じ、データをサービスする。 ここでのやりとりは SQL など施設独自の方法で構わない。
転送するデータの変換
MML マネージャーは転送したい診療データを「MML のコードにエンコード」し、必要なら「暗号化」し、「圧縮」をかけてネットワークへ送りだす。 診療データが元々 MML フォーマットであれば最初の操作は不要。 自施設内の LAN を流れる場合、暗号化も不要であろう。
ネットワーク上を転送
データは MML に暗号化と圧縮をかけた形でネットワーク上を流れる。
転送されたデータの変換
受け側のMML マネージャーは、受けたデータを逆の手順すなわち「解凍」「平文化」「MML から自施設仕様のフォーマットにデコード」する。MML をそのまま解釈できるクライアントを使う場合、最後の操作は不要。
クライアント
MML そのもの、あるいは自施設仕様に変換されたデータを読み書きする。 ユーザから見えるのはこのクライアントだけであり、これが「電子カルテ」そのものとなる。
(Fig.3) に示されるように、クライアントすなわち「電子カルテ」はネットワーク上の MML マネージャーを介してデータのやりとりを行う。MML マネージャーは Web の HTTPD(Hyper Text Transfer Protocol を取り扱う daemon すなわち、裏で動いている守り神)に似ているとも言える。
MML を直接読み書きするタイプのクライアントは、Web のブラウザーに近いものが考えれられるが、Web と根本的に違うところは対話的かつ能率的な入力を必要とする点である。Web の form と cgi(common gateway interface) を利用すれば、ある程度の対話的入力は可能であるが、臨床の現場で使うには速度や機能の面で現状では明らかに力不足である。
閲覧だけであれば MML の書式を HTML に準じたものにすれば、現在の Web ブラウザーでそのまま読むことができる。退院サマリーなどはこれで十分であろう。
サンマイクロシステムズ社の HotJava のように、プログラミングでき対話的な入力が可能な Web ブラウザーも現われはじめている。いずれは、それをそのまま電子カルテのクライアントとして使えるようになる可能性もある。
当面は「電子カルテ」記述用の専用アプリケーションか、入力面で Web ブラウザーを補うツールが必要になるであろう。
冒頭に述べたように、今後色々な施設で本格的な「電子カルテ」への取組みが始まろうとしている。著者が電子カルテ開発に着手してから10年余を経たが、まだまだ試行錯誤が必要な部分は多い。その発達段階においては、当院のような小規模施設における開発の方が試行錯誤を行い易く開発速度は速い。しかし、ある程度のスタンダードが決まった時点から後は、資金とスタッフなどに恵まれた大規模施設での開発が主体となるであろうと考えている。
色々な立場で色々な考えのもとになる「電子カルテ」が、MML のような共通のベース上で相互に情報を交換しつつ開発され、本当に現場で役立つものとして発展することを望むものである。
6年間日常診療に使ってきた経験から「電子カルテ」は極めて有用で、多くの医療施設で現在のワープロと同様の普及を見るものと確信している。異なるワープロで作成した文書が他のワープロで読み書きできないようなことがあってはならない。
武舎 広幸, 久野 禎子, 久野 靖:HTML 入門, (株）プレンテイスホール出版
根岸 正光, 石塚 英弘:SGML の活用, オーム社
大橋克洋:「電子カルテ」は思考の道具, 新医療, 22:145,1995.
Last update: 1995.9.30