＜レセプトのOCR領域が正常に印刷できない場合は以下のような手順で原因を確定してください。＞

�@コントロールパネル→フォントでプロフェッショナルドクター用のOCR Bフォントがインストールされているかどうかを確認する。 フォントの日付は平成10年2月25日で、サイズは１４０Ｋｂです。日付が異なる（古いフォント）フォントでは正常に印刷されません。 また、プロフェッショナルドクター用ではない別のＯＣＲフォントがインストールされていることがありますが、それでは正常に印刷できません。

まずパソコンにインストールされているフォントの確認が重要です。

＊インストールされてる場合→�Aへ＊インストールされていない場合  →インストールする　→正常に印刷可能　→解決                              →インストールする  →やはり印刷異常→�Aへ

�Aレセプトをプレビューでみて4の字にOCR Bフォントの特徴がない、もしくはOCR最下段の桁数が67桁ではない。

→プリンタの設定でOCR Bフォントの置換設定になっていないかを確認

＊プリンタの設定でOCR Bフォントの置換設定が”する”になっていない場合→�Bへ＊プリンタの設定でOCR Bフォントの置換設定が”する”になっている場合                              →フォントの置換をしない設定に変更する　→正常に印刷可能　→解決　　　　　　　　　　　　　                                           →やはり印刷異常→�Bへ

�Bレセプトをプレビューでみて4の字がOCR Bフォントの特徴を持ち、OCR最下段の桁数が67桁あるにもかかわらず、実際の印刷はプレビューと異なる場合

☆パソコンのOSに適合した最新のドライバを手に入れてインストールし直してください。

（６）
症状：
　マスターの食事の標準負担額を０にして、マスターの自動編集をしたら、入院レセプトで標準負担額が出ない。

原因と対策：
　カルテ用マスターおよびレセプト集計用マスターでは食事の標準負担額の点数は０にしておく必要があります。但し、レセプトの標準負担額の欄ではレセプト集計用マスターを用いて点数の表示をしていますので、レセプト集計用マスターの標準負担額の点数は０でなく、実際の点数を入力しておいてください。
（戻る）

＜Professional Doctor32のフォルダーがいつのまにかいっぱいになるのはなぜ？＞

（戻る）

＜ユーテイリテイー＞
（１）＜院外処方箋＞
院外処方箋で薬剤自己負担の免除者に対する場合に”(免）”と印刷したり、末尾に＜以下余白＞と印刷したいがどうしたらいいだろうか。

対応したレポートを使用したファイルを作成しています。

（２）＜自費診療＞
産婦人科で自費診療が多い。自費分を処理できますか？

従来、病院用あるいは多科用システムでは自費分の入力と会計計算が可能でしたが、一般の単科クリニック用の自費分処理可能なシステムもあります。

(3)＜検査データ自動取り込み機能＞
　98年10月1日出荷分からのプロフェッショナルドクターではデフォルトでテキストファイル化した検査データの自動取り込機能がついています。検査センターから検査データファイルをテキストファイルで電子メールなどで送信してもらえばプロフェッショナルドクター内で自動的に検査データの入力ができます。

（４）＜会計画面からの約束入力＞９８年１１月から
　会計画面から約束入力が可能になりました。酸素入力も簡単になりました。

（５）＜院外処方箋に薬局入力事項欄の新設＞９８年１１月から
　院外処方箋に薬局入力事項欄を新設しました。薬局入力事項欄は表示することも表示しないことも設定可能です。

（６）＜眼科用眼鏡処方箋入力フォームなどの改定＞９８年１１月から
　眼科用の眼鏡処方箋入力フォームや眼鏡処方箋・コンタクトレンズ処方箋などが新しくなりました。

（７）＜ノートタブ付画面＞99年1月から
患者登録名簿・会計画面・カルテ・患者医学情報画面がタブ付のフォームになりました。スクロール不要でタブによって画面を切りかえることができます。従来のスクロール画面で使用することも可能です。

（８）＜保険証確認日付の自動入力＞99年1月から
ボタンをクリックするだけで患者登録名簿に保険証確認日付を自動入力します。この情報は印刷するカルテ頭書きに表示されます。

（９）＜患者名簿から頭書きの印刷＞
患者登録名簿から頭書き（病名は現在のアクテイブ病名のみを表示）を印刷する機能が加わりました。これによりカルテ頭書きは、受付画面からの印刷・印刷パネルからの印刷に加えて患者登録名簿からも印刷できるようになりました。

（10）＜多数の薬剤を表示する処方箋＞
　18個以上の処方薬を表示する処方箋（B5)を印刷することが可能です。

上記のファイル（すべてワンパックです）をご希望のユーザーの方は送料・手数料として5000円を添えてノーバメデイコへお申し込みください。

オプション類：
　オプションとして以下のフォーム・レポートがあります。
（１）ＣＴ照射録
（２）Ｘ線照射録
（３）食事箋
（４）麻薬処方箋(入院・外来・院内）
（５）理学療法処方箋
（６）注射の判断料の回数表示を除外したレセプトシステム

（戻る）

＜お知らせ＞
　レセプトシステムで精神療法・理学療法などのレセプト分類番号８０の項目が（レセプトそのものには表示されるにかかわらず）「レセプト点検画面」に表示されないことがあります。その原因はレセプト適用区分フォーム に一部必要な項目が登録されていないためです。
これを回避するには以下のように処理してください。

�@カルテシステムのメインパネルの下部のマスター保守の部分の「薬剤投与法フォーム」を開きます。
�A上部の適用区分ボタンをクリックして、「レセプト適用区分フォーム」を開きます。
�Bレセプト適用区分フォームに新規レコードとして以下の4個のレコードを入力してください。
適用・適用コードの部分のみの入力で結構です。レセプト区分は空欄です。

適用              適用コードレセプト            区分その他          802H           
その他（公１２） 802W          
その他（公２）   802X          
その他（公１）   802Y  

以上でレセプト点検画面に精神療法・理学療法などの項目が表示されるようになります。

＜情報＞
−レセプトOCR領域の印字について−
　レセプトOCR領域の印字は通常2行、時に3行になります。レセプト用紙の一番下部の行を1行目、下から2番目が2行目、最上部が3行目とします。印字される数字の位置とその意味は次のようになります。

　カッコ内の数字は桁数です。CDは検証番号で1桁の数字です。
＜1行目(左から）＞1行目は全部で67桁になります。
保険者番号(8)・医療機関コード(7)・請求点数(7)・CD(1)・薬剤一部負担金(5)・CD(1)・一部負担金(5)・CD(1)・CD(1)・診療実日数(2)・診療年月(4)・CD(1)・市町村番号(8)・受給者番号(7)・CD(1)・都道府県番号(2)・点数表(1)・保険種別1(1)・保険種別２(1)・本人家族入外(1)・整理番号(1)・CD(1)

＜2行目(左から）＞2行目は医療保険単独分・老人保険分の場合は26桁、公費単独分・2者併用分の場合は65桁になります。
性別(1)・元号(1)・生年(2)・CD(1)・記号(10)・番号(10)・CD(１)・公費�@負担者番号(8)・公費�@受給者番号(7)・CD(1)・公費�@診療実日数(2)・公費�@請求点数(7)・公費�@薬剤一部負担金(5)・CD(1)・公費�@患者負担額(5)・CD(1)・CD(1)

＜3行目(左から）＞3行目は3者併用分の場合で39桁になります。
公費�A負担者番号(8)・公費�A受給者番号(7)・CD(1)・公費�A診療実日数(2)・公費�A請求点数(7)・CD(1)・公費�A薬剤一部負担金(5)・CD(1)・公費�A患者負担額(5)・CD(1)・CD(1)


（戻る）

＜平成11年4月1日からの制度改定について＞

（戻る）

＜Delphi版Professional Doctor体験後感想座談会報告＞
（これは1998年12月に行われたものです）
Ｎ（ノーバメデイコ）：日頃プロドクをご利用いただきありがとうございます。本日はプロドクユーザーの先生方にお集まりいただき、と申しましても札幌市在住の２名の先生方ですが、当社が大規模医療機関向けに開発しているDelphi版プロドクに触っていただいてそのご感想などを語り合っていただきたいと思います。その結果をもとに今後の開発の参考にさせていただきたいと考えております。また今後の当社の製品の開発などについても率直なご意見を賜りたいと存じます。
Ｎ：Delphi版プロドクを使用されてのご感想はどうでしょうか。

Ａ先生：慣れているせいか現行版のほうが使い勝手がいいような感じをうけました。入力がスムーズにいきませんね。

Ｂ先生：Delphi版はなんだか事務的で遊びがないような気がします。

Ｎ：まだ開発中で細部にわたっては手を入れていませんので、、、、、。デザイン的にどのフォームも同じように見えるということはあると思います。

Ｂ先生：さっき同じデータに接続していたわけでしょう？同じデータに接続して別のアプリケーションで入力できるというのは何か変な感じがしますね。ボタンの配置などは現在のシステムと同じなのでまごつきはしませんでしたが、開いたフォームが機能は同じでも現行版とは見た目はだいぶ違うなという印象を受けました。それと同じ機能のフォームでボタンの数が少ないのもありましたね。

Ａ先生：画面を開いているときにこれは何をする画面なのかなということがしばらく眺めていないとピンこないような感じがします。

Ｂ先生：僕もそれは感じましたね。それはどうしてなのかな。カラーが少ないせいですか。

Ａ先生：それからカルテの入力などで処方なんかを入力するときにタブキーでしか項目の移動ができないのは不便な感じがします。これは何とかしてほしいですね。

Ｎ：ユーザーインターフェースは開発ツールによって思想の違いがありますので、デフォルトの状態で使用しますとそれがモロに出てきます。それを何とか近づけて統一的にするようにとは努力しているんですが、、、、、、。ただおそらくお気づきの点はデータを表示するグリッドがみんな同じような外観をしているということが原因なのかなと思います。Delphiではデータを表示するグリッドの設計が簡単にできるものですから、それに甘えてどんなフォームでも同じグリッドを使って同じような外観にしてしまうということがあるかもしれません。ボタンの数が少ないフォームがあるというのは単純にまだ未完成だからです。それからフォームの数が少ないということはあります。というのは一つのフォームで多目的に使用するということがあります。たとえば、一つの画面で検査歴・処方歴などを切り替えて表示して、Ｄｏ処方・Ｄｏ検査・Ｄｏ注射も切り替えて入力するようにしています。

Ｂ先生：さっきDelphi版プロドクを触ったのはほんのちょっとだったんでわからないんですが、完成度はどのくらいですか？

Ｎ：完成度というのはオブジェクトの量的な完成度のこととしますと、７０％くらいでしょう。まだレポートができていません。

Ａ先生：レポートというのは？

Ｎ：印刷物です。カルテやカルテの頭書きのような印刷して保存するものですね。オブジェクトそのものがまだ全部完成していませんので質的な完成度についてはなんともいえませんが、少なくとも通常の処理に関しては作りながらテストを行ってきています。

Ｂ先生：受付画面は現行版とはだいぶ違いますね。

Ｎ：受付画面に表示する項目をふやしましたので、1行に収まりきれないのでスクロールしないでみるためには1行を2段にして表示するようにしました。全体をざっと見るためにカルテ番号と名前を表示する表も同時に表示して連動するようになっています。

Ｂ先生：カルテを開くとノートタブを使っているんですか、これは使いやすいと思いますが、今までのようにカルテの全貌が見えるほうが考えをまとめるのにいいんじゃないかと思いますがどうでしょうか。これですと、所見や薬剤を入力するたびにタブで切り替えなければいけないわけですよね。

Ｎ：これはいろいろ考え方の違いもあるかもしれませんが、従来処方などの入力欄が小さいという話がありまして、それを大きくしますとカルテ全体が非常に縦長になってしまうわけです。スクロールするにも限度がありますので今度はタブで切り替えることで全体的に一つ一つの入力欄を広く取れますのでのびのびした感じになったと思います。

Ｎ：カルテから指示歴ボタンをクリックすると、さっきいいました、処方歴・検査歴・注射歴などを一つの画面で切り替えて参照できるようになっています。Ｄｏ処理も同じく切り替えて行います。処方歴を表示していればＤｏ処方になりますし、検査歴を表示していればＤｏ検査になります。

Ａ先生：シンプルになりましたね。たださっき指示歴ボタンをクリックしたときには何も表示されていなくて一瞬ドキッとしました。

Ｎ：開いたときは何も表示されませんが、たとえばこの処方歴タブをクリックするとその都度問い合わせが実行されて表示されます。

Ｂ先生：ただこれは現行版で処方歴ボタンをクリックしたときのほうが速いような感じがしますが、正直なところどうですか？

Ｎ：確かに処方歴なんかをみるときは現行版のほうが速いと思います。原因はまだよく分かりませんが、LookUpはDelphi版のほうが速いので、おそらくデータベースエンジンにより得手不得手があるのでしょうね。そのため、Delphi版プロドクではテーブルを複数結合してクエリーを作るよりも、できるだけ単独のテーブルをもとにクエリーを作って、必要な項目はLookUp項目として追加するようにしています。

Ｂ先生：具体的にはどんなことですか？

Ｎ：たとえば処方歴ををみるときにデータは薬剤のテーブルに薬剤のコードが入力されているわけですが、実際はコードでなく薬剤名をみたいわけです。そのためコードをもとに薬剤マスターから薬剤名を表示するLookUp機能を使用しています。これが現行版では薬剤マスターテーブルを結合して薬剤名を表示していたということです。

Ａ先生：さっき気がついたんですが、カルテのSOAPはカルテに複数入力ができますね。これは新しい機能ですか。

Ｎ：SOAP欄が一つのカルテで複数の入力ができるのは入院外来版で最初からできるようになっています。Delphi版プロドクでは現在の入院外来版が移植のモデルになっています。

Ａ先生：私は外来版を使っていて入院外来版というのは知らないんですが、内容は相当違うんですか？

Ｎ：違うところもありますが、基本的には同じだと考えてください。

Ｂ先生：患者医学情報のことですけど、たくさんのタブがあって循環器系・呼吸器系などという見出しがついていますね。一つ一つの項目の入力欄が拡大しているのはいいと思いますけど、またまたさっきの話を蒸し返しですが、患者の医学情報は,、呼吸器系は入力してあるけど、神経系は空欄になっているというように入力済み欄と空欄が混在しているわけですよね。むしろ空欄のほうが多いはずです。入力されている事項を後で参照する場合にいちいちタブで探してみた挙げ句、全部空欄だったということになりませんか？これは参照しにくいと思いますよ。

Ｎ：一つ一つの入力欄を拡大するとタブを使用しないわけにはいかないと思います。今ご指摘の点は実は最初から考えていました。データのある項目とない項目をフォーム上で一目で区別して見れるようにできますので、いま言われたことはご心配要りません。

Ａ先生：むしろデータのある情報だけをまとめて表示するというのはどうですか。

Ｂ先生：データの入力を1ヶ所にするということですか？

Ａ先生：いやそうでなくてもいいんですけどね。

Ｎ：入力は各系の欄に入力して、表示用のデータは1ヶ所にまとめて表示するということですか。それはできますね。どちらがいいのか検討してみます。

Ｂ先生：患者登録名簿はすっきりしていますね。入力事項は今のものとかわらないですね。

Ｎ：基本的に現在のシステムと入力データは大きな違いはありません。患者名簿も５つのタブを使っていますが、ずいぶんすっきりしていると思います。

Ａ先生：カルテから患者名簿の参照も速いですね。

Ｂ先生：受診記録も速いですよ。ただスクロールが遅いような感じですね。照会画面とかも今のバージョンと同じ配置になっていますね。これはやはりそういう方針があってのことですか？

Ｎ：そうですね、やはり今までのシステムと統一的に扱わないと移植作業自体もうまくいかないということもあります。大規模にインターフェースを変更する必然性もないわけです。といいますのはプロフェッショナルドクターもリリースされて4年ですので、ある程度あちこち手を加えられています。そのため現段階で改めて大きく変更する必要もないと思っているわけです。

Ｂ先生：今見せてもらったソフトは大規模医療機関用とのことですが、われわれも使うことはできるんですか？使えなければこうやって見せてもらってもね、、、、、、という感じになるんですが。

Ｎ：ごもっともなご意見だと思います。
　そもそもこのシステムは社内で処理速度の比較用に作っていたものです。ここ数年の間にいろいろな開発ツールも出てきていますし、一つの製品がいろいろな用途に使えるわけではありませんのでいずれは大規模医療機関で百のオーダーの規模の端末を使用するシステムが必要になるはずですが、現在の状況ですと,まず各医療機関が独自に発注して自分の医療機関用にゼロから開発するというパターンしかありませんが、そのやり方では経費もかさんでとてもとても今の医療情勢では負担できないというのはハッキリしています。そこでパッケージとしてそんなシステムが構築できないかという話になってきたわけです。
　これはいつもいっていることですが、規模の大小に関係なく医療機関の業務内容は共通しているはずです。ですから最大公約数的な部分をしっかりしておけばどんな施設であっても使えるはずだということです。あるいは反対に最小公倍数を作っておくということで同じことが言えると思います。そこでこのシステムはそのための基本セットということです。ちなみにデータベースはOracleです。
　DelphiとOracleで神託コンビと呼んでいるんですが、ただ、問題はいろいろありまして、データベースが難しいと一般的なユーザーには到底使えないということがあります。電子カルテや医事システムの場合は制度の改定ということを常に視野に入れておく必要がありますが、Oracleのようなデータベースですとまず一般のユーザーは使えません。制度の改定のときにアプリケーションの修正だけですむようであれば問題はありませんが、どうしてもテーブルの拡張とか追加が必要になってきます。そういう場合はシステムエンジニアが常駐しているような施設でないと制度の改定のときに困るということがあります。
　そんなことで、クリニック規模の施設では今みていていただいたようなシステムはとても管理が難しいということで簡単に導入できますよとはいいにくい面があります。

Ａ先生：クリニックで実際に使っているところがありますか？

Ｎ：いえいえまだそんな段階ではないです。

Ｂ先生：今見せてもらったのは電子カルテの部分ですよね。レセプトシステムはどうなっていますか。

Ｎ：レセプトシステムは現行バージョンをそのまま使います。

Ｂ先生：そういうこともできるんですか。

Ｎ：できます。

Ｎ：といいますのは、今後の電子カルテの有るべき姿を考えると、やはり診療に関した機能を充実させるという新しい目標があると思います。

N：たとえば先生方のところにいつも厚生省から薬剤の副作用情報が送られてきますよね。厚生省とか製薬会社は副作用情報を送ったということで責任逃れができますけど、実際に薬を使うドクターであれば次から次と薬剤情報が送られてきても読まなかったでは済まされないことが起きてもおかしくありませんよね。だんだん時代が医師の責任をますます重くするような方向に進んでいますが、それに対抗する手段として電子カルテであれば処方した薬の相互作用なんかを即座に表示するような機能を持たせてきっちりと対応するということです。
　これは別に楽をしてずるをするという問題でなくて情報があふれている中でいかにそれを処理していって正しい道を進むことができるかという問題ですから、今後とても重要な問題だと思っています。ですから現行版のバージョンアップでも当然そのようなことを考えていますし、今までは医事システムの部分に重点を置きすぎていたきらいがあります。電子カルテでないとできないような機能で先生方のお役に立つようなものを増やしていきたいということです。

Ａ先生：ですけど、われわれ開業医としては医事システムとしてきちんとしてもらってこれからの制度の変化にも対応してもらわないと困りますよ。

Ｎ：もちろんそれは基本的な部分です。今後医事システムはレセプト電算化の方向に進んでいくと思いますが、そうなると、いまのようにレセプトの細かい部分でこの場合は表示する、あのような場合は表示しないというような一言で言えばどうでもいいことをひねくり回すような処理が減っていくと思うんですね。

Ｎ：コンピュータを使用して処理する場合はすべての情報を表示するということであればそっちのほうがよっぽど楽なんですが、紙のレセプトの場合はどうしても手書きの場合と同じような処理をする必要が出てきますから、あれこれいじくりまわす必要がありました。レセプト電算化になれば情報を吐き出してしまえばいいわけですから、一度作ってしまえばその辺の処理がずっと楽になると思います。

Ａ先生：さっきOracleは一般のユーザーには使えないという話がありましたが、それはどうしてですか？

Ｎ：とっつきにくいということと、まるで融通が利かないということですね。
Ｎ：つい最近までOracleの製品はパソコンソフト販売店では買えませんでした。本も今のように増えてきたのは最近のことではないでしょうか。いままでは一般のユーザーを対象に考えていなかったんでしょうね。私は個人的にはInterbaseがいいと思っているんです。行レベルのロックができますし、いち早くLinux版を出していますしね。使い方もシンプルですしね。SQLベースのデータベースで行レベルのロックができるのはInterbaseが初めてだったはずですよ。

Ｂ先生：これはDelphiでできているということでしたが、それも何か理由があるんですか。

Ｎ：Delphiは私が個人的に好きで色々作っています。会社で使うものは全部作っています。Ver．1の頃からの長い付き合いですからとっつきやすいですよ。ちょっとしたものはあっという間に作れます。

Ａ先生：さっき見せてもらったのもそうですか

Ｎ：Easy Writerはそうです。
（注：Easy Writerというのはカードに入力してテキストファイルを作るソフトです）
電子カルテのような大きなシステムは生産性が重要だと思っています。

Ｂ先生：今後のソフト開発はこのDelphiでやられるわけですか？

Ｎ：いいえそういうことではありません。その時々の最善のツールを選んでやります。
SQLベースのデータベースを使う電子カルテはJavaで作ろうということでやっていました。色々問題があって、休んでいたんですが、その間にDelphiでこつこつ作ってあったものを引っ張り出してきて手を入れました。

Ｂ先生：このシステムを私が使いたいというときにはどうすればいいですか。

Ｎ：Oracle＋Delphi版は規模の大きな病院用で導入する場合とか、先生のようにすでに現在のプロフェッショナルドクターをご利用中の場合にアップサイズしたいという場合に使っていただくということを考えています。
　病院の場合はシステム管理者が必要ですし、クリニックレベルでは先ほどもいいましたように最初からOracle+Delphi版を導入して使うということはどう考えても現実的ではないと思いますから、ある程度すでにプロフェッショナルドクターという電子カルテを使いこなしておられる場合にということになります。それからそういう場合は御自分でアップサイズから管理ができるというまでに勉強する必要もあります。

Ｎ：実際には開業のドクターが本来の医療をやりながら管理もするというのはたいへんなことで相当な無理があると思います。アップサイズ自体も1日で手際よく完了する必要がありますね。将来的には会社から全国へ出向いてアップサイズのお手伝いをすることも考える余地がありますね。

Ａ先生：今後はこのシステムがプロフェッショナルドクターの主流になるわけですか。

Ｎ：いえ、当分ここ４，５年は主流にはならないと思います。現在のプロフェッショナルドクターがとっつきやすさ、レポートの作りやすさなんかですばらしいものがありますので、制度の改定に迅速に対応できるという大事なメリットがあります。大事に大事にしていきます。99年のバージョンアップで性能も上がりますし。 ノーバメデイコ付属クリニックでもずっと使いつづけられます。
　Oracle+Delphiは将来のパソコン環境の変化に向けた準備のそのまた準備です。さっき開業のドクターがこういうシステムを管理するのはたいへんではないかとという話がありましたが、私はそうでもないと思っています。というのはつい最近まで個人でLANを構築するのはたいへんなことでしたが、今はまったくそんなことはありません。それと同じでSQLベースのデータベースが今よりずっと使いやすくなるでしょうし、ユーザーもデータベースになじんでいくと思います。ただそれには相当時間がかかります。４、5年かかるでしょう。その頃にはOSの世界も相当な変化が出ていると思います。将来のパソコン環境の変化は本屋さんでならべられる本を見ると大体分かりますよね。

Ｂ先生：ノーバメデイコでは今後のパソコン環境の変化をどういう風に予測していますか？

（注：この部分掲載を省略します。今後のパソコン環境予測については後日機会を改めて論議することができると思います）

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
Ｎ：病院では大学病院とか一部の病院を除いて電子カルテは普及していませんし、普及にはいろいろ問題があります。院内のコンセンサスの問題が一番大きいですね。コンピュータを使うとなると必ず反対する人が出てくるわけです。

Ａ先生：使う前からアレルギーを起こす人が必ずいますね。

Ｂ先生：そういう意味では個人の開業医が進んでいるとも言えますね。自分の判断だけで導入できますから。

Ｎ：大規模な病院で電子カルテが普及するのはまだまだ先のことだと思います。開業医でごく普通になった頃にやっと大病院でぽつぽつと出てくるという感じじゃないでしょうか。ノーバメデイコは管理が簡単な現行プロフェッショナルドクターを普及させていって、ユーザーの要望に応じてＳＱＬベースのデータベースにもアップサイズしたい場合はちゃんと対応したいですね。
ユーザーとともに成長したいということですね。

Ａ先生：プロドクがバージョンアップするときにはこのシステムもバージョンアップするんですか？

Ｎ：今度のバージョンアップのことでしたら、このシステムはすでに次期プロドクのバージョンアップ後の構造に対応しています。データ構造は同じでないといけませんので将来の構造をいち早く先取りしています。

Ｂ先生：次期バージョンアップで何か新機能の追加はありますか。

Ｎ：特別ないです。ただ処理を早くするため構造を変えるということと、マスターの変更があります。

Ｎ：いま予定している新機能は息の長い計画の中で実現する予定のものですね。電子カルテの長所を生かした機能ということで診療中にこういう機能があったらいいなというものを取り入れる計画です。

Ｂ先生：今のうちにいっておきたいんですが、さっき新しいシステムでどのフォームも同じように見えるということをいわれましたが、もう一つ、フォームが全体的に小さいんじゃないでしょうかね。なんとなく窮屈な感じがするのはそのせいだと思いました。今のプロドクのように大きすぎるくらいにしないと使いにくいですね。この部分も改善が必要と思いますよ。

Ｎ：参考にさせていただきます。本日は貴重なご意見をありがとうございました。

Ｂ先生：最終的な姿ができたらまた見せてください。注目しています。

（戻る）

＜紙カルテを印刷しないデータ保存法＞
厚生省が電子カルテも従来の画像情報と同様にデータの保存上一定の条件を満たせば紙のカルテとして保存しなくとも電子カルテとしてみとめるという通達を出しました。
条件は
�@真正性
�A見読性
�B保存性
ということですが、プロフェッショナルドクターのユーザーも今までのカルテ保存について毎日のカルテ印刷からようやく開放されるということでほっとされた方も多いと思われます。ホームページの”電子カルテが認知”欄でデータの保存方法について記載がありますが、現在のところCD-Rに書き込んでいくという方法が唯一可能な方法のようです。CD-Rでデータの保存を開始されたとして、紙のカルテの印刷はなくなるわけですから、今まで以上にデータの保存については神経を使う必要が出てくると考えられます。

★紙のカルテが消滅したクリニックでの問題点

�@＜CD-Rで毎日書き込みを行う場合に、すべてのデータを書き込みしていくのは無駄が多い＞
　確かに毎日データ．MDBをCD-Rに書き込んでいくとしますと、データサイズが100MBとしますと、同じCD-Rに書き込むとしても1週間で1枚以上消費することになります。それと毎日すべてのデータを保存していくことはなんとなく無駄が多いという感じもします。
　そこでまとまった＜データ．MDB＞を保存するのは1週間なり1ヶ月毎にして、毎日行う保存はその日に増加した分だけにするという考え方もあります。ただし、現在のプロフェッショナルドクターではその日増えたデータだけを出力しませんのでご自分でそのように改造する必要があります。この点は現在進行中のバージョンアップ版で、当日分のデータと過去のデータがテーブル上で分離されますので、今日のデータだけをテキストファイルとして出力して保存する機能を付け加える予定です。

�A＜カルテのデータを保存するとそれ以降はカルテの内容の変更はできない＝改ざんということになる？＞
　実際上、レセプト請求時にカルテ内容を見直して過去のデータを追加したり削除したりすることはありえますし必要です。このような変更はカルテを真正の内容に訂正するということですからいわゆる”改ざん”には該当しないと思われます。
　ただし、診療内容に関して訂正があった場合は、その変化がわかるということが重要です。そのために保存を頻繁に行うということが必要になります。
　たとえば、97年1月30日の診療内容について問題が発生したときに、97年1月30日の診療内容の保存データと半年後の保存データに食い違いがあれば、97年1月30日の診療内容が重要視されることになります。また、もし97年1月30日に近い日付のデータの保存がなく、その半年後の保存データしかないとしたら、半年後の保存データは証拠能力が弱いということになります。
そのために保存を頻繁に行うということが必要になります。

�B＜カルテの印刷は不必要になったが、その他の書類はどうする？＞
　他院からもらった紹介状・検査センターからの検査結果の紙・患者が持参した自宅での血圧経過を記載した紙など、診療に付随した紙はなくなりそうにありません。またこれらを無理になくしてしまう必要はないと思います。SONYのデータ−イータのような機器を使うと、紙を読み込んで置けばあとで呼び出して表示することができますので紙をなくすのにはよいかもしれません。またスキャナーで読み込んで保存するというのも同様の方法ですが、検索に時間がかかるかも知れません。またもしこのようなファイルをデジタル化して保存して紙を無くすというのであれば、これらのデータもきちんとバックアップしておく必要はあるでしょう。
　検査センターの結果報告書・紹介状など種類に応じて（患者毎でなく）まとめてファイルしておくのも実際的な方法だと思われます。

�C＜CD-Rにデータを書き込んでいけば改ざんができないものとして保証されますか？＞
　もちろんそんなことはありません。デジタルデータが絶対的に改ざん不能な態様で保存されることはありません。一度記録されたCD-Rそのものの内容は変更できませんが、アクテイブなデータを持ってきて新たなCD-Rを作成できるからです。
　一度入力した事項を変更することができない、あるいは変更のログがすべて記載され、人為的にアクセスできないというようなテーブルをカプセル化したような電子カルテのシステムが作れるかどうか考えてみますと、できないことはないと思いますが、制度の変化に追随できないなど致命的な欠陥が付随することが避けられませんので、実用的ではありません。したがってどうしてもテーブルにアクセスできるシステムを使用することになるわけですから、過去のデータを変更することは可能です。
　過去のデータを変更することができない様にすることよりも、本物があるので変更が意味を持たないというような制度を作ることがいずれ必要と思います。たとえば、医療機関が定期的にデジタルデータを預託できる公的な施設を設置するなどということです。


�C＜ＣＤ−Ｒへの保存の実際＞

　ＣＤ-Ｒに書き込む前に＜データ．MDB＞及び、＜サポート．MDB＞を同じコンピュータの同じドライブ内の一つのフォルダーに移しておきます。 フォルダーの名前をその日の日付に関係づけます。たとえば99年7月1日に保存するのであれば
￥990701\データ．MDB
というようにします。ついでフォルダーごとCD-Rに書き込みます。こうしておけば、フォルダ名からいつの書き込みかがわかりますし、同じファイルを一つのCD-Rメデイアに何度も書き込むことができて経済的です。
なお、書き込みが終了した後はファイルを本来のフォルダーに戻しておきます。
　実際にCD-R上で保存されている先生の経験では、データ．MDBのファイルサイズが５０Mb程度の場合、1週に1度保存して、1枚のCD-Rに７〜８回以上の書き込みが可能で、新しいCD-Rを2ヶ月に1枚位の割合で消費するということですので、１年間では５〜６枚程度ですんでしまうようです。
　CD-R内の保存された過去のデータを電子カルテから読み込むには、CD-R内の＜データ．MDB＞＜サポート．MDB＞をハードデイスク内に移動して、それに接続してカルテを立ち上げます。

（戻る）

＜電子カルテ認知の背景にプロドクの普及＞

　今年のはじめ、プロドクのユーザーの先生が、医師会の理事の先生にカルテを見せてくれと言われてみせたところ、印刷したプロドクのカルテをみた医師会理事の先生は県の技官に相談され、県の技官は厚生省までわざわざ出張して相談にいったということです。技官は厚生省に何を相談したかったのかはわかりません。おそらく紙に書かないコンピュータ処理でのカルテは許されないのではないかと考えていた可能性もあります。
技官はパソコンでカルテ！？電子カルテ！？＜＝＞パソコンカルテ？というようなごちゃごちゃした頭の中身だったのかもしれません。

その後、今年４月始めに医師会の理事の先生はユーザーの先生に”カルテの保存法に一部問題があるので後日県の技官が指導する”といわれたそうです。
プロフェッショナルドクターのユーザーの先生は当時、

�@データを１ヶ月に１回プリントアウトして保存している。
�A１週に１回、データ・サポート・マスターをＭＯにバックアップしている。

というようなデータの保存状況であったらしいので電子カルテのデータの保存法としては確かに不備はあったようです。
　ところが、プロフェッショナルドクターもユーザー数がうなぎ上りに増加しており、電子カルテに対する扱いをそろそろ緩和する必要性を感じていた厚生省では、今後も頭が固い医師会の先生や都道府県の無知な吏員から同じような電子カルテの取り扱いについての問い合わせが多くなると面倒だと感じたようで、電子カルテでのデータの保存に関してデータ保存の要件をはっきりきめて紙の印刷が不用になるように方針を固め、今回の指針を４月末に通達として出しました。
　通達を受け、今後はプロフェッショナルドクターも紙のカルテを印刷する必要はなく、さっそく５月からはカルテの印刷を止め、ＣＤ−Ｒに書き込んで保存している先生も増えています。
ちなみにユーザーの先生の連絡によると”その後医師会・県より何のアプローチもない”とのことです。
　以上のような顛末で、今回厚生省が電子カルテに関するデータ保存の指針を出して紙のカルテを不要とした背景の一部には、プロドクユーザーの先生に対する、医師会の理事の先生、県の吏員の活躍があったというのが事実のようです。
　なお、プロフェッショナルドクターは全国ほとんどすべての県で導入されていますが、厚生省の今回の通達以前にも同様の指導云々と言う話は聞いたことがありません。
（戻る）