標準化四題
浜松医科大学附属病院医療情報部 木村通男
１．MERIT-9, HL7Japanの進捗報告
１．１．MERIT-9
医療情報規格運用指針MERIT-9 は、MML, HL7, DICOM, JPEG などの各種規格を運用する際の詳細を定めたものである。昨年の当研究会では、検体検査結果記述のためのHL7の利用、画像データ記述の諸方法を、それぞれ川真田文章氏（大塚アッセイ研究所）、安藤裕先生（慶応大学）に発表していただき、更に筆者が運用するさまざまな形態、MMLからの外部エンティティ参照方法について述べた。
その後、処方（注射含む）についての利用方法について、古川裕之先生（金沢大学）、土屋文人先生（帝京大市原病院）を中心にまとめていただいた。これらの成果物は、MML/MERIT-9研究会ホームページで参照可能である(http://www.h.u-tokyo.ac.jp/mml)。また、一部はすでに英訳されている。
これまでの、日本における利用に際してのHL7の問題点については、HL7の会議の際に提出し、ほぼ当方の要望とおりに認められ、HL7 v2.3.1として公開されようとしている。
また、国立大学病院共通開発ソフトウエアとして、平成９年度は治験の管理システムが対象として選ばれたが、その仕様内で、処方、注射、検体検査結果、臨床試験登録の部分については、「共通プロトコル」として、MERIT-9で規定される内容が採用されている。
今後は、要望の多い生理検査（特にECG）や、これらを含む形での各種報告書の記述形式についての検討をおこなうことを考えている。
１．２．HL7Japan
1998年初夏に、HL7日本支部が、第７番目のHL7国際支部として発足する運びとなっている。日本医療情報学会標準化委員会と日本保健医療情報システム工業会(JAHIS)とが日本HL7協会を設置して、これが日本支部となる予定である。事務局はJAHIS（105-0001 東京都港区虎ノ門1-19-9 tel.03-3506-8010）内に設置される。本体の個人正会員の会費は、会費のみで運営される任意団体であるため比較的高い（年間275$）が、日本支部の会員（年会費１万円予定）となれば、会員としてドキュメントの購入や集会への参加ができる。HL7準拠システムをユーザが単に使うだけなら会員である必要はないが、仕様についてベンダーと交渉する場合にはドキュメントが要るであろうから、会員であることが望ましい。一方、ベンダーは準拠製品を作成するためには法人会員である必要があるが、法人会員となるにあたって、JAHIS会員企業である必要はない。
２．UNICODEを悪例とした、標準化の間違った考え方
２．１．UNICODE
UNICODEとは、今やISO10646となった、万国の文字を同時に均一に扱うことを目的とした、２バイト文字コードセットのことである。２バイトであるから、最大65536種類の文字を表現することができるが、特に文字種の多い表意文字について、日本、韓国、中国、台湾の文字を各国で利用されているすべての種類収用することはできなかった。そこで、一見似ているこれらの文字の、同じと考えられるものをまとめ、CJK Unified Idoegraphs として文字数を減少させた。これがひどいもので、図に見るように、日本語の「骨」が、簡体中国語のものと同じとされ、同じ9AA9というコードが振られている。中国簡体の漢字が混ざった日本語文書の気持ち悪さは、「中国人の作った日本語メニュー」として外国で時に実感できる。これが同じなら、Ｒ、ＮとЯ、Иも同じとして扱ってほしいものである。こういった反論の対策として、言語情報を文書毎に規定し、それにしたがって用いるべきフォントを選択する、ということになった。そのため日本で売られているUNICODEの文字コード表には、「骨」の所に9AA9としてコードが振られているので実態がわからない。当然これでは、「日本語で書かれた中国語の教科書」を書くことができない様に、同時に均一に扱う、という当初の大目標は破綻している。なお、我々が通常用いている、ISO2022による多バイト呼び出し法によれば、JIS日本文字とは別に、中国の文字セットさえそのワープロが持っていれば、問題なく記述することが出来る。
２．２．世界規格という美名の有害さ
すでにUNICODEが、ISO2022方式に劣ることは示された。しかし、これをそのまま用い、世界中で文字は２バイトとしてすべてシステムを作り替える勇気があるのなら、バカ平等としての価値は認められる。ところが、既存のASCII１バイト系でのソフトをそのまま生かし、かつ世界文字対応という美名を求める人々が、UTF-8という、２バイトUNICODEを畳み込む方法を提唱し、すでにISO10646-1のAnnex.Aとして規定されてしまっている。それによると、７ビットASCII文字は１バイトそのまま、ウムラウト（ドイツ語）、アクサン（フランス語）、ギリシャ語、ロシア語、ひらがな、カタカナなどは２バイト、漢字は３バイトを必要とする。他人の痛みの上で、世界規格という美名を求めているにすぎない。
我々はすでにISO2022という良い方法を持っているのであるから、これを利用し、これに技術的に劣るUNICODEを利用するべきでない。たとえ、事情を知らぬ人々によってJavaなどでUNICODEが採用されてもである。また、UNICODEは世界文字を同時に均一に対応出来るものである、とする誤解を正す必要がある。（参考文献：小林龍生: マルチリンガル文書と文字情報処理2 文字コードにとっての真の国際化とは, bit, Vol. 29, No. 11(1997年11月), pp 48 -- 54.）
筆者は、ただUNICODEの劣性を強調するためにこのことを取り上げたのではない。想像力に欠けた人々によって唱えられる、「世界規格」（世界制覇？）、という美名の危険性を示し、医療分野での国際標準化の動きへの啓蒙の一助となることが、目的である。今までの所、DICOM規格には日本企業の意向が十分に反映されているし、HL7に対して名前の「表記」とともに「読み」を格納するフィールドを求めた際に、我々の利用状況に想像力の及んだHL7のスタッフは、Aliasを使う、という様な、彼等にとって安易な表面的解決方法は取らなかった。今後も、こういった観念が保持されていくことを希望し、また、我々も、標準化制定作業において、この観念を大事にしていかなくてはならない。
３．標準基盤による画像処理のネットワークコンピューティング
標準基盤の導入は、様々な利点をもたらす。当研究会でも紹介されているDICOM/WWW server は、医用画像をHISのすべての端末で扱うことを可能とするものである。ここでクライアントの端末で、どれほどの画像処理を可能とするかについては、色々な方法がある。クライアントの端末に付加的なハードを持たせる、付加的なソフト（プラグインなどもこの中に入る）を持たせる、出来る限り単純なブラウザでも動くようにする、の３つである。
１つ目のケースは、すでにハードが高価であるが提供されており、例えば脳外科や放射線科にのみ配置されていたりする。２と３のケースは長年のHIS環境の変遷を反映していると考えられる。まず出現当初はHISはメインフレームとそれに接続されたダム端末によって形成されていた。その後クライアントにある程度のプログラムやマスターを持たせる構造となっているが、いままたネットワークコンピューティングが提唱され、先祖還りの様相である。
ただ、先祖還りとはいっても、その後の経験をまったく捨て去る必要はない。分散系アークテクチャの採用によって、負荷の分散が図れ、クライアントそのものは軽くてすむ、という設計が望ましい。ここで、負荷、とは、データ処理の処理負荷でもあり、データベースの量的負荷でもある。
データベースの分散化、構造化については研究が進んでいるが、一方の処理負荷の分散の話は、まさにこの、画像処理のケースが該当する。つまり、HISのネットワーク下に画像処理エンジンが数台あり、これを必要とするクライアント（HIS端末の内、単に画像を参照するだけでなく、画像処理をしたいと考えるもの）が、必要に応じて利用することにより、HIS端末すべてでそういった機能が利用出来るとするものである。もちろん、どのい程度の処理が、どの程度のリアルタイムのユーザからの入力を必要とするかによって、こういった負荷分散ができるものとできないものとがある。CTの３Dの例では、域値や視点軸の設定には、どれほど画像処理結果を見てのリアルタイムのフィードバックが必要とされるか、ということである。筆者の観察では、腹部、胸部のオブジェクトを描写するにはかなりのフィードバックを必要とするが、頭蓋内のオブジェクトについては、定型化が十分に可能であると思われる。
かかる負荷分散も、DICOM規格や当初のInternet規格の整備によってはじめて可能となったものである。こういった分散系の設計／実装には長い時間を要するので、アッパーコンパチブルでない次期ヴァージョン（矛盾する概念である）がすぐに出現するような環境下で、こういったものを開発することはリスクがある。ネットワークコンピューティングへの先祖還りへの追い風にも、こういったことがあると考えられる。
４．医事情報との切り口についての私見
４．１．医事「から」でなく医事「へ」
医事会計システムから得られた情報を元に、経営分析ができるかと問われれば、困難であろうといわざるを得ない。その理由は、１．経営分析の胆となる情報（特に病名）で、入力されていないものが多く、それをエントリさせることは困難である、２．エントリされているものでも、どうせ取れないからと、月２回目のCT、丸まった個別検査項目など、医事システムには届いていない情報が多い、の、２つである。１０年たって、確かにオーダエントリは進んだが、今だ病名エントリなどはしっかりしていないし、丸めに至っては甚だしくなっている。
従って、よりクレディビリティの高い経営分析が必要であれば、医事会計システム「から」の情報でなく、医事情報システム「へ」の情報を元とすべきである。
４．２．オーダ系と医事系の役割分担
一方で、オーダエントリ／電子カルテ系と、医事会計システムとの間の切り口は、まさに必要とされているものである。この意味からも、医事情報システムへの情報の標準化には、意義深いものがある。
しかし、現状の医事会計システムを見ると、オーダエントリシステムすら医事会計システムから派生して出来たという経緯を反映して、勝手にオーダ系で丸めてしまっているものが数多く見受けられる。例えば放射線撮影であれば照射録という法令で定められたものがあるので、そちらから実態を押さえられるが、衝撃波体外結石破砕などは、月２回目以降は実施しても記録として残されないこともある。特に中央診療施設（共用）のものでなく、各科の持ち物となっている検査機器にこの傾向は顕著である。増してや、オーダのない所でのレセコンに於いては、エントリの時点で丸め判断をさせているとすらいえる。
つまり、医事情報システムへの情報の標準化には、データ形式と、マスタの制定以前に、オーダ系と医事系との間の、役割の切り分けの折り合いを付けることがまず必要である。
さすがに、「８項目まで」が「７項目まで」に変わるだけで、オーダ系と医事系両方の変更が必要となることに気付いたメーカは、自社製品間でこの分岐点を設定し始めていまるが、レセコンにはあまりこの発想はない。
４．３．医事処理の環境変数
さてこの役割分担が出来ても、これだけで十分ではない。診療報酬請求のロジックの混迷は、前述の丸めの問題、相互処理（「、、、但しこれは◯◯が算定されていない場合のみ算定できる」など）、とともに、いやそれ以前に、数々の環境変数の設定の仕方が必ずしも定められていない、という点にある。もちろん、特定機能病院かどうか、なんとか加算のための厚生大臣の別に定める基準を満たす施設かどうか、などは簡単で客観的な方である。問題は、そういった算定資格に類するものが、文中に埋め込まれている場合で、これのフラッグの立て方は、各社まちまちになってしまっている。もちろんコードも振られていない。恐ろしいのは、「◯◯処置（△△の場合）」「◯◯処置（▲▲の場合）」と、各社のマスター項目の表記にロジックが埋め込まれている場合である。とはいってもこの方法、つまり質問ウィンドウをうるさく出して判断させるのでなく、マスタ項目を眺めるだけで判断できるようにしたこの工夫を咎める気は筆者にはない。問題は、ロジック埋め込みの切り口が各社各システムまちまちであるという点である。
そういう観点で、改めて診療報酬請求の本を眺めると、驚くべきことに気付く。このルールブックには、グロッサリー（用語集、用語定義）の部分が存在しない。そもそも、「一回の受診」の定義など、どこにも書かれておらず、判定の例があるのみである。
４．４．方策についての私見
まず、診療報酬請求ルールのオブジェクト分析をおこない、上記で明らかにした、ルールの情報記述的問題点を改善することが必要であろう。次いで、診療情報記述という点から医事請求用情報記述を観察し、特に処置や手術等において、医事請求用記述が診療記述の出発点として使えるもの、使えないものとに分類する。賛否はあるものの、現在最も広く利用されている記述方法が医事請求用のものであることは否めないので、これから出発出来るものは利用してさしつかえないであろう。これにより、診療記述として何を重点的に開発すべきかということも明確になるという利点もある。そしてこういったことを踏まえて、オーダ／電子カルテ系から医事系への情報の標準化に着手することが適当であろう。もちろん、それ以前に、レセコン／医事システムのオープン化は大前提であることは言うまでもない。
５．まとめ
以上、標準化に関する最近の話題を、とりとめなく並べた。研究会における話題提供の一助とでもなれば、筆者の幸いである。