JP6913308B2 - 医療文書管理システム - Google Patents

医療文書管理システム Download PDF

Info

Publication number
JP6913308B2
JP6913308B2 JP2018127518A JP2018127518A JP6913308B2 JP 6913308 B2 JP6913308 B2 JP 6913308B2 JP 2018127518 A JP2018127518 A JP 2018127518A JP 2018127518 A JP2018127518 A JP 2018127518A JP 6913308 B2 JP6913308 B2 JP 6913308B2
Authority
JP
Japan
Prior art keywords
knowledge
entry
knowledge entry
tree
case
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.)
Active
Application number
JP2018127518A
Other languages
English (en)
Other versions
JP2020008994A (ja
Inventor
姫野 信吉
信吉 姫野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Iryou Jyouhou Gijyutu Kenkyusho Corp
Original Assignee
Iryou Jyouhou Gijyutu Kenkyusho Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Iryou Jyouhou Gijyutu Kenkyusho Corp filed Critical Iryou Jyouhou Gijyutu Kenkyusho Corp
Priority to JP2018127518A priority Critical patent/JP6913308B2/ja
Priority to PCT/JP2019/024523 priority patent/WO2020008899A1/ja
Publication of JP2020008994A publication Critical patent/JP2020008994A/ja
Priority to US17/140,499 priority patent/US20210133608A1/en
Application granted granted Critical
Publication of JP6913308B2 publication Critical patent/JP6913308B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H70/00ICT specially adapted for the handling or processing of medical references
    • G16H70/60ICT specially adapted for the handling or processing of medical references relating to pathologies
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00Computing arrangements using knowledge-based models
    • G06N5/01Dynamic search techniques; Heuristics; Dynamic trees; Branch-and-bound
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2246Trees, e.g. B+trees
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/284Relational databases
    • G06F16/285Clustering or classification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00Computing arrangements using knowledge-based models
    • G06N5/02Knowledge representation; Symbolic representation
    • G06N5/022Knowledge engineering; Knowledge acquisition
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N7/00Computing arrangements based on specific mathematical models
    • G06N7/01Probabilistic graphical models, e.g. probabilistic networks
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/70ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for mining of medical data, e.g. analysing previous cases of other patients
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H70/00ICT specially adapted for the handling or processing of medical references
    • G16H70/20ICT specially adapted for the handling or processing of medical references relating to practices or guidelines
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00Computing arrangements using knowledge-based models
    • G06N5/04Inference or reasoning models

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Medical Informatics (AREA)
  • Public Health (AREA)
  • General Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • Primary Health Care (AREA)
  • Software Systems (AREA)
  • Biomedical Technology (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Evolutionary Computation (AREA)
  • Artificial Intelligence (AREA)
  • Computational Linguistics (AREA)
  • Pathology (AREA)
  • Probability & Statistics with Applications (AREA)
  • Pure & Applied Mathematics (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Analysis (AREA)
  • Computational Mathematics (AREA)
  • Algebra (AREA)
  • Bioethics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Description

本発明は、推論や判断、認識などの際に必要とされる知識の蓄積や検索を効率的に行う知識管理手段を用いて、医療文書の作成、検索などを効率的に行う医療文書管理システムに関する。
人間が日常行っている判断や推論をコンピュータに行わせることができれば、大量高速に日常業務を処理し、あるいは簡便化できる。このための開発が従来から行われてきている。
初期には、「もしAならばBである」、「もしBならばCである」などの判断ルールを蓄積しておき、「DはAである」という命題が与えられたとき、事前に蓄積された判断ルールを順次適用し、「DはCである」と推論するエキスパートシステムが開発された。感染症に対する最適な抗生剤を推論する「MYCIN」が知られている。
インターネットの時代に入り、より柔軟な検索が必要とされてきた。例えば、「Eはバイオリン奏者である」、「バイオリン奏者は音楽家である」、「指揮者は音楽家である」等などのウェブ上の記録や宣言を用いて、「Eは音楽家であるか?」という問いに答えるものである(セマンティック ウェブ:semantic web)。
ここで、「音楽家」という上位概念の下に、「バイオリン奏者」や「指揮者」、「作曲家」等などの下位概念が展開されている。このように、概念を構造的に記述すると(オントロジー:ontology)、ウェブ上に「Eは音楽家である」という直接的な記述がなくても、「Eはバイオリン奏者であるから、音楽家でもある」ことが推論され、前記の問いに正しく答えることができる。
ここで、多分野の概念を横断的に検索できるように、個々の概念や関係を、XMLなど書式を用いて、統一的な様式で記述しておく必要がある。この統一的な様式の一例として、RDF(Resource Description Framework)が提唱されている。概念や関係を個々の断片ごとに記述するやり方は、Prologなどのプログラム言語との相性が良く、リレーショナルデータベースとも馴染みやすい。
医療分野においても以下の非特許文献1が示すような疾患オントロジー構築が試みられている。また、一般産業分野でも特許文献1などが提案されている。
医療分野では医療記録を電子的に作成する、いわゆる電子カルテの導入が進んでいる。蓄積された電子文書を検索したり、複製したりすることで、簡便に医療文書が作成できるので普及が進んでいる。
臨床医学知識のオントロジー表現と活用(https://www.jstage.jst.go.jp/article/johokanri/52/12/52_12_701/_pdf)
特開2012-119004 号
初期のエキスパートシステムでは、実用レベルの運用に必要な多量の判断ルールの蓄積自体が大変である。また、「もしAならばB」の条件部Aは正確に一致する場合にしか適応されないため、前記の例のように、「バイオリン奏者」に対して「音楽家」の検索をかけた場合は該当なしとなってしまう。
セマンティック ウェブでは、オントロジーなどの構造的な記述により、「バイオリン奏者」や「指揮者」、「作曲家」等も「音楽家」の下部概念に含まれるという、いわば常識を活用して、ある程度あいまいな検索にも対応できるようになってきた。しかしながら、実際に具体的なオントロジーを構築してみると、記述形式の自由度が余りにも大きい故に、同一内容でも複数の記述様式が可能であり、構築者によって記述された構造がゆらいでしまう。このため、同じ内容であっても、異なる記述様式となる場合が多い。このため、複数のオントロジーを複数の人間が並行作業で構築した場合に、記述様式の不整合による混乱が生じてくる。また、様々な記述のやり方が混在するため、展開されたオントロジーを見ても容易に理解できないことが多く、可読性が悪いことが多い。
他方、個々の知識領域、知識項目、属性記述、親子関係記述などの知識断片をRDFなどの様式で記述した場合も、同様の記述様式の揺らぎは避けられず、そもそも知識断片の大量の羅列であり、知識の全体像が一覧できず、可読性は極めて悪い。
大量の知識を効率的に記述していくには、コンピュータが理解できる形式であることは言うまでもないが、人が見ても容易に理解できる可読性も必要である。特別な知識や技能が無くても容易に知識記述ができること、見て簡単に矛盾点などを指摘できることは、WEB2.0で推奨されているように、或る分野では知識を持っていてもコンピュータに関しては専門家でないたくさんの人たちが、ウェブを介して協力しながら、同時並行でオントロジーなどを構築してゆくのに不可欠な特性である。
医療文書の作成においては、使用される語彙や表現が、医師をはじめとする医療職の裁量に任されているため、記載すべき内容の範囲がばらついており、統計データを収集する際に、欠落データが極めて多く、不完全な分析に留まる原因となっている。
また、同じ内容でも、語彙や表現に揺らぎが大きいため、一元的な処理が困難で、同一内容の判定には人手によらざるを得ない。
これらのこともあり、医療文書は、単なる状況の記載に留まっており、記載されている内容から、確率の高い疾患名リストを推定したり、疾患どおしを鑑別するのに有用な検査や所見を推薦したりするインテリジェント化には程遠い現状である。
本発明はかかる従来の問題点を解決するためになされたものであって、その目的とするところは、ある領域の知識を、複数の知識ツリーに明確に分離して整理すること、各知識ツリーでは、ツリーを構成する知識エントリーが親子関係の階層構造で展開され、各知識エントリーは、当該知識エントリーに関するエントリー属性記述の集合で、前記エントリー属性記述は、別の知識エントリーないしエントリー属性記述への参照リンクを含むことで、表記の揺らぎのない系統的な知識の記述を可能にすることである。
さらに、親知識エントリーのエントリー属性記述を子知識エントリーが継承することで、属性記述を重複して記述する必要をなくすことである。別の領域に関しては、名前空間で分離された別の独立した知識ツリー群としての管理を可能とすることで、他領域での知識ツリーや知識エントリー名の重複を気にせずに興味ある領域の知識システムの構築に専念することが出来ることである。このような知識管理の枠組みを確立することで、機械処理が可能なのは勿論、人が見ても内容が一覧できる良好な可読性と、誰が作成しても記述の揺らぎがない知識管理システムを構築し、柔軟で高度な検索や推論を可能とする知識処理の基盤を提供することである。また、前記の知識管理システムの一部ないし全部を抽出して別の知識管理システムへ統合するといった知識管理システムの再構成を可能とすることで、知識管理システムの柔軟な運用を可能とすることである。
また、知識管理システムに対する問い合わせ、知識管理システムからの応答を可能として、現実社会での有効な活用を可能とすることである。さらにユーザーの実行権限を管理すること、検索のスコープを設定可能とすることで、破壊や混乱に対するセキュリティを確保することである。
他方、医療文書の作成においては、前記知識管理手段で定義された知識エントリーや属性記述への参照リンクを語彙として用いることで、表現の揺らぎを抑制し、以後の統計解析に耐えうる標準化された記述を可能にすることである。
また、参照リンクに判断論理を組み込むことにより、記載漏れやチェック漏れを無くし、完璧性の高い文書記載や、安全な医療指示文書の発行を可能にすることである。
さらに、知識管理手段内に効率的に蓄積された、疾患別の症状や所見の発現頻度を用いて、可能性のある疾患のリストを推定したり、疾患の鑑別を進めるために有用な検査や所見取得を推薦することで、正確で効率的な診療を可能にすることである。
前記目的を達成するための手段として、請求項1記載の医療文書管理システムでは、知識エントリーを記録する知識エントリー管理手段と、知識エントリーに関する属性記述を記録する知識エントリー属性記述管理手段を備え、知識エントリー属性記述管理手段に記述された語彙は、他の知識エントリーないし他の知識エントリーの属性記述へのリンクを有しており、医療文書の作成において、前記知識エントリー属性記述管理手段に記述された語彙を、医療文書内の参照リンクとして記述可能とする知識管理参照リンク利用手段を備えたことを特徴とする。
本願では、前記知識エントリー属性記述管理手段において、知識エントリー属性記述を、カテゴリーに分けて管理する知識エントリー属性カテゴリー管理手段を備えたことを特徴とする。
本願では、前記知識管理手段において、少なくとも一つの知識ツリーを管理する知識ツリー群管理手段と、前記知識ツリー毎に少なくとも一つ存在する知識エントリーを管理する、知識ツリー構造を前提にして拡張した知識エントリー管理手段を備え、前記各知識エントリーは、当該知識エントリーに関する属性を記述する知識エントリー属性記述と、当該知識ツリーの他の知識エントリーとの親子関係を記述する知識エントリー親子関係リンクからなり、前記知識エントリー属性記述は、異なる又は同一の知識ツリーに属する知識エントリー、または当該知識エントリーの知識エントリー属性カテゴリー、または当該知識エントリーの知識エントリー属性記述に対する参照リンクを含んでいることを特徴とする知識管理手段を備えたことを特徴とする。
本願では、前記参照リンクにおいて、当該知識エントリー属性記述に関連する外部文書ないし外部文書群、または当該文書の文書内記述に対して参照を行う外部文書参照手段を備えたことを特徴とする。
本願では、前記参照リンクにおいて、参照に際して実行すべきスクリプトを管理するスクリプト実行手段を備えたことを特徴とする。
本願では、前記参照リンクにおいて、参照の強さを設定したり、観察に応じて強さを可変とする参照強度管理手段を備えたことを特徴とする。
本願では、前記親子関係において、親知識エントリーの知識エントリー属性記述を子知識エントリーのエントリー属性記述へ継承する知識エントリー属性記述継承手段を有することを特徴とする。
本願では、前記参照リンクにおいて、語彙を参照した医療文書から、逆に、参照元の知識エントリーないし当該知識エントリーの知識エントリー属性記述に対して、症例リンクを作成する症例リンク作成手段を有することを特徴とする。
本願では、前記症例リンク作成手段において、当該症例で観察された症状/所見の各々、もしくは同時観察された症状/所見の組合せペアについて、前記観察された症状/所見の各知識エントリーに対し、前記症状/所見付きの症例リンクを作成する症状/所見別症例リンク作成手段を備えたことを特徴とする。
本願では、前記症状/所見症例リンク作成手段において、症状/所見別に症例リンクを分類集計する症状/所見別症例リンク集計手段を備えたことを特徴とする。
本願では、前記症状/所見症例リンク作成手段において、当該症例の疾患名が確定した際、同時観察された症状/所見について、当該疾患名の知識エントリーに対し、前記症状/所見別症例リンクを作成する確定疾患症状/所見症例リンク作成手段を備えたことを特徴とする。
本願では、疾患名未確定の症例において、当該症例の医療文書で観察された症状/所見、ないし症状/所見ペアの各々について、既に作成されている症例リンクの集合の積集合を求めることで、当該症例と類似した症例のリストを求める類似症例検索手段を備えたことを特徴とする。
本願では、前記類似症例検索手段において、得られた症例リストの確定疾患名を集計し、頻度順に表示する類似症例疾患名推定手段を備えたことを特徴とする。
本願では、疾患名未確定の症例において、当該症例の医療文書で観測された症状/所見に対し、前記症状/所見別症例リンク集計手段を用いて集計された疾患名別症状/所見観察頻度、または、前記観察された症状/所見の個々についての疾患名頻度分布、もしくはその両者を用いて、可能性の高い当該症例の疾患名のリストを推定する疾患名リスト推定手段を備えたことを特徴とする。
本願では、前記疾患名リスト推定手段で得られた複数の疾患名において、前記症状、所見別症例リンク集計手段を用いて集計された前記複数の疾患名の疾患名別症状、所見観測頻度を用いて、疾患名によって頻度分布の差の大きい症状、所見のリストを得て、疾患名の鑑別に有効な次に得るべき症状所見のリストを推定する診察検査推薦手段を備えたことを特徴とする。
本願では、前記診察検査推薦手段において、医療文書の作成の際、診察によって得られるべき症状、所見や、行われるべき検査の推薦リストを自動的に表示し、円滑な診察記録の作成や検査オーダーの作成を容易とする診察検査推薦表示手段を備えたことを特徴とする。
本願では、前記知識ツリー群管理手段において、複数の知識ツリー群を名前空間で分割して管理する名前空間管理手段を有することを特徴とする。
本願では、前記知識管理システムを構成する名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクの任意の部分を抽出して知識管理部分集合を作成し、別の知識管理システムにエクスポートする知識エクスポート手段を備えたことを特徴とする。
本願では、前記知識エクスポート手段で抽出された前記知識管理部分集合、或いは別個に構築された知識管理システムからの前記知識管理部分集合をインポートし、名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクを再構成する知識インポート手段を備えたことを特徴とする。
本願では、前記知識管理手段においては、名前空間、知識ツリー、知識エントリー、知識エントリー属性カテゴリー、知識エントリー属性記述、親子関係リンクの各々の作成、編集、削除、参照の機能について、前記医療作成手段においては、医療文書の作成、編集、削除、参照の機能について、ユーザーごとに前記機能の実行権限を管理するユーザー権限管理手段を備えたことを特徴とする。
本願では、前記知識管理手段において、前記知識エントリー間の親子関係や、前記知識エントリーの知識属性記述の内容を閲覧する知識閲覧手段を備えたことを特徴とする。
本願では、前記知識管理手段においては、(i)記録、管理されている知識内容についての問い合わせを受け付ける知識問い合わせ受付手段、問い合わせの内容に対して返答を行う知識問い合わせ返答手段、また、(ii)前記医療文書作成手段においては、記録、管理されている医療文書の内容についての問い合わせを受け付ける医療文書内容問い合わせ受付手段、問い合わせの内容に対して返答を行う医療文書内容問い合わせ返答手段、以上の(i)、(ii)の少なくとも一つを備えたことを特徴とする。
請求項1記載の医療文書管理システムでは、知識エントリー管理手段を備えているので、知識エントリーを単位とした情報分類システムが構築される。
知識エントリー属性記述管理手段を備えているので、各知識エントリーに属する情報が格納される。
参照リンクを含む知識管理手段を備えているので、参照リンクを介した広い情報収集システムが構築される。
知識管理参照リンク利用手段を備えているので、医療文書内容の記述語彙として、知識管理手段における参照リンクを利用可能である。
本願では、知識エントリー属性カテゴリー管理手段を備えたので、知識エントリー属性記述がカテゴリーに分けて管理される。
本願では、知識ツリー構造を前提にして拡張した知識エントリー管理手段を備えているので、知識ツリーを管理する知識ツリー群管理手段と、知識ツリー毎に少なくとも一つ存在する知識エントリーを管理する、知識ツリー構造を前提にして拡張した情報管理システムが構築される。
知識エントリー親子関係リンクを備えているので、知識エントリーに関する属性を記述する知識エントリー属性記述と、知識ツリーの他の知識エントリーとの親子関係が記述されて記録される。
知識エントリー属性記述は、異なる又は同一の知識ツリーに属する知識エントリー、または当該知識エントリーの知識エントリー属性カテゴリー、または当該知識エントリーの知識エントリー属性記述に対する参照リンクを含んでいるので、参照リンクを介した広い情報収集システムが構築される。
本願では、外部文書参照手段を備えたので、知識エントリー属性記述に関連する外部文書ないし外部文書群、または当該文書の文書内記述を参照しながら文書を作成することができる。
本願では、スクリプト実行手段を備えたので、参照リンクの種類等に応じて適切なスクリプトを選択して実行することができる。
本願では、参照強度管理手段を備えたので、参照の強さを設定したり、観察に応じて強さを可変とすることで参照リンクの優先度を管理することができる。
本願では、知識エントリー属性記述継承手段を備えたので、親知識エントリーの知識エントリー属性記述を子知識エントリーのエントリー属性記述へ継承することができる。
本願では、症例リンク作成手段を有するので、語彙を参照した医療文書から、逆に、参照元の知識エントリーないし当該知識エントリーの知識エントリー属性記述に対して、症例リンクを作成することができる。
本願では、症状/所見別症例リンク作成手段を備えたので、症例で観察された症状/所見の各々、もしくは同時観察された症状/所見の組合せペアについて、前記観察された症状/所見の各知識エントリーに対し、前記症状/所見付きの症例リンクを作成することができる。
本願では、症状/所見別症例リンク集計手段を備えたので、症状/所見別に症例リンクを分類集計することができる。
本願では、確定疾患症状/所見症例リンク作成手段を備えたので、症例の疾患名が確定した際、観察された症状/所見ないし症状/所見ペアの各々について、当該疾患名の知識エントリーに対し、前記症状/所見別症例リンクを作成することができる。
本願では、類似症例検索手段を備えたので、症例の医療文書で観察された症状/所見、ないし症状/所見ペアの各々について、既に作成されている症例リンクの集合の積集合を求めることで、当該症例と類似した症例のリストを求めることができる。
本願では、類似症例疾患名推定手段を備えたので、請求項12で得られた症例リストの確定疾患名を集計し、頻度順に表示することができる。
本願では、疾患名リスト推定手段を備えたので、症例の医療文書で観測された症状/所見に対し、前記症状/所見別症例リンク集計手段を用いて集計された疾患名別症状/所見観察頻度、または、前記観察された症状/所見の個々についての疾患名頻度分布、もしくはその両者を用いて、可能性の高い当該症例の疾患名のリストを推定することができる。
本願では、診察検査推薦手段を備えたので、症状、所見別症例リンク集計手段を用いて集計された前記複数の疾患名の疾患名別症状、所見観測頻度を用いて、疾患名によって頻度分布の差の大きい症状、所見のリストを得て、疾患名の鑑別に有効な次に得るべき症状所見の推薦リストを推定することができる。
本願では、診察検査推薦表示手段を備えたので、医療文書の作成の際、診察によって得られるべき症状、所見や、行われるべき検査の推薦リストを自動的に表示し、円滑な診察記録の作成や検査オーダーの作成を容易とする。
本願では、名前空間管理手段を有するので、複数の知識ツリー群を名前空間で分割して管理することができる。
本願では、知識エクスポート手段を備えたので、知識管理システムを構成する名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクの任意の部分を抽出して知識管理部分集合を作成し、別の知識管理システムにエクスポートすることができる。
本願では、知識インポート手段を備えたので、知識エクスポート手段で抽出された前記知識管理部分集合、或いは別個に構築された知識管理システムからの前記知識管理部分集合をインポートし、名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクを再構成することができる。
本願では、ユーザー権限管理手段を備えたので、名前空間、知識ツリー、知識エントリー、知識エントリー属性カテゴリー、知識エントリー属性記述、親子関係リンクの各々の作成、編集、削除、参照の機能について、前記医療作成手段においては、医療文書の作成、編集、削除、参照の機能について、ユーザーごとに前記機能の実行権限を管理することができる。
本願では、知識閲覧手段を備えたので、知識エントリー間の親子関係や、前記知識エントリーの知識属性記述の内容を閲覧することができる。
本願では、知識問い合わせ受付手段を備えたので、記録、管理されている知識内容についての問い合わせを受け付けることができる。
また、知識問い合わせ返答手段によって、問い合わせの内容に対して返答を行うことができる。
また、医療文書内容問い合わせ受付手段、医療文書内容問い合わせ返答手段を備えたので、記録、管理されている医療文書の内容についての問い合わせ、問い合わせの内容に対して返答を行うことができる。
本願では、検索スコープ管理手段備えたので、名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクの各々の作成、編集ユーザーを管理し、また、前記医療作成手段においては、医療文書の作成、編集ユーザーを管理し、特定のユーザーないしユーザーグループの作成した知識管理手段の部分或いは医療文書を、前記知識閲覧や知識問い合わせ受付手段、医療文書内容問い合わせ受付手段の検索対象範囲から除外する、あるいは逆に、特定のユーザーないしユーザーグループの作成した知識管理手段の部分や医療文書のみを、前記知識閲覧や知識問い合わせ受付手段、医療文書内容問い合わせ受付手段の検索対象範囲とすることができる。
最も単純な医療文書管理システムの一例を示す図である。 知識エントリー管理手段における知識エントリー管理マスターの一例を示す図である。 知識エントリー属性記述管理手段において、知識エントリー属性カテゴリーを用いて知識エントリー属性記述を行っている一例を示す図である。 知識エントリー属性カテゴリー管理手段における知識エントリー属性カテゴリーマスターの一例を示す図である。 ツリー状に構造化された知識エントリー群の例。知識ツリーを構成する知識エントリー群の一部を図示している。(a)「症状/検査所見」、(b)「疾患名」の知識ツリーの例を示す図である。 知識ツリー群管理手段としての知識ツリー群管理マスターを示す図である。 知識ツリー構造を前提にして拡張した知識エントリー管理手段における知識エントリー管理マスターの一例。第1列に、知識ツリーIDを付加している図である。 知識ツリー構造を前提に拡張した知識エントリー属性カテゴリー管理手段の一例である。第1列に、知識ツリーIDを付加している図である。 「I型糖尿病」と「II型糖尿病」の知識エントリー属性記述の内容を示している図である。 枝に当たるコンテナ型知識エントリーの一つである「糖尿病」の知識エントリーと、その葉に当たる「I型糖尿病」と「II型糖尿病」を例にとり、親子関係リンクと属性記述を図示したものである。 参照リンクの様々な実施形態を示す図である。 参照強度を有する参照リンクの一例を示す図である。 参照リンクに付随して実行されるべきスクリプトの一例を示す図である。 症例リンク作成手段の一例を示す図である。 診断名が確定した後の、症例リンクや診断名の登録処理の一例を示す図である。 症状/所見だけでなく、同時に観察された症状/所見のペアのリストも管理している一例を示す図である。 症例数、症状/所見ごとの観察頻度、疾患名の頻度などを集計したものの一例を示す図である。 名前空間管理の説明図である。 名前空間管理手段の説明図である。 知識閲覧手段の画面構成例を示す図である。
Figure 0006913308
図2は、図1に示した知識管理手段において、知識エントリーIDのマスターファイルを示す(知識エントリー管理手段)。
各知識エントリーの属性記述は、テキスト、XML、JSON、あるいはオブジェクトとして、知識エントリーIDと紐づける形で、リレーショナルデータベースやmongodb等々、任意のデータベースに記録すればよい(知識エントリー属性記述管理手段)。
知識エントリー属性記述は、量が増えてくると見通しが悪くなるので、図3に示すように、知識エントリー属性記述をカテゴリーに分けて記録、管理すると有用である。
図4は、知識エントリー属性カテゴリーのIDを管理するマスターファイルを示す。
前記知識エントリーID、図4の知識エントリー属性カテゴリーIDに紐づける形で、知識エントリー属性記述を任意のデータベースで記録管理すればよい(知識エントリー属性カテゴリー管理手段)。
図1〜4に示したように、知識エントリーが並列に羅列された単純な例でも、語彙の標準化など一定の効果はあるが、医療文書の語彙を網羅するには限界があり、図5以下に示すように、知識エントリー自体をツリー状に構造化する必要がある。
図5では、本発明の構造化された知識管理手段について、医療知識を例にとり概略を説明する。
知識ツリーとして、図5(a)「症状、検査所見」、図5(b)「疾患名」、を例示している。
他にも、「薬剤」、「処置」、「保険請求」等などの知識ツリーが考えられる。それぞれの知識ツリーは、親子関係で連結された知識エントリーの集合からなる。
図6は知識ツリー群管理手段の一例で、マスターテーブルの形式で、当該知識ツリー群内の知識ツリーIDと知識ツリー名を管理している。
図5(b)は、知識ツリーの一例として、「疾患名」知識ツリーを構成する知識エントリー群を図示している。
「疾患名」の知識エントリー群は、まず「代謝系」、「消化器系」、「運動器系」、「循環器系」などの大分類に分かれる。それぞれの大分類は、「代謝系」では「糖代謝系」、「脂質代謝系」、「アミノ酸代謝系」など中分類に分かれる。
中分類の「糖代謝系」は、さらに「糖尿病」、「糖原病」などの小分類に分かれる。小分類の「糖尿病」は、「I型糖尿病」と「II型糖尿病」を含む。
ここで、知識ツリーの末端、葉に当たる「I型糖尿病」と「II型糖尿病」などが具体的な疾患名である。それらの共通属性を括りだして枝に当たる小分類、中分類、大分類などの知識エントリー群が構成され、これらは下部の分類、葉の疾患名を収容するコンテナ型知識エントリーとして機能する。
ここでは大、中、小の分類階層としたが、領域によってはさらに深い階層としても良いし、浅い階層で十分な場合もある。ここでは病態をもとにした分類基準を用いたが、他に、「項部」、「頸部」、「上肢」などの部位別の分類の規準、「炎症系」、「腫瘍系」、「感染系」、「遺伝系」などの病因別の分類の規準もある。知識管理システムの管理者が、目的に応じて分類基準を設定すれば良い。場合によっては、分類基準を異にした知識ツリーを複数併存しても良い。
図7は知識ツリー構造を前提に拡張した知識エントリー管理手段の一例である。
マスターテーブルの形式で、当該知識ツリー群内において当該知識ツリー内(知識ツリーID=1 知識ツリー名「症状/所見」)の知識エントリーのIDを管理している。
本例では、知識エントリー名は、属する知識ツリー内ではユニークであるとしているが、場合によっては、「検査所見/理学所見/胸部/腫脹」と「検査所見/理学所見/腹部/腫脹」のように知識ツリー上の途中経路を併せて定義しても良い(経路依存知識ツリー名))。この場合は、途中経路で区別されるので、葉に当たる知識エントリー名自体は重複しても良い。また、属している知識ツリーが異なれば、図6のように定義されている知識ツリーIDで相互に区別されるため、同一の知識エントリー名も許される。
なお、本図では、知識ツリー群内の知識エントリーを、属している知識ツリーにかかわらず一元管理としているが、場合によっては、知識ツリーごとに別々にマスターテーブルを作り、知識エントリーを管理しても良い。
もし、属している知識ツリーによらず、知識ツリー群内を通してユニークな知識エントリー名とするならば、図7の第1列の知識ツリーIDは不要である。
なお、知識ツリーの親子関係の変更などの構造変化に際しては、知識エントリー名がユニークであれば変更作業は最小限で済むが、経路依存で知識エントリー名を定義している場合は経路を組み替えて知識エントリー名を再定義する必要があるので、対応が困難となる場合がある。
図8は知識ツリー構造を前提に拡張した知識エントリー属性カテゴリー管理手段の一例である。
マスターテーブルの形式で、当該知識ツリー群内において当該知識ツリー内(知識ツリーID=2知識ツリー名「疾患名」)の知識エントリー属性カテゴリーIDを管理している。
知識エントリー属性カテゴリー名は、属する知識ツリー内ではユニークである必要があるが、属している知識ツリーが異なれば、図6のように定義されている知識ツリーIDで相互に区別されるため、同一の知識エントリー属性カテゴリー名も許される。
なお、本図では、知識ツリー群内の知識エントリー属性カテゴリーを、属している知識ツリーにかかわらず一元管理としているが、場合によっては、知識ツリーごとに別々にマスターテーブルを作り、知識エントリー属性カテゴリーを管理しても良い。
もし、属している知識ツリーによらず、知識ツリー群内を通してユニークな知識エントリー属性カテゴリー名とするならば、図8の第1列の知識ツリーIDは不要である。
図9(a)、(b)は、「I型糖尿病」と「II型糖尿病」の知識エントリー属性記述の内容を示している。図5(b)の「疾患名」知識ツリーの末端の葉に当たる。両者の知識エントリー属性記述は多くの部分で共通していることがわかる。
知識エントリー属性記述の重複を避けるため、両者の上位知識エントリーである「糖尿病」を設定し、重複部分を括りだすと、知識エントリー属性記述の重複が無くなり、記憶容量の削減とともに、見通しの良さが得られる。
図10は、枝に当たるコンテナ型知識エントリーの一つである「糖尿病」の知識エントリーと、その葉に当たる「I型糖尿病」と「II型糖尿病」を例にとり、親子関係リンクと属性記述を図示したものである。
「糖尿病」は、親知識エントリーとして「代謝系」へのリンクを持ち、さらに子知識エントリーとして、「I型糖尿病」及び「II型糖尿病」へのリンクを持っている。
「糖尿病」の知識エントリー属性カテゴリーとしては、<病態>、<合併症>などがある。
<病態>としては、インシュリン分泌低下、高血糖、尿中に糖排泄などがある。
それぞれの<病態>の項目は、別の知識ツリーである「症状/所見」知識ツリーの該当する知識エントリーへの参照リンクからなっている。
このようにすることで、シソーラスのように統制語彙を用いて属性記述を行うことになり、表現のゆらぎを抑制することが出来る。
勿論ここで、従来のように直接に文字列を用いて属性記述を行っても良いが、揺らぎの抑制、また後述の参照リンクの機能の活用ができないため、好ましいとは言えない。
<合併症>として「腎不全」、「閉塞性動脈硬化症」などがある。
これらの合併症への参照リンクは、同じ「疾患名」知識ツリー内の、当該知識エントリーへの参照リンクとなる。
「I型糖尿病」の病因は膵臓のβ細胞の急速な壊死であり、従って治療はインシュリンの注射による補給しかない。
これに対して「II型糖尿病」の病因は、肥満や糖過食などによるもので、治療は食事制限、血糖降下剤の内服、最終的には、インシュリンの注射となる。
このように、「I型糖尿病」及び「II型糖尿病」は<病因>、<治療>を異にするが、その他の<病態>や<合併症>などは、両者共通で、親知識エントリーである「糖尿病」に記述されている。
葉に当たる「I型糖尿病」及び「II型糖尿病」では、<病因>や<治療>しか記述されてなくても、親知識エントリーに当たる「糖尿病」の<病態>、<合併症>の属性記述、さらにはより上部の代謝性疾患などの属性記述が継承される。
このように、共通の属性記述を、親知識エントリーに括りだすことで、子の知識エントリーは、最小限の属性記述で済むことになる。
知識エントリーの属性記述を、親子関係をたどりながら個々に見ていって頭の中で構成しても良いが、知識エントリー属性記述継承手段によって、当該知識エントリーよりも親に当たる知識エントリーの属性記述をすべて継承して図9(a)、図9(b)のように一括表示すれば、属性記述の一覧が容易となる。
知識エントリー属性カテゴリー単位で親から継承されてきた属性記述は、そのまま子知識エントリーの知識エントリー属性記述となる場合もあるが、子知識エントリーの当該知識エントリー属性カテゴリーに継承されてきた属性記述とは異なる知識エントリー属性記述が存在した場合は、子知識エントリーの当該知識エントリー属性記述が、親から継承されてきた知識エントリー属性記述に対して上書きしたり追記したりすることとなる。
この上書きないし追記された知識エントリー属性記述が、孫以下の知識エントリーに対して、さらに継承されてゆくことになる。この上書きないし追記の使い分けは、適宜知識エントリー属性記述継承手段によって設定すればよい。
図1に示したような知識エントリー属性カテゴリーを用いずに属性記述を行うこともありうるが、知識エントリー属性カテゴリーを用いることで、知識エントリー属性記述継承手段による属性カテゴリー毎の親子継承が容易に実行できる。
また、属性記述の上書き、追記が容易にできるので、より有用といえる。
なお、知識エントリー属性記述の親子継承は、親子の知識エントリー間に包含関係(この例では、「I型糖尿病」、「II型糖尿病」は、親知識エントリーである「糖尿病」に包含される)がある場合であり、書籍の目次と章立てのように単なる列挙であったり、自動車の構成部品として並列の関係にある車体と4つのタイヤなどのように、親子の知識エントリー間に内容の包含関係の無い場合は、知識エントリー属性記述の継承は行われない。
<症例>知識エントリー属性カテゴリーでは、当該疾患名を有する症例のカルテへの症例リンクが記録されている(症例リンク作成手段)。
これにより、当該疾患の患者記録を直接参照することが出来る。
症例カルテへの症例リンクとしては、医療機関ID+患者ID、患者カルテのURL、患者カルテファイルの名など、症例情報へのアクセスを可能にするものであれば、任意の形式で良い。また、<文献>などの知識エントリー属性カテゴリーを設けて、関連する書籍やファイル、ウェブ上の文書へのリンクを記載しても良い(外部文書参照手段)。
図11では、参照リンクの様々な実施形態を示している。
図11(a)は、図10で「糖尿病」の<病態>のなかの参照リンクである{高血糖}の構造を図示した例である。
ラベルで表示などの際用いられるテキストある“高血糖”と、「症状/所見」知識ツリー内の知識エントリーである「高血糖」へのリンクから構成されている。
場合によっては、図11(b)のように「高血糖」内の知識エントリー属性カテゴリーである<定義>にリンクしても良い。
ここでのリンクは「知識ツリー名/知識エントリー/(知識エントリー属性カテゴリー)」としているが、直接にリンク先のURL形式で表現しても良い。
ラベルは閲覧などに際しての表示内容である。
本例のように、リンク先の知識エントリー名をそのまま用いても良いが、見易いように、図11(c)のように“高血糖 血糖値>140mg/dl”などとしても良い。
このようにすれば、リンク先を個別に参照する工程がなくても、容易に一覧して概要を把握することが出来る。
図12では、「薬剤」知識ツリーの「フロセミド」知識エントリー内の<副作用と発生率>知識エントリー属性カテゴリーの参照リンクを示している。
第1行では、“高カリウム血症”のラベル、“5%”という参照強度、および「症状/所見」知識ツリー内の「高カリウム血症」知識エントリーへの参照リンクからなっている。
第2行は、”脱水症”のラベル、“1%”の参照強度、「症状/所見」知識ツリー内の「脱水症」知識エントリーへの参照リンクからなっている。様々な副作用があっても発生率は一様でない。
参照強度として発生頻度の情報を持つことで、考慮すべき副作用の順番が明確となる。また、この発生頻度は、ベイズ確率でいう事前確率となり、複数の薬剤投与化で副作用が発生した際に、原因薬剤を推定するベイズ推定に有用である。
さらに、前記参照強度を症例での観測頻度に応じて可変とすることで、より状況に即したベイズ推定などを行うことが可能となる(参照強度管理手段)。
図13は、疾患名知識ツリー内の「椎間板ヘルニア」知識エントリーで、<検査>知識エントリー属性カテゴリーにおいて、“MRI”のラベル、「検査」知識ツリー内の「MRI」知識エントリーへのリンクに併せて、MRI実施に際しての事前チェックを行う スクリプトのフローチャートを示したものである。このスクリプトは、「MRI」への参照リンク内に直接書いても良いが、スクリプトの記録場所へのリンクを書いても良い(スクリプト実行手段)。
このように、参照強度を含んだり、参照に当たって実行するスクリプトを管理する参照特性管理手段を有することで、ベイズ推定を行って対応に役立てたり、チェックミスをなくすことで、医療の安全性が向上する。
図14は、医療文書で使用された語彙を「症状/所見」ツリーからの参照リンクで構成する際に、参照された知識エントリー内に、当該医療文書への症例リンクを作成する症例リンク作成手段の例を示す(症状/所見別症例リンク作成手段)。
この症例リンク作成手段で蓄積された、知識エントリーごとの症例リンク群により、「発熱」などの症状/所見が認められた医療文書ないし症例の一覧を容易に得ることが出来る。ここで、発熱が認められた陽性所見を有する症例だけでなく、発熱が認められなかった陰性所見の症例に対しても<陰性症例>などの知識エントリー属性カテゴリーを設けて管理しておくと、疾患名の診断を進める上で更に有用である。
図15は、患者の疾患名が確定した後(ここでは「胃潰瘍」)の処理を示している。
先ず、「疾患名」知識ツリーの知識エントリー「胃潰瘍」の知識エントリー属性カテゴリーである<症例>に、当該患者への症例リンクを登録する。
ここでは、診断の根拠となる当該患者の個々の医療文書ではなく、患者IDを登録している。症状/所見は個々の医療文書で発生するが、疾患名は患者単位となるからである。
ここで、疾患名未定の段階での症状/所見の知識エントリー内<症例>への症例リンクの登録と、疾患名確定時点での症状/所見の知識エントリー内<症例>への症例リンクの登録とは、例えば<疾患名未確定症例>と<疾患名確定症例>などのように、区別して登録しておいた方が混乱が少ない。
当該患者で観察された症状や所見のリストの各々について、疾患名の「胃潰瘍」を知識エントリー属性カテゴリーの<疾患名>に登録する。
これにより、それぞれの症状、所見ごとに、可能性のある診断名のリストを得ることが出来る。
また、当該患者で観察された症状/所見のリストの各々について、当該症状/所見の知識エントリーの<症例>知識エントリー属性カテゴリーに症例IDを登録する。
これにより、それぞれの症状や所見が認められた症例の一覧を容易に得ることが出来る(確定疾患症状/所見別症例リンク作成手段)。
ここで、陽性所見だけでなく、陰性所見に関しても診断名のリストを登録しておけば、さらに有用である。
同様に、知識エントリー「胃潰瘍」自体にも、知識エントリー属性カテゴリー<症状/所見>に当該症例で観察された症状/所見リストを登録している。
これにより、疾患ごとに、症状/所見のリストが得られる。ここで、陽性所見だけでなく、陰性所見に関しても症状/所見のリストを登録しておけば、さらに有用である。
また、症状/所見のリストの各行に対し、観察された症例のIDも付けておけば、当該症状/所見を有する症例を容易に検索できる。
図16においては、各症例で観察された症状/所見だけでなく、同時に観察された症状/所見のペアのリストも管理している。
症状/所見は、必ずしも独立しておらず、相互に相関している場合がある。この場合、ある症状/所見が観察されると、別のある症状/所見が同時に観察、或いは、観察されないことが多い。
この場合、相関関係にある症状/所見を重ねても、得られる新たな情報は少ない。従って、診断を進めてゆく際は、相関のある症状/所見は、優先度を低めて扱う必要がある。
このような場合、観測された症状/所見の単純なリストでは、前記の鑑別を進めることが困難であり、同時観察された症状や所見のペアの集計が不可欠である。
ここで、陽性所見だけでなく、陰性所見に関しても同時観測症状/所見のリストを登録しておけば、さらに有用である。
図17は、図15や図16などで得られた症例のリスト、症状/所見のリスト、疾患名のリストなどから、症例数、症状/所見ごとの観察頻度、疾患名の頻度などを集計したものである。
図示はしていないが、同時観測された症状/所見のリストから、同時観測された症状/所見の頻度も集計される。これらの頻度の集計を用いて、逆に、診断名未知の症例で、観察された症状や所見から疾患名を推定したり、診断を確定するために次に行うべき有用な検査の推薦が可能となる。
日常の臨床現場では、過去に似たような症状/所見の患者を思い出して、診断名を類推することが多い。
しかし個人の経験する範囲では症例数に限りがあり、また記憶もあいまいなので、精度にも限界がある。
観察された症状/所見の知識エントリーには、図15に示すように、知識エントリー属性カテゴリーの<症例>に、当該所見が観察された過去の症例の症例IDのリストが管理されている。
診察を進めていて順次観察される症状/所見から、当該症状/所見を有する症例IDのリストの積集合を求めれば、その時点での症状/所見をすべて満たす症例の集合が得られる(類似症例検索手段)。
各症例の確定疾患名を集計し頻度順に並べれば、当該症例の疾患名候補のリストが得られる(類似症例疾患名推定手段)。
疾患名候補のリストを得るもう一つの方法は、図16に示した集計表を用いる方法である。
症状/所見ごとの知識エントリー属性カテゴリーである<疾患名>に当該症状/所見が観測された疾患名のリストが管理されている。
集計して得られた疾患名の頻度分布が、ベイズ確率でいう疾患名の事前確率に相当する。
新しい症状/所見が観察されるごとに、事後確率を更新してゆけばよい(疾患名リスト推定手段)。
疾患名の複数の候補が得られたならば、確定診断を得るために、次に何の症状/所見を求めれば良いかが問題となる。
図17に示すように、得られた疾患名候補ごとに、症状や所見の頻度分布が得られている。
疾患名候補間を比較して、頻度差の大きい症状/所見が診断確定に有用である。
前述のように、同時観測されやすい症状/所見は優先度を低めるとよい。当該症状/所見を得るための診察や検査を進め、得られた観察結果で、前節の事後確率を更新してゆけばよい。観察結果が得られたならば変化するであろう事後確率の大きさが、その症状/所見の診断確定への貢献度となる(診察検査推薦手段)。
この際に、同等の貢献度ならば、手間や費用が少ない方が、より実務的である。手間や費用(コスト)を数値化しておき、コストあたり最も診断確定への貢献度が高い順に表示して、診察や検査を進めてゆけばよい(診察検査推薦表示手段)。事後確率が一定水準に達したら、目的を果たしたことになる。なお、ここで得られるのは確率的な推論で会って、医師などの診断の示唆ないし補助として供されるものであり、責任を伴う診断そのものでないであることは言うまでもない。
図16では疾患名や症状/所見ごとの頻度分布を示したが、絶対数が少なく前節の処理が十分に行えない場合には、各知識エントリーの親子関係リンクを用いて、より上位である、親に当たる知識エントリーを用いればよい。当該親の知識エントリーの有する他の子知識エントリーの頻度分布も集約して合算できるからである。
このように、症状/所見、疾患名、症例などのリスト集計を通じて、疾患名の候補を得たり、疾患名を鑑別するために次に行うべき診察や検査の候補を推薦したりすることが可能となる。
なお、本発明で提供されるのは、疾患名の候補や診察や検査の推薦であり、確率的なものである。つまり、判断の責任を有する医師などに判断材料を提供するものであり、判断自体ではない。
図5で示した知識ツリー群は医療に関係したものであるが、知識を記述すべき領域は、他にも芸術や産業など等無数にある。
知識ツリー名は他の知識ツリー名と重複の無いユニークなものであることが必須であるが、関知しない他の領域で同一知識ツリー名が使われると、厄介な問題を引き起こす。
この問題を避けるため、図18のように、領域毎に名前空間を設定している。これにより、知識ツリー名は名前空間+知識ツリー名となるため、他の領域の知識ツリー名を完全に分離して考えることが出来る。
図19は、名前空間IDと名前空間名を、マスターテーブルの形式で管理している(名前空間管理手段)例である。必要に応じて、名前空間IDを、図2、図4、図6、図7、図8の1列目に付加することにより、大規模な知識の管理も混乱なく可能となる。
図20は、知識閲覧手段の一例である。
まず左から第1列の名前空間のリストから此処では「医療」を選択している。
この結果、第2列には「医療」名前空間に属する知識ツリー群の名前がリストアップされる。ここで「疾患名」知識ツリーを選択すると、先ず代謝系、循環器系などの大分類のリストが示される。
「代謝系」を選択すると、その下の中分類群である「糖代謝系」、「脂質代謝系」などのリストが示される。
「糖代謝系」を選択すると、その下の小分類である「糖尿病」、「糖原病」などがリストアップされる。
「糖尿病」を選択すると、知識エントリー属性カテゴリーである<病態>、<合併症>などが示される。
<病態>を選択すると、<病態>を構成する属性記述である“高血糖”や、“HbA1c高値”などの参照リンクが示される。
“高血糖”を選択すると、参照リンク先である「症状/所見」知識ツリー内の「高血糖」知識エントリーの属性カテゴリーである<定義>、<検査法>などが示される。
<定義>を選択すると、当該知識エントリー属性カテゴリーの内容が表示される。
図20で示したように、手作業で閲覧を進めることも有用だが、知識管理システムに検索などの問い合わせを行い、検索結果に対して集合演算や論理演算などの処理を行い、結果を表示したりファイルにダウンロードしたりすることはさらに有用である。
一連の問い合わせ手続きをスクリプト等で表記し、順に自動処理することができれば効率が良い(知識問い合わせ受付手段及び知識問い合わせ返答手段)。
同様に、医療文書に対しても、検索などの問い合わせを行い、検索結果に対して集合演算や論理演算などの処理を行い、結果を表示したりファイルにダウンロードしたりすることも有用である(医療文書内容問い合わせ受付手段、問い合わせの内容に対して返答を行う医療文書内容問い合わせ返答手段)
本発明の知識管理システムはクラウド上に構築することを想定している。しかし、会社や病院によっては、セキュリティ上の理由からウェブへの接続をしないオンプレミスの運用を行っている。
このような場合、知識管理システムを構成する名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクの任意の部分を抽出して知識管理部分集合を作成し、別の知識管理システムにエクスポートする知識エクスポート手段、さらに、前記知識エクスポート手段で抽出された前記知識管理部分集合、或いは別個に構築された知識管理システムからの前記知識管理部分集合をインポートし、名前空間、知識ツリー、知識エントリー、エントリー属性記述、親子関係リンクを自知識管理システムに統合、再構成する知識インポート手段を備えることで、クラウド上で整備された知識管理システムの一部ないし全部を、自社内部の知識管理システムに取り込むことが出来る。
また、自社内で優秀な知識管理システムが構築出来て、他に購入希望者があった際は、同様の手順で、知識管理システムの一部ないし全部を、他に移植することが出来る。
知識管理システムの扱う情報量は膨大になるため、作成には多数の人間の協力が必要である。
関与する人間の権限やスキルに応じて、名前空間、知識ツリー、知識エントリー、知識エントリー属性カテゴリー、知識エントリー属性記述、親子関係リンクの各々の作成、編集、削除、参照の機能などについて権限の設定を行うことは不可欠である(ユーザー権限管理手段)。
これにより、理解の乏しいユーザーによる知識管理システムの破損を防止することが出来る。また、ユーザーによる参照範囲を限定することによる、秘密とすべき知識の保持が可能となる。
本発明の知識管理システムをデータベースで実装するには、グラフデータベース、従来から多用されているリレーショナルデータベース(RDB)、最近ビッグデータの処理方法として注目を集めているキーバリューストア(KVS)などがある。どの実装を用いても可能であるが、それぞれの特長/欠点がある。
まずグラフデータベースは、ネットワーク状のグラフ関係を設定、表示することは得意だが、大規模処理では処理速度が速いとは言えず、大型の知識管理システムには不向きであろう。RDBでは、名前空間、知識ツリー、知識エントリー、知識エントリー属性カテゴリーなどのマスターテーブル管理下に、リレーションの各行ごとに、親子関係リンクや知識エントリー属性記述を行うことで本発明の知識管理システムを実装することが出来る。検索の自由度が高く、SQLなどの問い合わせ言語も完備されており、従前からのソフトウェア資産も多いため、RDBを用いた実装が現実的であろう。
KVSでは、1〜数項目のデータ(カラム)とキーとなるデータのセットからなる。
多種多様で自由な検索はRDBに劣る。しかし大量のデータでもMap処理、Reduce処理などといった分散処理が可能である。
図5における<症例>内の症例リストや、「症状/所見」知識ツリー内の「高血糖」の<症例>などでは、実際に電子カルテなどを運用すれば直ぐに膨大な症例リストとなる。
一属性の頻度分布は、いずれの方法を用いても容易に求められるが、「糖尿病患者で、HbA1cが10を超えて、尿たんぱくが2+以上の症例の頻度はどれくらいか?」といった、複数の要因からなる頻度を大規模症例のデータから求める際は、時にRDBの処理能力を超えてしまう。このような場合は、糖尿病患者リスト、HbA1c>10の患者リスト、尿たんぱく>2+の患者リストの間で、集合演算を行う必要がある。このような場合、KVSのMap/Reduceによる分散処理が極めて有効である。
さらに、本発明の知識管理システムでは、知識エントリーが階層構造となっているため、例えば、「発熱」の患者リストを検索したい場合、「発熱」の下部概念である「弛張熱」や「稽留熱」などの患者リストまで検索範囲を、必要に応じて拡げることが可能である。
このように、本発明の知識管理システムは、データベースの実装方式を問わないが、基本部分をRDBで、症例リストなどの処理をKVSで行うなどの組み合わせが最も有効であろう。
前記ユーザー権限管理手段で知識管理システムへのアクセスに関しユーザーごとに権限設定するが、これだけでは十分といえない。
対立する学説の信奉者同士が、互いの書き込みを否定する上書きを繰り返すといった例がみられる。
このような場合の解決策として、あるユーザーから見て、他の特定のユーザーの書き込みを検索対象から外す検索スコープ管理手段を用いれば、平和的な解決が可能である。
同じ「胸部痛」といっても、心臓疾患専門病院で発生すれば心筋梗塞の可能性が高いが、整形外科外来では肋骨骨折の可能性が高い。
このように、診療科などにより症状/所見発生頻度の事前分布は異なる場合が多い。
このような場合、似たような診療科、医療機関の形態、地域を合わせたところで検索スコープを設定すれば有用である。
以上、実施例を説明してきたが、本発明の具体的な構成は前記実施例に限定されるものではなく、発明の要旨を逸脱しない範囲の設計変更等があっても本発明に含まれる。
例えば、本申請書では医療を例にとったが、他に教育、人事など等、同様の議論が可能である。図に示した知識ツリー名、知識エントリー名、知識エントリー属性カテゴリー名などは、あくまで例示に過ぎず、実情に応じて変更してよい。
知識ツリーや知識エントリーなどの分類基準、知識エントリー属性カテゴリーの設定などは経験のある設計者が慎重に定義する必要がある。
本特許申請書の分類基準は一例に過ぎない。一旦分類基準が定義されると、以後の記述の揺らぎは最小限となる。

Claims (1)

  1. 知識エントリーを記録する知識エントリー管理手段と、
    知識エントリーに関する属性記述を記録する知識エントリー属性記述管理手段を備え、
    知識エントリー属性記述管理手段に記述された語彙は、他の知識エントリーないし他の知識エントリーの属性記述へのリンクを有しており、
    医療文書の作成において、前記知識エントリー属性記述管理手段に記述された語彙を、医療文書内の参照リンクとして記述可能とする知識管理参照リンク利用手段を備えたことを特徴とする医療文書管理システム。
JP2018127518A 2018-07-04 2018-07-04 医療文書管理システム Active JP6913308B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2018127518A JP6913308B2 (ja) 2018-07-04 2018-07-04 医療文書管理システム
PCT/JP2019/024523 WO2020008899A1 (ja) 2018-07-04 2019-06-20 医療文書管理システム
US17/140,499 US20210133608A1 (en) 2018-07-04 2021-01-04 Medical document management system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018127518A JP6913308B2 (ja) 2018-07-04 2018-07-04 医療文書管理システム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2020177056A Division JP7008939B2 (ja) 2020-10-22 2020-10-22 医療文書管理システム

Publications (2)

Publication Number Publication Date
JP2020008994A JP2020008994A (ja) 2020-01-16
JP6913308B2 true JP6913308B2 (ja) 2021-08-04

Family

ID=69060260

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018127518A Active JP6913308B2 (ja) 2018-07-04 2018-07-04 医療文書管理システム

Country Status (3)

Country Link
US (1) US20210133608A1 (ja)
JP (1) JP6913308B2 (ja)
WO (1) WO2020008899A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021205956A1 (ja) * 2020-04-06 2021-10-14 オムロン株式会社 生活機能評価システム、生活機能評価プログラム及び生活機能評価方法
CN117349425B (zh) * 2023-12-04 2024-03-22 北京仁科互动网络技术有限公司 知识条目的生成方法、装置、设备和存储介质
CN118535672B (zh) * 2024-07-26 2024-10-15 源海世纪控股(山东)有限公司 一种建设工程咨询档案资料构建方法及系统

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4431298B2 (ja) * 2001-03-02 2010-03-10 スマートインターネットソリューションズ株式会社 データベース管理システム及びプログラム
US20080040151A1 (en) * 2005-02-01 2008-02-14 Moore James F Uses of managed health care data
JP5207810B2 (ja) * 2008-04-22 2013-06-12 株式会社日立製作所 用語入力支援装置及び方法、並びにプログラム
EP2472447A4 (en) * 2009-05-18 2014-08-20 Takatoshi Yanase BASIC KNOWLEDGE SYSTEM, LOGICAL OPERATION METHOD, PROGRAM, AND STORAGE MEDIUM
US8788290B2 (en) * 2010-12-29 2014-07-22 Unival, Inc. Remote data management system with business intelligence in real-time
JP2013105401A (ja) * 2011-11-15 2013-05-30 Enegate:Kk オントロジー構築支援装置、そのプログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体
US20140344679A1 (en) * 2013-05-17 2014-11-20 Kwatros Corporation Systems and methods for creating a document
US20170169169A1 (en) * 2014-06-04 2017-06-15 Hitachi, Ltd. Medical Care Data Search System
JP2016042308A (ja) * 2014-08-18 2016-03-31 富士通株式会社 情報処理装置、情報処理方法、及び情報処理プログラム
JP6040398B2 (ja) * 2015-02-26 2016-12-07 ヴイアールアイ株式会社 情報提供装置、方法およびプログラム
JP5893791B1 (ja) * 2015-07-28 2016-03-23 株式会社医療情報技術研究所 多施設統合文書管理システム
US20170228500A1 (en) * 2016-02-09 2017-08-10 Justin Massengale Process of generating medical records
JP6928332B2 (ja) * 2019-05-26 2021-09-01 株式会社医療情報技術研究所 知識管理システム

Also Published As

Publication number Publication date
WO2020008899A1 (ja) 2020-01-09
US20210133608A1 (en) 2021-05-06
JP2020008994A (ja) 2020-01-16

Similar Documents

Publication Publication Date Title
JP6814482B2 (ja) 知識管理システム
CN110415831A (zh) 一种医疗大数据云服务分析平台
JP7083977B2 (ja) 知識管理システム
US20210133608A1 (en) Medical document management system
CN104769588B (zh) 队列识别系统
JP2021077382A5 (ja)
Khan et al. Towards development of health data warehouse: Bangladesh perspective
Rubin et al. A data warehouse for integrating radiologic and pathologic data
JP6792750B2 (ja) 診断支援システム
Zhou et al. Clinical decision support system for hypertension medication based on knowledge graph
Geifman et al. Towards an age-phenome knowledge-base
Lu et al. Emerging technologies for health data analytics research: a conceptual architecture
Leroux et al. Using CDISC ODM and the RDF Data Cube for the Semantic Enrichment of Longitudinal Clinical Trial Data.
JP6868860B2 (ja) 知識管理システム
JP7008939B2 (ja) 医療文書管理システム
Huff et al. A medical data dictionary for decision support applications
Timón et al. Extending xnat platform with an incremental semantic framework
Gupta et al. Entity resolution for maintaining electronic medical record using oyster
JP2020129385A5 (ja)
JP2021012738A5 (ja)
US10585916B1 (en) Systems and methods for improved efficiency
Bajracharya et al. Entity Event Knowledge Graph for Powerful Health Informatics
De La Calle et al. e-MIR 2: a public online inventory of medical informatics resources
Branescu et al. Solutions for medical databases optimal exploitation
Reina et al. Extending XNAT platform with an incremental semantic framework

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190311

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20190401

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20190515

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190705

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20190828

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20191031

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200204

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20200401

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200515

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20200811

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201022

C60 Trial request (containing other claim documents, opposition documents)

Free format text: JAPANESE INTERMEDIATE CODE: C60

Effective date: 20201022

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20201124

C21 Notice of transfer of a case for reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C21

Effective date: 20201127

C876 Explanation why request for accelerated appeal examination is justified

Free format text: JAPANESE INTERMEDIATE CODE: C876

Effective date: 20201202

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20201225

C211 Notice of termination of reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C211

Effective date: 20210104

C305 Report on accelerated appeal examination

Free format text: JAPANESE INTERMEDIATE CODE: C305

Effective date: 20210106

C22 Notice of designation (change) of administrative judge

Free format text: JAPANESE INTERMEDIATE CODE: C22

Effective date: 20210118

C13 Notice of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: C13

Effective date: 20210201

C302 Record of communication

Free format text: JAPANESE INTERMEDIATE CODE: C302

Effective date: 20210311

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210317

C22 Notice of designation (change) of administrative judge

Free format text: JAPANESE INTERMEDIATE CODE: C22

Effective date: 20210421

C23 Notice of termination of proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C23

Effective date: 20210506

C03 Trial/appeal decision taken

Free format text: JAPANESE INTERMEDIATE CODE: C03

Effective date: 20210614

C30A Notification sent

Free format text: JAPANESE INTERMEDIATE CODE: C3012

Effective date: 20210614

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210628

R150 Certificate of patent or registration of utility model

Ref document number: 6913308

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

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250