○木村通男
浜松医科大学 医療情報部
日本医療情報学会MERIT-9研究会代表幹事
Michio Kimura
Hamamatsu University, School of Medicine, Department of MedicalInformatics,
Chair, MERIT-9 Committee, Japan Association of MedicalInformatics,
Keywords: Standardization, Clinical data exchange, XML
１．はじめに
医療情報交換規格運用指針MERIT-9(MEdical Record, Image, Text -InformationeXchange)を筆者が提唱し、はや２年が経つ。この間、数多くの識者の協力を得て、画像、検査、処方について、診療施設のDB間で情報交換が可能となるほどに、DICOM規格やHL7規格の利用についての詳細が定められた。そしてその結果の一部は日本のみの問題ではないと考えられたため、HL7規格に対して改善提案としてサブミットされ、v.2.3.1として認められた。またこのプロセスを通じて、日本と外国の医療習慣の相違を浮き彫りにできたことは望外の喜びであった。
平成11年4月に、日本医療情報学会理事会において、MERIT-9研究会が正式に認められ、今後の検討や規格のメンテ、普及を行なうこととなった。本稿では、本年度の活動に向けて、留意すべき点と筆者が考えている技術要素について、概観を述べる。
２．診療施設間情報交換と診療施設DB間情報交換 −情報の粒度
診療施設間で情報を交換するためには、以下のような、さまざまなレベルで、両者の間に合意がなければならない。
ａ．メディア（例えばFD, MOなど）ｂ．ファイル形式（例えばDOSファイル、Macintoshファイルなど）
ｃ．文法（例えばHL7 v2.3など）
ｄ．項目コード（例えば臨床病理学会コード[1]など）
ａ．ｂ．の２つは医療固有の問題ではない。ｃ．で初めて医療用の記述文法を必要とする。ただ、これだけではまだ不十分である。「検査結果」が書かれているべきところに「γGTP=120」「ganma-GTP=120」といった様々な記法が考えられるため、解釈のために人間の認識能力が必要である。（逆に、人間が読むことを前提としているならば、ここまでで診療施設間情報交換は可能である。）
しかし、上記２つを同値と認識できない機械の上のDB間で情報を交換するためには、項目コードについても双方に合意がなければならない。とすると、DB間での交換を目指すならば、項目コードについて、標準化されたものがある分野でしか、実現は困難である、という結論に至る。これを日本の医療の現状に照らしてみれば、関係各団体の努力により、画像、臨床検査、処方については、こういったレベルでの情報交換が可能となっている、と、考えられる。
しかしその臨床検査、処方についても、これだけでは不十分である。HL7の最新版v2.3.1では、日本からの提案で、人名など固有名詞に対して、漢字氏名、氏名読み（カタカナかひらかなか、全角か半角か、あるいはアルファベットか）などを持つことが出来るようになっている。ただ、これらは記述する文法上の場所が与えられているだけであり、実際にローマ字を入れるべきか、カタカナで入れるべきか、といった決定には注意を要する。そもそも、姓と名を区別して持てるHISばかりでないかもしれない。しかし、こういったことを定めなければ、DB化は実現できないのである。
３．HL7の限界 −適用範囲
HL7[2]のインプリメントされている状況を世界的に見ると、結果報告が主のようである。HL7はECGを波形データとして扱う仕組は持っており、現在HL7のWGで再検討されている最中であるが、現在の版のそれは広く使われてはいない。大体の場合、ECGベンダー独自の形式で記述されており、またそれらは各ベンダー独自のデータ圧縮方法と密接に関連している。したがってECGについては、まだまだ標準化されたデータ形式があるとはいえない。
HL7には患者診察所見を記載する方法もあるが、これも広く用いられてはいない。この原因の一つは、所見を記載するための臨床的な項目コードがないためである。日本には、日本臨床病理学会臨床検査項目分類コードが存在し、検査会社各社によってメンテされており、コードの共通語として主流になりつつあるが、同様の目的の、LOINCと呼ばれるコードがアメリカにある[3]。LOINCは、臨床検査項目コードとともに、ClinicalLOINCとして臨床所見用の項目を充実させている。ともあれ、日本にはこういったコードのよいものがない。またLOINC臨床コードも網羅的とはいえない。（彼等は不十分な部分の補充を歓迎しているが。）また、どちらにせよ現状では診察所見は通常自由文によって記述されることが多く、必然的に構造化された意味関係を持つ。現状のHL7では意味構造を記述することは困難なので、これらについてもHL7では十分な対応は困難である。
ともあれ、HL7は既存する医療情報規格としてはもっとも大きな成功を収めているが、これですら、これだけですべての問題を解決することは不可能なのである。
４．診療施設DB間情報交換の実現 −コンフォーマンス
医療情報規格としてはもっとも大きい成功を収めているといえるDICOM規格[4]でさえ、実装となると、さまざまな問題が生じる。1999年4月のJMCP（医療画像機器技術展示）で、CyberRADのコーナーにおいて、メーカ技術者による、DICOM実装時に経験した問題点の報告と検討があった。これはたいへん興味深いものであり、こういった報告があるということは、逆にDICOMの規格としての普及の実績を示すことなのであろうと考える。それはさておき、そこで指摘された問題点は、以下のようなものであった。
a. リコン画像が別検査になる、複数のシリーズの画像を交互に挿入して１シリーズにしてしまうようなものがある、など。b. 患者名、患者ID、検査日などが来ないものがある、など。
c. 3Dをうまく作れない、いきなり出た画像が真っ黒、など。
d. 同じ画像が２重に入って、２つの別の検査になっている、など。
まずa.であるが、Study-Series-Imageという３階層の画像番号記述のインクリメントの仕方が標準化されておらず、メーカによってまちまちであることが原因と考えられる。
次にb.であるが、これらはDICOM規格ではtype2（あれば送ること必須）であり、type1（無条件必須）ではないためと考えられる。
c.の様なトラブルが一番よく聞かれる。3Dをうまく作ったり、画像をいきなりそこそこの階調で表示するには、規格上type3（任意）である、検査部位、WindowWidth/Levelなどが送られてきている必要があるが、これがないためと考えられる。
d.は更に奥深い。通信途絶時のタイムアウト時間、再送時の発番などは、規格にもない。しかしこれらの取り決めがなければ、信頼できる伝送は期待できない。
DICOM規格は、コンフォーマンスステートメントの確認を口やかましく求める。上記のようなトラブルは、その多くが、丁重なコンフォーマンスステートメントの確認および、更にそれ以上の実装サイトでの相互の取り決めをしておけば、避け得るものである。しかし、特に日本では、調達の技術仕様書に「DICOM規格準拠であること」といった文言のみが書かれていることが多い。そしてまた、こういったトラブルは、データ受け手の側に負担がかかることが大多数である。
この状態を解決するには、なにより、ユーザ側の知識向上が必要である。いったい何をしたいのか、将来どういう拡張が考えられているのか、こういったユースケースを明確にしてこそ、必要な情報が伝送されることが可能であり、b.c.といった種類のトラブルが避けられる。ただ、規格の広範囲化や、病院の情報機器のインテグレーションが進むにつれ、通常のユーザではこういった知識に対応しきれなくなっているように考えられる。そろそろ日本でも、医療分野の職業的システムインテグレータが必要とされているのではないだろうか。そして現状でこれを求めるならば、病院全体サイズのシステムの調整については医療情報担当者、放射線部内のシステムの調整については放射線技師が、もっとも適した職制であろうかと思われる。
５．MERIT-9における、ユースケースの絞り込み
MERIT-9[5,6,7](MEdical Records, Images, Texts, -InformationeXchange)は、診療施設間患者情報交換の際に各種医療情報規格を運用するための指針として策定されたものである。当初想定した、この指針の利用される形態は「診療情報提供紹介状」「外注検査依頼／結果」「院外処方せん」「個人的診療歴記録」「病院内症例蓄積」の５つであったが、ここまでで示したように、標準化された項目コードを有する部分でしか、標準化されたといえるDB間交換は困難なので、「紹介状」「処方せん」「外注検査」という３つについて、実装を目指すこととした（図１）。
また、前述のように、ユースケースを絞れば、実用のためには、HL7やDICOMが持たないメタな情報を更に必要とする。紹介状であれば、宛先、差出人、これが「紹介状」であることを示すもの、などで、検査結果報告であれば、このレポートに含まれる患者リスト、などである。しかしこういったものは、それぞれのユースケースに特化しているので、汎用のMML[8]では、対処しきれない可能性が考えられた。そのため、上記のような各ユースケースごとに、密着する形で対応する必要があると、考えられた。そこで、まず、診療情報提供紹介状のために、定められた様式を構造化したXML-DTDを定めた（図２）。また、それらの項目の記述内容、形式についても図３で示した。
そして通常、そのXMLファイルから、外部エンティティとしてHL7ファイルなどが参照される形態を採る。一般性を確保するために、外部エンティティはＵＲＩとして記述される。
こういった利用を実現するために、MERIT-9では下記の事項についての規定がなされている。
６．MERIT-9の範囲と限界
オフラインの場合の情報交換媒体、オンラインの場合の伝送プロトコル、暗号化方法、などについてはMERIT-9は記述しない。これは、利用される形態の種類が多く、様々なニーズに対応できる唯一の規定、というものが存在しないと思われるからである。したがってこれらの項目については、情報交換する双方の間で、別途ネゴシエーションされなければならないが、こういった技術の進歩は、一つのデータ形式の寿命よりずっと短期間で進んで行くと思われるため、その時々の「旬」の技術の成果を用いることによるメリットが、ネゴシエーションを必要とするというデメリットより大きいと考えるためである。
また、検体検査結果、画像についてはほぼ十分な記述ができており、処方記述についても適当な薬剤コードを使ってHL7を用いることが妥当であるという結論をほぼ得ている。しかし、所見などの記述が診療施設間で交換されるには、未だ適切な記述の標準化がなされていないので、現在はMERIT-9にこれについての指針はない。
７．MERIT-9の現状と展望
まず、成果物は、日本医療情報学会MERIT-9研究会ホームページで、会員でなくとも閲覧することができる（http://www.h.u-tokyo.ac.jp/merit9/ または http://www.mi.hama-med.ac.jp/）。ここには、研究会の幹事リスト、規約などとともに、上記XML-DTDや、臨床検査に関する規約がJAHIS原案として、画像に関する規約がMERIT-9画像関連フォーマットとして、更に処方に関する成果物も掲載されている。
処方は検体検査や画像よりも日米の医療文化の差が大きかったため、処方についてHL7を日本で用いるためには、数々のエレメントや選択枝データを用意する必要があった。それらのあるものは、HL7に日本からの提案としてサブミットされ、あるものは日本独自のものとして、ローカルに規定されている。具体的には前者は投与時期と食事との関係記述、一日量重視か一回量重視かの視点、などであり、後者は処方単位コード、処方剤型コードなどである。MERIT-9の目的は、より良好な医療情報交換のための基盤整備であるので、全体としての患者情報交換のための利用だけでなく、上記のような成果物を断片的に利用されることも歓迎である。ぜひ上記ホームページの仕様書を見て、数々のコードテーブルを、各種インプリメンテーションの際には参照されたい（図４）。
本年度は、実装試験を開始する予定である、具体的には、WindowsやMacintosh上で動くMERIT-9文書ブラウザを作成し、PDSとして無料で配布する。これは当然DICOM画像ファイルビューア、HL7ファイルビューアを含む。紹介状にデータとともにブラウザが通常付随するほどの普及を目指したい。一方でHISやPACSの機能として、MERIT-9準拠紹介状作成ツールの試作をHIS,PACSベンダとともにおこなう。
病名、波形データなど、標準化の基盤整備が中間的な程度である項目については、標準化の進展を見守りながら、規定の展開を考えていく予定である。
また、当指針は、病院情報システムの入札仕様として利用されることを強く意識して策定されているため、そのための完成度を高めるためにも、諸兄からのコメントを歓迎する、と、共に、積極的に利用されることを深く希望する。
参考文献
[1] 日本臨床病理学会、臨床検査項目コード第１０回改訂、臨床病理出版、1998 .（またはhttp://www.alles.or.jp/~jscp1/jlac10_1.htm）[2] Health Level Seven, HL7 version 2.3, 1996. (規格書はHL7に入会することによって入手できる。HL7, 3300 Washtenaw Ave., Suite.227, Ann Arbor, MI, 48104-4250, USA. または、http://www.hl7.org）
[3] Forrey AW, McDonald CJ, De Moor G, Huff SM, Logical observation identifier names and codes (LOINC) database: a public use set of codes and names for electronic reporting of clinical laboratory test results. Clinical Chemistry 1996; 42(1) pp. 81-90. （または、http://www.mcis.duke.edu/standards/termcode/loinc.htm）
[4] Digital Imaging and Communications in Medicine (DICOM), NEMA Publications PS 3.1-3.12, The National electrical Manufacturers Association, Rosslyn VA, 1992-5. （または、http://www.nema.org/nema/medical/dicom/）
[5] M. Kimura, K. Ohe, H. Yoshihara, Y. Ando, F. Kawamata, F. Tsuchiya, H. Furukawa, S. Horiguchi, T. Sakusabe, S. Tani, and M. Akiyama, MERIT-9: a patient information exchange guideline using MML, HL7 and DICOM, Int'l J of Medical Informatics, 51: 59-68, 1998.
[6] 木村通男、大江和彦、吉原博幸、医療情報交換規格運用指針MERIT-9の概要、第１７回医療情報学連合大会論文集、pp.566-567, 1997.
[7] 川真田文章、臨床検査データ交換規約JAHIS-DRAFT、第１７回医療情報学連合大会論文集、pp.564-565, 1997.
[8] 吉原博幸、大江和彦、大橋克洋、日紫喜光良、山本隆一、山崎俊司、廣瀬康行、松井くにお、山下芳範、皆川和史、木村通男、医療情報交換規約 -Medical Markup Language (MML) version 1.0 -、第１７回医療情報学連合大会論文集、pp.648-649, 1997. （または、http://www.miyazaki-med.ac.jp/medinfo/SGmeeting/SGmeeting.html）