JP6814482B2 - 知識管理システム - Google Patents

Description

本発明は、推論や判断、認識などの際に必要とされる知識の蓄積や検索を効率的に行う知識管理システムに関する。

人間が日常行っている判断や推論をコンピュータに行わせることができれば、大量高速に日常業務を処理し、あるいは簡便化できる。このための開発が従来から行われてきている。
初期には、「もしＡならばＢである」、「もしＢならばＣである」などの判断ルールを蓄積しておき、「ＤはＡである」という命題が与えられたとき、事前に蓄積された判断ルールを順次適用し、「ＤはＣである」と推論するエキスパートシステムが開発された。感染症に対する最適な抗生剤を推論する「ＭＹＣＩＮ」が知られている。

インターネットの時代に入り、より柔軟な検索が必要とされてきた。例えば、「Ｅはバイオリン奏者である」、「バイオリン奏者は音楽家である」、「指揮者は音楽家である」等などのウェブ上の記録や宣言を用いて、「Ｅは音楽家であるか？」という問いに答えるものである（セマンティック ウェブ：semantic web）。
ここで、「音楽家」という上位概念の下に、「バイオリン奏者」や「指揮者」、「作曲家」等などの下位概念が展開されている。このように、概念を構造的に記述すると（オントロジー：ontology）、ウェブ上に「Ｅは音楽家である」という直接的な記述がなくても、「Ｅはバイオリン奏者であるから、音楽家でもある」ことが推論され、前記の問いに正しく答えることができる。
ここで、多分野の概念を横断的に検索できるように、個々の概念や関係を、ＸＭＬなど書式を用いて、統一的な様式で記述しておく必要がある。この統一的な様式の一例として、ＲＤＦ（Resource Description Framework）が提唱されている。概念や関係を個々の断片ごとに記述するやり方は、Prologなどのプログラム言語との相性が良く、リレーショナルデータベースとも馴染みやすい。

医療分野においても以下の非特許文献１が示すような疾患オントロジー構築が試みられている。また、一般産業分野でも特許文献１などが提案されている。

特開2012-119004号

臨床医学知識のオントロジー表現と活用（http://www.sanken.osaka-u.ac.jp/labs/nano/contents/meeting/pdf/S12_ohe.pdf）

初期のエキスパートシステムでは、実用レベルの運用に必要な多量の判断ルールの蓄積自体が大変である。また、「もしＡならばＢ」の条件部Ａは正確に一致する場合にしか適応されないため、前記の例のように、「バイオリン奏者」に対して「音楽家」の検索をかけた場合は該当なしとなってしまう。
セマンティック ウェブでは、オントロジーなどの構造的な記述により、「バイオリン奏者」や「指揮者」、「作曲家」等も「音楽家」の下部概念に含まれるという、いわば常識を活用して、ある程度あいまいな検索にも対応できるようになってきた。しかしながら、実際に具体的なオントロジーを構築してみると、記述形式の自由度が余りにも大きい故に、同一内容でも複数の記述様式が可能であり、構築者によって記述された構造がゆらいでしまう。このため、同じ内容であっても、異なる記述様式となる場合が多い。このため、複数のオントロジーを複数の人間が並行作業で構築した場合に、記述様式の不整合による混乱が生じてくる。また、様々な記述のやり方が混在するため、展開されたオントロジーを見ても容易に理解できないことが多く、可読性が悪いことが多い。

他方、個々の知識領域、知識項目、属性記述、親子関係記述などの知識断片をＲＤＦなどの様式で記述した場合も、同様の記述様式の揺らぎは避けられず、そもそも知識断片の大量の羅列であり、知識の全体像が一覧できず、可読性は極めて悪い。
大量の知識を効率的に記述していくには、コンピュータが理解できる形式であることは言うまでもないが、人が見ても容易に理解できる可読性も必要である。特別な知識や技能が無くても容易に知識記述ができること、見て簡単に矛盾点などを指摘できることは、ＷＥＢ2.0で推奨されているように、或る分野では知識を持っていてもコンピュータに関しては専門家でないたくさんの人たちが、ウェブを介して協力しながら、同時並行でオントロジーなどを構築してゆくのに不可欠な特性である。

本発明はかかる従来の問題点を解決するためになされたものであって、その目的とするところは、ある領域の知識を、複数の知識ツリーに明確に分離して整理すること、各知識ツリーでは、ツリーを構成する知識エントリーが親子関係の階層構造で展開され、各知識エントリーは、当該知識エントリーに関するエントリー属性記述の集合で、前記エントリー属性記述は、別の知識エントリーないしエントリー属性記述への参照リンクを含むことで、表記の揺らぎのない系統的な知識の記述を可能にすることである。
さらに、親知識エントリーのエントリー属性記述を子知識エントリーが継承することで、属性記述を重複して記述する必要をなくすことである。
別の領域に関しては、名前空間で分離された別の独立した知識ツリー群としての管理を可能とすることで、他領域での知識ツリーや知識エントリー名の重複を気にせずに興味ある領域に専念することが出来ることである。
このような知識管理の枠組みを確立することで、機械処理が可能なのは勿論、人が見ても内容が一覧できる良好な可読性と、誰が作成しても記述の揺らぎがない知識管理システムを構築し、柔軟で高度な検索や推論を可能とする知識処理の基盤を提供することである。
また、前記の知識管理システムの一部ないし全部を抽出して別の知識管理システムへ統合するといった知識管理システムの再構成を可能とすることで、知識管理システムの柔軟な運用を可能とすることである。
また、構築された知識管理システムの内容を閲覧できるだけでなく、知識管理システムに対する問い合わせ、知識管理システムからの応答を可能として、現実社会での有効な活用を可能とすることである。さらにユーザーの実行権限を管理すること、検索のスコープを設定可能とすることで、破壊や混乱に対するセキュリティを確保することである。

前記目的を達成するための手段として、請求項１記載の知識管理システムでは、知識の記録、管理において、少なくとも一つの知識ツリーを管理する知識ツリー群管理手段と、前記知識ツリー毎に少なくとも一つ存在する知識エントリーを管理する知識エントリー管理手段を備え、前記各知識エントリーは、当該知識エントリーに関する属性を記述する知識エントリー属性記述と、当該知識ツリーの他の知識エントリーとの親子関係を記述する知識エントリー親子関係リンクからなり、前記知識エントリー属性記述は、異なる又は同一の知識ツリーに属する知識エントリーに対する参照リンクを有する語彙、または当該知識エントリーのエントリー属性記述に対する参照リンクを有する語彙を含み、前記親子関係において、親知識エントリーのエントリー属性記述を子知識エントリーのエントリー属性記述へ継承する知識エントリー属性記述継承手段を有し、前記知識エントリー属性記述及び知識エントリー親子関係リンクを備えた知識エントリーを有して構成されるデータ構造を利用して必要とする知識にアクセスするアクセス手段を備えたことを特徴とする。

本願では、前記知識エントリー属性記述を、カテゴリーに分けて管理する知識エントリー属性カテゴリー管理手段を備えたことを特徴とする。

本願では、前記親子関係において、親知識エントリーのエントリー属性記述を子知識エントリーのエントリー属性記述へ継承する知識エントリー属性記述継承手段を有することを特徴とする。

本願では、前記参照リンクにおいて、参照の強さや参照に当たって実行するスクリプトを管理する参照特性管理手段を有することを特徴とする。

本願では、前記参照特性管理手段において、前記参照の強さを観測頻度に応じて可変としたことを特徴とする。

本願では、前記参照リンクにおいて、当該エントリー属性記述に関連する外部文書ないし外部文書群に対して参照を行う外部文書参照手段を備えたことを特徴とする。

本願では、前記知識ツリー群管理手段において、複数の知識ツリー群を名前空間で分割して管理する名前空間管理手段を有することを特徴とする。

本願では、前記知識管理システムを構成する名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクの任意の部分を抽出して知識管理部分集合を作成し、別の知識管理システムにエクスポートする知識エクスポート手段を備えたことを特徴とする。

本願では、前記知識エクスポート手段で抽出された前記知識管理部分集合、或いは別個に構築された知識管理システムからの前記知識管理部分集合をインポートし、名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクを再構成する知識インポート手段を備えたことを特徴とする。

本願では、前記名前空間、知識ツリー、知識エントリー、知識エントリー属性カテゴリー、知識エントリー属性記述、親子関係リンクの各々の作成、編集、削除、参照の機能について、ユーザーごとに前記機能の実行権限を管理するユーザー権限管理手段を備えたことを特徴とする。

本願では、前記知識管理システムにおいて、前記知識エントリー間の親子関係や、前記知識エントリーの知識属性記述の内容を閲覧する知識閲覧手段を備えたことを特徴とする。

本願では、前記知識管理システムにおいて、記録、管理されている内容についての問い合わせを受け付ける知識問い合わせ受付手段、問い合わせの内容に対して返答を行う知識問い合わせ返答手段を備えたことを特徴とする。

本願では、前記名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクの各々の作成ユーザーを管理し、特定のユーザーないしユーザーグループの作成した知識管理システムの部分を、前記閲覧や知識問い合わせの検索対象範囲から除外する、あるいは逆に、特定のユーザーないしユーザーグループの作成した知識管理システムの部分のみを前記閲覧や知識問い合わせの検索対象範囲とする検索スコープ管理手段備えたことを特徴とする。

請求項１記載の知識管理システムでは、少なくとも一つの知識ツリーを管理する知識ツリー群管理手段と、前記知識ツリー毎に少なくとも一つ存在する知識エントリーを管理する知識エントリー管理手段を備えているので、特定の領域の知識が各知識ツリーに明確に分離して管理され、各知識ツリーでは、ツリーを構成する知識エントリーが階層構造に展開して管理される。
各知識エントリーは、当該知識エントリーに関する属性を記述する知識エントリー属性記述と、当該知識ツリーの他の知識エントリーとの親子関係を記述する知識エントリー親子関係リンクからなるので、表記の揺らぎのない系統的な知識の記述が可能となる。
知識エントリー属性記述は、異なる又は同一の知識ツリーに属する知識エントリー、または当該知識エントリーのエントリー属性記述に対する参照リンクを含んでいるので、リンク先の適切な情報を参照可能である。

本願では、知識エントリー属性記述を、カテゴリーに分けて管理する知識エントリー属性カテゴリー管理手段を備えているので、知識エントリーの属性記述がカテゴリー別に適切に管理される。

本願では、親子関係において、親知識エントリーのエントリー属性記述を子知識エントリーのエントリー属性記述へ継承する知識エントリー属性記述継承手段を有するので、共通の属性記述は、親知識エントリーに括られ、子の知識エントリーは、最小限の属性記述で済む。
また、知識エントリーの親に当たる知識エントリーの属性記述はすべて継承して表示され、属性記述の総合的把握が容易となる。

本願では、参照リンクにおいて、参照の強さや参照に当たって実行するスクリプトを管理する参照特性管理手段を有するので、状況に即したベイズ推定などを行うことが可能となり、チェックミスを防止し、医療の安全性が向上する。

本願では、参照特性管理手段において、前記参照の強さを観測頻度に応じて可変としたので、より状況に即したベイズ推定などを行うことが可能となる。

本願では、参照リンクにおいて、当該エントリー属性記述に関連する外部文書ないし外部文書群に対して参照を行う外部文書参照手段を備えたので、関連する書籍やファイル、ウェブ上の文書の参照が可能である。

本願では、知識ツリー群管理手段において、複数の知識ツリー群を名前空間で分割して管理する名前空間管理手段を有するので、領域毎に名前空間を設定される。これにより、他の領域の知識ツリー名と分離して管理され、大規模な知識の管理も混乱なく可能となる。

本願では、知識管理システムを構成する名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクの任意の部分を抽出して知識管理部分集合を作成し、別の知識管理システムにエクスポートする知識エクスポート手段を備えたので、知識管理システム間のコンテンツのやり取りや、知識管理システムを社内とは分離したクラウド上に構築することが可能となる。

本願では、知識エクスポート手段で抽出された前記知識管理部分集合、或いは別個に構築された知識管理システムからの前記知識管理部分集合をインポートし、名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクを再構成する知識インポート手段を備えたので、クラウド上で整備された知識管理システムの一部ないし全部を、自身の知識管理システムに取り込むことが出来る。
さらに、必要に応じて、知識管理システムの一部ないし全部を、他のネットワークに移植することが出来る。

本願では、名前空間、知識ツリー、知識エントリー、知識エントリー属性カテゴリー、知識エントリー属性記述、親子関係リンクの各々の作成、編集、削除、参照の機能について、ユーザーごとに前記機能の実行権限を管理するユーザー権限管理手段を備えたので、不慣れなユーザーによるシステムの破損を防止することが出来る。また、ユーザーによる参照範囲を限定することによる、秘密とすべき知識の保持が可能となる。

本願では、知識エントリー間の親子関係や、前記知識エントリーの知識属性記述の内容を閲覧する知識閲覧手段を備えたので、階層構造に沿った知識閲覧が可能である。

本願では、知識管理システムにおいて、記録、管理されている内容についての問い合わせを受け付ける知識問い合わせ受付手段、問い合わせの内容に対して返答を行う知識問い合わせ返答手段を備えたので、必要な情報に対する検索の自動化によりアクセス性が向上する。

本願では、名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクの各々の作成ユーザーを管理し、特定のユーザーないしユーザーグループの作成した知識管理システムの部分を、前記閲覧や知識問い合わせの検索対象範囲から除外する、あるいは逆に、特定のユーザーないしユーザーグループの作成した知識管理システムの部分のみを前記閲覧や知識問い合わせの検索対象範囲とする検索スコープ管理手段備えたので、不適切な対象を検索範囲から除外したり、検索対象を特定の領域に限定して適切な情報を取得することができる。

知識ツリー群の一例で、医療知識ツリー群の概略図である。疾患名、症状/所見、薬剤名など等の知識ツリーから構成されている。 知識ツリー群管理手段の一例である。知識ツリー群内の各知識ツリーの知識ツリーＩＤと、知識ツリー名称をマスターテーブルの形で管理している。 知識ツリー群の一例として、疾患名知識ツリーを構成する知識エントリー群の一部を図示している。 知識エントリー管理手段の一例である、疾患名知識ツリーを構成する知識エントリー群にたいして、前記知識ツリーＩＤ、知識エントリーＩＤと知識エントリー名をマスターテーブルの形で管理している。 疾患名知識ツリーを構成する知識エントリーの一つである糖尿病を例として、親子関係リンク、知識エントリー属性記述を図示している 知識エントリー属性カテゴリー管理手段の一例である。知識ツリーＩＤ、知識エントリー属性カテゴリーＩＤ、知識エントリー属性カテゴリー名をマスターテーブルの形で管理している。 エントリー属性記述を構成する参照リンクの参照特性管理手段の説明図である。(a)ラベル、及び知識エントリー項目ないし知識エントリー項目内の定義知識属性カテゴリーへの参照リンク例(b)参照リンクに、発生頻度などの参照強さを管理する参照リンク例(c)参照の際に、実行すべき一連のスクリプトを定義した参照リンク例 名前空間管理の説明図である。 名前空間管理手段の説明図である。 知識閲覧手段の画面構成例である。

図１では、本発明の知識記録システムを、医療知識を例にとり概略を説明する。
知識ツリーとして、「疾患」、「症状、検査所見」、「薬剤」などを例示している。
他にも、「処置」、「保険請求」等などが考えられる。
それぞれの知識ツリーは、親子関係で連結された知識エントリーの集合からなる。
知識ツリー群管理手段は、当該知識ツリー群内にある知識ツリーを管理する。

図２は知識ツリー群管理手段の一例で、マスターテーブルの形式で、当該群内の知識ツリーＩＤと知識ツリー名を管理している。
図３は、知識ツリーの一例として、「疾患名」知識ツリーを構成する知識エントリー群を図示している。
「疾患名」の知識エントリー群は、まず「代謝系」、「消化器系」、「運動器系」、「循環器系」などの大分類に分かれる。それぞれの大分類は、「代謝系」では「糖代謝系」、「脂質代謝系」、「アミノ酸代謝系」など中分類に分かれる。中分類の「糖代謝系」は、さらに「糖尿病」、「糖原病」などの小分類に分かれる。

小分類の「糖尿病」は、「Ｉ型糖尿病」と「II型糖尿病」を含む。
ここで、知識ツリーの末端、葉に当たる「Ｉ型糖尿病」と「II型糖尿病」などが具体的な疾患名である。それらの共通属性を括りだして枝に当たる小分類、中分類、大分類などの知識エントリー群が構成され、これらは下部の分類、葉の疾患名を収容するコンテナ型知識エントリーとして機能する。
ここでは大、中、小の分類階層としたが、領域によってはさらに深い階層としても良いし、浅い階層で十分な場合もある。ここでは病態をもとにした分類基準を用いたが、他に、「項部」、「頸部」、「上肢」などの部位別の分類の規準、「炎症系」、「腫瘍系」、「感染系」、「遺伝系」などの病因別の分類の規準もある。このように分類基準による表現の揺らぎはありうるが、いずれにしても、知識管理システムの管理者が一旦分類基準を決定すれば、以後の表現の揺らぎは消失する。要は、知識管理システムの管理者が、目的に応じて分類基準を設定すれば良い。場合によっては、分類基準を異にした知識ツリーを複数併存しても良い。

図４は知識エントリー管理手段の一例である。
マスターテーブルの形式で、当該知識ツリー群内において当該知識ツリー内の知識エントリーのＩＤを管理している。
知識エントリー名は、属する知識ツリー内ではユニークである必要があるが、属している知識ツリーが異なれば、図２のように定義されている知識ツリーＩＤで相互に区別されるため、同一の知識エントリー名も許される。
なお、本図では、知識ツリー群内の知識エントリーを、属している知識ツリーにかかわらず一元管理としているが、場合によっては、知識ツリーごとに別々にマスターテーブルを作り、知識エントリーを管理しても良い。
もし、属している知識ツリーによらず、知識ツリー群内を通してユニークな知識エントリー名とするならば、図４の第１列の知識ツリーＩＤは不要である。

図５は、コンテナ型知識エントリーの一つである「糖尿病」の知識エントリーと、その葉に当たる「Ｉ型糖尿病」と「II型糖尿病」を例にとり、親子関係リンクと属性記述を図示したものである。
「糖尿病」は、親知識エントリーとして「代謝系」へのリンクを持ち、さらに子知識エントリーとして、「Ｉ型糖尿病」及び「II型糖尿病」へのリンクを持っている。

「糖尿病」の属性記述カテゴリーとしては、＜病態＞、＜合併症＞などがある。
＜病態＞としては、インシュリン分泌低下、高血糖、尿中に糖排泄などがある。
それぞれの＜病態＞の項目は、別の知識ツリーである「症状/所見」知識ツリーの該当する知識エントリーへの参照リンクからなっている。
このようにすることで、シソーラスのように統制語彙を用いて属性記述を行うことになり、表現のゆらぎを抑制することが出来る。
勿論ここで、従来のように直接に文字列を用いて属性記述を行ったり、文書へのリンクを張ったりしても良いが、揺らぎの抑制、また後述の参照リンクの機能の活用ができないため、好ましいとは言えない。
＜合併症＞として「腎不全」、「閉塞性動脈硬化症」などがある。これらの合併症への参照リンクは、同じ「疾患名」知識ツリー内の、当該知識エントリーへの参照リンクとなる。

「Ｉ型糖尿病」の病因は膵臓のβ細胞の急速な壊死であり、従って治療はインシュリンの注射による補給しかない。
これに対して「II型糖尿病」の病因は、肥満や糖過食などによるもので、治療は食事制限、血糖降下剤の内服、最終的には、インシュリンの注射となる。
このように、「Ｉ型糖尿病」及び「II型糖尿病」は＜病因＞、＜治療＞を異にするが、その他の＜病態＞や＜合併症＞などは、両者共通で、親知識エントリーである「糖尿病」に記述されている。
葉に当たる「Ｉ型糖尿病」及び「II型糖尿病」では、＜病因＞や＜治療＞しか記述されてなくても、親知識エントリーに当たる「糖尿病」の＜病態＞、＜合併症＞の属性記述、さらにはより上部の代謝性疾患などの属性記述が継承される。
このように、共通の属性記述を、親知識エントリーに括りだすことで、子の知識エントリーは、最小限の属性記述で済むことになる。知識エントリーの属性記述を、親子関係をたどりながら個々に見ていって頭の中で構成しても良いが、知識エントリー属性記述継承手段によって、当該知識エントリーよりも親に当たる知識エントリーの属性記述をすべて継承して表示すれば、属性記述の総合的把握が容易となる。

知識エントリー属性カテゴリー単位で親から継承されてきた属性記述は、そのまま子知識エントリーの知識エントリー属性記述となる場合もあるが、子知識エントリーの当該知識エントリー属性カテゴリーに継承されてきた属性記述とは異なる知識エントリー属性記述が存在した場合は、子知識エントリーの当該知識エントリー属性記述が、親から継承されてきた知識エントリー属性記述に対して上書きしたり追記したりすることとなる。この上書きないし追記された知識エントリー属性記述が、孫以下の知識エントリーに対して、さらに継承されてゆくことになる。
この上書きないし追記の使い分けは、適宜知識エントリー属性記述継承手段によって適宜設定すればよい。

属性カテゴリーを用いずに属性記述を行うことも可能であるが、属性カテゴリーを用いることで、知識エントリー属性記述継承手段による属性カテゴリー毎の継承が容易に把握できる。また、属性記述の上書き、追記が容易にできるので、より有用といえる。

＜症例＞知識エントリー属性カテゴリーでは、当該疾患名を有する症例のカルテへの参照リンクが記録されている。
これにより、当該疾患の患者記録を直接参照することが出来る。症例カルテへの参照リンクとしては、医療機関ＩＤ＋患者ＩＤ、患者カルテのＵＲＬ、患者カルテファイルの名など、症例情報へのアクセスを可能にするものであれば、任意の形式で良い。さらに、当該患者カルテの文書ＩＤまで、例えば文書種類＋作成年月日などを含めても良い。また、＜文献＞などの知識エントリー属性カテゴリーを設けて、関連する書籍やファイル、ウェブ上の文書へのリンクを記載しても良い（外部文書参照手段）。

図６は知識エントリー属性カテゴリー管理手段の一例である。
マスターテーブルの形式で、当該知識ツリー群内において当該知識ツリー内の知識エントリー属性カテゴリーのＩＤを管理している。
知識エントリー属性カテゴリー名は、属する知識ツリー内ではユニークである必要があるが、属している知識ツリーが異なれば、知識ツリーＩＤで相互に区別されるため、同一の知識エントリー属性カテゴリー名も許される。
なお、本図では、知識ツリー群内の知識エントリー属性カテゴリーを、属している知識ツリーにかかわらず一元管理としているが、場合によっては、知識ツリーごとに別々にマスターテーブルを作り、知識エントリー属性カテゴリーを管理しても良い。
もし、知識ツリー群内でユニークな知識エントリー属性カテゴリー名を用いるならば、第１列の知識ツリーＩＤは不要である。また、本図で説明したような知識エントリー属性カテゴリー管理手段を用いずに、知識ツリーのルートに当たる知識エントリーに知識エントリー属性カテゴリーを直接書き込んで以下に継承させるやり方も可能であるが、検索などを自動化する際にマスターテーブル方式よりも手順が複雑になるので、特に大規模知識管理システムでは、好ましいとは言えない。また、個々の知識エントリーにユーザーが自由に知識エントリー属性カテゴリーを定義するやり方もありうるが、重複や記述の揺らぎが起こりやすく、同様に、好ましいとは言えない。

図７では、参照リンクの様々な実施形態を示している。
図７（ａ）は、図５で「糖尿病」の＜病態＞のなかの参照リンクである｛高血糖｝の構造を図示した例である。
ラベルである“高血糖”と、「症状/所見」知識ツリー内の知識エントリーである「高血糖」へのリンクから構成されている。
場合によっては、「高血糖」内の知識エントリー属性カテゴリーである＜定義＞にリンクしても良い。ラベルは閲覧などに際しての表示内容である。
本例のように、リンク先の知識エントリー名をそのまま用いても良いが、見易いように、“「高血糖 血糖値＞140ｍｇ/ｄｌ”などとしても良い。
このようにすれば、リンク先を個別に参照する工程がなくても、容易に一覧して概要を把握することが出来る。

図７（ｂ）では、「薬剤」知識ツリーの「フロセミド」知識エントリー内の＜副作用と発生率＞知識エントリー属性カテゴリーの参照リンクを示している。
第１行では、“高カリウム血症”のラベル、“５％”という参照強度、および「症状/所見」知識ツリー内の「高カリウム血症」知識エントリーへの参照リンクからなっている。
様々な副作用があっても発生率は一様でない。参照強度として発生頻度の情報を持つことで、考慮すべき副作用の順番が明確となる。
また、この発生頻度は、ベイズ確率でいう事前確率となり、複数の薬剤投与化で副作用が発生した際に、原因薬剤を推定するベイズ推定に有用である。

図７（ｃ）は、疾患名知識ツリー内の「椎間板ヘルニア」知識エントリーで、＜検査＞知識エントリー属性カテゴリーにおいて、“ＭＲＩ”のラベル、「検査」知識ツリー内の「ＭＲＩ」知識エントリーへの参照リンクに併せて、実施に際してのチェック スクリプトのフローチャートを示したものである。
このように、参照の強さや、参照に当たって実行するスクリプトを管理する参照特性管理手段を有することで、ベイズ推定を行って対応に役立てたり、チェックミスをなくすことで、医療の安全性が向上する。さらに、前記参照特性管理手段において、前記参照の強さを症例での観測頻度に応じて可変とすることで、より状況に即したベイズ推定などを行うことが可能となる。
さらに、例えば或る患者の＜症状＞として「発熱」を記述する際、「症状/所見」知識ツリーの「発熱」知識エントリーへの参照リンクで、前記参照特性管理手段を用いて、発熱の「あり/なし」の極性を管理しても良い。また、発熱」知識エントリーから、当該患者のカルテへの参照リンクを同時に張っても良い。このようにすれば、発熱のある患者都内患者の割合はどうか？、或いは、発熱のある患者のリストが欲しいといった要求に容易に答えることが出来る。

図１で示した知識ツリー群は医療に関係したものであるが、知識を記述すべき領域は、他にも芸術や産業など等無数にある。
知識ツリー名は他の知識ツリー名と重複の無いユニークなものであることが必須であるが、関知しない他の領域で同一知識ツリー名が使われると、厄介な問題を引き起こす。
この問題を避けるため、図８のように、領域毎に名前空間を設定している。これにより、知識ツリー名は名前空間＋知識ツリー名となるため、他の領域の知識ツリー名を完全に分離することが出来る。図９は、名前空間ＩＤと名前空間名を、マスターテーブルの形式で管理している（名前空間管理手段）例である。必要に応じて、名前空間ＩＤを、図２、図４、図６の１列目に付加することにより、大規模な知識の管理も混乱なく可能となる。

図１０は、知識閲覧手段の一例である。
まず左から第１列の名前空間のリストから此処では「医療」を選択している。
この結果、第２列には「医療」名前空間に属する知識ツリー群の名前がリストアップされる。ここで「疾患名」知識ツリーを選択すると、先ず代謝系、循環器系などの大分類のリストが示される。「代謝系」を選択すると、その下の中分類群である「糖代謝系」、「脂質代謝系」などのリストが示される。
「糖代謝系」を選択すると、その下の小分類である「糖尿病」、「糖原病」などがリストアップされる。
「糖尿病」を選択すると、知識エントリー属性カテゴリーである＜病態＞、＜合併症＞などが示される。
＜病態＞を選択すると、＜病態＞を構成する属性記述である“高血糖”や、“HbA1c高値”などの参照リンクが示される。
“高血糖”を選択すると、参照リンク先である「症状/所見」知識ツリー内の「高血糖」知識エントリーの属性カテゴリーである＜定義＞、＜検査法＞などが示される。
<定義>を選択すると、当該知識エントリー属性カテゴリーの内容が表示される。

図１０で示したように、手作業で閲覧を進めることも有用だが、知識管理システムに検索などの問い合わせを行い、検索結果に対して集合演算や論理演算などの処理を行い結果を表示したりファイルにダウンロードしたりすることはさらに有用である。
一連の問い合わせ手続きをスクリプト等で表記し、順に自動処理することができれば効率が良い（知識問い合わせ受付手段及び知識問い合わせ返答手段）。

本発明の知識管理システムはクラウド上に構築することを想定している。
しかし、会社や病院によっては、セキュリティ上の理由からウェブへの接続をしない運用を行っている。このような場合、知識管理システムを構成する名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクの任意の部分を抽出して知識管理部分集合を作成し、別の知識管理システムにエクスポートする知識エクスポート手段、さらに、前記知識エクスポート手段で抽出された前記知識管理部分集合、或いは別個に構築された知識管理システムからの前記知識管理部分集合をインポートし、名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクを自知識管理システムに統合、再構成する知識インポート手段を備えることで、クラウド上で整備された知識管理システムの一部ないし全部を、自社内部の知識管理システムに取り込むことが出来る。
また、自社内で優秀な知識管理システムが構築出来て、他に購入希望者があった際は、同様の手順で、知識管理システムの一部ないし全部を、他に移植することが出来る。

知識管理システムの扱う情報量は膨大になるため、作成には多数の人間の協力が必要である。
関与する人間の権限やスキルに応じて、名前空間、知識ツリー、知識エントリー、知識エントリー属性カテゴリー、知識エントリー属性記述、親子関係リンクの各々の作成、編集、削除、参照の機能などについて権限の設定を行うことは不可欠である（ユーザー権限管理手段）。
これにより、理解の乏しいユーザーによる知識管理システムの破損を防止することが出来る。また、ユーザーによる参照範囲を限定することによる、秘密とすべき知識の保持が可能となる。

本発明の知識管理システムをデータベースで実装するには、Ｎeo4jなどのグラフデータベース、従来から多用されているリレーショナルデータベース（ＲＤＢ）、最近ビッグデータの処理方法として注目を集めているキーバリューストア（ＫＶＳ）などがある。
どの実装を用いても可能であるが、それぞれの特長/欠点がある。
まずＮeo4Jは、ネットワーク状のグラフ関係を設定、表示することは得意だが、大規模処理では処理速度が必ずしも速いとは言えず、大型の知識管理システムには不向きであろう。
ＲＤＢでは、名前空間、知識ツリー、知識エントリー、知識エントリー属性カテゴリーなどのマスターテーブル管理下に、リレーションの各行ごとに、親子関係リンクや知識エントリー属性記述を行うことで本発明の知識管理システムを実装することが出来る。
検索の自由度が高く、ＳＱＬなどの問い合わせ言語も完備されており、従前からのソフトウェア資産も多いため、ＲＤＢを用いた実装が現実的であろう。

ＫＶＳでは、1〜数項目のデータ（カラム）とキーとなるデータのセットからなる。従って、多種多様で自由な検索はＲＤＢに劣る。しかし大量のデータの処理に関しては、MapReduceなどといった分散処理が高速で可能である。
図５における＜症例＞内の症例リストや、「症状/所見」知識ツリー内の「高血糖」の＜症例＞などでは、実際に電子カルテなどを運用すれば直ぐに膨大な症例リストとなる。一属性の頻度分布は、いずれの方法を用いても容易に求められるが、「糖尿病患者で、HbA1cが10を超えて、尿たんぱくが２＋以上の症例の頻度はどれくらいか？」といった、複数の要因からなる頻度を大規模症例のデータから求める際は、時にＲＤＢの処理能力を超えてしまう。このような場合は、糖尿病患者リスト、HbA1c＞10の患者リスト、尿たんぱく＞2+の患者リストの間で、集合演算を行う必要がある。このような場合、ＫＶＳのMapReduceによる分散処理が極めて有効である。

さらに、本発明の知識管理システムでは、知識エントリーが階層構造となっているため、例えば、「発熱」の患者リストを検索したい場合、「発熱」の下部概念である「弛張熱」や「稽留熱」などの患者リストまで検索範囲を、必要に応じて拡げることが可能である。
このように、本発明の知識管理システムは、データベースの実装方式を問わないが、基本部分をＲＤＢで、症例リストなどの処理をＫＶＳで行うなどの組み合わせが最も有効であろう。

前記ユーザー権限管理手段で知識管理システムへのアクセスに関しユーザーごとに権限設定するが、これだけでは十分といえない。ある対立する学説の信奉者同士が、互いの書き込みを否定する上書きを繰り返すといった例がみられる。このような場合の解決策として、あるユーザーから見て、他の特定のユーザーの書き込みを検索対象から外す検索スコープ管理手段を用いれば、平和的な解決が可能である。

同じ「胸部痛」といっても、心臓疾患専門病院で発生すれば心筋梗塞の可能性が高いが、整形外科外来では肋骨骨折の可能性が高い。このように、診療科などにより症状/所見発生頻度の事前分布は異なる場合が多い。このような場合、似たような診療科、医療機関の形態、地域を合わせたところで検索スコープを設定すれば有用である。

以上、実施例を説明してきたが、本発明の具体的な構成は前記実施例に限定されるものではなく、発明の要旨を逸脱しない範囲の設計変更等があっても本発明に含まれる。
例えば、本申請書では医療を例にとったが、他に教育、人事など等、同様の議論が可能である。知識ツリーや知識エントリーなどの分類基準、知識エントリー属性カテゴリーの設定などは経験のある設計者が慎重に定義する必要がある。本申請書の分類基準は一例に過ぎない。一旦分類基準が定義されると、以後の記述の揺らぎは最小限となる。

Claims (1)

1. 知識の記録、管理において、
   少なくとも一つの知識ツリーを管理する知識ツリー群管理手段と、前記知識ツリー毎に少なくとも一つ存在する知識エントリーを管理する知識エントリー管理手段を備え、
   前記各知識エントリーは、当該知識エントリーに関する属性を記述する知識エントリー属性記述と、当該知識ツリーの他の知識エントリーとの親子関係を記述する知識エントリー親子関係リンクからなり、
   前記知識エントリー属性記述は、異なる又は同一の知識ツリーに属する知識エントリーに対する参照リンクを有する語彙、または当該知識エントリーのエントリー属性記述に対する参照リンクを有する語彙を含み、
   前記親子関係において、親知識エントリーのエントリー属性記述を子知識エントリーのエントリー属性記述へ継承する知識エントリー属性記述継承手段を有し、
   前記知識エントリー属性記述及び知識エントリー親子関係リンクを備えた知識エントリーを有して構成されるデータ構造を利用して必要とする知識にアクセスするアクセス手段を備えたことを特徴とする知識管理システム。