私大協2K20703メモ

私大協2K20703メモ（文責　橋本）
参加者　
_ 私大協有志；
北里　田中、帝京　冨澤、埼玉　小高、慈恵　能勢、近畿　喜多、日大　海野
_ 研究班；堀口、橋本
2002年７月3日午後1-3時半、於　帝京大学板橋病院医療システム部会議室。

内容
１．7月開始様式１提出作業の各校進捗状況、問題点について。

帝京を除きすべて紙ベース。

入力支援システムを用いた各科入力ないし医事課または病歴室入力。

問題点として

入力支援システムの辞書機能

ICD5桁や.9コードへの対応問題。

２．4月以降の取り扱いについて、ならびに来年度からの標本病院についての質疑応答。

E/Fファイルの取り扱い。
標本病院の業務。
レセプト様式とレセ電算対応。

３．原価計算プロジェクトの説明と質疑応答。

文科省のプロジェクトとの位置関係。
今後の問題、EFファイルとの関連など。

４．その他要望について

病名入力システムや病名検索システムの評価、グルーパーソフトへの教訓を。
各施設担当者との連絡体制について。

まとめ

ICD5桁や.9コードの取り扱いについて統一見解を厚労省名で各施設に再度流し直してほしい（7月は対応しきれなくても8月以降建て直しを図るには今から見解を）
レセプトについて。統一フォーマットよりは分けて欲しい。またシステムとしても現行レセ電を維持したまま、DPC/包括部分だけをサポートするAdd onシステムで対応するのが望ましい。
最新情報の通達ルートがまだ不確実。各校代表アドレスを実務者のものにするよう再確認を。

質疑応答から

冨沢（帝京）	帝京病院のイントラ様式1入力システムの供覧・説明。ついで各施設での7月調査開始前後の状況について報告。
小高（埼玉）	各科にPC1台ずつ配布し、各科での入力とした。様式2はDL方式。各科むけマニュアルの作成。各科担当（レセプトチェック医師）を責任者とする。退院後2日以内に医事課がレセプトを打ち出し、それを担当医に届けて内容をチェックしてもらう。窓口は医事課に一元化。問題は入力支援システムの辞書機能が弱いため苦情がきている。市販辞書など購入しパッチする予定。
喜多（近畿）	マニュアルを作成し、電子サマリーシステムと合体したもの（NEC）など考えていたが、早くても完成は7月中以降になるとのことで、挫折し、紙ベースの人海戦術に切り替えた。様式２はDL方式。まずは対応マスター作りに時間がかかっている。様式1は退院時にサマリーと一緒に様式1もくっつけて医事課におろすように指示、医事課でコード化・内容チェックを行い、各担当医に問い合わせを行い、その後一括入力としている。問題は、提出が遅れ気味になっていること、それと病名の.9コードが気になっている。入力支援システムと病名君ではヒット数も違うし、どれをスタンダードとしたらよいのか。
田中（北里）	.9コード問題はうちでも発生し、病歴室のほうから入力が4桁になっているが、ICDは5桁なんだとクレームがきた。矢島企画官に先日説明会にきてもらった際に5桁でやることで決着した。
海野（日大）	日大は医事課でなく病歴室ですべて対応することにしているため、問題を当方では把握していない。病歴管理士がすべてコーディングをやってくれているので、いままでのサマリー病名の取り扱いと変わらない。
橋本（研究班）	5桁問題も.9問題もDPC開発チームとレセ電算傷病名マスター開発チームとの連絡が取れていなかったために発生したシステムバグである。外保連からの当初圧力があったことなどあり、α版でレセ電算コードとの対応を公式に取れなかったこともある。β版では両者の間での整合性を図る必要が双方から認識されていて、すでに開原・阿南会談なども予定されている。またα版の臨床病名を傷病名マスターのリードタームに切り替える作業もMEDISに発注されたと聞いている。ただ完全にバグを取るにはまだ数ヶ月はかかるだろう。
田中（北里）	6月28日の段階で当院に矢島企画官を招き、200人（うちドクターが60人くらい）を対象に院内説明会を行った。其の前に各科にパイロットとして50枚くらい任意に様式1を埋めてもらった。各科から1名咳に者を選出してもらい、この事前パイロット結果をもとに議論してもらった。問題点としては１）記入漏れ、特に入院経路など、２）各種病名定義の解釈の問題（どれが資源を最も投入したというのかとか）、３）その他臨床的問題点などが挙げられた。様式1用紙は退院会計と一緒に医事課に降り、医事課で内容を点検し担当医に照会した上で、医事課的にOKが出るとそれを病歴にまわしてコードを振ってもらうようにしている。4月以降については医師による直接オンライン入力システムも検討中。なお様式２はレセプトファイルから独自にエクセルに落とす。Kコードもstringで抜いて落とし込むようにしている。それよりも気になるのは、このDPCのグルーパーソフトがいつ配布されるかだ。4月以降に間に合うのか？システムを組めるかどうかだけの問題ではなく、北里では戦略的にコードによってどう売上が変わるかシュミレーションするシステムを作りたいと考えている。おそらく配布ソフトではそうした戦略的分析には使えないと思うので、独自に作らなくてはならない。その都合上公表タイミングが知りたい。
橋本（研究班）	現在学会には8月一杯をめどにβ版の検討承認を求める方向で動いている。その後グルーパーソフトを作るのに1ヶ月、それを使って実際特定機能病院から上がってきたデータを分析し、最終的に中医協が分類に正式承諾を下すのは来年1月になるだろう。それからソフトがばら撒かれても確かに遅い。
堀口（研究班）	分類の数なども特定機能病院からのデータを分析してみた結果変わる可能性がある。分析は早めても12月にはかかる。しかし大きな改訂はおそらくないと思う。公表上β版ではるが、ほぼcandidate版と思ってもらってそれをもとに動いてもらうしかないだろう。
橋本（研究班）	確かに残された時間から見て、分析結果を以って分類を大きく変えることはおそらくできないだろう。今回手術外だしについて健保連の内々の了解が得られていることから、β版はそれほど大改訂を必要とするほどにはならないと思う。またもしそうなっても、開発などに残された時間との都合上、分類枠そのものはそのままにしておいて、重み付け係数だけは違うとか、同じという感じで対応するしかないだろう。
海野（日大）	日大は完全紙ベースで、中央でPC２台を新たに用意したのみで入力している。いままで入院病歴を退院時にくっつけてあげていたので回収が悪かったが、今回は入院時の段階でカルテに様式用紙をくっつけて病棟にあげて退院時におろしてもらうようにしている。回収票は病歴室でチェック・コード化・入力としていて医事課はタッチしていない。問題は病歴室まで票が戻ってくるのが依然遅いこと。4月以降については様子見。システムについてはすべて富士通に丸投げしているので、むこうがなんといってくるかで決まる状態。入院時の病名オーダーは富士通のシステムに入っているのでやっているが、この情報は医事課に流れていない。退院病名も改めて退院時に書いてもらうようにしなおした。
橋本（研究班）	帝京の経験からも富士通のパッケージに含まれている病名オーダーシステムは他のサブシステムとの連携が悪く、しかも今回のような複数種類の病名を整理するのには全く無力であり、使い勝手はないと思う（埼玉も同意見）。
能勢（慈恵）	慈恵は医事は日立のシステムだが、様式１はminor vendorを選び、帝京と同じくイントラを利用としていたが、まだ動いていない。Vendorが医療システムの仕事になれていないため、マスター部分などへの対応ができていない。止む無く紙ベースで運用中。システムダウン対策用の対応として用意していたものを使っている。慈恵は科別サマリーシステムであったので、これを機会に病院全体のサマリーシステムに切り替えようとしている。各病棟で医師・看護婦・事務がそれぞれ入力すべきところをon site 入力してまとめるようなシステムをイメージしている。それをプリントアウトして最終的に病歴でチェックするというのが試案である。なお様式２は、DL方式で今月半ばには対応取れるともう。来年以降についてEFは継続になるのか、それとも標本病院だけの話なのかわからないので、対応が取れない。様式1自体は上記の新しいサマリーシステムに発展解消させるつもりだ。
橋本（研究班）	昨日会議では、１）標本病院はEFファイル対応病院ということでお願いする。２）その中から原価計算調査協力病院を国立・私立・公立など層化抽出して小数お願いする。ということになった。なおEFファイルと包括むけ新レセプトとの関係だが、これまでの続紙としてEFファイル出力をくっつけて出してもらうという意見もあるが、果たして支払い基金がそれを要求できるロジックを用意できたのかどうかは、まだ聞いていない。
堀口（研究班）	おそらくそういう形での続紙としての提出は義務付けできないだろう。EFファイルはあくまで標本病院で、ということになると思う。
田中（北里）	問題を整理したい。１）Fはなんのために使うのか？そもそも紙で出しても使いものにならないはずだ。また支払い基金がもらってもこれは使いようがないだろう。それに包括になれば査定はないはずだというのがこちらの認識だ。Fはなぜいるのか？費用や原価計算そのものには役立たないではないか。北里固有の問題としてFは4月には間に合わない。手挙げで標本病院からFの提出を求めるというのならわかるが。しかしどれくらいの病院でFを出せるのか？標本病院からEFを出させてそれを厚労省が使うのはOKだし、いずれはEFとなるというのもOKだが、4月から全参加病院義務化にされるのは反対だ。２）それからレセプト様式の問題。HIV・移植など出来高支払いが残るのであれば、これまでの出来高レセはそのままの出力形式として残して欲しい。一方で包括用レセプトは一部外だしの部分はあるにしても、基本的には「明細書なしの請求書」になるわけだから、外だし部分だけ（現在の検査・入院管理などの一覧のあたりに）書き出して、あとは分類コードと該当点数、調整係数だけ別に「請求書」を作らせて欲しい。その部分をレセコンの外に造るだけならPCベースで十分だし、わざわざレセコン内部のアルゴリズムを動かすために外注など出さなくて済む。先に紹介された帝京のイントラシステムのように、診断群分類に必要な情報は医事電算システムの外で発生するようにできるのだから、わざわざそれをレセプトに取り込むよりも、必要情報をレセ電から出してきて、レセ電の外で様式１情報とくっつける「請求書発行専用PC」を構築すれば済むことだ。３）あと問題となるのがここのレセプトではなくて、総括票である。これを作成するのに今でも手間が掛かっている。そこで出来高と包括とが混ざってくると話がややこしいので、出来高総括票と包括総括票に分けてもらうほうがいい。
堀口（研究班）	3番目の総括票の話は厚労省対支払い基金の問題なので、ここではコメントできない。一方Fファイルの使用法だが、DPCの分類の精緻化を図るためのデータとして用いることが主になる。
橋本（研究班）	Fの使い勝手としては今堀口氏がいったような１）DPC精緻化のための資料、に加えて２）包括後の診療内容・質の担保情報、３）原価ベースの重み付け係数の計算は当分先になるだろうから、その間のチャージベースウエイトを精緻化するための情報、４）最後に原価計算時の按分比率のためのデータとして用いることなどが挙げられる。
能勢（慈恵）	総括票はどっちにしても作らなくてはならないだろうし、わけてもしょうがないのではないだろうか。分けたシステムでやるとなると、例えば自費で最初やっていたのが途中から保険対応に変わったときとか、対応できない。ひとつのコンピューターシステムで処理できないと。プリントアウトの段階で分けて出力すればいいだけでぇないか。そうしないと原価計算うんぬんのときも困る。
橋本（研究班）	出来高・包括のシステム対応として、ひとつのシステムでやるというのと、出来高システムの上に包括処理用システムをadd onするというのと2つ意見が出ている。一方、包括と出来高のレセプト形態そのものは分けたほうがいいのか、それともひとつのフォーマットでできるようにしたほうがいいのか。昨日の議論でも、出来高情報はそのままいじくらないで出力させて、包括情報だけを追加出力印刷するという意見もあったが、公的文書に2種類の異なる情報を載せるのは混乱のもとだという意見もあった。矢島企画官としてはひとつのフォーマットを考えている様子だ。
田中（北里）	ひとつの書類の上に2種類の情報が載っているのは患者様への説明をするためにも、病院側としても困る。やはり出来高と包括の出力形態そのものは分けるべきだ。新しい制度になるわけだし、見た目にも分けてもらったほうが現場の混乱も少ない。
橋本（研究班）	システムを分けたほうがいいのかどうか、またレセプトの様式を分けたほうがいいのか1つにしたほうがいいのか。議論が収束しにくいが、その理由を明確にできれば判断の基準が得られるかもしれない。まず阻害要因としては、移植やHIVなどそもそも包括対象から外れるものがあることに加えて、包括対象でもはずれ値についてどのようにそれを定義し、支払い扱いにするのかがまだ固まっていないことがあげられそう。
堀口（研究班）	はずれ値については、一定度の限度の在院日数を越えた場合、そこからの1日定額を割引額とするという案が、企画官から出ていたが。
橋本（研究班）	まだ確定的な話にはなっていないし、中医協待ちのところがある。
喜多（近畿）	それからうちのように分院を抱えているところは、同じメインフレームで情報システムが動いているのに、かたや出来高、かたや包括への対応を要求されている。この点も問題だ。
田中（北里）	そのような場合のことを考えても、出来高レセ電システムは残しておいて、包括対応の外付けシステムをくっつけるほうがのぞましい。帝京の病名入力システムだってメインのレセ電算とは独立しているし、それで包括診療に必要な情報は取れてしまうのだから。
冨沢（帝京）	しかし独立に動いているだけではまずい。我々のシステムでも病名入力システムから得た情報をメインフレームのほうに流し直して経営統計などが取れるようにしておかなくてはならない。其の点でいずれはメインに取り込むことを考えたほうがよくはないか。
小高（埼玉）	確かに経営統計を意識したレセプト様式を考慮して欲しい。オーダーシステム側から得られる情報を用いる部分と外付け病名入力システムから得た情報を用いる部分を分けて。その点では、オーダー側から取る数値情報はメインフレーム上で処理して、そこで外付けシステムから得た病名情報だけあとから取り込むというほうがやりやすいだろう。
田中（北里）	経営情報といえば、これからは包括による計算だけでなく、これまでの出来高による仮想収入情報も算出して、包括後いくら減増収だったのかを分析しなくてはならない。其の上でも出来高情報処理を消すわけにはいかない。今までどおりの数字を院内ではもっていなくてはならない。よって出来高ベースのレセ電算はそのままにしておいて、そこに包括処理用のシステムをadd onするのがよいと思う。
田中（北里）	それにしてもF対応が取れる病院はどれくらいあるのだろうか。
橋本（研究班）	6月20日までの各病院回答ではほとんどがEFのDL方式を取るといってきている。
田中（北里）	マスター開発など間に合うのか？
堀口（研究班）	薬剤なども含む全マスターの対応は間に合わないので、手術処置だけは、という形でブロック説明会資料から要件を緩和している。
能勢（慈恵）	それは知らなかった。全国説明会にはでていたが、ブロックは出ていなかったので。
橋本（研究班）	では最後に原価計算のほうの話。資料供覧。
堀口（研究班）	文科省系、全国医学部長病院長会議のワーキンググループの構成と現状についての説明。当初医療情報部系教官が作ったものは緻密だが肝腎のデータが取れないため事務方から抵抗を示され、事務方研究グループが立ち上がったが、こちらも動きがにぶい。
橋本（研究班）	文科省の手前つぶすわけにも行かなかったところ、DPC側からの申し出で、これを錦の御旗に活動を再開することで大枠合意し、来週話し合いがもたれる。しかし問題は、向こうは当初から文科省の考えとして大学・医学部の経営情報分析システムの開発を念頭においてきている。一方こちら側としては病院と医学部・大学を分けて考えてもらえるよう要請する。これが第一の試金石となる。第2にEFが使えるところをサンプルとして集めて実施するということ。これについても、向こうとしては全国国立医学部での導入を考えてはいるだろうが。あと今回の申し出では出さないが、DPC側の最終到達目標としては病院会計準則に則った会計処理ができること。当面の狙いとして、原価ベースによるDPC重み付け計算はまだまだ先になりそうであり、むしろ今机上での議論で空回りしている問題、たとえばアセットや研究教育費などどこまでを評価対象として保険でカバーするのかといった問題について、まず実証データを取ってから議論しましょう、ということであくまでパイロット的調査を実施することになるだろう。では最後その他の要望について。
冨沢（帝京）	病名入力支援システムや病名君などの使い勝手をヒアリングして評価しまとめて欲しい。Stand aloneシステムであったり、コード内容の整合性の問題があったりなど今回の調査開始にあたっては準備段階で現場にかなり混乱があった。次回グルーパーソフトを全国配布する際にはこうした問題が起こらないようにする上でも、是非今回の教訓から学んで対応を考え頂きたい。むしろ固まったシステムを配布するよりはマスターとかDATファイルとかのソースだけ公開してもらって、あとは各自作りこみなさいといってもらったほうがいいのかもしれない。
田中（北里）	あと、情報が五月雨式に渡されるので、どれが最新なのかわかりにくい。ベータ版のことについても病名君とかマスターとかについても、どれがいつ一番新しいのか、アナウンスして欲しい。どこを見ればよいのか。
能勢（慈恵）	先ほどのEFファイルのマスター作成の話なども知らなかった。どうも厚労省からの回答メールも届いていないのがあるようだ。
堀口（研究班）	研究班のホームページのほうに疑義解釈集は載せてあるが今のところ使い勝手が悪いので改良中。またこれまで高城氏のところにきていたメールについてもそれを一括処理して回答をホームページ上にQ&Aとして掲載するための準備をすすめている。なお各校の代表のメールアドレスを確認して発送しているはずだが、それが院長とか責任者だからというだけで送信先アドレスになっていて施設内で連絡が回っていない可能性があるので、各自確認して欲しい。
田中（北里）	3人ぐらい登録したはずだが、リストの一番上だけに回っているらしい。もう一度各校の代表者アドレスがだれになっているか確認のお知らせを出してもらえないだろうか。

次回会合にむけて
７月２3日に私大協情報処理研
次回予定
7月3１日　1－3時、帝京にて。
題目は「調査データ収集、運用開始後の問題点について」