アーキテクチャ指向による仕様変更に強い医療情報モデル作りへの取組み

○友枝敦^１ , 美代賢吾^２ , 坂本憲広^３
株式会社ＳＲＡＳＩビジネス第二部オブジェクト指向グループ^１ , 東京大学医学部附属病院中央医療情報部^２ , 九州大学医学部附属病院医療情報部^３

Towards A Health Care Domain Model Robust Against Changes and Modifications of Specification

An Architecture-Oriented Approach

○Atsushi Tomoeda^１ , Kengo Miyo^２ , Norihiro Sakamoto^３

Object-Oriented Group, Software Research Associates, Inc.(tomoeda@sra.co.jp)^１ , Hospital Computer Center, University of Tokyo Hospital^２ , Division of Medical Informatics, Kyushu University Hospital^３

Abstract：Through development and maintenance, hospital information systems are always exposed to numerous requests of changes and modifications. Existing software methodologies are not flexible enough to cope with these requests. In this paper, we propose a new powerful methodology called Architecture Oriented Technique (AOT).AOT is derived from Object Oriented Modeling. In AOT, Architecture comprises Field Architecture (FA) and Task Architecture (TA). FA is a cluster of requirements in a target domain while TA is a procedure of tasks contained in the FA. The inheritance and generalization of these Architectures produce a flexible domain model, which is robust to changes and modifications. To demonstrate the potential of AOT, we applied it to a real health care domain and developed a robust domain model on pathology.

Keywords： software architecture, architecture-oriented, object-oriented, methodology, information system

１．はじめに

　経験上容易に推察されるように、ソフトウェアシステムに於ては開発当初からリリース以降の保守期間に渡り、かなりの規模の仕様変更が発生し^[Jon93]、問題となっている。また大規模なソフトウェアシステムほどその寿命が長くなる傾向にあり^[Jon93]、仕様変更の波を受け続ける可能性は高まる。
　医療分野に於ては医療行為の質と効率が直接的に患者サービスの質に影響を与え、種々の改善変更は避けることはできない。さらに今まさに医療情報の分野は医療改革の波を受け、大きな影響を受けるのは時間の問題となっている。しかしながら近視眼的硬直的な現行のシステム作りでは変更に対する迅速柔軟な対応は望むべくもない。
　一方どのような医療改革がなされたとしても、患者の病気のパターンが変わるわけではない。ましてや－若干の治療方針の変更はあるにせよ－医療改革によって医療の本質が変わるわけではない。すなわち、物ごとには変わるものと変わらないもの、あるいは変わり易いものと変り難いものとがあるものである。この事をシステム構築上適切に取扱うことができれば、種々の仕様変更の影響を最小限に留めることが出来るようになる。
　われわれは上記問題意識の元“アーキテクチャ指向”を提唱する。“アーキテクチャ指向”に基づき病理ドメインのモデル化を行ったところ、仕様変更に関しても十分な有効性があるとの感触を得たので報告する。

２．アーキテクチャ指向

　アーキテクチャ指向では、システム化の対象となる実存する問題領域であるフィールドと有意味な機能単位の問題領域であるタスクとに分けて考える。これらの問題領域自身の構造やその解の構造に関するソフトウェア・アーキテクチャ（以降“アーキテクチャ”）を基本に分析／設計を行う^[友枝95]。類似の手法としてデザインパターンがあげられる^[Gam95]が、デザインパターンは設計フェーズ以降の主にコーディングテクニックに関する部品化であり、下位部品がオブジェクトという単位からパターン，アーキテクチャに拡大されたに過ぎない。これに対しわれわれの提唱する“アーキテクチャ指向”では、より上流より目的指向の種々の問題領域のアーキテクチャを利用，継承具体化し再利用する。このような上流からの大規模部品は劇的な工数削減効果があるという報告もある^[Tra88]。　
本稿では“アーキテクチャ指向”の基本技術の中から次の２つのをとりあげる。　
（１）アーキテクチャの継承　個人病院 is-a 病院，大学病院 is-a 病院のように概念的に上下関係にあるものは、オブジェクトが継承するようにアーキテクチャを継承する。アーキテクチャの継承によって、モデルの可読性も向上する。　
（２）アーキテクチャのマッピング　前述のあまり変わることのない本質的な部分のみを記述したフィールドのアーキテクチャに対して、そこに要求される仕事／機能としてのタスクのアーキテクチャを貼付け／マッピングしていく。
　大局的視点に立ったフィールド・アーキテクチャと比較的汎用なタスク・アーキテクチャとが粗結合で関係付けられた柔軟なシステム構成であることから、仕様変更に強いシステム構築が可能になる。

３．病理フィールド

　病院フィールドの特殊型である大学病院フィールドのサブフィールド、病理フィールドを対象とする。
　病院フィールドは一般的な医療行為に関するアーキテクチャが記述され、大学病院フィールドには上記アーキテクチャの差分である特定機能病院としてのアーキテクチャ記述が付加される。病院フィールドはサブフィールドとして各診療科や各部門を有する。病理フィールドは生理検査部門フィールドの特殊型に位置づけられる。
　病理フィールドは病理検査にまつわる病理部外との関りに関するものと病理部内のものとに大別される。前者は病理検査と検査を依頼する臨床医や検査対象となる患者などとの関係である。但しこれらは検査一般に共通するものである。従ってこの部分の基本アーキテクチャは検査フィールドに記述されたものを継承し、病理フィールドでは病理検査固有の部分のみをカスタマイズする。一方後者は病理標本など病理検査に関係する各種の事物やその情報を生成利用する病理部の組織や担当の関係である。病理検査も病理学的診断にまつわるアーキテクチャをトップに、その特殊型として組織診と細胞診、さらに組織診の特殊型として生検，手術材料，術中迅速が位置づけられ、各々上位アーキテクチャを継承しその差分のみを記述する。

４．汎用タスク

　特定のタスクを遂行する上で必要なオブジェクトとそれらの構造およびそれらの間のタスク遂行上のプロトコルが記述される。対象フィールドや開発システムに対するテンポラリな要求に縛られない汎用なタスクのアーキテクチャを用いることで、他システムでも利用可能な仕様変更への許容性，利用の幅が確保できる。さらに他システムでも利用され実績のあるアーキテクチャを用いれば、新規開発に比べ品質と開発期間面での恩恵を享受することができる。以下、病理フィールドで用いる汎用タスクいくつかを提示する。
　（１）仕事遂行タスク
　病理業務を遂行するにあたり、病理部組織内固有の作業手順が存在する。この手順を一般的な仕事遂行タスクの枠組みの中で記述することで、作業手順の変更に対する影響が極力押さえられる。本タスクは、自分に関連した仕事を収集，モニタするための「トレイ」と各仕事の「作業環境」からなる。収集，モニタする仕事の種類／状態などのルールはフィールドの言葉で記述することが可能となる。フィールドとのマッピングは主にルール記述を通して行われる。なおオーダリングもこのタスクで記述される。
　（２）セキュリティタスク
　個々の病理業務に関係する情報毎にセキュリティルールを設定することが望まれる。本タスクはアクセスした人物やシステムを表す「ユーザ」とセキュリティ対象である「データ」そしてその「オーナ」から構成される。ルールは仕事遂行タスク同様フィールドの言葉で記述することができる。例えば病理所見に関しては、“一般に、病理部の医師と検査を申し込んだ医師および検査依頼課の患者主治医とその指導医は参照可。特例として、検査依頼課以外の患者主治医は条件付きで参照可”などの設定が可能。また病理所見ではあっても特殊な事例などの任意の所見に関しては個別にセキュリティルールを設定することもできる。なお各々の情報は不正なアクセス改竄を防ぎつつ、緊急時のイレギュラなアクセスにも対応するために、セキュリティルールは“通常”“特例”の２段階を設定する。通常を越えて特例で情報にアクセスした場合、その旨をその情報のオーナへ自動的に通知するなどの特例アクセス時処理も設定することができる。フィールドとのマッピングは主に「データ」およびルールを通してなされる。

５．専用タスク

　当然ながら今回の対象である病理フィールド固有のタスクも存在する。全く同じフィールドではアーキテクチャの再利用は可能であるが、一般的にはこのタスクは個々に開発しなければならない。但し、専用タスクが汎用タスクの特殊系であったり、専用タスクの中に汎用タスクを内包している場合もある。この場合はある程度の再利用が可能である。病理フィールドで用いる専用タスクを簡単に紹介する。
　（１）病理診断タスク
　その中に病理標本作成などのサブタスクを含む。
　（２）患者情報参照タスク
　これは他の部門でも用いるものである。病理診断を行う際、参考情報としてアクセス参照される。
　（３）その他
　病院フィールドはタスクとして、医事会計，オーダリングその他さまざまなものを内包している。各々汎用タスクである会計タスク，仕事遂行タスクの特殊型として記述される。

６．おわりに

　本稿では、近視眼的硬直的な現行のシステム作りから脱却し、大局的視点に立った比較的汎用な仕事を元にシステムを構成する手法として“アーキテクチャ指向”を提案し、仕様変更に強いシステム作りの可能性を示した。現在は病院フィールド，病理フィールドおよび仕事遂行タスク，セキュリティタスクのモデル化がほぼ終了し、仕事遂行タスクの設計に入っているところである。今後も“アーキテクチャ指向”に則ったシステム構築を進め、“アーキテクチャ指向”の現実的で詳細な評価検討を通じ、実用的な医療情報システム作りに貢献できればと願っている。
　将来的に“アーキテクチャ指向”に基づき医療関連のフィールドやタスクのアーキテクチャが準備，整備されれば、個々の要求／事情に合せてアーキテクチャを具体化特殊化しつつタスクのアーキテクチャをフィールドのアーキテクチャに割当てる仕事が、システム設計の主な仕事となるかもしれない。また同じアーキテクチャからの派生で作られたシステムは、互いに均質でデータ交換も比較的容易になるであろう。さらには上流の要求分析，仕様策定に対してもフィードフォワードがかけられるようになると期待される

図表

参考文献

[Gam95] Gamma,E.,Helm,R.,Johnson,R.,Vlissides,J.：Design Patterns：Addison-Wesley Publishing Company、1995.
[Jon93] Jones,C., 鶴保, 富野監訳：ソフトウェア開発の定量的手法：共立出版、1993.
[Tra88] Tracz,W.：RMISE workshop on software reuse meeting summary, in tutorial:Software reuse:emerging technology：IEEE Computer Society Press、pp.41-53，1988.
[友枝95] 友枝：オブジェクト指向パターンの合成・適用に関する考察：情処シンポジウム論文集、Vol.95，No.3，pp.229-236，1995

Microsoft Access TO HTML Converter.Medical Informatics,Shimane medical UNIV.