JP2021012738A - 医療文書管理システム - Google Patents
医療文書管理システム Download PDFInfo
- Publication number
- JP2021012738A JP2021012738A JP2020177056A JP2020177056A JP2021012738A JP 2021012738 A JP2021012738 A JP 2021012738A JP 2020177056 A JP2020177056 A JP 2020177056A JP 2020177056 A JP2020177056 A JP 2020177056A JP 2021012738 A JP2021012738 A JP 2021012738A
- Authority
- JP
- Japan
- Prior art keywords
- knowledge
- entry
- medical document
- management system
- medical
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Landscapes
- Medical Treatment And Welfare Office Work (AREA)
Abstract
Description
初期には、「もしAならばBである」、「もしBならばCである」などの判断ルールを蓄積しておき、「DはAである」という命題が与えられたとき、事前に蓄積された判断ルールを順次適用し、「DはCである」と推論するエキスパートシステムが開発された。感染症に対する最適な抗生剤を推論する「MYCIN」が知られている。
ここで、「音楽家」という上位概念の下に、「バイオリン奏者」や「指揮者」、「作曲家」等などの下位概念が展開されている。このように、概念を構造的に記述すると(オントロジー:ontology)、ウェブ上に「Eは音楽家である」という直接的な記述がなくても、「Eはバイオリン奏者であるから、音楽家でもある」ことが推論され、前記の問いに正しく答えることができる。
ここで、多分野の概念を横断的に検索できるように、個々の概念や関係を、XMLなど書式を用いて、統一的な様式で記述しておく必要がある。この統一的な様式の一例として、RDF(Resource Description Framework)が提唱されている。概念や関係を個々の断片ごとに記述するやり方は、Prologなどのプログラム言語との相性が良く、リレーショナルデータベースとも馴染みやすい。
医療分野では医療記録を電子的に作成する、いわゆる電子カルテの導入が進んでいる。蓄積された電子文書を検索したり、複製したりすることで、簡便に医療文書が作成できるので普及が進んでいる。
セマンティック ウェブでは、オントロジーなどの構造的な記述により、「バイオリン奏者」や「指揮者」、「作曲家」等も「音楽家」の下部概念に含まれるという、いわば常識を活用して、ある程度あいまいな検索にも対応できるようになってきた。しかしながら、実際に具体的なオントロジーを構築してみると、記述形式の自由度が余りにも大きい故に、同一内容でも複数の記述様式が可能であり、構築者によって記述された構造がゆらいでしまう。このため、同じ内容であっても、異なる記述様式となる場合が多い。このため、複数のオントロジーを複数の人間が並行作業で構築した場合に、記述様式の不整合による混乱が生じてくる。また、様々な記述のやり方が混在するため、展開されたオントロジーを見ても容易に理解できないことが多く、可読性が悪いことが多い。
大量の知識を効率的に記述していくには、コンピュータが理解できる形式であることは言うまでもないが、人が見ても容易に理解できる可読性も必要である。特別な知識や技能が無くても容易に知識記述ができること、見て簡単に矛盾点などを指摘できることは、WEB2.0で推奨されているように、或る分野では知識を持っていてもコンピュータに関しては専門家でないたくさんの人たちが、ウェブを介して協力しながら、同時並行でオントロジーなどを構築してゆくのに不可欠な特性である。
また、同じ内容でも、語彙や表現に揺らぎが大きいため、一元的な処理が困難で、同一内容の判定には人手によらざるを得ない。
これらのこともあり、医療文書は、単なる状況の記載に留まっており、記載されている内容から、確率の高い疾患名リストを推定したり、疾患どおしを鑑別するのに有用な検査や所見を推薦したりするインテリジェント化には程遠い現状である。
さらに、親知識エントリーのエントリー属性記述を子知識エントリーが継承することで、属性記述を重複して記述する必要をなくすことである。別の領域に関しては、名前空間で分離された別の独立した知識ツリー群としての管理を可能とすることで、他領域での知識ツリーや知識エントリー名の重複を気にせずに興味ある領域の知識システムの構築に専念することが出来ることである。このような知識管理の枠組みを確立することで、機械処理が可能なのは勿論、人が見ても内容が一覧できる良好な可読性と、誰が作成しても記述の揺らぎがない知識管理システムを構築し、柔軟で高度な検索や推論を可能とする知識処理の基盤を提供することである。また、前記の知識管理システムの一部ないし全部を抽出して別の知識管理システムへ統合するといった知識管理システムの再構成を可能とすることで、知識管理システムの柔軟な運用を可能とすることである。
また、知識管理システムに対する問い合わせ、知識管理システムからの応答を可能として、現実社会での有効な活用を可能とすることである。さらにユーザーの実行権限を管理すること、検索のスコープを設定可能とすることで、破壊や混乱に対するセキュリティを確保することである。
また、参照リンクに判断論理を組み込むことにより、記載漏れやチェック漏れを無くし、完璧性の高い文書記載や、安全な医療指示文書の発行を可能にすることである。
さらに、知識管理手段内に効率的に蓄積された、疾患別の症状や所見の発現頻度を用いて、可能性のある疾患のリストを推定したり、疾患の鑑別を進めるために有用な検査や所見取得を推薦することで、正確で効率的な診療を可能にすることである。
知識エントリー属性記述管理手段を備えているので、各知識エントリーに属する情報が格納される。
参照リンクを含む知識管理手段を備えているので、参照リンクを介した広い情報収集システムが構築される。
知識管理参照リンク利用手段を備えているので、医療文書内容の記述語彙として、知識管理手段における参照リンクを利用可能である。
知識エントリー親子関係リンクを備えているので、知識エントリーに関する属性を記述する知識エントリー属性記述と、知識ツリーの他の知識エントリーとの親子関係が記述されて記録される。
知識エントリー属性記述は、異なる又は同一の知識ツリーに属する知識エントリー、または当該知識エントリーの知識エントリー属性カテゴリー、または当該知識エントリーの知識エントリー属性記述に対する参照リンクを含んでいるので、参照リンクを介した広い情報収集システムが構築される。
また、知識問い合わせ返答手段によって、問い合わせの内容に対して返答を行うことができる。
また、医療文書内容問い合わせ受付手段、医療文書内容問い合わせ返答手段を備えたので、記録、管理されている医療文書の内容についての問い合わせ、問い合わせの内容に対して返答を行うことができる。
各知識エントリーの属性記述は、テキスト、XML、JSON、あるいはオブジェクトとして、知識エントリーIDと紐づける形で、リレーショナルデータベースやmongodb等々、任意のデータベースに記録すればよい(知識エントリー属性記述管理手段)。
図4は、知識エントリー属性カテゴリーのIDを管理するマスターファイルを示す。
前記知識エントリーID、図4の知識エントリー属性カテゴリーIDに紐づける形で、知識エントリー属性記述を任意のデータベースで記録管理すればよい(知識エントリー属性カテゴリー管理手段)。
図5では、本発明の構造化された知識管理手段について、医療知識を例にとり概略を説明する。
知識ツリーとして、図5(a)「症状、検査所見」、図5(b)「疾患名」、を例示している。
他にも、「薬剤」、「処置」、「保険請求」等などの知識ツリーが考えられる。それぞれの知識ツリーは、親子関係で連結された知識エントリーの集合からなる。
図6は知識ツリー群管理手段の一例で、マスターテーブルの形式で、当該知識ツリー群内の知識ツリーIDと知識ツリー名を管理している。
「疾患名」の知識エントリー群は、まず「代謝系」、「消化器系」、「運動器系」、「循環器系」などの大分類に分かれる。それぞれの大分類は、「代謝系」では「糖代謝系」、「脂質代謝系」、「アミノ酸代謝系」など中分類に分かれる。
中分類の「糖代謝系」は、さらに「糖尿病」、「糖原病」などの小分類に分かれる。小分類の「糖尿病」は、「I型糖尿病」と「II型糖尿病」を含む。
ここで、知識ツリーの末端、葉に当たる「I型糖尿病」と「II型糖尿病」などが具体的な疾患名である。それらの共通属性を括りだして枝に当たる小分類、中分類、大分類などの知識エントリー群が構成され、これらは下部の分類、葉の疾患名を収容するコンテナ型知識エントリーとして機能する。
ここでは大、中、小の分類階層としたが、領域によってはさらに深い階層としても良いし、浅い階層で十分な場合もある。ここでは病態をもとにした分類基準を用いたが、他に、「項部」、「頸部」、「上肢」などの部位別の分類の規準、「炎症系」、「腫瘍系」、「感染系」、「遺伝系」などの病因別の分類の規準もある。知識管理システムの管理者が、目的に応じて分類基準を設定すれば良い。場合によっては、分類基準を異にした知識ツリーを複数併存しても良い。
マスターテーブルの形式で、当該知識ツリー群内において当該知識ツリー内(知識ツリーID=1 知識ツリー名「症状/所見」)の知識エントリーのIDを管理している。
本例では、知識エントリー名は、属する知識ツリー内ではユニークであるとしているが、場合によっては、「検査所見/理学所見/胸部/腫脹」と「検査所見/理学所見/腹部/腫脹」のように知識ツリー上の途中経路を併せて定義しても良い(経路依存知識ツリー名))。この場合は、途中経路で区別されるので、葉に当たる知識エントリー名自体は重複しても良い。また、属している知識ツリーが異なれば、図6のように定義されている知識ツリーIDで相互に区別されるため、同一の知識エントリー名も許される。
なお、本図では、知識ツリー群内の知識エントリーを、属している知識ツリーにかかわらず一元管理としているが、場合によっては、知識ツリーごとに別々にマスターテーブルを作り、知識エントリーを管理しても良い。
もし、属している知識ツリーによらず、知識ツリー群内を通してユニークな知識エントリー名とするならば、図7の第1列の知識ツリーIDは不要である。
なお、知識ツリーの親子関係の変更などの構造変化に際しては、知識エントリー名がユニークであれば変更作業は最小限で済むが、経路依存で知識エントリー名を定義している場合は経路を組み替えて知識エントリー名を再定義する必要があるので、対応が困難となる場合がある。
マスターテーブルの形式で、当該知識ツリー群内において当該知識ツリー内(知識ツリーID=2知識ツリー名「疾患名」)の知識エントリー属性カテゴリーIDを管理している。
知識エントリー属性カテゴリー名は、属する知識ツリー内ではユニークである必要があるが、属している知識ツリーが異なれば、図6のように定義されている知識ツリーIDで相互に区別されるため、同一の知識エントリー属性カテゴリー名も許される。
なお、本図では、知識ツリー群内の知識エントリー属性カテゴリーを、属している知識ツリーにかかわらず一元管理としているが、場合によっては、知識ツリーごとに別々にマスターテーブルを作り、知識エントリー属性カテゴリーを管理しても良い。
もし、属している知識ツリーによらず、知識ツリー群内を通してユニークな知識エントリー属性カテゴリー名とするならば、図8の第1列の知識ツリーIDは不要である。
知識エントリー属性記述の重複を避けるため、両者の上位知識エントリーである「糖尿病」を設定し、重複部分を括りだすと、知識エントリー属性記述の重複が無くなり、記憶容量の削減とともに、見通しの良さが得られる。
「糖尿病」は、親知識エントリーとして「代謝系」へのリンクを持ち、さらに子知識エントリーとして、「I型糖尿病」及び「II型糖尿病」へのリンクを持っている。
<病態>としては、インシュリン分泌低下、高血糖、尿中に糖***などがある。
それぞれの<病態>の項目は、別の知識ツリーである「症状/所見」知識ツリーの該当する知識エントリーへの参照リンクからなっている。
このようにすることで、シソーラスのように統制語彙を用いて属性記述を行うことになり、表現のゆらぎを抑制することが出来る。
勿論ここで、従来のように直接に文字列を用いて属性記述を行っても良いが、揺らぎの抑制、また後述の参照リンクの機能の活用ができないため、好ましいとは言えない。
<合併症>として「腎不全」、「閉塞性動脈硬化症」などがある。
これらの合併症への参照リンクは、同じ「疾患名」知識ツリー内の、当該知識エントリーへの参照リンクとなる。
これに対して「II型糖尿病」の病因は、肥満や糖過食などによるもので、治療は食事制限、血糖降下剤の内服、最終的には、インシュリンの注射となる。
このように、「I型糖尿病」及び「II型糖尿病」は<病因>、<治療>を異にするが、その他の<病態>や<合併症>などは、両者共通で、親知識エントリーである「糖尿病」に記述されている。
葉に当たる「I型糖尿病」及び「II型糖尿病」では、<病因>や<治療>しか記述されてなくても、親知識エントリーに当たる「糖尿病」の<病態>、<合併症>の属性記述、さらにはより上部の代謝性疾患などの属性記述が継承される。
このように、共通の属性記述を、親知識エントリーに括りだすことで、子の知識エントリーは、最小限の属性記述で済むことになる。
知識エントリーの属性記述を、親子関係をたどりながら個々に見ていって頭の中で構成しても良いが、知識エントリー属性記述継承手段によって、当該知識エントリーよりも親に当たる知識エントリーの属性記述をすべて継承して図9(a)、図9(b)のように一括表示すれば、属性記述の一覧が容易となる。
この上書きないし追記された知識エントリー属性記述が、孫以下の知識エントリーに対して、さらに継承されてゆくことになる。この上書きないし追記の使い分けは、適宜知識エントリー属性記述継承手段によって設定すればよい。
また、属性記述の上書き、追記が容易にできるので、より有用といえる。
なお、知識エントリー属性記述の親子継承は、親子の知識エントリー間に包含関係(この例では、「I型糖尿病」、「II型糖尿病」は、親知識エントリーである「糖尿病」に包含される)がある場合であり、書籍の目次と章立てのように単なる列挙であったり、自動車の構成部品として並列の関係にある車体と4つのタイヤなどのように、親子の知識エントリー間に内容の包含関係の無い場合は、知識エントリー属性記述の継承は行われない。
これにより、当該疾患の患者記録を直接参照することが出来る。
症例カルテへの症例リンクとしては、医療機関ID+患者ID、患者カルテのURL、患者カルテファイルの名など、症例情報へのアクセスを可能にするものであれば、任意の形式で良い。また、<文献>などの知識エントリー属性カテゴリーを設けて、関連する書籍やファイル、ウェブ上の文書へのリンクを記載しても良い(外部文書参照手段)。
図11(a)は、図10で「糖尿病」の<病態>のなかの参照リンクである{高血糖}の構造を図示した例である。
ラベルで表示などの際用いられるテキストある“高血糖”と、「症状/所見」知識ツリー内の知識エントリーである「高血糖」へのリンクから構成されている。
場合によっては、図11(b)のように「高血糖」内の知識エントリー属性カテゴリーである<定義>にリンクしても良い。
ここでのリンクは「知識ツリー名/知識エントリー/(知識エントリー属性カテゴリー)」としているが、直接にリンク先のURL形式で表現しても良い。
ラベルは閲覧などに際しての表示内容である。
本例のように、リンク先の知識エントリー名をそのまま用いても良いが、見易いように、図11(c)のように“高血糖 血糖値>140mg/dl”などとしても良い。
このようにすれば、リンク先を個別に参照する工程がなくても、容易に一覧して概要を把握することが出来る。
第1行では、“高カリウム血症”のラベル、“5%”という参照強度、および「症状/所見」知識ツリー内の「高カリウム血症」知識エントリーへの参照リンクからなっている。
第2行は、”脱水症”のラベル、“1%”の参照強度、「症状/所見」知識ツリー内の「脱水症」知識エントリーへの参照リンクからなっている。様々な副作用があっても発生率は一様でない。
参照強度として発生頻度の情報を持つことで、考慮すべき副作用の順番が明確となる。また、この発生頻度は、ベイズ確率でいう事前確率となり、複数の薬剤投与化で副作用が発生した際に、原因薬剤を推定するベイズ推定に有用である。
さらに、前記参照強度を症例での観測頻度に応じて可変とすることで、より状況に即したベイズ推定などを行うことが可能となる(参照強度管理手段)。
このように、参照強度を含んだり、参照に当たって実行するスクリプトを管理する参照特性管理手段を有することで、ベイズ推定を行って対応に役立てたり、チェックミスをなくすことで、医療の安全性が向上する。
この症例リンク作成手段で蓄積された、知識エントリーごとの症例リンク群により、「発熱」などの症状/所見が認められた医療文書ないし症例の一覧を容易に得ることが出来る。ここで、発熱が認められた陽性所見を有する症例だけでなく、発熱が認められなかった陰性所見の症例に対しても<陰性症例>などの知識エントリー属性カテゴリーを設けて管理しておくと、疾患名の診断を進める上で更に有用である。
先ず、「疾患名」知識ツリーの知識エントリー「胃潰瘍」の知識エントリー属性カテゴリーである<症例>に、当該患者への症例リンクを登録する。
ここでは、診断の根拠となる当該患者の個々の医療文書ではなく、患者IDを登録している。症状/所見は個々の医療文書で発生するが、疾患名は患者単位となるからである。
ここで、疾患名未定の段階での症状/所見の知識エントリー内<症例>への症例リンクの登録と、疾患名確定時点での症状/所見の知識エントリー内<症例>への症例リンクの登録とは、例えば<疾患名未確定症例>と<疾患名確定症例>などのように、区別して登録しておいた方が混乱が少ない。
これにより、それぞれの症状、所見ごとに、可能性のある診断名のリストを得ることが出来る。
また、当該患者で観察された症状/所見のリストの各々について、当該症状/所見の知識エントリーの<症例>知識エントリー属性カテゴリーに症例IDを登録する。
これにより、それぞれの症状や所見が認められた症例の一覧を容易に得ることが出来る(確定疾患症状/所見別症例リンク作成手段)。
ここで、陽性所見だけでなく、陰性所見に関しても診断名のリストを登録しておけば、さらに有用である。
同様に、知識エントリー「胃潰瘍」自体にも、知識エントリー属性カテゴリー<症状/所見>に当該症例で観察された症状/所見リストを登録している。
これにより、疾患ごとに、症状/所見のリストが得られる。ここで、陽性所見だけでなく、陰性所見に関しても症状/所見のリストを登録しておけば、さらに有用である。
また、症状/所見のリストの各行に対し、観察された症例のIDも付けておけば、当該症状/所見を有する症例を容易に検索できる。
症状/所見は、必ずしも独立しておらず、相互に相関している場合がある。この場合、ある症状/所見が観察されると、別のある症状/所見が同時に観察、或いは、観察されないことが多い。
この場合、相関関係にある症状/所見を重ねても、得られる新たな情報は少ない。従って、診断を進めてゆく際は、相関のある症状/所見は、優先度を低めて扱う必要がある。
このような場合、観測された症状/所見の単純なリストでは、前記の鑑別を進めることが困難であり、同時観察された症状や所見のペアの集計が不可欠である。
ここで、陽性所見だけでなく、陰性所見に関しても同時観測症状/所見のリストを登録しておけば、さらに有用である。
図示はしていないが、同時観測された症状/所見のリストから、同時観測された症状/所見の頻度も集計される。これらの頻度の集計を用いて、逆に、診断名未知の症例で、観察された症状や所見から疾患名を推定したり、診断を確定するために次に行うべき有用な検査の推薦が可能となる。
しかし個人の経験する範囲では症例数に限りがあり、また記憶もあいまいなので、精度にも限界がある。
観察された症状/所見の知識エントリーには、図15に示すように、知識エントリー属性カテゴリーの<症例>に、当該所見が観察された過去の症例の症例IDのリストが管理されている。
診察を進めていて順次観察される症状/所見から、当該症状/所見を有する症例IDのリストの積集合を求めれば、その時点での症状/所見をすべて満たす症例の集合が得られる(類似症例検索手段)。
各症例の確定疾患名を集計し頻度順に並べれば、当該症例の疾患名候補のリストが得られる(類似症例疾患名推定手段)。
症状/所見ごとの知識エントリー属性カテゴリーである<疾患名>に当該症状/所見が観測された疾患名のリストが管理されている。
集計して得られた疾患名の頻度分布が、ベイズ確率でいう疾患名の事前確率に相当する。
新しい症状/所見が観察されるごとに、事後確率を更新してゆけばよい(疾患名リスト推定手段)。
疾患名の複数の候補が得られたならば、確定診断を得るために、次に何の症状/所見を求めれば良いかが問題となる。
疾患名候補間を比較して、頻度差の大きい症状/所見が診断確定に有用である。
前述のように、同時観測されやすい症状/所見は優先度を低めるとよい。当該症状/所見を得るための診察や検査を進め、得られた観察結果で、前節の事後確率を更新してゆけばよい。観察結果が得られたならば変化するであろう事後確率の大きさが、その症状/所見の診断確定への貢献度となる(診察検査推薦手段)。
この際に、同等の貢献度ならば、手間や費用が少ない方が、より実務的である。手間や費用(コスト)を数値化しておき、コストあたり最も診断確定への貢献度が高い順に表示して、診察や検査を進めてゆけばよい(診察検査推薦表示手段)。事後確率が一定水準に達したら、目的を果たしたことになる。なお、ここで得られるのは確率的な推論で会って、医師などの診断の示唆ないし補助として供されるものであり、責任を伴う診断そのものでないであることは言うまでもない。
なお、本発明で提供されるのは、疾患名の候補や診察や検査の推薦であり、確率的なものである。つまり、判断の責任を有する医師などに判断材料を提供するものであり、判断自体ではない。
知識ツリー名は他の知識ツリー名と重複の無いユニークなものであることが必須であるが、関知しない他の領域で同一知識ツリー名が使われると、厄介な問題を引き起こす。
この問題を避けるため、図18のように、領域毎に名前空間を設定している。これにより、知識ツリー名は名前空間+知識ツリー名となるため、他の領域の知識ツリー名を完全に分離して考えることが出来る。
図19は、名前空間IDと名前空間名を、マスターテーブルの形式で管理している(名前空間管理手段)例である。必要に応じて、名前空間IDを、図2、図4、図6、図7、図8の1列目に付加することにより、大規模な知識の管理も混乱なく可能となる。
まず左から第1列の名前空間のリストから此処では「医療」を選択している。
この結果、第2列には「医療」名前空間に属する知識ツリー群の名前がリストアップされる。ここで「疾患名」知識ツリーを選択すると、先ず代謝系、循環器系などの大分類のリストが示される。
「代謝系」を選択すると、その下の中分類群である「糖代謝系」、「脂質代謝系」などのリストが示される。
「糖代謝系」を選択すると、その下の小分類である「糖尿病」、「糖原病」などがリストアップされる。
「糖尿病」を選択すると、知識エントリー属性カテゴリーである<病態>、<合併症>などが示される。
<病態>を選択すると、<病態>を構成する属性記述である“高血糖”や、“HbA1c高値”などの参照リンクが示される。
“高血糖”を選択すると、参照リンク先である「症状/所見」知識ツリー内の「高血糖」知識エントリーの属性カテゴリーである<定義>、<検査法>などが示される。
<定義>を選択すると、当該知識エントリー属性カテゴリーの内容が表示される。
一連の問い合わせ手続きをスクリプト等で表記し、順に自動処理することができれば効率が良い(知識問い合わせ受付手段及び知識問い合わせ返答手段)。
同様に、医療文書に対しても、検索などの問い合わせを行い、検索結果に対して集合演算や論理演算などの処理を行い、結果を表示したりファイルにダウンロードしたりすることも有用である(医療文書内容問い合わせ受付手段、問い合わせの内容に対して返答を行う医療文書内容問い合わせ返答手段)
このような場合、知識管理システムを構成する名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクの任意の部分を抽出して知識管理部分集合を作成し、別の知識管理システムにエクスポートする知識エクスポート手段、さらに、前記知識エクスポート手段で抽出された前記知識管理部分集合、或いは別個に構築された知識管理システムからの前記知識管理部分集合をインポートし、名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクを自知識管理システムに統合、再構成する知識インポート手段を備えることで、クラウド上で整備された知識管理システムの一部ないし全部を、自社内部の知識管理システムに取り込むことが出来る。
また、自社内で優秀な知識管理システムが構築出来て、他に購入希望者があった際は、同様の手順で、知識管理システムの一部ないし全部を、他に移植することが出来る。
関与する人間の権限やスキルに応じて、名前空間、知識ツリー、知識エントリー、知識エントリー属性カテゴリー、知識エントリー属性記述、親子関係リンクの各々の作成、編集、削除、参照の機能などについて権限の設定を行うことは不可欠である(ユーザー権限管理手段)。
これにより、理解の乏しいユーザーによる知識管理システムの破損を防止することが出来る。また、ユーザーによる参照範囲を限定することによる、秘密とすべき知識の保持が可能となる。
まずグラフデータベースは、ネットワーク状のグラフ関係を設定、表示することは得意だが、大規模処理では処理速度が速いとは言えず、大型の知識管理システムには不向きであろう。RDBでは、名前空間、知識ツリー、知識エントリー、知識エントリー属性カテゴリーなどのマスターテーブル管理下に、リレーションの各行ごとに、親子関係リンクや知識エントリー属性記述を行うことで本発明の知識管理システムを実装することが出来る。検索の自由度が高く、SQLなどの問い合わせ言語も完備されており、従前からのソフトウェア資産も多いため、RDBを用いた実装が現実的であろう。
多種多様で自由な検索はRDBに劣る。しかし大量のデータでもMap処理、Reduce処理などといった分散処理が可能である。
図5における<症例>内の症例リストや、「症状/所見」知識ツリー内の「高血糖」の<症例>などでは、実際に電子カルテなどを運用すれば直ぐに膨大な症例リストとなる。
一属性の頻度分布は、いずれの方法を用いても容易に求められるが、「糖尿病患者で、HbA1cが10を超えて、尿たんぱくが2+以上の症例の頻度はどれくらいか?」といった、複数の要因からなる頻度を大規模症例のデータから求める際は、時にRDBの処理能力を超えてしまう。このような場合は、糖尿病患者リスト、HbA1c>10の患者リスト、尿たんぱく>2+の患者リストの間で、集合演算を行う必要がある。このような場合、KVSのMap/Reduceによる分散処理が極めて有効である。
このように、本発明の知識管理システムは、データベースの実装方式を問わないが、基本部分をRDBで、症例リストなどの処理をKVSで行うなどの組み合わせが最も有効であろう。
対立する学説の信奉者同士が、互いの書き込みを否定する上書きを繰り返すといった例がみられる。
このような場合の解決策として、あるユーザーから見て、他の特定のユーザーの書き込みを検索対象から外す検索スコープ管理手段を用いれば、平和的な解決が可能である。
同じ「胸部痛」といっても、心臓疾患専門病院で発生すれば心筋梗塞の可能性が高いが、整形外科外来では肋骨骨折の可能性が高い。
このように、診療科などにより症状/所見発生頻度の事前分布は異なる場合が多い。
このような場合、似たような診療科、医療機関の形態、地域を合わせたところで検索スコープを設定すれば有用である。
例えば、本申請書では医療を例にとったが、他に教育、人事など等、同様の議論が可能である。図に示した知識ツリー名、知識エントリー名、知識エントリー属性カテゴリー名などは、あくまで例示に過ぎず、実情に応じて変更してよい。
知識ツリーや知識エントリーなどの分類基準、知識エントリー属性カテゴリーの設定などは経験のある設計者が慎重に定義する必要がある。
本特許申請書の分類基準は一例に過ぎない。一旦分類基準が定義されると、以後の記述の揺らぎは最小限となる。
Claims (23)
- (i)知識の記録、管理において、少なくとも一つ存在する知識エントリーを管理する知識エントリー管理手段を備え、
前記知識エントリーは、当該知識エントリーに関する属性記述を記録、管理する知識エントリー属性記述管理手段を備え、
当該知識エントリー属性記述管理手段は、前記属性記述から、他の知識エントリーないし当該他の知識エントリーの属性記述への参照リンクを含んでいることを特徴とする知識管理手段と、
(ii)医療文書の作成において、医療文書内容の記述語彙として、前記知識管理手段における参照リンクを利用可能とする知識管理参照リンク利用手段を備えたことを特徴とする医療文書作成手段の、
(i)(ii)両者を備えたことを特徴とする医療文書管理システム。
- 前記知識エントリー属性記述管理手段において、
知識エントリー属性記述を、カテゴリーに分けて管理する知識エントリー属性カテゴリー管理手段を備えたことを特徴とする請求項1記載の医療文書管理システム。
- 前記知識管理手段において、
少なくとも一つの知識ツリーを管理する知識ツリー群管理手段と、前記知識ツリー毎に少なくとも一つ存在する知識エントリーを管理する、知識ツリー構造を前提にして拡張した知識エントリー管理手段を備え、
前記各知識エントリーは、当該知識エントリーに関する属性を記述する知識エントリー属性記述と、当該知識ツリーの他の知識エントリーとの親子関係を記述する知識エントリー親子関係リンクからなり、
前記知識エントリー属性記述は、異なる又は同一の知識ツリーに属する知識エントリー、または当該知識エントリーの知識エントリー属性カテゴリー、または当該知識エントリーの知識エントリー属性記述に対する参照リンクを含んでいることを特徴とする知識管理手段を備えたことを特徴とする請求項1〜2いずれか記載の医療文書管理システム。
- 前記参照リンクにおいて、
当該知識エントリー属性記述に関連する外部文書ないし外部文書群、または当該文書の文書内記述に対して参照を行う外部文書参照手段を備えたことを特徴とする請求項1〜3いずれか記載の医療文書管理システム。
- 前記参照リンクにおいて、
参照に際して実行すべきスクリプトを管理するスクリプト実行手段を備えたことを特徴とする請求項1〜4いずれか記載の医療文書管理システム。
- 前記参照リンクにおいて、
参照の強さを設定したり、観察に応じて強さを可変とする参照強度管理手段を備えたことを特徴とする請求項1〜5いずれか記載の医療文書管理システム。
- 前記親子関係において、
親知識エントリーの知識エントリー属性記述を子知識エントリーのエントリー属性記述へ継承する知識エントリー属性記述継承手段を有することを特徴とする請求項3〜6いずれか記載の医療文書管理システム。
- 前記参照リンクにおいて、
語彙を参照した医療文書から、逆に、参照元の知識エントリーないし当該知識エントリーの知識エントリー属性記述に対して、症例リンクを作成する症例リンク作成手段を有することを特徴とする請求項1〜7いずれか記載の医療文書管理システム。
- 前記症例リンク作成手段において、
当該症例で観察された症状/所見の各々、もしくは同時観察された症状/所見の組合せペアについて、前記観察された症状/所見の各知識エントリーに対し、前記症状/所見付きの症例リンクを作成する症状/所見別症例リンク作成手段を備えたことを特徴とする請求項8記載の医療文書管理システム。
- 前記症状/所見症例リンク作成手段において、
症状/所見別に症例リンクを分類集計する症状/所見別症例リンク集計手段を備えたことを特徴とする請求項9記載の医療文書管理システム。
- 前記症状/所見症例リンク作成手段において、
当該症例の疾患名が確定した際、同時観察された症状/所見について、当該疾患名の知識エントリーに対し、前記症状/所見別症例リンクを作成する確定疾患症状/所見症例リンク作成手段を備えたことを特徴とする請求項9〜10いずれか記載の医療文書管理システム。
- 疾患名未確定の症例において、
当該症例の医療文書で観察された症状/所見、ないし症状/所見ペアの各々について、既に作成されている症例リンクの集合の積集合を求めることで、当該症例と類似した症例のリストを求める類似症例検索手段を備えたことを特徴とする請求項9〜11いずれか記載の医療文書管理システム。
- 前記類似症例検索手段において、
得られた症例リストの確定疾患名を集計し、頻度順に表示する類似症例疾患名推定手段を備えたことを特徴とする請求項12記載の医療文書管理システム。
- 疾患名未確定の症例において、
当該症例の医療文書で観測された症状/所見に対し、前記症状/所見別症例リンク集計手段を用いて集計された疾患名別症状/所見観察頻度、または、前記観察された症状/所見の個々についての疾患名頻度分布、もしくはその両者を用いて、可能性の高い当該症例の疾患名のリストを推定する疾患名リスト推定手段を備えたことを特徴とする請求項9〜13いずれか記載の医療文書管理システム。
- 前記疾患名リスト推定手段で得られた複数の疾患名において、
前記症状、所見別症例リンク集計手段を用いて集計された前記複数の疾患名の疾患名別症状、所見観測頻度を用いて、疾患名によって頻度分布の差の大きい症状、所見のリストを得て、疾患名の鑑別に有効な次に得るべき症状所見のリストを推定する診察検査推薦手段を備えたことを特徴とする請求項14記載の医療文書管理システム。
- 前記診察検査推薦手段において、
医療文書の作成の際、診察によって得られるべき症状、所見や、行われるべき検査の推薦リストを自動的に表示し、円滑な診察記録の作成や検査オーダーの作成を容易とする診察検査推薦表示手段を備えたことを特徴とする請求項15記載の医療文書管理システム。
- 前記知識ツリー群管理手段において、
複数の知識ツリー群を名前空間で分割して管理する名前空間管理手段を有することを特徴とする請求項3〜16いずれか記載の医療文書管理システム。
- 前記知識管理システムを構成する名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクの任意の部分を抽出して知識管理部分集合を作成し、別の知識管理システムにエクスポートする知識エクスポート手段を備えたことを特徴とする1〜17いずれか記載の医療文書管理システム。
- 前記知識エクスポート手段で抽出された前記知識管理部分集合、或いは別個に構築された知識管理システムからの前記知識管理部分集合をインポートし、名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクを再構成する知識インポート手段を備えたことを特徴とする請求項18記載の医療文書管理システム。
- 前記知識管理手段においては、
名前空間、知識ツリー、知識エントリー、知識エントリー属性カテゴリー、知識エントリー属性記述、親子関係リンクの各々の作成、編集、削除、参照の機能について、前記医療作成手段においては、医療文書の作成、編集、削除、参照の機能について、ユーザーごとに前記機能の実行権限を管理するユーザー権限管理手段を備えたことを特徴とする請求項1〜19いずれか記載の医療文書管理システム。
- 前記知識管理手段において、
前記知識エントリー間の親子関係や、前記知識エントリーの知識属性記述の内容を閲覧する知識閲覧手段を備えたことを特徴とする請求項1〜20いずれか記載の医療文書管理システム。
- 前記知識管理手段においては、
(i)記録、管理されている知識内容についての問い合わせを受け付ける知識問い合わせ受付手段、問い合わせの内容に対して返答を行う知識問い合わせ返答手段、
また、(ii)前記医療文書作成手段においては、記録、管理されている医療文書の内容についての問い合わせを受け付ける医療文書内容問い合わせ受付手段、問い合わせの内容に対して返答を行う医療文書内容問い合わせ返答手段、
以上の(i)、(ii)の少なくとも一つを備えたことを特徴とする請求項1〜21いずれか記載の医療文書管理システム。
- 前記知識管理手段においては、
名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクの各々の作成、編集ユーザーを管理し、また、前記医療作成手段においては、医療文書の作成、編集ユーザーを管理し、特定のユーザーないしユーザーグループの作成した知識管理手段の部分或いは医療文書を、前記知識閲覧や知識問い合わせ受付手段、医療文書内容問い合わせ受付手段の検索対象範囲から除外する、あるいは逆に、特定のユーザーないしユーザーグループの作成した知識管理手段の部分や医療文書のみを、前記知識閲覧や知識問い合わせ受付手段、医療文書内容問い合わせ受付手段の検索対象範囲とする検索スコープ管理手段備えたことを特徴とする請求項1〜22いずれか記載の医療文書管理システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020177056A JP7008939B2 (ja) | 2020-10-22 | 2020-10-22 | 医療文書管理システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020177056A JP7008939B2 (ja) | 2020-10-22 | 2020-10-22 | 医療文書管理システム |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2018127518A Division JP6913308B2 (ja) | 2018-07-04 | 2018-07-04 | 医療文書管理システム |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2021012738A true JP2021012738A (ja) | 2021-02-04 |
JP2021012738A5 JP2021012738A5 (ja) | 2021-08-19 |
JP7008939B2 JP7008939B2 (ja) | 2022-01-25 |
Family
ID=74226543
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2020177056A Active JP7008939B2 (ja) | 2020-10-22 | 2020-10-22 | 医療文書管理システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP7008939B2 (ja) |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009265758A (ja) * | 2008-04-22 | 2009-11-12 | Hitachi Ltd | 用語入力支援装置及び方法、並びにプログラム |
JP2018055278A (ja) * | 2016-09-27 | 2018-04-05 | キヤノン株式会社 | 医用情報処理装置、医用情報処理システム、医用情報処理方法およびプログラム |
-
2020
- 2020-10-22 JP JP2020177056A patent/JP7008939B2/ja active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009265758A (ja) * | 2008-04-22 | 2009-11-12 | Hitachi Ltd | 用語入力支援装置及び方法、並びにプログラム |
JP2018055278A (ja) * | 2016-09-27 | 2018-04-05 | キヤノン株式会社 | 医用情報処理装置、医用情報処理システム、医用情報処理方法およびプログラム |
Also Published As
Publication number | Publication date |
---|---|
JP7008939B2 (ja) | 2022-01-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6814482B2 (ja) | 知識管理システム | |
Dohan et al. | Using computers to analyze ethnographic field data: Theoretical and practical considerations | |
US8392419B2 (en) | Computer research tool for the organization, visualization and analysis of metabolic-related clinical data and method thereof | |
CN104769588B (zh) | 队列识别*** | |
Willett et al. | SNOMED CT concept hierarchies for sharing definitions of clinical conditions using electronic health record data | |
Khan et al. | Towards development of health data warehouse: Bangladesh perspective | |
Zhou et al. | Clinical decision support system for hypertension medication based on knowledge graph | |
US20210133608A1 (en) | Medical document management system | |
JP6792750B2 (ja) | 診断支援システム | |
Grandi et al. | Efficient management of multi-version clinical guidelines | |
JP7083977B2 (ja) | 知識管理システム | |
JP6868860B2 (ja) | 知識管理システム | |
JP7008939B2 (ja) | 医療文書管理システム | |
JP2021077382A5 (ja) | ||
Huff et al. | A medical data dictionary for decision support applications | |
JP2020129385A5 (ja) | ||
JP2021012738A5 (ja) | ||
Gupta et al. | Entity resolution for maintaining electronic medical record using oyster | |
De La Calle et al. | e-MIR 2: a public online inventory of medical informatics resources | |
Scharnhorst et al. | Looking at a digital research data archive-Visual interfaces to EASY | |
Branescu et al. | Solutions for medical databases optimal exploitation | |
Panesar et al. | Preparing Data | |
Hübenthal | Databases and Knowledge Graphs | |
Montemurro | Tools for Integrative Cancer Data Annotation: a Visual Mining Based Approach | |
Papež | Archetype-based approach for modelling of electroencephalographic/event-related potentials data and metadata |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20210628 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20210628 |
|
A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20210707 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20211013 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20211128 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20211213 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20211224 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 7008939 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |