電子カルテにおける患者情報の共有と連携～歯科カルテにおける問題～

At Hokkaido University Hospital Center of Dental Clinics, we started to operate the E.M.R. for dental medicine since July 1, 2010. This system was developed under the concept, which is operating only one medical record by one patient in Hokkaido Univ. Hospital. But on the medical records for the social insurance, it was operated under the strict rule of the insurance at dental clinics in Japan. So there was severe balance to satisfy such two demands. Then it was necessary that new and other function is developed at the systems of dental medicine. One is the intensive view; we called it dental portal view. And at the timing of input the information of personal disease history on initial visit, we make the record under with the reference to other existing data of the patients on the E.M.R. On the other hand, we developed other contents for input the clinical comment for only dental clinic. It was independent function from the records in medicine for reason of the insurance.

1. はじめに

　2003年、北海道大学歯学部附属病院は、同医学部附属病院と統合し、北海道大学病院歯科診療センタとなった。事務、中央診療部門等の統合が行われる一方、病院情報システムの統合は、次の更新のタイミングに持ち越された。この旧システムは、同じNEC社製のシステムをベースにしていたが、患者ID、マスタ、DB等別々であった。このため、患者IDの名寄せやマスタの統合等の準備を介し、2008年新システムへの移行をもって、病院情報システム上での統合が達成された。
　新システムは、NEC社製MegaOak HRをベースとし、仕様策定より病院全体の情報の共有・連携を意識し、「北大病院としての1患者1カルテ」を達成すべく開発してきたもので、全ての患者基本情報、オーダ履歴、医療画像等は、医科歯科問わず一元的に扱うことを基本としている。稼働当初から、段階的に院内手紙の電子化・共通化や説明・承諾書の電子化・統一化等を行った上で、最終的に2010年6月より医科外来及び病棟、7月より歯科外来において電子カルテシステムの運用を開始することとなった。本カルテシステムにおいても、当然ながら、前述の患者情報の共有と連携の原則をもって開発に望んだものであるが、そこには、これまでの機能にない問題が存在していた。
　今回、患者情報の共有と院内連携の観点から、歯科向けカルテシステムの開発を通して浮かび上がった問題点とその対応について、報告を行う。

2. 診療録の電子化により浮き上がる問題

　電子カルテシステムの機能として、患者をキーとして、診療行為及び診査・検査等の記録を一元的に集約管理する事は重要である。この際、その情報の性質を軸として管理する事が重要で、医科歯科、診療科、部署等の違い等は、付加的なものとすべきである。その一方で、保険診療録となると、その重心は保険における療養給付の基となる記録ということになり、当然医科歯科の保険請求毎に分けて管理することが必要となる。これらは、明らかに矛盾していることから、双方の機能を100％満たす事は、非常に困難であるといえる。また、病棟と外来においても、同じ診療録とはいえ、診療形態の違いからその記載内容はかなり相違しており、無理な統一は業務の非効率化を招きかねない。

3. 歯科診療録における問題

　歯科用の保険診療録は、療養担当規則等によりその記載内容について厳しく規定づけされている。特に行った処置行為毎の点数や日〆の総点数、一部負担金額、月〆の診療日数、総点数、一部負担金の合計額の記載など医事的な情報の記載も義務づけられている。また、当該日の主訴や所見、記事だけでなく多くの処置項目について記事記載が必要となっている。画像オーダについても、診断料算定の根拠としての記事記載が義務づけられている。これを、実現するにあたっては、単なるオーダ履歴を集約しただけでなく、各々に対してカルテ上でコメントを入力する機能が必要になってくる。　さらに、日常的な自費診療についても、診療の継続性を保ちつつ、きちんと分けて管理することを考えねばならない。
　

4. 情報の共有・連携と個別化

　これらの問題を解決するにあたり、全てを同時に満たす事は難しいことより、本院においては画面構成毎に共有・連携と独自性のバランス配分を変えることとした。すなわち、1号紙の既往歴等の登録画面やそれとリンクする新規開発の歯科ポータル画面等において、極力医科を含めた情報の共有・連携に努める一方で、2号紙や診査票の管理等では、システム本体に追加して別機能を用意することとした。これにより、かなりの部分で先の問題の解消をはかることができたが、その一方で多くが新規機能となり、実装にあたっては基本パッケージ延長上の医科システムに比べ大幅なカスタマイズを要することとなった。

4.1 1号紙における連携

　1号紙情報のアレルギー、感染情報、障害情報、禁忌情報等については、既存患者基本オーダと連携することとした。すなわち、歯科1号紙上独自の情報として入力するのではなく、登録画面上から自動的に患者基本オーダを呼び出した上で入力を行い、その情報をリンクさせて表示することとした。また、本情報は、1号紙だけでなく別途新規開発した歯科ポータル画面上にも連携させることで、より有効的な活用を目指している。

図1　歯科ポータル画面:

図2　連携説明:

4.2 歯科2号紙の独立と関連オーダとの連携

　所謂歯科2号紙においては、保険診療録としての側面及び従来の紙カルテのイメージを踏襲して欲しいという現場からの要望もあり、カルテ本体とは別画面構成をとることとした。これにより、多くの歯科外来保険診療上の問題は解決できたが、入外連携および医科連携においては、一部不十分な部分が残っている状態である。
　　その一方で、オーダとの連携機能については、カルテ入力操作の軽減からも重要であることから、重視し開発を行った。基本的にオーダ項目については、自動的に記事入力編集画面（通称：カルテエディタ)上に自動的に流用することで、重複入力を抑止することとした。また、画像オーダや検査オーダの結果については、記事入力画面並びに2号紙参照画面上で項目を指定することでダイレクトに参照を可能とした。また、別画面で入力する歯周検査結果等も同様な動きとし、また同一画面上で、検査結果を参照しながら記事・コメントを入力できるようにした。

図3　歯科2号紙イメージ:

4.3 スキャン結果の連携と独立

　紙文書のスキャン結果については、カルテ本体側で医科歯科含めて病院として一元管理した上で、歯科カルテ側にも歯科分の情報を抽出して表示する機能を用意することとした。

図4　診査・スキャン管理画面イメージ:

4.4 医科歯科連携のさらなる強化

　医科側からの骨髄や臓器移植等を前提とした口腔内感染源除去等の依頼は、増加しつづけている。現在、医科担当医からの依頼が口腔外科の振り分け医宛に届く。これを元に歯科受診日を調整し、当日の歯科予診にて診査を行った上で、治療計画の立案と各担当科への振り分けを行っている。治療が必要となった場合、移植等を前提としていることより、限られた治療期間で圧縮した治療が必要になる事が多く、複数の医師のチームアプローチが必須であり、治療計画、治療の進捗及び経過等の情報共有がかかせない。また、治療終了後、依頼元の医科担当医への経緯の報告も必要となる。従来は紙で行ってきた医科側とのやりとりについては、現在システム上の院内お手紙機能を利用し、また歯科医師相互の情報共有については、電子化した専用のプロトコールを用いる事で対応している。今後は、依頼から報告までの一連の流れを一括して管理できるシステムを導入し、さらなる連携の強化を目指す予定である。

5. おわりに

　医科歯科統合した本院のような拠点医療施設に於ける病院情報システム及びその上で動く電子カルテにおいては、情報の連携・共有を進める一方で、保険請求や診療形態の違いによる様々な問題に対処して行くことが必要になる。現時点で、全てを同時に満たす事は難しいことから、本院においては、各画面毎に機能的なバランス配分を変える事で対処することとした。しかし、一部入外2号紙間の連携等に関しては、レスポンスや基盤システム上の制約もあり、言うなれば不完全な状態で運用を行っている。この解決にあたっては、障害時や参照レスポンスの向上も鑑み、現状のシステムとは別に、ヘルスレコードとして参照できる専用ビュワーの構築を考えている。