廣瀬 康行
東京医科歯科大学 歯科麻酔学講座 助手
歯学部附属病院
情報処理委員会 企画調整専門部会長
ここではそのような根源的な問題には一瞥を加えるにとどめつつ（日本医療情報学会シンポジウム
í97にて発表予定），プロブレムentity変遷の記述のための述語等を試考する．なお本稿は平成７年度の東京医科歯科大学における民間等との共同研究による成果の一部を基としている．
「なにか」の構造には「なにかの見かた」や「なにかの整理のしかた」が前提となっていることは，既に述べた．これは常識である．また事実と真実とのdiscrepancyや，事実と・事実から抽出する文脈ならびにその解釈とのdiscrepancyも，常識である．にも関わらずこれらは「なにか」が卑近であったり複雑長大であったりすると，意識的無意識的に看過されてしまう傾向があるようである．
MMLからAdvanced MMLへという主題の中でのプロブレム記述言語の考察なのであるから，まず既知の「パッケージ」の構造を支えている観点なり理由なりを反省したのち，新しいパッケージの構造を与えうる視座を概観する．
紙カルテの構造は，その記録媒体の制約が主原因となって，情報ソースに依存している．
つまり検査伝票は検査伝票貼付台紙へ，看護記録は看護記録用紙へ，などのごとくである．これは紙媒体を前提とした場合，実世界での単純な意味での運用からすれば，合理的であると認めるべき構造である．しかし，データや情報の相互参照性や患者病歴の文脈性という観点からすれば，絶望的な構造であろう．
となると，単に紙カルテの構造を模倣した病歴DB構造ならば，その価値の評価は限定的となろう．換言すれば，そこには文脈も論理も支える構造が無いのである．それらが見えるように感ずるのは，ヒトの思考が介在しているからに過ぎない．これを良しとするか否かは，DBの目的に依存しよう．
現版のMMLは，様々な意味で価値あるものである．通常の・したがって頻度の高い・診療情報の交換に威力を発揮するとともに，急速に充実化する通信環境を前提としつつ，分散した医療情報の統括管理を実現する手段を提供している．よって構想当時の発想は慧眼であったと言えよう．
しかしその構造は，端的に言えば，医師の「現場での処理や思考材料の見えかた」に依存していると言えよう．これは基本的には構造構築の視座を診療のsceneに置いている．有用ではあるものの思考過程に深く踏み込んだ構造であるとは言いにくいし，診療の論理を構造的に反映しているわけではない．
今後は，少なくとも様々な観点を包含しうるMMLの構造を考案していかなければならないという認識を，関係者全員が共有しているものと理解している．だからこそのAdvanced MMLへである．
POMRには，そもそも病歴記述においての思考過程を，そしてできれば診療の論理を重視したいという観点の存在していることが窺える．したがってその目標と視座については，本論の主題に最も適合している．しかしその構造はWeedの提唱をそのまま受け入れるには無理がある．というのも，個々のデータや情報の間の絡まりを記述したり表現したりすることには限界があるからである．
おそらくWeedは公的な提唱以上のことを考察したに違いないと思われるが，周知と流布とを考慮すれば，紙主体の時代には自ずと限界があったのであろう．電算処理環境への志向は，むしろそれゆえのことだったのかも知れない．
思考空間の定式化と病歴構造の在りかたについての詳細は日本医療情報学会シンポジウム
í97に，そしてその後の論文に譲るとして，ここではPOMRを写し取るための新しい病歴構造は，思考の過程や診療の論理を視座としていることのみを確認しておきたい．
プロブレムリストとは何であるか．それは主要な症状や徴候から始まって病名に至り，その解決とともに消滅していく「着眼点」の集合である．したがってその塊は，時間の推移とともに変遷していくものである．
また病歴の記述が歴である以上は，それは時間の推移に絡まりながらの状態遷移を前提としている．病歴記録の構造において論理性を求める場合，時間の軸性はプロブレムリストの列をもって担わせるのが妥当である．
他の可能性としては治療目標（ゴール）や診療計画（プラン）が挙げられる．なお診療のsceneを投影した構造に対して，時間の軸性を担わせることは適切ではないと思われる．というのも，複雑多重な内部構造と，多量のデータ粒を持たざるをえないために，sceneは軸的というよりも重畳的なイメージとなってしまう．欲しいものとは，重畳的なシートを貫く軸なのであるから．
プロブレムは診療における着眼点であるとともに，多様大量の情報が整理されたうえでの集約点でもあるという二面性を有している．プロブレムは相互干渉しつつゴールやプランの選択空間を制約するために，それぞれの優先性の考慮を主張し，その理由を求めている．またプロブレムの生成は，情報集約による概念化の過程でもある．
いづれにせよプロブレムリストの形成と変更には，別の括りとしての思考過程の部分構造が必要である．歴史的な構造を例にして言えば，POMRのプログレスノートなどがこれにあたる．さらには，知識や教科書といった塊も必要となろう．プロブレムリストに入るべきプロブレムというアイテムすなわちデータ粒は，このような思考ステップを反映するブロックから生起してくるのである．
まず時間軸の方向を考えると，プロブレム・アイテムの生成，停止，単射，収束，発散，重み付け（優先順位）の変化が挙げられる．なお単射には，アイテムが変化する場合と，変化しない場合とがある．
またアイテムが変化する場合にも，同一概念の範疇として扱える事項の詳細化，あるいは逆に退行などもあり得るであろう．なお活性化や不活性化は一般的な遷移であろう．一方，異質なアイテムへの単射もあり得るのかも知れない．これを扱うのか否か等については，共に議論したい．
次に思考過程方向を考えると，発生もしくは昇格，消滅もしくは降格，という二種類が挙げられる．昇格と降格は，プロブレムリストとプログレスノートなどとの間のアイテムの移動と捉えることができる．結局のところプロブレム変遷の記述は，プロブレムだけを独立させて行うことは，不可能とは言わないまでも，論理や文脈の連なりとその一貫性とに配慮すれば，不適切なのである．
前章を下敷きとしながらプロブレム記述言語を考察すると，プロブレム・アイテムをハンドリングする動詞が必要となることが明らかである．その際，どの集合（思考ステップを反映するブロック）からどの集合へ移したのかをも記述する必要がある．プロブレムリストも一つの思考ブロックと見なせる．
なお英語の不適切さについては御容赦いただくとともに，御助言を賜りたい．
デフォルトでは，n-1時刻のプロブレムリストから，n時刻のプロブレムリストへの遷移とする．これら以外の間において遷移を記述する可能性は，極めて少ないであろう．
動詞などについては以下に列挙する通りである．なお，目的語となるべきプロブレム・アイテムを取るものと取らないもとのがあるが，それは自明であろう．
１）生成 put
２）停止 （遷移の終了） terminated
３）一意対応 （item 無変化） progression ？
・状態無変化 ---
・不活性化 with inactivated
・活性化 with activated
４）一意対応 （item 変化） progression
・詳細化 with ？
・退行？ with ？
・異質？ with ？
５）多対１対応（収束） conversion
６）１対多対応（発散） diversion
７）重み付けまたは優先順位 with priority ##
また with は，修飾節として処理可能であると思われる事項である．
プロブレムリストと，プロブレムリスト以外の思考ステップ・ブロックなどとの間のやりとりでは，対象集合を明示的に記述する必要があろう．したがって from 〜 to 〜 節が必須となる．
ただしそれらのブロックは，同一診療サイクル内にあることをデフォルトとしても良いであろう．この場合，時制は共にn時刻である．もし時制が異なる場合には，from 〜 to 〜 節のそれぞれの目的語に対して，of 節で修飾することになる．これは例えば，n-1時刻の診療サイクル「の」思考ブロック，という意味に解釈していただきたい．
動詞については以下に列挙する通りである．
１）発生もしくは昇格 (put), promoted
２）消滅もしくは降格 (pull),
denoted
病歴のイデアが時間の軸を含んでいることと，それを写し取るための構造が軸性を持っていることとは異なる．また診療が論理性をもって為されていること・ならびに・論理性をもって記述されていることと，病歴記録の構造が論理性をもって構成されていることとは異なる．
両者を混同してしまいがちなのは，ヒトが智恵を持っているからに他ならない．加えて，考察者がその事象に対して卑近かつ日常的に接しているがためであろう．
一方，プロブレムへの指向はゴールやプランの発見のための実践的な手段であるとともに，思考の論理性ならびにその記述記録を要求するものであることを見てきた．
したがって，プロブレムの記述を精確に行うためには時間と文脈と論理とを統一的に扱う必要があり，それには病歴記録構造の全体と関わってしまうことを認識した．そして構造の設計と構築には，ある特定の視座が前提となっていることも，改めて明らかとなった．
しかし実運用上での有用性からの要求もある．病歴記録の構造に関する止揚とは何であろうか．
それは data/information repository と context とを分離した病歴記録構造にすることであろう．データや情報の実体はrepositoryの中に納めるようにして，contextは特定の見方によるスコープを提供するだけとする．そしてcontextには多様性を許容することである．
そうすれば多様なcontextの構造によって，多様な視座による文脈表現に対応できることになるのではなかろうか．この際，entityの扱いは重要である．オブジェクト化が必須か否かは不明であるが，少なくともカプセル化は有用に思える．
いづれにせよ病歴構造の記述手法は，新たな展開を待っていると言えよう．そのためにはDTD/SGMLの限界を見極めておく必要があるのかもしれない．
参考文献ならびに資料
参考文献ならびに資料