診療の詳細記録を永久保存・再利用するデータベース機能と、
レセコンの機能を融合させたマルチメディア電子カルテシステム

2011秋の新製品-3  グループ化した病院や診療所で、他の病院に来院した患者のカルテを参照できる

＜背景＞

＜集合データベースの問題＞

この方式（集合データベース、集合ＤＢと呼びます）は、本質的に難しい問題があります。いくつもの病院で時々刻々入力、変更される情報を集合ＤＢに反映させなければなりません。数多くの病院の情報を正しく集合ＤＢに反映させること自体、技術的に煩雑である上に高価なシステムが必要となります。また、集合ＤＢ中には膨大な量の患者個人情報が収納されるので、厳重な機密管理が必要となり、これも大きな追加費用がかかる原因になります。また、病院は院長がすべての責任を持っていますが、集合ＤＢは各院長の管理下には無いので、組織的な責任の持ち方も難しくなります。

＜ＤＲＳＣＯＳＭＯＳメッシュ上のリクエスター、患者クエリー、リスポンダー、モデル＞

ＤＲＳでは、「ＤＲＳＣＯＳＭＯＳ」により、グループに所属するすべての病院のすべてのＰＣがメッシュ状に通信経路を確立します。あるドクターがある患者をＤＲＳカルテ上に呼び出すと、ＤＲＳカルテプログラムはその患者のＩＤや氏名や生年月日などを含んだ存在問い合わせ（患者クエリー）をメッシュ経由ですべての病院に送ります（問い合わせするＰＣをリクエスターと呼びます）。各病院には、患者クエリーに答えるＰＣ（リスポンダー）が何台か用意されており、リスポンダーが自分の病院のＤＢを検索してこの患者の情報が自分の病院に存在するかどうか調べます。存在している場合、リスポンダーは、リクエスターに対し、患者のＩＤとＤＢのアドレス（ＵＲＬ）をＩＰＶ６で返し、リクエスターは他病院のＤＢをＩＰＶ６で直接読んでカルテ情報を得ます。

＜シンプルで安価なフェイルオーバーによる可用性確保＞

リスポンダーは一病院内に複数稼働させても良く、また、すべてのＤＲＳＰＣがリスポンダーの機能を持っており、故障の時に自動的に他の適したＰＣがリスポンダーに昇格できる（フェイルオーバー）ので、常時稼働させることが容易で費用もかかりません。

＜患者一元管理の方法＞

グループ内で一人の患者に対して一つのＩＤを付与することが保障されている場合は、他病院へのクエリーは患者ＩＤで行うことができます。ＤＲＳを全病院で利用した場合は、ＤＲＳの分散型ＩＤ発番機能を利用できます。これは、互に通信することなく、また、一元的な発番サーバーを利用することなく、各病院が自分で他と衝突しないＩＤを発行するアルゴリズムです。

しかし、現実には、過去にすでに付与されたＩＤや複数のメーカーの体系の異なる患者ＩＤがグループ内に混在しています。

＜病診連携での認証方法＞

グループ外の病院や診療所とカルテ共有する場合は、参照者が正当な医師であることを確認しなければなりません。ＤＲＳでは、Ａ病院で患者Ｍを診療中のドクターＤが、ＤＲＳＣＯＳＭＯＳ機能で連携している病院、診療所に患者存在クエリを送ります。Ｘ病院にＭのカルテが存在することを知った場合、ＡがＸ病院に対して認証の要求を送ります。Ｘ病院ではＤが正当な参照者であるかどうかを認証します。判定は、ＰＫＩのような社会的インフラを利用しても良いし、通信や電話を使って人が判断することもできます。

ＤＲＳにおいては、このように、情報を開示する側の責任で相手の認証を行います。この方法は、情報管理の責任の所在を明確にすることができ、認証の社会的インフラが整っていない環境においても、現実的で実用的な認証を行うことができます。両方の病院の同一患者の主治医どうしが、その患者に関して話せば、情報請求者の正当性を容易に判断できるはずです。