JP2001014416A - 病理情報システム及びデータ取得方法 - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 カスタマイズ性及び保守性を向上した病理検
査に関する情報を取り扱う病理情報システムパッケージ
を得る。 【解決手段】 病理情報システムは、業務を表示するア
プリケーション層、その業務の基本データの表示及び設
定を定型化しプロパティを参照し登録するコンポーネン
ト層、このコンポーネント層とデータ交換を行うデータ
取得オブジェクトを上記業務に対応したクラスごとに設
けデータベースとのデータ交換を行うデータ層からな
り、複数のデータベーステーブルが階層別に結合された
階層構造をなし、各データベーステーブルは基本部であ
る基本属性クラスと拡張部である拡張クラスとから構成
されている。さらに、上記階層別に結合されたデータベ
ーステーブルは階層順に上位から検査情報、検査別情
報、材料情報、診断情報、診断履歴情報から構成されて
いる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、病院システムの
中の病理検査に関する情報を取り扱う病理情報システム
パッケージの改良に関するものである。

【０００２】

【従来の技術】一般に、病院システムは一般的な臨床、
血液等の検査、癌の検査診断を行う病理の３段階に分か
れるが、中でも病理はその業務の性格から、各病院毎の
運用はほとんど同じであるが、管理項目が病院毎に違う
ことが多く、パッケージの横展開がしにくい。医療情報
処理システムの一例として、特開平９−２３１２７２号
公報に記載されたシステムがある。このシステムは、日
別データをデータとして持ち、日付をキーに各種日付処
理を行うことに特徴を有するものであるが、医療情報に
関しては、医療情報オブジェクトが医療情報ファイルか
らデータを読込み、データ処理部で処理することが記載
されている。しかしながら、管理項目が増加した場合に
ついては記載されておらず、おそらく、オブジェクト及
びデータベースを構築し直す必要が発生するものと思わ
れる。

【０００３】

【発明が解決しようとする課題】上記のような従来の医
療情報システムでは、データと手続きとを一まとめにし
たオブジェクトという単位のソフトウェア部品から構成
されているが、管理項目が増加した場合には、オブジェ
クト及びデータベースを再構築する必要があり、特にパ
ッケージソフトウェアの場合には使用者側でのカスタマ
イズに負担がかかるという問題点があった。この発明
は、上述のような課題を解決するためになされたもの
で、病理情報システムパッケージのカスタマイズ性及び
保守性を向上するためのものである。

【０００４】

【課題を解決するための手段】この発明に係る病理情報
システムは、業務を表示するアプリケーション層、その
業務の基本データの表示及び設定を定型化しプロパティ
を参照し登録するコンポーネント層、このコンポーネン
ト層とデータ交換を行うデータ取得オブジェクトを上記
業務に対応したクラスごとに設けデータベースとのデー
タ交換を行うデータ層からなるものである。また、上記
データベースは複数のデータベーステーブルが階層別に
結合された階層構造をなし、各データベーステーブルは
基本部と拡張部とから構成されているものである。さら
に、上記コンポーネント層において、プロパティをデー
タベーステーブルとして保持するものである。さらにま
た、上記データベーステーブルは表示項目、表示順序、
表示形式からなるものである。また、上記データベース
はクラス別に異なるデータベーステーブルから構成され
ているものである。さらに、上記階層別に結合されたデ
ータベーステーブルは階層順に上位から検査情報、検査
別情報、材料情報、診断情報、診断履歴情報から構成さ
れているものである。この発明に係るデータ取得方法
は、コンポーネントにより検体番号を指定するステッ
プ、その検体番号に基づきデータ取得オブジェクトによ
りＳＱＬを発行するステップ、データベースからデータ
を取得するステップ、得られたデータをデータ取得オブ
ジェクトにおいて保持するステップからなるものであ
る。

【０００５】

【発明の実施の形態】実施の形態１．図１は病理情報シ
ステムの一実施の形態における基本的なデータ構造を示
すもので、１はリレーショナルデータベースとしてのデ
ータベースで、複数のデータベーステーブルが階層別に
結合された階層構造をなし、各データベーステーブルは
基本部である基本属性クラスと拡張部である拡張クラス
とから構成されている。この拡張クラスはユーザのカス
タマイズ反映時に利用されるものである。階層別に結合
されたデータベーステーブルは階層順に上位から検査情
報２、検査別情報３、材料情報４、診断情報５、診断履
歴情報６から構成されている。検査情報２はクラス番号
（１）の検査クラスのデータベーステーブルからなり、
以下の下位層に結合された各データベーステーブルの検
体番号を一意のキーとして検索することができる。各ク
ラス名の括弧内の数字はクラス番号を示している。検査
別情報３においては、各検査の情報を業務の実態に合わ
せて、組織、細胞、剖検に分離されている。細胞診検査
クラス（３）は唾液、腹水等の体液を採取する検査であ
り、その体液の中に異常な細胞が含まれていないか検査
する。もし異常な細胞が含まれている場合には、組織診
検査クラス（２）において、身体の組織（肉片）を採取
し癌細胞であるか否かを検査する。剖検検査クラス
（４）は死後の解剖の検査を意味しており、死亡の原因
を探ることが主たる目的である。検査別情報３を３つの
クラスにまとめたことにより、業務レベルのデータ細分
化によるデータベースの肥大化を防止することができ
る。同様に各結果情報も組織、細胞、剖検に分離し、そ
の結果情報はデータベースの検索効率を考慮し、最終報
告とその他履歴を分離し、診断情報５と診断履歴情報６
に分割されている。複数の医師による診断結果を総合的
に判断して最終診断がなされることになる。臨床医に報
告の後、再度検査が行われることもあり、その診断結果
も診断履歴情報６に格納される。材料情報４の検査材料
クラス（８）は、材料コードによる一意キーにせず、検
査材料番号をキーにすることで同一検査材料を登録可能
にしている。病院の運用により変動しにくいデータ設計
とするためである。図２は、実施の形態１における全体
の制御を司る処理プログラムの構成図である。図におい
て１１は処理プログラムで、その全体はアプリケーショ
ン層１２、コンポーネント層１３、データ層１４の３つ
の層から構成されている。アプリケーション層１２は業
務を部品として表示しているもので、テキスト及びラベ
ルの集合体を入力部品として、ラベルの集合体を表示用
の部品としてそれぞれＧＵＩとして画面上に表示してい
る。コンポーネント層１３はアプリケーション層１２で
表示されている各業務の部品としてのコンポーネント１
５の集まりであり、そのコンポーネント１５の基本デー
タの表示及び設定をオブジェクトとして定型化しデータ
層１４で保持されているプロパティを参照し登録する。
１６はデータを取得するためのデータ取得オブジェクト
としての取得ルーチンである。各クラスごとに生成され
ており、データベース１からデータを取得し、コンポー
ネント層１３の各部品にデータを渡す役目をしている。
この様に、データの取得に分散可能なオブジェクトを利
用することにより、負荷分散を図ることができ、システ
ムの規模に柔軟に対応可能な病理情報システムとするこ
とができる。

【０００６】図３は利用者が新たに追加したい管理項目
を拡張情報として入力する場合の一例を示しており、利
用者の要求として、検査クラス（１）において検体の情
報として勤務時間外に検査する検査項目を管理したいこ
とと、組織診検査クラス（２）において、臓器を保存す
る臓器瓶数を管理したいとの２つの要求があったと仮定
する。前者の場合には、クラス番号１の項目番号１、拡
張項目名「時間外」、拡張タイプはフラグとして拡張項
目入力用のデータベーステーブル２１に入力する。同様
に、後者の場合にはクラス番号２の項目番号１、拡張項
目名「臓器瓶数」、拡張タイプは数値としてデータベー
ステーブル２１に入力する。

【０００７】データベーステーブル２１に入力された拡
張情報は、それぞれの該当するクラスのデータベーステ
ーブルの拡張クラスに格納され、データの取得及びデー
タの表示については、基本属性クラスに格納されたデー
タと同様に処理することができる。

【０００８】図４は、実施の形態１におけるシステムを
実現するための機器構成の一例を示したもので、各コン
ポーネント１５と取得ルーチン１６との間の通信には、
共通オブジェクト間通信インターフェースを採用してい
るため、取得ルーチンをクライアント側又はサーバ側の
いずれに設けることも可能であり、これにより柔軟なシ
ステム構成が容易に実現可能になつている。

【０００９】図において２５は最小構成であり、サーバ
及びクライアントを同一マシン上で動かすスタンドアロ
ーンシステムである。２６は小規模構成であり、サーバ
にある程度のパワーのある機種を採用し、クライアント
にはそれほどはパワーのない機種を数台採用する。この
小規模構成によると、サーバ側でデータベース１の処理
を行うため、クライアント側の資源消費が少なくて済む
利点がある。２７は中規模構成であり、一部のパワーの
あるクライアントではデータベースの処理を行いサーバ
の負荷の軽減を図る。非力なクライアントは、あまりデ
ータベース１に負荷がかからない業務に使用する。２８
は大規模構成であり、各クライアントがデータベースの
処理を行い、サーバはデータベース１の登録、検索処理
に専念する。

【００１０】図５はデータベース１上に格納されている
検査基本情報を利用する場合の処理の動作を示すもの
で、コンポーネント１５から検索キーとなる検体番号を
指定する。データ取得オブジェクトであるデータ取得ル
ーチン１６はその検体番号を基にＳＱＬを発行しＳＱＬ
はデータベース１を検索し求めるデータを取得する。得
られたデータはデータ取得ルーチン１６上でプロパティ
として保持される。コンポーネント１５はデータ取得ル
ーチン１６上のプロパティ情報を参照し表示項目に対応
するデータを画面上に表示する。また、他のプログラム
が検査基本情報を利用するときは、データベース１を参
照することなく、データ取得ルーチン１６上のプロパテ
ィ情報を参照することにより求めるデータが迅速に得ら
れることになる。図６はデータ取得の処理の流れを記述
したフローチャートであり、アプリケーションとしての
ユーザプログラムとコンポーネント１５とデータ取得オ
ブジェクト１６に分け、それら相互の関係を示してい
る。先ず、ユーザプログラムにて表示するコンポーネン
ト１５を生成する（ステップＳ１）。生成されたコンポ
ーネント１５では、画面を生成し（ステップＳ２）、初
期表示値が指定されているかチェックする（ステップＳ
３）。初期表示値が指定されている場合にはデータ取得
オブジェクト１６を生成する（ステップＳ４）。生成さ
れたデータ取得オブジェクト１６では、データ取得のた
めのＳＱＬを生成し（ステップＳ５）、データベース１
からデータを取得する（ステップＳ６）。データ取得の
終了前（ステップＳ７）では、取得データをプロパティ
として保存する（ステップＳ８）。一方、コンポーネン
ト１５では、表示項目として指定されているプロパティ
情報をデータ取得オブジェクト１６において参照し（ス
テップＳ９）、データ取得オブジェクト１６では指定さ
れたプロパティ情報をコンポーネント１５に返し（ステ
ップＳ１０）、コンポーネント１５ではそのプロパティ
情報を取得し画面に表示する（ステップＳ９）。

【００１１】上記のように、ユーザプログラムは表示す
るコンポーネントを生成する役割のみを担当するので、
拡張クラスにより新たに表示項目が追加になったとして
も、コンポーネント１５において処理することにより追
加の処理がなされるので、ユーザプログラムを修正する
必要がなく、ユーザの利用形態に合わせるカスタマイズ
が容易に達成される。カスタマイズ性と同時に保守性も
向上することは明らかである。図７は画面に表示するコ
ンポーネントのプロパティをデータベーステーブルとし
て保持する一例を示している。データベーステーブルを
修正することにより、表示の形式、表示順を変更するこ
とができる。例えば、図の上側のデータベーステーブル
３５において、表示項目名の患者番号が表示形式で連続
番号であるのを、図の下側のデータベース３６で表示項
目名を患者ＩＤと修正し、表示形式をハイフンの混入し
た形式に修正すると、図の上側左の表示するコンポーネ
ント３７は図下側のコンポーネント３８の様に変更され
る。同様にして、項目名の採取日の表示を取りやめ新た
に提出医名を表示するように変更することも可能であ
る。この様に、コンポーネント層１３の表示形式、表示
順序、表示項目などのプロパティを設定することによ
り、データベース１上のどの項目をどのように表示する
かを容易に調整することが可能になる。

【００１２】図８は図７のコンポーネントを画面上に表
示する場合の処理フローである。先ず，コンポーネント
としてのコントロールが設定したデータベーステーブル
の存在をチェックする（ステップＳ１１）。データベー
ステーブル上のデータを優先させるためである。存在し
ない場合はコンポーネントとしてのコントロールが保持
するプロパティを取得する（ステップＳ１２）。データ
ベーステーブルが存在する場合には、データ取得ルーチ
ン１６をコールする（ステップＳ１３）。表示順を取得
しデータベース１から取り出す項目を確認する（ステッ
プＳ１４）。データ取得ルーチン１６をコールする（ス
テップＳ１５）。取得した項目をソートする（ステップ
Ｓ１６）。次に、表示形式に従ってデータを整形し（ス
テップＳ１７）、画面へ表示する（ステップＳ１８）。

【００１３】図９は画面に表示するコンポーネントの配
置を自由に変更可能なことを示している。図ではデータ
を入力するためのコンポーネントの配置を示している
が、検査材料属性入力コンポーネント４１は検査材料属
性入力コンポーネント４２のように表示の形状を変更す
る必要があるが、この場合は別途のカスタマイズが必要
になる。図１０は実施の形態１における処理プログラム
の流れの一例を示すもので、４５は患者情報参照画面
で、患者情報を表示するコンポーネントが生成される
と、画面上に「患者名（カナ）」「患者名（漢字）」
「生年月日」「性別」が連続する行として表示される。
次に、患者属性取得オブジェクトが生成されるが、生成
のみでデータベース１へのアクセスは行わない。次に、
患者番号を指定し、決定ボタンを押すと、患者の情報が
表示され４６に示す患者情報参照画面になる。先ず、患
者情報表示コンポーネントが患者属性取得オブジェクト
に対し、患者番号「１２３４５６７８」のデータを取得
するように指示する。ここで処理プログラムはデータ取
得完了通知を受け取るまで待つ。次に、患者属性取得オ
ブジェクトの患者名（カナ）のプロパティを参照し、画
面に表示する。同様にして、患者名（漢字）、生年月
日、性別を画面に表示する。次に、既往歴表示ボタンを
押すと４７に示す既往歴表示画面が表示され、画面上に
既往歴が表示される。ここでは、患者属性オブジェクト
の既往歴のプロパティを取得し画面表示しているもので
ある。次に、リストを指定し、診断参照ボタンを押す
と、４８に示す診断参照画面が表示され、診断情報が表
示される。先ず、患者情報を表示するコンポーネントを
表示するが、内容は最初に取得した患者情報をそのまま
利用する。次に診断情報を表示するコンポーネントを生
成する。次に検体番号Ｐ９９−００００１を指定して診
断情報取得オブジェクトを生成する。ここで、データ取
得完了まで待機する。次に診断情報取得オブジェクトの
診断のプロパティを参照し「悪性腫瘍」を画面に表示す
る。次に診断情報取得オブジェクトの所見のプロパティ
を参照し、「数多くの転移が見られます」を画面に表示
する。

【００１４】

【発明の効果】この発明は以上述べたように構成されて
いるので、以下に述べる効果を奏する。業務を表示する
アプリケーション層、その業務の基本データの表示及び
設定を定型化するコンポーネント層、このコンポーネン
ト層とデータ交換を行うデータ層からなる３階層に構成
したので、病理情報システムパッケージのカスタマイズ
性及び保守性が向上する効果がある。また、複数のデー
タベーステーブルが階層別に結合された階層構造をな
し、各データベーステーブルは基本部と拡張部とから構
成されているので、病理情報システムパッケージのカス
タマイズ性及び保守性が向上する効果がある。さらに、
コンポーネント層において、プロパティをデータベース
テーブルとして保持するように構成したので、プロパテ
ィを画面上に表示するカスタマイズ性が向上する効果が
ある。また、データベーステーブルは表示項目、表示順
序、表示形式からなるように構成したので、プロパティ
を画面上に表示するカスタマイズ性が向上する効果があ
る。さらにまた、データベースはクラス別に異なるデー
タベーステーブルからなるように構成したので、病理情
報システムパッケージのカスタマイズ性及び保守性が向
上する効果がある。また、階層別に結合されたデータベ
ーステーブルは階層順に上位から検査情報、検査別情
報、材料情報、診断情報、診断履歴情報からなるように
構成したので、病理情報システムパッケージのカスタマ
イズ性及び保守性が向上する効果がある。さらに、コン
ポーネントにより検体番号を指定するステップ、その検
体番号に基づきデータ取得オブジェクトによりＳＱＬを
発行するステップ、データベースからデータを取得する
ステップ、得られたデータをデータ取得オブジェクトに
おいて保持するステップからなるように構成したので、
迅速にデータを取得できデータベースを効率的に利用で
きる効果がある。

【図面の簡単な説明】

【図１】 この発明の実施の形態１を示す基本的なデ
ータ構造のプロック図である。

【図２】 この発明の実施の形態１を示す全体の制御
を司る処理プログラムの構成図である。

【図３】 この発明の実施の形態１を示す管理項目を
拡張情報として入力する場合の入力画面の模式図であ
る。

【図４】 この発明の実施の形態１を示す機器構成の
システム構成図である。

【図５】 この発明の実施の形態１を示す検査基本情
報を利用する場合の処理動作を示すブロック図である。

【図６】 この発明の実施の形態１を示すデータ取得
の処理の流れを記述したフローチャートである。

【図７】 この発明の実施の形態１を示すコンポーネ
ントのプロパティをデータベーステーブルとして保持す
る状態を示すブロック図である。

【図８】 この発明の実施の形態１を示すコンポーネ
ントを画面上に表示する場合の処理フローである。

【図９】 この発明の実施の形態１を示すコンポーネ
ントの配置を自由に変更可能なことを示す模式図であ
る。

【図１０】 この発明の実施の形態１を示す処理プロ
グラムの流れの一例を示すブロック図である。

【符号の説明】

１ データベース ２ 検査情報 ３ 検査別情報 ４ 材料情報 ５ 診断情報 ６ 診断履歴情報 １２ アプリケーション層 １３ コンポーネント層 １４ データ層 １５ コンポーネント １６ データ取得オブジェクト（取得ルーチン）

Claims (7)

【特許請求の範囲】
1. 【請求項１】 業務を表示するアプリケーション層、そ
   の業務の基本データの表示及び設定を定型化しプロパテ
   ィを参照し登録するコンポーネント層、このコンポーネ
   ント層とデータ交換を行うデータ取得オブジェクトを上
   記業務に対応したクラスごとに設けデータベースとのデ
   ータ交換を行うデータ層からなることを特徴とする病理
   情報システム。
2. 【請求項２】 上記データベースは複数のデータベース
   テーブルが階層別に結合された階層構造をなし、各デー
   タベーステーブルは基本部と拡張部とから構成されてい
   ることを特徴とする請求項１記載の病理情報システム。
3. 【請求項３】 上記コンポーネント層において、プロパ
   ティをデータベーステーブルとして保持することを特徴
   とする請求項１記載の病理情報システム。
4. 【請求項４】 上記データベーステーブルは表示項目、
   表示順序、表示形式からなることを特徴とする請求項３
   記載の病理情報システム。
5. 【請求項５】 上記データベースはクラス別に異なるデ
   ータベーステーブルから構成されていることを特徴とす
   る請求項２記載の病理情報システム。
6. 【請求項６】 上記階層別に結合されたデータベーステ
   ーブルは階層順に上位から検査情報、検査別情報、材料
   情報、診断情報、診断履歴情報から構成されていること
   を特徴とする請求項２記載の病理情報システム。
7. 【請求項７】 コンポーネントにより検体番号を指定す
   るステップ、その検体番号に基づきデータ取得オブジェ
   クトによりＳＱＬを発行するステップ、データベースか
   らデータを取得するステップ、得られたデータをデータ
   取得オブジェクトにおいて保持するステップからなるこ
   とを特徴とするデータ取得方法。