04/12/09 標準的電子カルテ推進委員会第５回議事録 　　　　　　　　　　　　第５回標準的電子カルテ推進委員会 　　　　　　　　　　　　　　　　　　　　　　日時　平成１６年１２月９日（木） 　　　　　　　　　　　　　　　　　　　　　　　　　１５：００〜 　　　　　　　　　　　　　　　　　　　　　　場所　厚生労働省６階共用第８会議室 ○高本補佐 　定刻となりましたので、「第５回標準的電子カルテ推進委員会」を開催いたします。 最初に、委員会開催に当たりまして、厚生労働省医政局医療技術情報推進室長の新村よ りご挨拶申し上げます。 ○新村室長 　それでは一言ご挨拶申し上げます。委員の方々におかれましては、ご多忙のところ、 本委員会にご出席いただきまして誠にありがとうございます。今年度は平成13年に公表 いたしました、保険医療分野における情報化に向けてのグランドデザインが、５カ年の 計画になっておりますので、いわば折り返しの年になるということでございます。これ までの電子カルテシステム普及に関連した産官学の取組みを評価し、今後のより望まし い情報化に結び付けていくという観点からも、本委員会での検討は極めて重要と認識し ております。 　また、12月７日、一昨日ですが、首相官邸でＩＴ戦略本部が開かれましたが、そこで も医療の情報化がテーマになり、種々議論が行われたところでございます。併せて、評 価専門調査会からは医療分野の評価報告書が提示されまして、利用者の視点から見た、 成果に結び付くような評価のあり方、普及のあり方について提案がなされたところでご ざいます。こういった提案も考慮しながら、今後適切な医療分野の情報化を進めていき たいと考えております。 　前回の本委員会におきましては、取りまとめいただいた中間論点整理メモに基づい て、委員の皆様方はもとより、標準的電子カルテ関連研究班との連携の下、今後主要な 検討事項を検討する体制について合意を図らせていただいているところですが、本日 は、そのうち３つの検討課題について検討状況をご報告いただくことになっておりま す。標準的電子カルテシステムの推進に係る最終的な提言に向けて、引き続き議論を深 めていただければ幸いでございます。以上、簡単ですがご挨拶とさせていただきます。 よろしくお願いいたします。 ○高本補佐 　続きまして、本日の委員の出席状況についてご報告いたします。井上委員、小川委 員、水口委員、新倉委員、山本委員はご都合により欠席との連絡をいただいておりま す。水口委員の代理として、東芝メディカルシステムズＳＩ事業部成松亮様にご出席い ただいております。よろしくお願いいたします。これ以降の議事進行については、大江 座長にお願いいたします。 ○大江座長 　委員の皆様には師走のお忙しい中、お集まりいただきまして誠にありがとうございま す。議事に入る前に、事務局より資料の確認をお願いいたします。 ○高本補佐 　お手元に「第５回標準的電子カルテ推進委員会議事次第」があると思います。２の議 事、（２）主要検討項目の検討状況についての３番目の○ですが、相互運用性の確保に ついては、「保健医療福祉情報システム工業会 篠田」となっておりますが、本日は木 村委員からプレゼンテーションを頂戴することになっておりますので、訂正していただ ければと思います。次に１枚紙で「出席者名簿」、資料１、２、３は、本日のプレゼン テーションに用いる資料で、それぞれ９頁、５頁、４頁となっていますのでご確認くだ さい。 　その下が、参考資料１「厚生労働科学研究第６回標準的電子カルテ関連報告会」で す。参考資料２は「医療情報ネットワーク基盤検討会最終報告の概要について」、参考 資料３は「標準的電子カルテ推進委員会中間論点整理メモ」です。参考資料４は「主要 な検討事項と検討体制について」、参考資料５は「今後の委員会等の開催予定」です。 未配付等の不備がありましたらご指摘ください。なお、委員には、今後の医療情報ネッ トワーク基盤のあり方についてということで、医療情報ネットワーク基盤検討会最終報 告の正式な報告書を併せて提示していますので、ご参照ください。 ○大江座長 　資料に不備がなければ、本日の議事に入ります。前回の委員会以降の動向について、 事務局より説明をお願いいたします。 ○高本補佐 　参考資料１です。11月28日に名古屋で開催された、第24回医療情報学連合大会の開催 に当たり、医療情報学会様にご配慮いただき、第６回標準的電子カルテ関連研究報告会 を開催させていただきました。その際の研究課題として、本委員会にも関連の深い研究 班から、研究の進捗状況の報告がありました。 　詳細については資料どおりですが、まず、これまでの研究の進捗状況、研究概要とし て報告していただくとともに、併せて、今後の標準的電子カルテ推進に係るディスカッ ションを行いました。これらの研究概要については、かなり研究が進んでいることがわ かる資料となっておりますので、細かいことについては適宜報告していただけると思い ますが、現時点では、このように研究班が意欲的に取り組んでいるということです。 　本委員会とも関連がある医療情報ネットワーク基盤検討会については、平成16年９月 30日に最終報告をいただいたところです。本日はその概要について資料として付けてお ります。詳細は省きますが、電子署名を活用するための公開鍵基盤のあり方、電子署名 を駆使して、さまざまな健康診断書等の電子化を容認することなど、貴重な提言をいた だいておりますので、今後の委員会での議論でも参照していただきたいと思います。 　参考資料３、４については、前回、この委員会で取りまとめられた中間論点整理メモ に基づいて、今後の主要な検討事項として14項目が抽出され、それぞれについて委員 会、委員、関連研究班、その他留意事項として、今後の検討体制が決定したところです が、その決定事項についてのメモです。適宜、参照いただきたいと思います。前回の委 員会以降の主要な動向については以上です。 ○大江座長 　前回の委員会以降の動向について、ご意見、ご質問があればお願いいたします。名古 屋の医療情報学連合大会では報告会があって、大変盛況で、このような報告会は、大き なテーマでいくつも研究班があるときには、今後も継続して行われていくといいと思い ました。後半のディスカッションは、報告会では今回初めての試みだったと思います が、これについて、一般の方にわかるような記録なり、サマリーが後で出るのでしょう か。 ○高本補佐 　現時点ではまだ準備ができておりませんが、今後、この委員会にもご披露させていた だきたいと考えております。 ○大江座長 　出る予定だということです。委員の方々は、かなりの数の方が出られたと思います が、何かコメントがあればお願いいたします。本日配付された参考資料４、５について は、後ほどその他のところで詳細な説明、議論をいただく時間を取ろうと思いますの で、一応報告をいただいたということで終わりたいと思います。 　議事に入る前に、松原委員は都合により前半で退席されるとのことですが、特に何か 発言がありましたらお願いいたします。 ○松原委員 　特にありません。 ○大江座長 　（２）主要検討項目の検討状況の報告に入ります。今日は大きく３つのテーマについ て報告をすることになっております。最初は私が担当しております「標準的電子カルテ に要求される基本機能の情報モデルの開発」ですが、用意した資料１に基づいて説明さ せていただきます。その後、ご意見、ご質問をいただき、議論していきたいと思いま す。 　資料１と参考資料１の中にもサマリーが載っておりますので、両方をご覧いただきな がらお聞きくださればと思います。何度か報告しておりますが、私の担当している研究 班は、標準的な電子カルテに要求される基本的機能を整理する。病院ごとの役割、医療 機関の役割が違う場合、どのような機能が必要で、どのような機能はオプションでいい かということを整理して、機能のモデルを示そうというのが目的です。 　具体的なステップとしては、昨年度、国内でほぼ完全にペーパーレス電子カルテを動 かしている５病院を選びました。海外はアメリカのメイヨ・クリニックでの視察、これ は事前にかなり詳細に予備調査を行い、かなりの資料もいただき、その上でそれぞれの 機能が実際にどのような場面で、どの程度使われているかということも含めて調査をい たしました。その調査結果に基づいて、機能のリスト、要件リストというものを作り、 そこから機能をグルーピングするような形で抽象化をし、モデルを記述するといったこ とをしております。 　調査は先ほどお話したとおりですが、調査の結果、病院によって微妙に細かいところ の機能はかなり違っている、あるいは使われ方が違うということはありますが、それを 集約する形で整理し、要件リストを作る。それを抽象化するわけですが、いろいろ調べ た結果、コンピュータシステムのユーザーに対する機能、組織に対する機能をどのよう な形で形式的に記述するか、モデル化するかということは、典型的な方法として、必ず しも確立した方法が提案されていないことがわかりました。ここでは機能を抽象化し、 機能要件の階層構造をつくることにしましたが、その際、機能をいくつかの分類視点に 分けて考えてみることを試みました。 　具体的には、ここに７つの分類軸というものを導入しました。何がその機能を提供し ているのか。今回は主語を確定してしまえば、その後が決まるということもあったの で、アクター、つまり働く機能を提供している側をシステムとして固定した形で行いま したので、ほとんどの場合、「システムが」ということになります。 　どのようなときに使われるかということは非常に重要なわけですが、それも具体的に はユーザーが何かのアクションを起こしたときに、その機能が使われる、提供されると いう場合と、患者のある検査結果がこのような状態になったとき、あるオーダがこのよ うな状態になったときなど、「ある情報がある状態になったとき」にその機能が役割を 提供するという記述の仕方です。システム自体の状態、例えば電源が入ったときなどい ろいろあると思いますが、そのようないくつかの起動条件が整ったときに、機能が提供 されるかという視点から分類する起動条件。 　その機能が提供される場所、例えば入院した部屋、検査室、大きな目で見た場合は、 ある役割を持った医療機関でのみ使われるなど、そのような機能の提供場所、あるいは ユーザーから見た場合は使用場所の視点。 　システムがその機能を、一体誰に提供するのかといった提供対象者の視点。例えばユ ーザーに、管理者に、システムが別のシステムにということもあるので、対象者がシス テムということもあります。 　次に、どのような情報を提供するかということです。ある情報を組み合わせて操作す るような機能の場合もあるので、そのようなときは第２対象といった意味合いでの操作 対象。言葉としてはわかりにくいかもしれませんが、２つの情報を組み合わせるような 場合の第２対象物です。これはかなり重要ですが、どのような目的のためにその機能が 用意されているか、提供されるか、あるいは、その機能が本来目的としている機能は何 かといったことを整理する視点。具体的にその機能を実現する方法。こういった形で、 それぞれの機能を分類してからモデル化することを試みました。 　全体で約367項目の集約した機能項目があり、それらをこの視点に基づいて分類して いくことになりました。全体の表はまだ整理中の部分もありますし、表全体は非常に大 きなものなので、全体を示すことはできませんが、一部を示すと、このような形で整理 を進めているところです。先ほど説明したように、具体的には分類の軸を、最終的に誰 が、どのような条件で、どこで、誰に、何を、どのように、どうするという述語を入れ ると８種類になるわけですが、そのような視点でこのような分類表を作りました。 　この表の水色の所が枝葉で、いちばん下のレベルの機能項目になります。これを列挙 した上で、それを集約した、抽象化した機能、さらに包括的に抽象化した機能という形 で、黄色の部分は抽象的な機能の表現になっています。これで言うと、何か情報を表示 する機能として、情報が存在していること自体を表示する機能と、ユーザーなりが何か 確認すべき情報がある機能、それがどこにあるかということを表示する機能という形 で、階層的にここが分類されていますが、最終的には、この機能はユーザーがシステム にログインしたときに、スタッフで何か強制的に知らせるような連絡情報が存在すると き、それをユーザーが確認すべき情報があるということを示す。確実な情報伝達を確保 するために示すということになります。 　例えばログインしたとき、すぐユーザーに知らせなければいけないような機能がある 場合、つまり、あなたのいないうちに別の人からこのような検査オーダが発生しました と、それは主治医がログインしたとき、必ず知らせたほうがいいわけで、そのような情 報を提供する機能になります。このような形で整理を進めています。 　当然、機能自体をどんどん抽象化していくと、必ずしも電子カルテに特化したような 機能ではなくて、ごく当たり前の情報システムがユーザーに提供する機能体系になって いきます。これはいちばん最後の動詞の部分の「何をどうするか」で、表示するのか、 指定するのか、収集するのかといった部分だけで分類すると、最上位の抽象化したトッ プレベルは、何か表示する機能、指定する機能、収集する、比較する、通知する、追 加、修正、破棄なども含めた編集、出力、保持と大きく８分類になっていますが、これ を７つの分類軸それぞれについて抽象化すると、１つの機能が動詞も入れて、合計８種 類の分類軸で、それぞれの視点から分類されることになります。ですから、ある機能 は、どの分類軸で言えばどのような階層にあるかという整理の仕方ができるようになり ます。 　これはシステムのデータ表示機能の部分を少し抜き出したものですが、ユーザーが１ 患者の診療記録を編集するときに、何らかのフォーマットのリストを提示する機能とい う形で整理します。これはシステムのデータの表示機能のツールを、表示する機能の部 分を抜き出したものですが、このような形で現在整理が進められています。 　そのように整理したものを、機能モデルの形でモデル図に表現していくことを同時に 試みました。例えば、１つの機能というのは、いまお話したように、いつ、誰が、どこ で、何のために、どのように、何を提示する、何をする機能かといった形で１つの機能 が提供できる。それぞれの機能が法的には必須の機能であるのかどうか、技術のレベル によって機能の提供の仕方が変わる可能性があるかどうか、そもそも機能の必要性が法 律以外の要素としてはどのようなことによるかということを、最上位の機能の属性とし て保持する形で仮にモデル化を進めています。 　このようにしておくと、例えば、なぜこの機能はあるのかといったときに、それが法 律に依存した機能なのか、そうではないのかということがこの部分で管理できます。も う１つ、ユーザインタフェースの依存などもありますが、ある機能を実現するために、 ある特殊なユーザインタフェースが必須であるものなのか。それとも、そのようなこと には依存しないで実施できるものなのかといったことも、この中で表現できるようにな るわけです。この機能は具体的に、どの情報が、どのような条件のときに、どのような 情報を操作するかという部分を持っているので、その部分については当然、ＨＬ７のレ ファレンス・インフォメーションモデルで記述される情報との対応づけが可能になりま す。 　ユーザーのアクション、あるユーザーがどのようなアクションを起こしたときにと か、システム内部のデータがどのような状態になったときにその機能が使われるか、提 供されるかといった部分は、まさに業務フローのモデルと直結してくるわけですから、 いわば、この機能モデルの周辺に業務フローモデル、データ情報モデルがあり、それぞ れと関係づけることができるようになると思われます。 　７つの分類軸、動詞を入れて８つの分類軸があり、それぞれについて機能階層のモデ ル化を進めているとお話しましたが、例えば情報操作対象物、対象者に視点を置いて分 けた場合は、このような分類になると思います。このような形で、いろいろな機能を多 軸で分類していくということを行っています。 　今後の計画ですが、いま示したようなモデルの表、現在はまだ最終的に細かいところ を整理しつつありますが、これとモデル図を公開する。公開することによって、表を使 えばFunction Listがあるし、それぞれの分類の視点で構造化が行われているので、そ れを使って１つの機能を多軸で分類し、参照することができるわけです。機能の相互の 依存関係はこれから分析することになりますが、表の中で記述されている機能と機能と の間の関係性を、別の形で書きたいと思っております。先ほど300数十の機能があると 言いましたが、この粒度の詳細化、ある部分についての十分な詳細化をする必要がある ということで、もう少し粒度の調整をしたいと考えています。 　医療現場のコンテキスト、使われる環境、使われるいろいろな状況の要因といったも ので、モデルがどう変わっていくかということを、今後検討していく必要もあるだろう と考えております。12月上旬と書きましたが、何とか来週中に作業を終えて、来週後半 か再来週の頭には、特に機能モデルの表についての公表を行い、修正意見を求めたいと 考えています。今後の予定では、年度末に最終案の公表に漕ぎ着けたいといった状況で す。 　Ｊ−ＭＩＸという、電子化された診療録情報の交換のための項目セットというものが ありますが、まずはあのようなイメージで標準的電子カルテが備えるべき機能の一覧表 を作り、Ｊ−ＭＩＸの場合は、特に各項目に分類コードが付いていなかったので、今回 は７プラス動詞軸１の８種類の分類に基づくコードを、それぞれの機能項目に付けるこ とにより、非常に複雑な視点からでも１つの機能を選び出すことができるようにした い。 　利用方法としては、例えばクリニックでこのようなことが必須である電子カルテを作 りたいときには、これとこれとこれを選べば、芋ずる式にそれに必須の機能のリストを 作ることができるようになると思われるので、そのようなイメージのものを最終成果物 の１つとして出したいと思っております。以上で私からの報告は終了しますが、何かご 質問、コメント等があればお願いいたします。 ○大久保委員 　実際に病院を調査した結果ということですが、本当はもっとこのような機能があった ほうがいいが、技術的にできないようなものがあったときに、その辺はどのように反映 をするのですか。 ○大江座長 　事前にある程度書類調査をした上で、それに研究班の視点も加えて、このような機能 もあったほうがいいのではないか、もしかしたら将来必要になるのではないかといった ものを付け加えたリストを作りました。それを調査に行ったときに、このような機能は ないのかといったヒアリングを、システム開発に関わった管理者とユーザーの両方に聞 く。ユーザーも医師、看護師、複数の職種の方に聞いたのですが、研究班も思い付かな いような理想的な機能というものは、もちろんたくさんあるわけですが、それはちょっ と置いておいて、現時点であるべきではないかと思われる機能は、おそらく項目に挙げ てあると思います。 ○木村委員 　この話は、やればやるほど電子カルテというよりも、病院情報システムの話、オーダ 系だけの話になるような、だからどうということもないのですが、そのような意味で電 子カルテだけに限定する話ではなくなっているでしょうね。 ○大江座長 　そうです。調査すると、木村委員の言われるように、かなりの部分は電子カルテだけ の特別な機能ではないということが、むしろわかってしまうのです。いわゆる電子カル テならではの機能とはどの部分なのかというのは、確かに疑問も出てくるところです。 　ただ、非常に違うのは、従来のオーダリングシステムというのは、ある人から別の人 へ何かを伝達する、ある部署から別の部署へ要求を伝えることが基本であるのに対し て、電子カルテならではの機能は、その場で起こった、あるいはその場で入手した情報 を記録することが主体であり、そのために必要な機能や情報をどう手に入れることがで きるかという部分に注がれているのだろうと思います。抽象化してしまうと、電子カル テであろうがなかろうが、場合によっては医療情報システムであろうがなかろうが、み んな共通の表現になってくると思います。 ○阿曽沼委員 　このモデルが想定する規模などに、何か限定的なものがあるのか。病院内部の情報処 理と外へのというのは、どのように考えるのでしょうか。 ○大江座長 　調査対象病院の性格からしても、１つの情報システムを複数の医療機関がシェアして いるようなものは、今回はまだ想定していなくて、一応、１医療機関１システム独立 型、ペーパーレスで動く規模ということになると思います。ただ、医療機関の規模とし ては、調査対象は一応病床がある病院を選び、今回は無床の診療所はその対象にはいた しませんでしたが、病床数はかなり小さい規模から大きい規模まで調べました。しか し、実際にはそれほど違いがなかったので、あまり病院の規模などには依存してはいな いのではないかと思います。 　時間が余りましたら、個別に戻っていただいても結構ですので、予定している２つ目 の項目に移りたいと思います。２つ目は「医療安全確保の視点から電子カルテシステム のあり方等」ということで、保険医療福祉情報システム工業会の成松様からお願いいた します。 ○成松氏（水口委員代理） 　澤田先生の研究班のお手伝いということで、ＪＡＨＩＳのほうにワーキンググループ を立ち上げました。今日はその立ち上げた内容と、ワーキンググループの中での作業で はないのですが、以前ＪＡＨＩＳのほうで安全に関わる、処方ミスに対するガイドライ ンというものを報告したことがありました。お手元の資料にはないので、後ほど何らか の形で配付させていただきますが、いままでやったことの経緯という意味で、それを含 めて報告させていただきたいと思います。 　まず、ワーキンググループの立ち上げの報告をいたします。テーマとしては「医療安 全の確保に電子カルテが寄与できる領域等の検証及び安全性の確保の視点からのシステ ムのあり方」となります。私は診療支援システム委員会の委員長を拝命させていただい ておりますが、その下に医療安全検討ワーキンググループというものを受け皿として立 ち上げました。当初、澤田先生からのリクエストがあるのではないかということから、 一度摺合せをしておかなければいけないということで、10月九州大学を訪問させていた だき、意見交換を実施いたしました。 　その時点では澤田先生のほうも情報をあまり持っていらっしゃらなくて、方針的なも のは出ておりませんでした。最初からわかっていた話ですが、先生は医療安全の中でも 処方を中心に研究しているということで、そのときに全体を推進にすることは難しいと いうお話をいただきました。 　次の頁ですが、ワーキンググループの目的としてはこのようなものを考えておりま す。これはＪＡＨＩＳの医療システム部会の中でのワーキンググループの目的というこ となので、本来、この委員会でどのような方向で、どう考えられていくかということに ぴったり沿ったものではないかもしれません。と言いますのは、この委員会で検討した 結果を持ち帰り、またこの中で揉んでということをしなければ、ワーキンググループの 方向も定まらない部分もあるからです。ここでは将来的なことを含めて、取りあえず、 ＪＡＨＩＳのワーキンググループの中ではどのようなことをやろうかということを決め て、スタートを切ったという背景があります。 　目的は「医療における安全に関し、情報システムの視点から支援すべき内容をまと め、医療安全の確保に資する情報システムの普及を目指す」ということで検討しており ます。ワーキンググループの概要としては、ＪＡＨＩＳ医療システム部会、診療支援シ ステム委員会のワーキンググループとして設置するとともに、電子カルテ推進委員会の 作業アイテムであるこのテーマに対するＪＡＨＩＳとしての受け皿という２つの側面を 持ち、活動するということになっております。 　ＪＡＨＩＳのワーキンググループの成果としては、このようなことを考えたいという ことで、例えば医療安全に関しては、情報システムが支援すべき機能、場面とその範 囲、これは処方の話になりますが、処方オーダ時の内容チェックや不適正なオーダを防 止するためのさまざまな機能を洗い出す、診療行為実施時の患者特定の支援、これは、 例えばバーコードの利用などで最近言われている話ですが、患者取り違え防止に対する 情報システムとしての支援、医療スタッフ間の情報伝達や情報共有に対する支援、とい ったものも安全という側面からは重要なテーマではないかと思います。また、医療機関 内の話や複数の医療機関をわたるような話を含めて、治療計画に対するガイドラインな どをつくるとき、例えばデータベースをつくるとかそれを提供していくといった情報シ ステム支援の部分がありますが、このようなものが医療安全に関してあるだろうという ことです。 　我々はベンダーの集まりですので、このような部分が各ベンダーのシステムの中に、 少なくともこのようなことはないといけないという、ある程度コンセンサスを得られる 範囲のものをつくっていかなければいけないと思っています。後ほど説明する、以前行 った処方ミスのガイドラインについても、そのような内容が求められ、最終的な報告の 中にも入っています。これは平成13年のことでしたので、いまのシステムにいくつかそ のようなものが反映されて、ある意味では役に立っているのではないかと考えておりま す。 　いまの話に関連しますが、最終的に成果あるいは報告すべきものとしては、最後の所 にあるように、「チェックやガイドに関するコンテンツ整備の枠組みに関する提言」と いうことで、例えばマスター、これは以前にも話題になったことがあるかと思います が、医薬品の名称、副作用、極量値などのマスターをどう整備するか、これは一部いろ いろな試みとしてすでに提供されているものもありますが、マスターの評価に関するこ とがあります。コードについても、いろいろな側面のコードが混在しているところがあ りますので、その体系などを含めて検討が必要です。 　以前から診療支援システム委員会の中で少し検討していたのですが、ＨＬ７のArden Syntaxというものがあって、チェックするときにどのようなロジックで処方の内容を チェックすべきか、チェックするときの体系としてこのようなものが適切であり、それ に対して、このような要件が備わらないとコンピュータのほうで使うことができないな ど、使っていく上での条件などは、私どもですべて解決できるわけではないので、問題 提起を含めてそのようなものを検討していくことを考えております。 　以上のことが、今年度だけということではなく、ワーキンググループが今後継続的に やっていこうという内容になっております。これはワーキンググループの中で、こんな ことがあるということで例示したものに過ぎないのですが、医療事故の発生要因で、い ろいろな書物の請売りであり、研究者ではありませんから、いろいろな資料を集めて表 にしただけの話になりますが、医療事故には、エラーと言われるもの、ルール違反をし たことによって起こってしまったものと大きくは２つに分けられます。エラーに関して は、「うっかりミス」「漏れ」「思い違い」などがあります。 　このようなものに対して、情報システムでどのような対策ができるのか。ここでは大 括りな言葉で書いてあるので、どれも皆同じようなことになりますが、例えば転記す る、データを加工して、ビューを変えて見るなど、情報システムはいろいろなことをや っております。 　例えばうっかりミスであれば、転記ミスが発生したときに、情報システムでは転記し なくても、ビューを変えて見ることができる、データを確保して見ることができるな ど、言葉で言うと自動化ということができます。あるいは、入力したときに入るべきも のが入っていないというチェックができます。そのような形で、うっかりミス、漏れ、 思い違いといったことが情報システムでカバーできるわけです。 　表の黄色の所をどのようなデータを基にして、どのような形で調べていけば、ベンダ ーのガイドライン、ボトムラインとして、最低限このようなことをやっていかなくては いけないかということが提供できるかを考えねばならないと思っています。ルール違反 に関しても、これにはいろいろな問題はあるのかもしれませんが、どうしてもこのよう な点を踏んでいかないと、情報システム上で次のステップに進まないとか、そのような 仕掛けはある程度は考えられるのではないかということで、どこまでできるかという問 題はあると思いますが、ある程度はお手伝い、支援できるのではないかと思います。医 療事故の発生する場面において、情報システムがどのような支援をするかということ を、このような形で整理していこうという議論をいたしました。 　いまのところはこの範囲なので、先ほどのご報告のように細かないろいろなことを申 し上げることができないのですが、方針的なものということで説明いたしました。澤田 先生は一部の処方に関する研究のため、全体を引っ張るという形にはなりませんでした が、私どもとしては、現場で起こるいろいろなことに対して、その問題点をどうシステ ムで支援するかについて、起こっていることに対してある程度ガイドしていただけた り、提供していただける先生方や現場の方々と一緒にこの作業をさせていただきたいと 思います。私どもとしては、机上でこのようなことが起こるのではないかという推定 で、検討を行っていてもしようがないので、そのような方をご紹介いただき、実務的に 一緒に作業していただけるとありがたいと思っております。 　報告としてはこのような感じですが、次は平成13年３月の報告で、私どもＪＡＨＩＳ （保健医療福祉情報システム工業会）は厚生労働省の指示により、処方ミス対策会議を 設置しました。平成12年11月、「サクシン」と「サクシゾン」の事故だったと思います が、薬をオーダエントリーするときに指示間違いがあり、ＪＡＨＩＳが処方ミス対策ガ イドラインを取りまとめました。これについては、こんなことをやったという報告だけ に留めて、後ほど資料を提供させていただきます。ただいま申し上げたような経緯があ り、指示をいただいたのですが、この中では処方指示の処理手順は、先生から指示があ り、それを監査し、調剤し、調剤監査し、引き渡して服薬、投与といった形でなされま す。このステップごとにいろいろな法的な背景などがありますが、これが情報システ ム、オーダエントリーシステムを中心とした情報システムでは、どのように関わってい るかを分析しました。オーダエントリーそのものはいろいろな機能があるわけですが、 その中で処方ミス対策機能を中心に考えたとき、例えば薬品を選択する場合の薬品名、 重複投与量、麻薬や毒薬などについてはどうするか等、いろいろな対策を取っていま す。当時は登載しておらず、今後このようなことが登載されるであろうとベンダーのほ うで考えていることも含んではいたのですが、そのようなものを洗い出しました。ま た、薬効、常用量、用量の最大値など、いろいろなチェックがされていますが、このよ うなことが薬品チェックというテーマです。 　それ以外に、情報提供、漏れがないようなチェックリストなどを帳票で提供したり、 調剤を実施するときに最終の確認ができるようなタイミングの問題やそれ以外の支援な ど、いろいろな機能が付いていて、その時点でもある程度情報システムによってカバー されることは少なくないという結論が出ております。ところが、やはり先ほど述べたよ うな事故が起きてしまい、機能があるにもかかわらず起きた、その内容はどのようなこ とかということを分析しております。 　表では指示誤り、伝達誤り、取り違い、システム自身の間違いなどに分類しておりま す。システム自身の間違いの中にマスター設定というものがあるのですが、マスターと いうのは人為的に登録するので、そのときにミスが起こるわけですから、システムとい うよりも人為的ミスであり、システムのミスとはしておりません。このときも、このよ うないろいろな誤りの原因、発生要因があるだろうと分析しております。 　それを大括りに括ったところ、情報関連、運用関連、マスター関連と分類できるので はないか、情報関連では薬品名称、これは人間が目で見て選択することから、表示名称 などは紛らわしくないような状態にしなければいけないといったこと、マスター関連で はメンテナンス不良、マスターに関しては手間がかかるので、共通のマスターで手間が かからないようなことをしてあげなければいけないのではないか、各ベンダーのほう で、そのようなものを用意しているケースもあり、ＭＥＤＩＳのマスターなども出てき て環境は良くなっていますが、当時としては、マスターは大事だという話が載っており ます。 　情報システムの役割としては、「正確な情報を素早く提供し、人間の判断に入力・選 択ミスの入り込む余地を減らすこと」「蓄積データを広く提供し、第三者によるミスの 早期発見及び運用回避の確認をすることに寄与する」があります。そのために先ほど出 てきたいろいろなミスの要因に対して、次のようなことを対応策としてやっていったら いいのではないかと述べています。１つはシステムの機能ですが、もう１つはマスター を共通なもの、標準的なものとして用意することによって、かなり避けられるのではな いか、その中で、やはり名称を情報システムとして適切な名称になるように、選択のと きにミスが起こらないようにという意味ですが、そのようなことが必要だと結論づけま した。 　最後の所にバーコードリーダーやＩＣカードの活用事例があるという話があります が、これは患者と処方箋、調剤薬と処方箋といった確認照合をどう行うかということで すが、３年前の検討の中では除外されております。これは新たなハードウェアや別の環 境が当時としては必要だということから、そこまで言及するのはやめようということに なりました。必要だということまでは書いてあるのですが、どのような形で対策の中に 盛り込むかということに対し、ここに盛り込むとベンダーがどう対応すればいいかとい う問題も発生してきますので、これは対象外としました。話が戻りますが、マスターを 中心とした改善や機能のところで述べたような改善をしていこうということが対応策と して出されております。 　ガイドラインとして最後にまとめていますが、具備すべき処方ミス防止機能として３ 段階あります。１つは確認事項で、このシステムがどのような思想でできているかを、 医療機関にきちっと説明し、それに即した運用をしてもらうことが大事である。一方的 に、つくったものを黙って提供しても、意思疎通がないと、それがミスに繋がるという ことがあるので、いまいろいろ用意している機能についても、その考え方をきちっと提 供し、やっていこうという話があります。 　また、システムとしてどうしても改善しなければいけないことがあり、もちろん行っ ているシステムはあるのですが、最低限このようなことをやりたいということで、いま ではかなりの所がやっていますが、病名と処方薬剤のクロスチェックがあります。この 中で危険性の高いものだけでも有効ではないかという結論を出しております。危険性の 高いものについては色を変えるなどが有効であるが、それについてはどれも警報が出て しまうと警報の意味がなくなるということから、厳選しなければならない、名称を整 理、縮小して、重複したような名前にならないようにしなければならないなどというこ とを言っています。また、これはかなりのベンダーが採用していますが、薬剤選択入力 時、２桁が結構あったのですが、３桁以上でなければいけないようにした、これについ ては改善事項として実際のシステムでも採用されてきています。また、やればより良い ということも、追加事項として記載されております。 　先ほど述べた、情報処理用の標準的なマスターを策定していかなければいけないとい うことに対して、報告書の中では、「もうすぐ提供されそうなので」といった表現がさ れていますが、その辺はちょっといろいろ事情があって、必ずしもきちっとした形にな っていない（補注）のかもしれません。運用上、設計上の問題についても記載がありま すが、時間の関係で省略させていただきます。以上、３つの整理でガイドラインを提出 させていただいております。これが平成13年３月時点の話です。今般、ワーキンググル ープで作業する中でも、せっかくこのようなことをやりましたので、それらを踏まえて 作業していきたいと思いますが、ただ、これは処方だけですので、これ以外のことを含 めて、近いうちに方針を決めて作業に入りたいと思っております。（補注）報告当時に 想定されていた「情報処理用名称」を含んだ形式のマスターは提供されなかった ○大江座長 　ただいまの報告に対して、何かご質問、ご意見があればお願いいたします。 ○木村委員 　薬品マスターという話があり、必ずしもうまくいっていないようなおっしゃり方をさ れていましたが、驚くべきことです。ＨＯＴコードというものは、ＭＥＤＩＳも即応体 制を整えて、物流コードとも体制を整えつつあるのです。その活動があるにもかかわら ず、いまのお話では、必ずしもきちんとした形でできていないと言われたのはどのよう な意味ですか。 ○成松氏 　できていないということではなく、ここで言っている形にはなっていないということ です。ちょっと言葉が足りなかったかもしれませんが、先ほど名称をこのようにしなけ ればならないといったことがガイドラインの中で少し出ていて、近々このような形で出 てくるだろうという記述があるのです。 ○木村委員 　名称の付け方のガイドラインですか。それともマスターそのものですか。 ○成松氏 　ガイドラインそのものはマスターだけではないのですが、名称の部分の話をちょっと したつもりだったのです。 ○木村委員 　あのようなマスターがちゃんとあるのに、ベンダーの方がそれをいかにも十分でない みたいなおっしゃり方をされるのはいかんことだと思います。 ○成松氏 　申し訳ありません。そのような意味ではありませんでした。 ○大江座長 　報告のあった情報処理用医薬品マスターは、具体的にはコードだけではなく、名称が 情報処理システム用に適切な形になった名称であり、警告を出すための上限量といった データも付いたような情報処理用のマスターという意味では、まだ完全にでき上がって いるものではないという意味ですか。 ○成松氏 　そうです。 ○大江座長 　この委員会としては、参考資料４にもある検討事項の10番の「医療安全の確保に電子 カルテが寄与できる領域等の検証及び安全性の確保の視点からのシステムのあり方等」 について、いまご報告いただいたわけです。前回の委員会では、関連する研究班として は澤田先生の研究班が考えられるということで、リストに挙げさせていただいています が、基本的には研究班のカバーしている範囲と、10番の検討事項の範囲とは大きさが非 常に違うわけです。 　10番の検討項目は非常に大きい項目で、それに対し、関連する研究班として挙げた澤 田班のほうは、その中でも処方オーダに直結する部分を研究されているということで す。テーマ自体が非常に大きいので、いま報告していただいたように、ＪＡＨＩＳのワ ーキンググループでの検討事項を、この委員会でも反映できたらと思いますし、澤田研 究班の結果も、反映できるところはこの委員会で反映できればという趣旨であります。 最終的には委員会全体で、大きなテーマを報告書にどうまとめるかを検討していくかと いうことになるだろうと思います。 ○高田委員 　保健・医療・福祉情報システム工業会（JAHIS）では診療支援システム委員会の下に 医療安全検討ワーキング・グループを組織し活動を開始されたということを、今日、成 松さんに発表していただきました。この中でコメントがありましたように、医療の安全 性の確保に関する実務的な活動をされている方に、ＪＡＨＩＳのワーキンググループに 参加していただき、一緒に活動していただきたいという希望があるということです。適 切な方がいらっしゃれば、推薦していただくなど、何かの機会を設けていただければと 思っています。この点についてご関係の皆様にご配慮いただけますと幸いです。 ○大江座長 　いまご報告いただいた内容に関して、ほかに何かございますでしょうか。 　処方オーダーのところについて、平成13年の検討を少しご報告いただきましたが、も ちろん処方に特化したこともあると思いますが、逆に、処方に限らず取り込めるような 趣旨も随分あると思いますので、そういうものも処方に限らずうまく、基本的に考える べき事項としてまとめることができるのであれば、そういう視点も是非今後検討できた らと思います。 ○成松氏 　わかりました。 ○廣瀬委員 　後半のほうがむしろ重要で、資料も頂戴したいなと思っていたのですが。もちろん技 術が進歩すればさまざまな機能を付加して行けるのかもしれませんが、少なくとも現時 点においてはシステムの責任と人間の責任とを明確に分離しておくべきでしょう。と言 いますのも、工業界あるいはシステムに対する過度の期待は、逆に診療リスクを増大さ せてしまう危険があるからです。その辺りは、ＪＡＨＩＳからレポートが出されるとき に明確にされておいたほうが宜しいのかな、という気がします。 ○成松氏 　はい、わかりました。ありがとうございます。 ○大江座長 　その後半の部分のガイドラインというのは、公表されているものですか。誰でも手に 入るものですか。 ○成松氏 　はい、公表されています。このパワーポイントは、今回この委員会のために打ってき たものですが、報告資料の形式のものは、ＪＡＨＩＳのホームページに掲載していま す。 （補注）http://www.jahis.jp/site/houkoku/report/houkokusyo/2001/unnh/gaidorain.pdf ○大江座長 　ということですので、また一度ご覧いただきたいと思います。それから、このテーマ について委員の方から少しご意見をいただきたいのは、いわゆるオーダシステムが寄与 できるという以上に、今後の標準的な電子カルテというものが貢献できる、あるいは貢 献するために、何か持つべき機能というような視点で、特別なものがあるかどうか。何 かご意見をいただけたらと思いますが、いかがでしょうか。 ○廣瀬委員 　クリニカル・ガイドラインのような、という意味ですね？ ○大江座長 　例えば、１つの切口は、何かその電子カルテシステムなりオーダリングシステムが自 動的にチェックをしようとする。出されようとしている医薬品の名前と、電子カルテの 内容、病名でもいいですが、それを使ってチェックしようとしたときに、電子カルテ側 のほうの情報が、やはりきちっと必要な細かさで入っていないとチェックできないわけ です。例を言うと、病名が入っていなければ、病名とチェックすればいいなと言ってい ても、マスターにもデータがあっても、チェックは現実にはできないということです。 　つまり、電子カルテが持つべき必須のデータ、これだけはチェックしたいから、これ だけはやはり電子カルテに、こういう形で記録しておいてほしいというようなことも出 てくるのではないかと思うのですが、その辺りの検討がおそらく必要ではないか。そう いう意味で、これからの電子カルテが持たなければいけない機能とか役割とか、そうい う視点での追加がもしあれば、出しておいていただけると今後の検討課題にできるので はないかと思います。高田委員、いかがですか。 ○高田委員 　平成１６年１１月２８日に名古屋国際会議場において開催された第６回 標準的電子 カルテ関連研究報告会で、標準的電子カルテ推進に関するディスカッションの席上にお いて、安全性の確保に必要な「ユニット」というものを考えてはどうかと提案させてい ただきました。 　例えば、行われている行為をチェックするというだけではなくて、行われるべきであ るにもかかわらず行われていない行為に何があるのかということをチェックし、こうい う行為が行われる必要があるのではないかというリマインダーを出す、というような機 能が必要ではないかと考えています。例えば、ある薬をある一定期間飲んでいるにもか かわらず、チェックされるべき検査項目が実施されていない場合にこれを指摘するなど です。 　必要な行為が行われていないということを洗い出し適切なリマインダーを提示するに は、情報システムとしてどのような機能や情報を整備しなければいけないか？という観 点での検討が必要なのではないかと考えております。 ○廣瀬委員 　山ほどあるのですが一つだけ申し上げますと、診療におけるゴールというかエンドポ イントというか、その辺りを明確にするような機能を盛り込まないといけないのかなと 思っています。すなわち、もちろん病名も必要ですし、いくつかの検査項目も必要でし ょうけれど、のみならず、ゴールあるいはエンドポイントを明確にするような『入れ物 』を用意しておくといった設計は、今後検討されてよいのではないかと考えておりま す。 ○大江座長 　ほかに、この医療安全に関係して、電子カルテがどう役割を果たせるかというような ことで、検討すべき事項、視点がございましたらお願いします。 ○木村委員 　基本的な安全性の確保はマン・マシンシステムでということがあると、この視点は、 電子カルテが寄与できるとか、情報システムの切口でということに、工業会の立場はわ かるのですが、ちょっとタコ壷ふうに見えるのです。マン・マシンシステムとしての安 全性の確保の中で、何が寄与できるかという視点をもつならば、もう少し処方オーダの とか、そういう方向ももちろん大事なのですが、もうちょっと広い安全性の確保の議論 の中で、ここで電子的に何が寄与できるかという視点がほしい。 　つまり、求めていくべき対象は、情報システムと全然関係なく、いろいろ安全性の確 保のために行われた成果の中で、そういうものは情報システム的なものの観点がないと すれば、こういう助けがあるというような、つまり、タコ壷は駄目で、人間系との絡み を忘れていただきたくないと思います。 ○大江座長 　この検討事項そのものは、中間論点整理メモに挙げられている言葉そのままですの で、その中でシステム側から見たとき、どういう事故があるかということを、ＪＡＨＩ Ｓのワークキンググループではご報告いただいたということだろうと思います。 　ですから、我々はこの委員会の中で、いまご指摘があったような、人間系との関与の 中でどう考えていくかということも、これから報告書に入れていくべきことだろうと思 いますので、そのようにしたいと思います。 　それでは続いて、３つ目の報告ですが、「相互運用性の確保について」ということ で、木村委員からお願いいたします。 ○木村委員 　この参考資料４の検討体制の13番、「新旧システム間での円滑なデータ移行、異なる システム間での互換性確保」という部分の話なのですが、その前にちょっと、この参考 資料で私が関係する部分に４と５があります。４は、いま大江先生が機能、プリミティ ブの洗い出し作業をされているという、その後ろに医療情報学会というのがあって、私 の関係で、副会長の立場及び、例の学会から出した電子カルテの定義と見解というのが あります。 　この間の連合大会のシンポジウムの場でも、ややアップデートしたいと、ＩＳＯのＯ Ｉに、電子カルテの定義、機能要件があり、一方アメリカでも、ご存じのとおり、ＩＯ ＭやＩＨＳＬが出した電子カルテの機能要件があります。そういう動きもあるというこ とをご紹介するとともに、もう１つ、これは私の個人的な立場ですが、医療情報学会か ら出した定義に従うと、電子カルテは何パーセントかという調査を早速、静岡県の病院 相手にしてみようと思います。どうもやはり、現状で出ているあの７％とかいう話は、 ペーパーレスの普及でしょうし、メーカーが電子カルテと称するものの出荷台数ですよ ね。違う観点での調査も是非したいということで、実は早速やってみようかと思ってい ます。 　５番については、私の名前が書いてありますが、あちらに作佐部先生もいらっしゃい ますが、この参考資料１の後のほうに、こんなことでやるということが書いてあります ので、ご期待をということでございます。この21頁の紙は表裏が逆で、裏側には20頁の 続きが書いてあります。 　13番の内容をご説明させていただきます。これには、２つ項目があるわけです。新旧 システム間での円滑なデータ移行と、異なるシステム間での互換性確保です。実は新旧 システム間というのも、異なるシステム間であって、連携の相手は昔の自分ということ もあるのです。ですから、根はかなり近いものがあって、１つの論点としておまとめに なったのであろうと理解しております。これは私の所と坂本先生の所、あとは当然なが ら、工業会に入っていただくようにということで、この３名でいろいろ相談をしまし た。 　先に、この異施設間連携の話をさせていただきますが、まず、この話をする前に、や はりちょっと構造的な問題について言わせてください。構造としては、いちばん外で、 ＸＭＬで記述しよう。これで出せますから大丈夫ですというメーカーがありますが、と んでもないですね。これは、便箋はＡ罫にしますというレベルですね。次はＨＬ７ＣＤ Ａ、これも当然ながら、２号用紙という種類のドキュメントタイプだとしましょう。 　そこで、２号用紙の中で初診時の所見はどこかという箱があって、これは、先ほど大 江先生からもご紹介のありました、Ｊ−ＭＩＸというＭＥＤＩＳがした仕事が非常によ ろしいと思います。 　さらにこの中に、コードが必要であろう。例えば膝蓋腱反射くらい書かないと駄目で すが、初めてこのコードの相互のシステム間、異施設間の理解があって、値が渡せるの です。この値が、プラスと書くか、亢進と書くかというのはまだ違いますね。データタ イプが大事である。こういう構造があって、それぞれにデータタイプが大事だというの は、こういうことなんだということを理解してください。 　異施設間の連携をする際に、まずこの対象のデータを確定しないと話は進みません。 全部というのは、なかなか難しいです。現状で、画像や臨床検査、機械が出してくれる データ、まず標準的形式としてすでに、ＨＬ７ＣＤＡやＤＩＣＯＭがかなり普及してい る。現実に、臨床検査会社はＨＬ７形式で、ＪＬＡＣコードでお返しいたしますという ことをしていますし、ＤＩＣＯＭで、ＣＤ等でやり取りするということも始まりつつあ ります。ＩＨＥのＰＤＩという規格もできて、この間、そのデモをしていました。あ と、コードの標準化の問題がやはりあるだろうとは思いますが、これは揃ってはきてい る。 　その次に定型文書、つまり、タイムサマリーとか紹介状とか、各種報告書とか処方箋 とか、人に見せるための文書、人に何かを伝達するための文書です。これは、上記の各 種コードや、例えばＨＬ７などの構造とともに、その中の文書の構造、これはＪ−ＭＩ ＸとＣＤＡということになると思うのですが、タグの名前やデータ対応、ここの辺がズ ラズラとくるわけです。タグの名前や、コードやデータタイプが大事ですということで す。さらに、最近はチーム医療が大事で、所見ももちろん人に読ませるためなのです が、所見経過及び専門的な内容や、例えば経営指標といったものは、これはさらにこう いったものの上に、それぞれの独自の細かい構造が必要であろうということになりま す。 　というわけで、ここの範囲は簡単、ここはそろそろできつつある、これはもう少し難 しいぞということになるわけです。実は、医療情報学会で電子カルテの定義を作ったと きの分析と同じような話になります。 　そうすると、現状と方向性は何かというと、先ほど申し上げた、ＨＬ７やＤＩＣＯＭ はＩＳＯですね。ＩＳＯのインターナショナル・スタンダード化という意味です。各種 コードは、ＭＥＤＩＳ及び厚生労働省の努力もあって、そして現実にそれぞれに携わる 先生方、業界の皆さんの苦労もあって、まあ、そろそろ揃いつつありますね。薬剤、検 体検査、病名、先ほど、ちょっとＰＨＹＸＡＭの話をしましたが、あれは身体所見、看 護カード、それで私がやっております画像検査とか、そういう項目があります。その５ つがあります。 　しかし、構造やタグやデータタイプというところが、まだ十分ではないので、先ほど の３つある２番目のところが、できる、できないの所に現状はあるだろうということで す。ＭＭＬというものがあって、ＸＭＬで記述するということがあるのですが、あれ は、やはりデータタイプとか、粒度の部分が浅くて、互換性に問題があると私は思って おります。現実に、いろんな病院が先進的に電子カルテを入れられたところ、やはり交 換ができない。何とか方法はないかということで、Ｊ−ＭＩＸがやはり基盤として網羅 性があるので、それに準拠するのがよいのではないかというとりまとめを、坂本先生が されつつあります。 　そうすると、先ほど大江先生のところでも、ああいう項目分析をしたときに、「何を 」とか、「誰が何の目的で」という部分は、実はＨＬ７のリファレンス・インフォメー ションモデルに、辞書として載っているというか、その辞書に準拠して、お互いに情報 交換することが望ましい。ということは、Ｊ−ＭＩＸのＲＩＭ準拠というのはやはり大 事だという話が出てきました。 　もちろん、その最後の３番目の部分、各種詳細の内容、専門外来の内容であるとか、 特にこういう項目で疾病に関して調査したいという話に関しては、これはもちろん、そ の専門グループに検討していただきたいのです。そのときに、例えば、あまり特別なも のを作らないように、一応ＲＩＭというものもありますので、そういう形での指針みた いなものがあるといいかなと思います。現実に、糖尿病学会ではミニマムセットという ものをつくられて、それをちょっと載せるというのを今後、静岡でやろうかということ を考えております。 　次は「新旧システム間」です。これは、異システム間、昔の自分とのデータ連携で す。技術的にはそれは同じようなものなのですが、個人情報保護法というのを考える と、旧システムをサーバーごと置いておくというのがいいのですが、それはちょっと現 実的ではない。中間的に、全部紙にはき出しておくという話もあるでしょう。標準的な 形式に落として検読性を確保するというのが、やはり妥当な方向性だろうと思います。 旧システム、それは今頃、Windows3.1を置いてやってということもないでしょうから、 そうなると、検査結果、処方はＨＬ７へ、画像はＤＩＣＯＭへという方向に、当然収容 されていくだろうと思います。 　先ほど申し上げた所見などは、ＸＭＬや、例えばエクセルの形式、ＣＳＶというの は、いちばん最下層の形式だけでは移行はできない。先ほど申し上げたように、タグと かデータタイプが大事なので、やはりもう１回言いますが、Ｊ−ＭＩＸのＲＩＭ準拠と いうところまでくれば、そのＪ−ＭＩＸの大枠の先は、やはりちょっと難しいと思うの です。少なくとも、新しい電子カルテのシステムで、初診時所見は初診時所見として移 行できるというふうに思います。それで、その上での内容は、まずは検読性の確保とい うレベルで見ることができるというのであれば、最低限のレベルは保障されているなと いうふうに考えます。 　そうすると、やはり大事になってくるのが、各種マスターの標準化です。この間の名 古屋での連合大会に先立ってさせていただいた、ＨＥＬＩＣＳ協議会のセミナーの場 で、あそこで私もちょっとパネルの企画を依頼されたので、あそこで是非、各パネリス トの方におっしゃっていただきたいとお願いしたのは、移行のタイミングです。どのよ うな方向でいくべきかというので、例えば薬剤であると、あれはＨＯＴはちゃんと一気 通貫になっているので、一気にやりやすい。一気にやるときに自動的にやりやすい。例 えば病名に関しては、結構ローカルにお作りになった病名マスターとの摺合せは、機械 的にいくのは、半分ちょっとくらいで、やはり人間の目、医者の目が要るなという話で す。そういう見通しのパネルをさせていただきました。 　それで、当然ながら、各マスターを作ってメンテをする側は、できれば代表的なマス ター間の対照表であるとか、各種マスターの履歴とかいうことをもっておく必要がある だろう。それ以前に、マスターに履歴が持てる情報システムを、ベンダーはちゃんと作 っていただかないと、こういうことに対応できないということがあります。ですから、 実はこの部分の話は、ユーザーのアウェアネスを上げる点も大事ですが、そのために は、やはりベンダーの方々に、やはりユーザーの先のことを考えた提案をしていただき たい。ユーザーの方々には、ここの部分で、いまケチッて独自のものを使うことが、結 局費用の先送りになるということを理解していただく必要があるのではないかと思いま す。 　ですから、例えば病名の例でいえば、あの病名マスターは、標準語としてのリードタ ームと、院内としての細かい記述というのを構造的にもっている。それに対して、シス テムが病名を１つだけしか持てないというのであれば、良さが生きないし、移行のとき にスムーズにいかない。あの心というか、良さを発揮した製品を、やはりベンダーの方 々に作っていただきたいと私は思います。それをすることによって、移行がスムーズに なり、少し先行的な費用になる部分に対するユーザーの理解ということになろうかと思 います。 　しかし、いままではマスターもそんなに整備されていなかったので、それはもう無理 もない話だと思います。いままでのことは、私は問う気はありません。これからはそう いうふうにしましょうということです。ですから、この、新旧システムのデータ移行の 話も、いま動いているシステムを、来年買うシステムにどう移行するかというのは、さ すがにまだ無理で、いま買うものは、先のことを考えて入れておこうというようなくら いに、先見性をもって、システムの導入を検討される必要があるということです。 　よく言うのですが、結婚のときに、離婚のことを考えて契約書を書かざるを得ない。 つまり、ベンダーには必ず、「このシステムを６年間使った後、あなたは我々が一生懸 命入れたデータを、どういう形で、いくらで置いていってくれるの。それにはお金を取 るの」という話ですね。 　共著者に篠田さんと書いてあるところで、こういう話をするのは申し訳ない気もする のですが、やはり旧システムの移行に対して、前のベンダーが上代何千万円というのを 平気で請求するという、そういう市場の状況を考えると、それは商売になっている。だ から、そういう目にあわないようにというのを、こういう場で強調していくということ が私の責務だろうと思っています。 　ベンダーのきつい話、最後に逆に、ベンダーの立場で申し上げますが、やはり６カ月 でいきなりシステムが決まって移行とか、２週間でルールを変えようとか、そういう無 理なことを発注するので、やはりベンダーのＳＥも疲れてしまいますし、ドキュメント も十分でなく、とにかく動けばいいという作業が多い。特に、新旧システム間の移行の ときに、そういうことが多いので、やはりそれは無理が起こって、結局はコストがかか る可能性があるということを、やはり知っていただきたいということは、ベンダーの立 場で申し上げるということでございます。 ○大江座長 　ありがとうございました。ただいまのご報告について、何かご意見、ご質問ございま すでしょうか。データ移行の話ですので、ユーザー、ベンダー双方一緒に考えるべき非 常に大きなテーマの１つですが、何か補足すべきことがありましたら、委員の方々でお 願いします。よろしいですか。 ○木村委員 　よく質問されるんですよね、中間的な移行のときの形式としてどうですかと。いつも 私が申し上げるのは、ＸＭＬ、Ｊ−ＭＩＸの箱、そこまではいけると言い続けてきたの ですが、やはりここはＲＩＭ準拠にしないと、ちょっと世界ではぐれ者になるのもいや なので、急ぐなというふうに思っています。 ○大江座長 　いかがでしょうか。特にございませんか。 　今日予定している３つの報告を終わりましたが、全体を通して、何かお気づきの点な どありましたらお願いいたしますが、よろしいでしょうか。 　それでは、参考資料４を委員会としてもう一度、全体を思い起こしながら今後のこと を考えたいと思います。今日報告がありましたのは、まず参考資料４の１番と４番、こ れは項目が別になっていますが、これは中間論点整理メモの章立ての関係で別になって いるわけで、基本的には電子カルテの機能に関することです。私の研究班で検討してお りますが、これについては、この委員会としての報告書にまとめていくことについて、 どの程度まで細かくするかで非常に難しいのですが、何か、これくらいのことは最低限 書いたほうがいいとか、ここまでは細かくしなくてもいいだろうというようなご意見ご ざいますでしょうか。 ○木村委員 　やはりこれは、ＩＯＭのガイドラインですよね。 ○大江座長 　はい。 ○木村委員 　これも是非。 ○大江座長 　そうすると、大きなガイドラインが示される程度のことは、この委員会の報告に取り 込んでいくとよいのではないかということですね。阿曽沼委員、この機能のことに関し て、報告書としてまとめるとするといかがですか。 ○阿曽沼委員 　さっきもちょっと申しましたが、自分たちの病院にとって、投影しやすいといいます か、活用しやすいように、適用するときのガイドラインみたいな、注意事項みたいなも のが具体的に細かく出てくると。 ○大江座長 　医療機関とユーザーの立場から見て、使いやすい形にまとめるのがよいだろうという ことですね。 ○阿曽沼委員 　そうです。 ○大江座長 　逆に、システムの提供側からすると、こういうような形のまとめ方があると、役に立 つのではないかというような、何かご意見ございますか。 ○御船委員 　我々、ソフトベンダーの立場で申し上げますと、今回の機能要件とは別に、我々はい ろんな病院とご契約して、いろいろそのシステムの構築、それからカスタマイズをさせ ていただいております。いろいろなご要望があるのですが、その場合に、私どもでいち ばん気をつけているのは、やはりレスポンスの劣化をできるだけしないようにというこ とを、結構実は考えております。いろいろご要望があるのですが、やはりそれを百パー セントにすることによって、どうしてもこの劣化を起こしますと結局、納期も品質も要 望も満たしたとしても、ユーザー満足度は全く得られない。要するに使ってもらえない ような破目に陥りますので、実際のご要望をどのように吸収するかということで、そう いうことをいちばん考えます。 　今回の機能要件に関しても、まだ実際には、12月の後半にある程度の案が出るという ことですが、それを見させていただいて、これはシステム的に対応するのは結構大変だ なと。それをすることによって、先ほど言いましたように、レスポンスの劣化を起こす ようであれば、代替案ができるような、そういうふうな受け口もちょっと考えていただ ければありがたいと思います。 ○大江座長 　非常に重要なご指摘だと思います。いろいろな機能があっても、ユーザーから見て使 いやすいというのは、レスポンスがよく、気持よくサクサクと動くというのが、非常に 重要なことだと思います。それなくして、使いやすいシステム、あるいは、その機能が 使えるということはないと思います。これは機能を、どういうふうに報告書を細かいレ ベルまで取り込むのかにもよりますが、レスポンスへの影響度との関係というものを考 慮した形で、まとめていくということですね。 　そういう意味で、最も書きにくい、評価しにくい、予測しにくいレスポンスについ て、今回の委員会では、あまり正面きって検討事項に入れていないというところがあり ますので、それをどう扱うか、ちょっとまた次回以降で時間のあるとき、少しご意見を いただきたいと思います。 ○阿曽沼委員 　重要な指摘だと思うのですが、いわゆる技術、システムの構造とか構成とか、コスト とか、環境といいますか、それ以外のところに影響されることがあまりにも多すぎるの で、それを書き続けていくと、基本的には報告書としての意味が薄れたりというような ことがある。そういうことは注意をするというコメントは必要だと思いますが、そこの 部分はやはり相当細かく書き上げていくということに、報告書として意義があるのかと いうことについては、ちょっと検討する必要があると思います。 　ただ、１回公表された後に、それに対してやはり、パブリックコメントではないので すが、そういったものがもし代案として出れば、それを併記して、補足資料として付け ていくということのほうが、むしろ現実的かなという気がしないでもないですが。 ○大江座長 　その辺は、報告書をまとめる段階で、またいろいろまとめ方の問題ですので、ご議論 をいただいてからと思います。 　それでは続いて、２つ目のことで、何か戻って補足すべきことはございますか。ある いは、報告書をまとめていくに当たって、考慮すべき事項など、お気づきの点がありま したらお願いします。よろしいでしょうか。 　３つ目の「相互運用性の確保」については、いちばん最後にご報告いただきました が、13番に当たりますね。これは、ほかの、例えば11番、12番などとも密接に関連しま すので、今後またこの領域の検討を報告書の中でどう取り込むか、検討するときにもも う一度戻って議論できると思いますが、何かいまの時点でお気づきのことがあります か。よろしいでしょうか。 　それでは、今日ご報告いただいたことについては、出された議論を踏まえて、ご意見 をどのように取りまとめるか、それからどういうふうに報告書に取り込んでいくか、ま た事務局とも論点整理をした上で、次回以降にお示ししたいと思います。そういう形で よろしいでしょうか。それでは、進め方についてはそのようにさせていただきます。 　それから、今後、残ったいくつかのテーマについて今日のような形で、次回以降、報 告をいただいて議論するという形にしていきたいと思います。それでは今後の進め方、 連絡などについて、事務局のほうからお願いします。 ○高本補佐 　参考資料４をいまご覧いただきましたので、事務局から、それに対して補足させてい ただきます。実はただいま、平成17年度、現在取り組んでいただいている標準的電子カ ルテに関する研究がございますが、その同じ医療技術評価総合研究事業のほうについて は、「医療安全の確保に資する電子カルテシステム等の開発と評価に関する研究」とい うことで、公募を行っているところでございます。明日が締切りということになってお ります。 　この検討体制の表でいきますと、新研究、次年度以降を視野に入れたという、「その 他」のところにありますように、３番及び、本日少しご検討いただいた10番について は、基本的にいまご紹介した研究テーマに合致するもので、いまいくつかの手挙がなさ れているところです。引き続いて、そういう点では、報告書を受けた形で、新たな研究 に取り組まれることを、事務局としても期待しているところでございます。 　今後の日程については、参考資料の５をご覧ください。本日は第５回で、主要な検討 事項についてご報告をいただき、討議していただきました。今後、すでに委員の皆様に はご案内のとおり、来年ですが、１月27日及び３月３日については、すでに日程を確定 させていただきました。できれば先ほどの参考資料４の表で今回検討できなかったとこ ろ、例えば６番、14番などについては、次回１月27日に、第７回、３月３日には、２ 番、３番、５番、８番、９番に該当するような項目について、関係する委員または研究 班などから、ご報告を頂戴しつつ、本日のようにご討議いただきたいというふうに、事 務局としては考えているところでございます。 　また、できれば３月末に、その報告書案を検討していただく委員会の開催を、いま考 えているところでございますが、これについても、近日中に、日程調整の上、ご報告さ せていただきたいと考えております。場所等の詳細については、また追ってご連絡させ ていただきます。 ○大江座長 　今後の進め方について、ただいまの事務局のご説明に、何かご質問、確認すべき事項 等ありますでしょうか。よろしいでしょうか。 　それでは、予定よりも少し早目に進んで、今日の予定は大体終わりましたので、特に 何かご発言がないようでしたら、次回、１月27日のスケジュールをご確認いただいて、 今日の委員会は終了したいと思います。 　それでは本日は熱心にご議論いただきまして、ありがとうございました。これで終了 いたします。 （了） 照会先 医政局 研究開発振興課 医療技術情報推進室 企画開発係　中内 TEL　03-5253-1111（内 2588） FAX　03-3503-0595