JPH03177967A - データ処理方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 ［産業上の利用分野］ 本発明は、−殻内にはデータ処理システムおよび処理に
関し、かつ、特定的には、種々のデフォールト（ｄｅｆ
ａｕｌｔ）　、エディツト（ｅｄｉｔ）、計算（ｃａｔ
ｃｕｌａｔｉｏｎ）およびリスト（ｌ　ｉ　ｓ　ｔ）手
順（ｐｒｏｃｅｄｕｒｅｓ）がデータがあるフオームの
１つまたはそれ以上のフィールドにエツタされるに応じ
てイネーブルされ得るデータ処理システムに関する。

本発明は本発明の譲り受は人に譲渡された以下の発明、
即ち米国特許第４．８７８．１７５号、「パラメータを
付加／削除することにより患者に特定的なフローシート
を発生する方法」、に関連している。

［従来の技術および発明が解決しようとする課題］本発
明は、種々のルーチン手順がユーザ入力に応じて呼出さ
れるデータ処理システムにおいて有用性がある。ユーザ
入力は１つまたはそれ以上の「属性（ａｔｔｒｉｂｕｔ
ｅｓ）Ｊ　、即ちデータオブジェクト（即ち、データベ
ースにおけるデータフィールド）における有用なデータ
の最も小さいものの形をとることができる。ここに付属
書類Ａとして添付した用語集を参照。

伝統的には、ライブラリィは（ここで以後ＤＥＣＬと言
及される、デフォールト、エディツト、計算、およびリ
ストのような）ルーチン手順に対して構築される。各機
能は１つの特定の属性を処理するために書かれている。

すべてのアプリケーションはそれらが用いる属性に対し
適切な機能を呼ばなければならない。ライブラリィの機
能が変えられ、加えられ、あるいは削除される時、その
機能を用いるすべてのアプリケーション（即ち、該機能
が関連する属性）は正しく修正され、再コンパイルされ
、かつ再テストされなければならない。

本発明を用いることにより、ルーチンの機能は属性と関
連しかつ自動的に別個の処理によって呼出される。アプ
リケーションは決してそれらを取扱わない。またルーチ
ンの機能は１つより多くの属性または属性タイプに関連
することができ、それによりそれらが再利用され得る。

その結果、ルーチンタスクの責任はアプリケーションか
ら除去される。エラー、メンテナンス時間、実施時間、
および設計時間の対応する低減がある。また、複雑性の
低減もあるが、これはＤＥＣＬは再使用可能であり（ｉ
つより多くの属性と共に使用でき）、従って同じ数は必
要でないからである。ノード、またはプログラムパーツ
のライブラリィ、はアプリケーションが構築されるに応
じて組立てられる。さらに、コードはより読取りやすく
かつ理解しやすい。

システムにおけるＤＥＣＬの手順の数を低減することに
より、メンテナンス可能性が増強され、かつアプリケー
ションの実施がスピードアップされる。新しいＤＥＣＬ
の手順を書く変わりに、アプリケーション設計者は現存
するものを再使用できる。これはプログラマ−の生産性
を高めるが、それはアプリケーションのプログラマ−は
彼または彼女が知る必要のない詳細事項から隔離される
からである。

さらに、本発明は異なる顧客の導入に対しシステムをカ
スタム化しかつ構成する能力を増強する。

特定の目的を達成するため組合わされた別個のかつ独立
な処理の集合の形で（例えば、フィルタおよびパイプ）
ＵＮＩＸシェルスクリプトを利用することが知られてい
る。しかしながら、ＵＮＩＸシェルスクリプトは本発明
により開示された方法とかなり異なっている。ＵＮＩＸ
はインタフェースのラインごとの（ｌｉｎｅ−ｂ７−ｌ
ｉｎｅ）スタイルに向けられておりこの場合制御スレッ
ドはマウス駆動されるインタフェースを供えたユーザに
よるよりはむしろプログラムによって制御される。また
、ＵＮＩＸはフィールド指向ではなくむしろデータの流
れ（ｓｔｒｅａｍ）に向けられている。

またルーチン手順を関係するコードの部分としてフオー
ムの定義における属性に関連付けることが知られている
。しかしながら、そのようなルーチン手順は属性に緊密
に結合されている。それらは本発明に関してここで述べ
る意味における再利用可能なものではない。

またルーチン手順をＳＱＬのような標準関係データベー
スにおけるテーブルのフオームにおける属性と関連付け
ることが知られている。しかしながら、そのようなルー
チン手順もまた属性と緊密に結合されておりかつ再利用
可能なものではない。

（デフォールト、エディツト、計算、およびリストのよ
うな）ルーチン手順はテーブルを介して属性と関連して
おり、かつイベントに応じてアプリケーションズ・マネ
ージャ処理により実行される。ルーチン手順のすべては
アプリケーションにとって透明である。アプリケーショ
ンはそれらが存在することを知る必要はない。

また、ルーチン手順はそれらが１つより多くの属性また
はある特定のタイプの任意の属性を処理できるように書
くことが可能であり、従って必要な手順の数を低減する
。

本発明はデータエントリイに対し自動的に処理を行なう
、即ち処理が「データ駆動される（ｄａＨｄｒｉｖｅｎ
）　Ｊ任意のシステムにおいて使用可能である。

従って、本発明の目的は、アプリケーションからルーチ
ン手順に対する責任を除去するソフトウェア・アーキテ
クチャを提供することにある。

本発明の他の目的は、ルーチンエディツト手順がテーブ
ルを介して属性と関連付けられておりかつイベントに応
じてアプリケーションズ・マネージャ処理により実行さ
れるソフトウェア・アーキテクチャを提供することにあ
る。

本発明の他の目的は、ルーチン手順がテーブルを介して
属性タイプと関連しておりかつイベントに応じてアプリ
ケーションズ・マネージャ処理により実行されるソフト
ウェア・アーキテクチャを提供することにある。

本発明の他の目的は、エディツト手順がテーブルを介し
て属性と関連しておりかつイベントに応じて所定の優先
度でアプリケーションズ・マネージャ処理によりは実行
されるソフトウェア・アーキテクチャを提供することに
ある。

本発明のさらに他の目的は、ルーチンデフォールト手順
が属性タイプと関連され得るソフトウェア・アーキテク
チャを提供することにある。

本発明の他の目的は、ルーチン計算手順がテーブルを介
して属性と関連しておりかつイベントに応じてアプリケ
ーションズ・マネージャ処理により実行されるソフトウ
ェア・アーキテクチャを提供することにある。

本発明の他の目的は、ルーチンリスト手順がテーブルを
介して属性と関連しておりかつイベントに応じてアプリ
ケーションズ・マネージャ処理により実行されるソフト
ウェア・アーキテクチャを提供することにある。

本発明のさらに他の目的は、ルーチンリスト手順が属性
タイプと関連され得るソフトウェア・アーキテクチャを
提供することにある。

本発明の他の目的は、ルーチンクロスフィールド（ｃ＋
ｏｓｓ−［１ｅｌｄｌ　エディツト手順がテーブルを介
して属性と関連しておりかつイベントに応じてアプリケ
ーションズ・マネージャ処理により実行されるソフトウ
ェア・アーキテクチャを提供することにある。

本発明の他の目的は、ルーチンデフォールト、エディツ
ト、計算、およびリスト手順がテーブルを介して属性と
関連しておりかつイベントに応じて所定の優先度でアプ
リケーションズ・マネージャ処理により実行されるソフ
トウェア・アーキテクチャを提供することにある。

［課題を解決するための手段および作用」これらおよび
他の目的は本発明の好ましい実施例に従って１つまたは
それ以上のエディツト手順によりデータが入力されかつ
有効化されるデータ処理システムにおける該エディツト
手順を行なうための方法を提供することにより達成され
、該方法は入力データを複数の属性の内の１つに分類す
る段階、前記複数の属性に対しエディツト手順のテーブ
ルを提供する段階、与えられた属性が入力された時前記
属性に対する何らかのエディツト手順を含むかを判定す
るためにテーブルをチェックするルーチンに入る段階、
もしそうであれば前記エディツト手順を前記属性に適用
する段階、そしてもしそうでなければ前記ルーチンを退
出する段階を具備する。

［実施例」 本発明は添付の特許請求の範囲に特に指摘されている。

しかしながら、本発明の他の特徴は添付の図面を参照し
て以下の詳細な説明を参照することによりより明らかと
なりかつ本発明が最もよく理解できるようになるであろ
う。

データ処理システムの背景的説明 患者のケアプロセス 第１図から第４図までは、本発明が実施されかつ有用性
を与えるシステムの背景説明を提供する。

そのようなシステムはさらに上に述べた関連発明に記載
されている。しかしながら、本発明は高度の個別対応（
ｃｕｓｌｏｍｉｚａｔｉｏｎ）が可能でなければならな
い任意のデータ処理システムにおいて広い用途を有して
おりかつ第１図から第４図に示されたシステムに関連す
るもののような実施に制限されないことを意図している
。

第１図は、典型的な病院環境における患者のケアプロセ
スを一般的に示すブロック図である。

医師３０１は病院の滞在中にわたり患者３１５の世話（
ケア）およびマネージメントに対して責任を持つ。患者
を病院に入れるに際し、医師は患者を査定しかつ診断に
来る。この診断にもとづき医師は彼の経過ノート（ｐｒ
ｏｇｒｅａｓ　ｎｏｔｅ）にケアの計画を書きかつ看護
人および他の病院の職員３０３により実行されるべき医
師オーダ３０６のリストを発生する。医師のオーダ３０
６はカーデックス（Ｋａ＋ｄｅｘ）３１　（Ｌタスクリ
スト（Ｔａｓｋ　Ｌｉ５ｔ）　　３１２、レクイジショ
ン（Ｒｅｑｕｉｓｉｔｉｏｎ）　　３１４、および患者
のケア計画３０２の実行全体に役立つ他の関連するフオ
ームの源である。看護オーダ３０８もまたカーデックス
３１０およびタスクリスト３１２に対応する介在事を発
生する。

カーデックス３１０およびタスクリスト３１２における
他の介在事は病院手順３２２によって指令され、該病院
手順はケアの病院標準、病院のポリシイ、および規則を
含む。看護人および他の病院職員３０３はカーデックス
３１０およびタスクリスト３１２に書かれた命令を実行
しかつ次に必要な文書を提供するための要求を満たすよ
う適切なフオームに記入する。

フローシート３２３および診断結果３２６のような他の
フオームは患者または患者のティシュ、流動体、その他
に対し直接行なわれる特定の測定、試験結果、および／
または計算３１６を文書化する。同様に、介護（ｉ＋ｕ
ｅ＋ｖｅｎｌｉｏｎｓ）および他の療法（ｔｈｅｒａｐ
ｙ）　　３２０が医療管理記録フオーム３３２および他
のフオームに文書化される。

看護人および医師は患者３１５および介護および療法３
２０の結果を観察しかつ彼らの観察３１８を経過ノート
３２４および他の関連するフオームに文書化する。

観察３１８および経過ノート３２４から医師３１０また
は看護人３０３は患者３１５の現在の状態に対応する新
しい一組のオーダ３００を書く。

次に第２図を参照すると、本発明の自動化臨床記録シス
テムを実施するための典型的なハードウェア構成のブロ
ック図が示されている。第２図は、ローカルエリアネッ
トワーク（ＬＡＮ）１に結合された複数のワークステー
ションまたはターミナル２，２２，３２．３４および８
５を具備する分散型コンピュータシステムを示す。

該システムは典型的には病院または診療所において、集
中治療ユニットのような、看護治療ユニットに使用する
ために導入される。ターミナル２および２２の各々は患
者のベツドサイドに配置される。１つのターミナルは単
一の患者の使用に捧げることができ、あるいはそれは複
数の患者のために使用することもできる。ターミナル３
２および３４は看護ステーションまたは看護人／医師ラ
ウンジ領域に配置することができる。ターミナル８５は
システム管理者によってシステムを構築しかつ維持する
ためにおよび、システム状態およびエラーメツセージを
表示し、記録し、かつ診断を行なうような、付加的なサ
ービスを提供するために使用されるシステムコンソール
である。

ターミナル２のような、各々のベツドサイドのワークス
テーションまたはターミナルは観察者に情報を表示する
ための可視的スクリーン３を備えたビデオデイスプレィ
、計算、データ格納、および通信機器を含みかつそれに
関連してキーボードおよびマウス５のような指示装置を
有するノ＼ウジング４、そして１つまたはそれ以上のベ
ツドサイド装置８およびＩＯへの接続７および９を含む
。

ベツドサイド装置８および１０はＥＫＧモニタ、呼吸モ
ニタ、その他のような、治療を行なっている患者に適し
た患者監視機器の形をとることができる。ベツドサイド
ターミナル２２はターミナル２に結合されたものから異
なる組のべ・ソドサイド装置２８および３０に結合でき
る。

看護ステーションまたはラウンジターミナル３２および
３４、そしてシステムコンソール８５、は患者治療ユニ
ットに使用されているものと同じでよいが、ベツドサイ
ド装置の接続はなく、あるいはそれらはそれらが同様の
機能を提供する限りやや異なる機器（例えば、パーソナ
ルコンピュータ）を備えていてもよい。

ＬＡＮＩにはまたファイルサーバ６２および関連するデ
イクス記憶装置６４が結合されている。

ファイルサーバ６２はワークステーション２゜２２、　
３２．　３４．および８５によってディスク記憶装置６
４に情報を書き込みかつディスク記憶装置６４から情報
を読出すために制御されたアクセスを提供する。

任意選択的にＬＡＮＩにはＬＡＮＩへの種々のシステム
周辺機器を結合するために（図示しない）インタフェー
スを結合できる。例えば、遠隔アクセスモデムをそのよ
うなインタフェースの１つに結合して病院内または、医
者の住居のような、離れて位置するいずれかの場所に配
置された遠隔ターミナル（図示せず）からのシステムへ
のアクセスを提供することができる。遠隔アクセスはま
た離れた場所の設備からシステムの問題を診断するため
に使用することができる。研究所のシステムをインタフ
ェースに結合し研究情報を研究所システムおよび臨床管
理システムの間で通信できるようにすることができる。

オーダ通信システムをインタフェースに結合してオーダ
がシステムから他の病院システム（例えば、薬局または
研究室）におよびその逆に通信することができる。記録
格納装置をインタフェースに結合してシステムに記憶さ
れた任意の情報を磁気テープまたは光ディスクのような
適切な記録メディアに安全に格納することができる。

プリンタ８１および８３がファイルサーバ６２に結合さ
れ患者の情報を病院職員の便宜のために印刷しかつすべ
ての観察、オーダ、パラメータの読み、治療計画、およ
び監視される患者に関する他の患者情報の適切な法的記
録を維持することができる。プリンタ８１および８３は
、例えば、レーザプリンタまたは高速ドツトマトリクス
プリンタのような任意の適切なプリンタでよい。プリン
タは任意選択的にもし必要であればベツドサイドターミ
ナルおよび／または看護ステーションまたはラウンジの
ターミナルに結合することができる。

動作においては、システムの使用者、典型的には看護婦
または医師、はキーボード、マウス、またはライトペン
、タッチパッド、トラックボールその他のような情報を
入力するための他の適切な手段の使用によりシステムと
の対話を行なう。

「アイコン」、スクリーン感知領域、または同等のもの
、あるいはエンドアプリケーションに適切なこれらの任
意の組合わせもまた提供できる。

「アイコン」はスクリーン上に表示されるシンボルであ
ってその機能は現在のスクリーン環境に照らしてシステ
ムによりユーザのために定義されるものであり、かつこ
れらはユーザのアプリケーションの直接の要求に応じて
容易に変えることができるものである。本発明において
はアイコンはシステムユーザによりマウスによってスク
リーンカーソルを動かしかつアイコン上で「クリックす
る」、即ちカーソルがアイコンに乗っている間にマウス
ボタンを押圧する、ことにより選択される。

ユーザはシステムに対しキーボードによりおよび／また
は指示装置（単数または複数）により情報または質問を
与え、かつ彼はシステムからスクリーン上に表示された
情報によりおよび／または、別の実施例においては、音
声合成をも含み得る可聴信号によって情報を受ける。

患者のフローシート 第３図は、本発明の自動化臨床記録システムにおけるフ
ローシート情報スクリーンを示す。

第３図に示されるフローシートスクリーンはほぼ時間ご
とのインターバルで記録された患者ドナルド・Ｍ・ジャ
クソンの生命徴候情報を示す。例えば、体温（ｉ６７行
）、脈拍（ｉ６８行）、および収縮期の動脈圧および拡
張期の動脈圧（ｉ６９行）が測定されかつ記録される。

フォームズマネージャ 第４図は、フォームズマネージャ（ｆｏｒｍｓ　ｍａｎ
ａｇｅｅｌ　のアプリケーションプログラムおよびデー
タベースへの関係を示すブロック図である。フォームズ
マネージャ１１１は入力、出力、およびシステムアプリ
ケーションおよびデータベースの内のおよび間のインタ
フェース、あるいはバッファ、として使用される。

入力装置１１２がフォームズマネージャ１１１に結合さ
れている。入力装置１１２はジョイスティックを有する
キーボードとして示されているが、任意の形の入力装置
でよい。一般に、通信は入力装置１１２からフォームズ
マネージャ１１１に行なわれる。しかしながら、フォー
ムズマネージャ１１１が入力装置１１２における可視的
または音響的装置を作動させる必要があるかもしれない
。

このため、フォームズマネージャ１１１から入力装置１
１２へいくらかの通信があるであろう。

フォームズマネージャ１１１にはまたオペレータ・デイ
スプレィ・モジュール１１３が接続されている。デイス
プレィ１１３は典型的には陰極線管（ｃＲＴ）であるが
、種々の形式のフラットパネル型デイスプレィのような
数多くの任意の形式のデイスプレィでよい。通信は一般
にフォームズマネージャ１１１からデイスプレィ１１３
に行なわれる。しかしながら、タッチセンススクリーン
または他の形式の入力装置をデイスプレィ１１３からフ
ォームズマネージャ１１１に通信を必要とするシステム
において導入することができる。

フォームズマネージャ１１１はまたアプリケーションプ
ログラム１１４およびデータベースと相互作用する。こ
の特定の例に対する、データベースは一般データベース
１１５と特定データベース１１６に分割されている。デ
ータベースは機能的に分離されるかもしれないが、双方
共同じ物理的ロケーションに含まれ得ることを理解すべ
きである。

このような形式の電子的データベースにおいては、フロ
ーシートのセルが該セル内の情報を拡張するそれに関連
したフオームまたはリポートを備えることができる。こ
のフオームは１つまたはそれ以上のオブジェクトクラス
のｔつまたはそれ以上のオブジェクト例（ｏｂｉｅｃｌ
　１ｎｓｔａｎｃｅｓ）から得られる種々の属性（ａＮ
ｒｉｂｌｅｓ）および処理ルールにより構成することか
できる。オブジェクト例はオブジェクトクラスの実例化
したものである。オブジェクトクラスはそれが構造を定
義するという点で（プログラミング言語において使用さ
れる）型（ｔｙｐｅ）と同じである。これらのフローシ
ートセルのための情報および基本的なフオームは種々の
患者の記録を含むデータベースから来る。フオームおよ
び記録の例は同時継続特許出願「スプレドシート・デイ
スプレィを形成する方法」および「複数データフィール
ドを有するスプレドシート・セル」に見られる。

動作においては、オブジェクトが入力装置１１２を通し
てフォームズマネージャに入力される。この入力はチェ
ックされかつ特定の患者のためにデータベース１１６に
記憶される。あるフォムが表示されるべき場合には、フ
ォームズマネージャ１１１−は表示すべきオブジェクト
のリストを得る。オブジェクトの１つの源はアプリケー
ションプログラム１１４である。フォームズマネージャ
は次にデータベース１１５から該オブジェクトに関連す
る表示タイル（ｄｉｓｐｌａ７　ｔｉｌｅｓ）を引出す
。タイルに置かれるべきデータが次にデータベース１１
６から得られる。これらの入力を用いて、フォームズマ
ネージャ１１１はデイスプレィ１１３上に表示されるフ
オームを展開する。

第５図は、本発明のアプリケーションソフトウェアのア
ーキテクチャのブロック図を示す。

このアプリケーションソフトウェアのアーキテクチャは
アクション指向型（ａｃｔｉｏｎ−ｏｒｉｅｎｔｅｄ）
アプリケーションを特定する方法である。フォームズマ
ネージャ１００はユーザアクションを「イベント」に翻
訳しかつ該イベントをグラフマネージャ１０１に送る。

グラフマネージャ１０１は入力イベントをふるい分け、
適切な時間に呼んでいるＤＥＣＬの世話をし、対話ノー
ドの編成を処理し、かつデータフローを輸入／輸出する
。

ユーザは行動（アクション）を行なう。フォームズマネ
ージャ１００はユーザのアクションにもとづきイベント
を発生する。グラフマネージャ１０１はフォームズマネ
ージャ１００により発生されたイベントを捕獲する。

アプリケーションソフトウェアのアーキテクチャ内に書
かれたアプリケーションはグラフ（そして場合によって
はサブグラフ）に集められた１組の対話ノードおよびグ
ラフを描くグラフテーブルエントリからなる。アプリケ
ーションにおける対話ノードは種々の属性を用いる。各
属性はそれに関連して一群の手順を有し、それらのいず
れも任意選択的なものである。これらの手順は集合的に
ＤＥＣＬとして知られているデフォールト、エディツト
、計算、およびリストである。

デフォルト（ＤＥＦＡＵＬＴ）手順は一般的にバブル１
０２によって示され、エディツト（ＥＤＩＴ）手順はバ
ブル１０３により、計算（ｃＡＬＣＵＬＡＴｌ　ＯＮ）
手順はバブル１０５により、クロスエディツト（ｃＲＯ
３Ｓ−ＥＤ　ＩＴ）手順はバブル１０４により、そして
リスト（ＬＩｓＴ）手順はバブル１０７によって示され
ている。

機能グラフ アプリケーションの調整用論理は１組の機能グラフとし
て表わされる。機能グラフは有向グラフへと接続された
１組のノードおよびアーク（ａｒｃＳ）である。機能グ
ラフはアプリケーションを数多くの独立したしかし協働
するモジュールに分割することを許容する。グラフにお
ける各ノードは呼び出された時にそれが行なうよく定義
された機能を有する。（グラフにおけるノードはサブグ
ラフを表わすかもしれない。）アプリケーション設計者
はこれらのグラフに関してアプリケーションを特定し、
存在するノードのライブラリーから描きかつ多分該ライ
ブラリーに新しいノードを加える。

機能グラフは１組の次のフオームの三つ組によって定義
される、即ち（ソース　ノード（ｓｏｕｒｃｅｎｏｄｅ
）　、アーク（ａｔｃ）　、デスティネーション−ノー
ド（ｄｅｓｔｉｎａｔｉｏｎ　　ｎｏｄｅ）　）　ｏ各
機能グラフは少なくともフオーム（ＧＲＰＨＩＮＩＴ、
アーク、デスティネーション　ノード）の少なくとも１
つの三つ組を有している。ＧＲＰＨＩＮＩＴはグラフへ
のエントリポイントを定義する「擬似ノード（ｐｓｅｕ
ｄｏ　ｎｏｄｅ）　Ｊである。ＧＲＰＨＩＮＩＴから来
るアークの各々はその親グラフから機能グラフに来るア
ークの１つと整合すべきである。

第６Ａ図および第６Ｂ図は、２つの機能グラフを示す。

第６Ａ図は、“ｆ　　ａｄｔ”と題するグラフを示し、
かつ第６Ｂ図は第６Ａ図のグラフ２００内の同じ名前の
手順的ノード（ｐｒｏｃｅｄｕ＋ａｎｏｄｅ）　　２０
５に対応する、”ｆ　　１ｎｄｅｘ”と題するグラフを
示す。

グラフ２００においては、ノードｆ　　１ｎｄｅＸはア
ークＩＮＤＥＸを介して「呼ばれる（ｃａｌｌｅｄ）Ｊ
。グラフ２１０においては、ＩＮＤＥＸと呼ばれるアー
クはＧＲＰＨＩＮＩＴ２１１をグラフの第１のノード２
１２とリンクする。

グラフを退出するには、フオーム（ソース　ノード、ア
ーク、ＧＲＰＨＥＸＩＴ）の少なくとも１つの三つ組が
存在しなければならない。ＧＲＰＨＥＸＩＴはグラフの
退出点を規定する「擬似ノード」である。ＧＲＰＨＥＸ
ＩＴに来るアークの各々はその親グラフにおける機能グ
ラフを去るアークの１つと整合すべきである。

Ｇｒｐｈ　　ｍｇｔはこれらの機能グラフの実行の管理
に責任を有する。各ノードはそれが完了すると状態値（
ｓｔａｔｕｓ　ｖａｌｕｅ）を戻す。Ｇｒｐｈ　　ｍｇ
ｔは親のグラフのどのアークが続くか、従ってどのノー
ドを次に呼出すかを判定するため状態値を使用する。さ
らに、呼ばれたノードはそれを呼んだアークの名前を渡
され、該ノードにその処理を行なうために付加的な情報
を与える。機能グラフにおけるノードはいくつかのノー
ドタイプの１つでよく、あるいはそれは他の機能グラフ
でよい。

これは機能グラフがアプリケーションによって要求され
た場合にホストされることを許容する。

対話ノード 機能グラフにおける各ノードはイベントプロセッサとし
て構成される。イベントは、マウスボタンのクリッキン
グまたはフィールドの値の変更のような、アクションの
結果として発生される。ノードの本体はイベントループ
であり、ノードが退出するまで、各入力イベントを順次
処理する。各ノードは各イベントに対する処理を規定す
るコードセグメントと共に、それが理解する１組のイベ
ントを有する。

第７図は、対話ノードの構造を示す。各ノードはイベン
トプロセッサとして構成される。該ノードの本体はイベ
ントループであり、ノードが退出されるまで、各入力イ
ベントを順次処理する。各ノードはそのイベントに対す
る処理を規定するコードセグメントと共に、それが理解
する１組のイベントを有する。イベント処理は以下のカ
テゴリーの１つまたはそれ以上に対応する。

フオームのデイスプレィおよび除去 ７オームメニユーの表示 ユーザエントリーのフオームデータフィールドへのイネ
ーブル／ディスエーブル フオームオブジェクトのユーザ選択の受け入れ／拒絶 （オブジェクトアクションの環境内で）データベースに
おけるオブジェクト例の生成／変更／削除 データベースへの処理の手早い送付、先に入力したオブ
ジェクトアクションのロールパック 他の処理（例えば、患者のチャートのオープニング、リ
ポートの印刷要求、その他）へのメツセージの発生 この処理を行なうためには、イベント処理コードは典型
的には、現在選択されているオブジェクト例に対し、あ
るいはデータベースの他のデータに対し、データベース
に間合わせる必要がある。

イベント イベントは２つのソース、即ちノードへの入力グラフア
ーク（ノードが受信する最初のイベントはノードを呼出
させるグラフアークである）、およびユーザ対話により
発生されるイベント（即ち、ユーザアクションによりト
リガされるイベント）、から来る。これらのイベントは
２つのクラス、即ち予め定義されたイベントおよびアプ
リケーション定義イベント、に分割される。予め定義さ
れたイベントは充分に定義された条件下でシステムおよ
び／またはユーザのアクションにより発生される。各ノ
ードはこれらのイベントに対する処理を定義しなければ
ならない。アプリケーションもまたフオームメニュー選
択に関連するイベントを規定できる。アプリケーション
定義イベントはその関連するメニュー選択がユーザによ
って選択された時には常に発生される。

グラフテーブル 機能グラフはデータベースにおけるテーブル（「グラフ
テーブル」）におけるエントリーによって規定される。

エントリーはグラフノードの間およびグラフの間の順序
付けを規定する。グラフテーブルの各エントリーはソー
スノードネーム、アークネーム（イベント）、デスティ
ネーションノードネーム、およびソースノードを含むグ
ラフのネームを含む。従って、グラフネーム、ソースノ
ード、およびイベントを与えることにより、グラフマネ
ージャは次に呼出すノード（デスティネーションノード
）の名前を捜すことができる。

グラフマネージャによって確保される３つの特別のノー
ドネームがある。ソースノードネームに対し”ｇｒａｐ
ｈ　　１ｎｉｔ”を備えたグラフテーブルにおけるエン
トリーはグラフへのエントリーポイントである。デステ
ィネーションノードに対するｇｒａｐｈ　　ｅｘｉｔ”
を有するエントリイはグラフからの退出点である。

ここに添付されたグラフテーブルはそれぞれ第６Ａ図お
よび第６Ｂ図に示された“ｆ　　ａｄｔ″およびｆ　　
１ｎｄｅｘ″と題する２つの機能グラフに対するエント
リーを示す。例えば、グラフ“ｆ　　ａｄｔ”において
ＩＮＩＴイベントはソースノードＧＲＡＰＨｌＮｌＴ２
Ｏ１およびデスティネーションノードＳ　　ＣＥＮＳＵ
Ｓ２０３をリンクする。

グラフマネージャ内でのイベント処理 （予め定義されたおよびアプリケーションにより定義さ
れた）すべてのイベントから、グラフマネージャは６個
のみ、即ちＤＥＦＡＵＬＴ、ＮＥＷ、Ｓ　ＩＧＮ、ＯＫ
、ＭＯＲＥ、およびＣＲＯ３Ｓ　　ＥＤＩＴのみを捕捉
／ふるい分けする。

ＤＥＦＡＵＬＴおよびＣＲＯ８Ｓ　　ＥＤＩＴイベント
はアプリケーション対話ノードへ決して渡されず、他の
ものはある処理が完了した後渡されるであろう。

これらのイベント及び結果としての処理は添付の付属書
類Ｂに見られる擬似コードに説明されている。

詳細な説明 ＤＥＣＬの一般的説明 本発明に関しては、「属性」はデータオブジェクトにお
ける有用なデータの最小のもの（即ち、データベースに
おけるデータフィールド）である。

変わらない各属性に関連するある処理タスクが存在する
。例えば、特定の属性のユーザ入力を有効化するための
ルールはどのアプリケーションがユーザにデータの入力
を許容しているかにかかわらず同じである。

伝統的には、ライブラリィはそのような機能のために構
築され、かつすべてのアプリケーションはそれが使用す
る属性に対する適切な機能を呼ばなければならない。各
機能は１つの特定の属性を処理するために書かれる。あ
るライブラリィの機能が変えられ、削除され、または加
えられる時、その機能を使用する（即ち、その機能が関
連する属性を使用する）すべてのアプリケーションは（
正しく）修正され、再コンパイルされ、かつ再テストさ
れなければならない。

そのようなルーチンタスク（または手順）に対する責任
をアプリケーションから除去することはエラー、メンテ
ナンス時間、実施時間、および設計時間を低減する。以
下はアプリケーションがそれらを取扱う必要がないよう
に自動的にルーチン手順を行なうための方法を説明して
いる。またシステムにおいて必要とされるルーチン手順
の数を低減する方法も説明されている。

アプリケーションは種々のオブジェクト属性を使用する
。各属性はそれに関連して一群の手順を有しており、こ
れらのいずれも任意選択的（ｏｐｔｉ。

ｎａｌ）なものである。これらの手順はデフォールト（
属性に対しデフォールト値を供給する）、エディツト（
属性に対する新しい値を有効化する）、計算（他の属性
値から属性値を計算する）、およびリスト（リストから
サブリストを構築する）を含むことができる。デフォー
ルト、エディツト、計算（ｃａｌｃｕｌａｌｉｏｎｓ）
、およびリストは集合的にＤＥＣＬとして知られている
。

システムにおける異なるＤＥＣＬ手順（特に、エディツ
ト）の数を減らすために、ＤＥＣＬは１つより多くの属
性と関連できるであろう。例えば、ある日付が現在の日
付より遅くないことを保証するエディツト手順が存在す
るかも知れない。同じことを行なうが、各々が異なる属
性を取扱う点でやや異なる多くのエディツトを書くより
もそのＩつのエディツトを多くの属性（例えば、入学日
、誕生日）と関連付けることがより良好であろう。

さらに、エディツト手順は属性タイプと関連することが
でき、それによりあるエディツト手順が自動的にあるタ
イプのすべての属性におよびそのタイプの子供のタイプ
のすべての属性に自動的に適用される。例えば、ユーザ
により入力された数が数字桁のみを含んでおりかつ特定
の範囲にある（例えば、０−３２７６７）ことを保証す
るエディツトが存在するであろう。このエディツトはそ
のタイプがｉｎｔｅｇｅｒ　（整数）であるすべての属
性に関連する。さらに、該エディツトはタイプｉｎｔ　
　ｉｄ（その親のタイプはｉｎｔｅｇｅｒ）および５ｔ
ａｆｆ　　ｉｄ（その親のタイプはｉｎｔ　　ｉｄ）の
属性に適用できるであろう。

あるタイプの「子供」のタイプは、「親」のタイプとし
て言及される、他のタイプの特性を含む１つである。例
えば、ここに添付した属性タイプテーブルを参照して、
タイプ“５ｔａｆｆ　　ｉｄ”はタイプ“ｉｎｔ　　ｉ
ｄ″の”ｃｈｉｌｄ（子供）”である。属性タイプの遺
伝の概念を通して、すべての子供は彼らの親のエディツ
トルールおよび格納フォーマットを受は継がなければな
らない。

アプリケーションがある属性を使用する時、それは自動
的にその属性に関連するＤＥＣＬを用いる。従って、ア
プリケーションの設計者はＤＥＣＬによって取扱われる
詳細について心配する必要はないが、その理由はアプリ
ケーションはそれらを取扱う必要がないからである。い
ったんＤＥＣＬがある属性のために書かれると、その属
性を使用するいずれのアプリケーションもこれらの手順
を（自動的に）使用する。

属性はそれらに関連するＤＥＣＬの任意の組合わせを持
つことができる。例えば、ある属性はＤＥＣＬを持たな
くてもよく、あるいはそれはリスト手順およびエディツ
ト手順を有するが、何らの変換、デフォールト、または
計算を持たないかも知れない。

デフォールト デフォールト手順は、もしそのような値が存在すれば、
それに関連する属性のためのデフォールト値を決定する
。１つの属性はそれに関連して多くても１つのデフォー
ルト手順を持つことができる。

第８図は、デフォールト手順の構造を示す。デフォール
ト手順はｆｏｒｍｓ　　ｍｇｔアルゴリズムにもとづき
、ＤＥＦＡＵＬＴイベントが関連するフィールドに対し
受信された時呼出される。ＤＥＦＡＵＬＴイベントはユ
ーザがデータエントリイのためのフィールドを選択した
時に発生する。

デフォールト手順は、もしそれが存在すれば、その属性
のためのデフォールト値を決定し、かつその値をデータ
ベースに格納する。

エディツト エディツト手順は１つまたはそれ以上の属性に対する一
組の有効性の制約、あるいはエディツト規則を定義する
。エディツト規則は、属性スペシファイア（エディツト
手順はすべての属性を含むために「万能札化（ｗｉｌｄ
−ｃａｒｄｅｄ）　Ｊすルコとカテきる１つより多くの
属性と関連づけることができるので）、エディツト規則
を表すプール表現、およびもしエディツト規則が外れた
場合に表示するためのエラーメツセージを含む。もしエ
ディツト規則に外れると、エディツト手順は退出する（
エディツト手順内の何らの後続のエディツト規則もテス
トされない）。

エディツト規則に加え、エディツト手順はエディツト規
則警告（ｅｄｉｔ　ｒｕｌｅ　ｗａｒｎｉｎｇｓ）を定
義することができる。エディツト規則警告はもしプール
表現の評価が不可になるとユーザーがメツセージを提供
されかつ先に進むかそうでないかを決定することを許容
される点を除き、エディツト規則と同じである。もしユ
ーザーが先に進むことを選択すれば、エディツト規則は
パスとなる。それ以外はそれは不可となる。

上に述べたように、各属性はそれに関連するゼロまたは
それ以上のエディツト手順を持つことができる。さらに
、属性タイプはそれらに関連してエディツト手順を持つ
ことができ、それらはそのタイプの任意の属性に対し適
用される。属性タイプはまたシステム属性タイプテーブ
ルに規定される任意の親の属性タイプのエディツトを受
は継ぐエディツト手順および属性タイプの間の関連は属
性タイプに対するデータベースルックアップテーブルに
明細化されている。ここに添付した属性タイプテーブル
を参照。

属性はそれらに関連する２つのクラスのエディツト、す
なわち単一フィールドのエディツトおよびクロスフィー
ルドのエディツトを持つことができる。単一フィールド
のエディツトは新しいデータがある属性のために入力さ
れた時には常に開始される。エディツトは一定情報（例
えば、月は１と１２の間に、１と１２を含めて、なけれ
ばならない）に基づき、あるいは「システムデータ」（
例えば、現在の日付）に対して有効であることをチェッ
クする。

クロスフィールドエディツトはユーザーがフオームを離
れようとする時に新しいデータを受信しているすべての
フィールドに対し開始される。それらはまたフィールド
がエントリーのためにイネーブルされておれば（何らか
のデータがそのフィールドにエンターされているか否か
にかかわらず）「要求されている（＋ｅｑｕｉｔｅｄｌ
　Ｊと指定された任意のフィールドに対して開始される
。クロスフィールドエディツトはそれらが関連するフィ
ールドとデータベースにおける他のデータの間の整合性
（例えば、■Ｖドリップのドーズ量、濃度、および量が
整合すること）をチェックするために使用される。それ
らはまた要求されたフィールドを実施するために使用さ
れる。

属性はエディツト手順の各クラスの内のゼロまたはそれ
以上を有することができる。

第９図は、エディツト手順の構造を示す。

計算（ｃａｌｃｕｌａｔｉｏｎｓ） 計算手順はデータベースにおける他の情報に基づき属性
の値を引き出す方法を規定する。計算手順は該計算手順
に関連する「トリガ（ｔｒｉｇｇｅｒｓ）　ｊの１つに
対するシステムデータベースに新しい値が入力された時
に開始される。「トリガ」は目標の属性を計算する方程
式における独立変数である。

トリガの値が更新されるとき、関連する属性のための計
算手順が呼ばれかつ実行される。

「計算手順」はデータベースにおける他の情報に基づき
属性の値を聞出すための方法を規定する。

計算手順は方程式の形をとることができる。

トリガ値は、例えば、システムユーザーのアクションに
より、または血圧リーダまたは尿コレクタのような変換
器の出力のような他の適切な入力手段により、システム
データベースにおいて変わり得る。

計算手順はそれが有効なトリガとともに呼出されたかを
判定し、トリガデータを入手し、計算を行ない、かつ結
果を出力する。結果の出力は他の従属する計算をトリガ
することができる。

第１０図は、計算手順の構造を示す。

リスト リスト手順はそのリスト項目がランタイム中に変わるリ
ストを実施するために使用される。リスト手順はリスト
手順の本体に特定された規則に基づきマスクリストから
項目を選択し、かつこれらの項目を表示のためにフォー
ムズマネージャに渡す。

ＤＥＣＩ、および属性の間の関連は属性のためのデータ
ベースルックアップテーブルに特定される。

ここに添付した属性テーブルを参照。

第１１図は、リスト手順の構造を示す。

属性オーダー 非常に多くのＤＥＣＬが属性と関連し得るからそれらが
属性に適用される順序（ｏｒｄｅｒ）が重要である。例
えば、エディツトは以下の順序で適用される。すなわち
、属性タイプに対する継承ツリー（ｉｎｂｅｒ…ｎｃｅ
　ｔ−ｒｅｅ）における最も原始的な属性タイプに対す
るすべてのエディツト、次に次の子供のタイプに対する
エディツト、および以下同様である。次に、属性それ自
体に対するすべてのエディツトが適用される。任意の与
えられたレベル内で、エディツトはテーブルにおける定
義の順序（すなわち、左から右）で適用される。

クロスフィールドエディツトは（属性タイプでなく）属
性とのみ関連できるから、特定の属性に対するクロスフ
ィールドエディツトのみが（テーブルの定義順序で）呼
出される。属性は有効であると考えられるためにそれと
関連するすべてのエディツトを渡さなければならない。

添付の属性テーブルにおけるテーブル例を使用して、有
効と考えられるために″ｗｈｏ″属性は（順番に）エデ
ィツトｅ　　ｖａｌｉｄ　　ｉｎｔ。

ｅ　　ｖａｌｉｄ　　１ｎｔｉｄ、ｅ　　ｖａｌｉｄｓ
ｔａｆｆｉｄ、ｅ　　ｎｕｒｓｅｉｄ、およびｅａｃｔ
ｉｖｅ　　ｉｄを渡さなければならないであろう。エデ
ィツト規則ｅ　　ｖａｌｉｄ　　ｉｎｔは有効な整数を
チエ゛ツクし、ｅ　　ｖａｌｉｄ　　１ｎｔｉｄは有効
な内部ｉ、　　ｄ、をチェックしｅｖａｌｉｄ　　５ｔ
ａｆｆｉｄは有効なスタッフｉ。

ｄ、をチエ’ｙりし、ｅ　　ｎｕｒｓｅｉｄは有効な看
護婦ｉ、　　ａ、をチェックし、そしてｅ　　ａｃｔｉ
ｖｅ　　ｉｄは有効な現在のｉ、ｄ、をチェックする。

アプリケーションを特定するとき、アプリケーション設
計者はどの属性をアプリケーションが使用するかを特定
しなければならない。アプリケーションがある属性を使
用するとき、それは自動的にその属性に関連するＤＥＣ
Ｌを用いる。従って、アプリケーション設計者はＤＥＣ
Ｌにより取扱われる詳細について心配する必要はないが
、それはアプリケーションがそれらを取扱わないからで
ある。−旦ＤＥＣＬがある属性のために書かれると、そ
の属性を用いる任意のアプリケーションもまたそれらの
手順を（自動的に）使用する。

再び、ＤＥＣＬは、異なるユーザー環境に対しシステム
をカスタム化するために、単に適切な属性テーブルを変
えることにより容易に変えることができることを強調す
べきである。

属性はそれらに関連するＤＥＣＬの任意の組合せを持つ
ことができる。例えば、ある属性はＤＥＣＬを持たない
かもしれず、あるいはそれはリスト手順および３つのエ
ディツト手順を有するが、デフォールトまたは計算を持
たないかもしれない。

アプリケーションはイベント駆動され（ｅｖｅｎｔ−ｄ
ｒｉｖｅｎ）かつ従ってそれらがイベントを受信するプ
ロセス（または、それらが１より多くある場合、複数の
プロセス）により制御される。イベントおよびそれに関
連する属性（単数または複数）に基づき、制御プロセス
は該属性に関連する適切な手順を呼出す。次に、イベン
トおよび手順の結果に基づき、制御プロセスは任意選択
的にイベント（単数または複数）をアプリケーションに
渡す。

制御プロセスはテーブル１のような、テーブルにおける
手順をルックアップすることにより特定のイベントおよ
び属性に対しどの手順（単数または複数）を呼出すかを
決定する。従って、手順を加え、変更し、または削除す
ることは単に適切なテーブルエントリーを変えることを
必要とするのみである。アプリケーションコードは変更
される必要はない。

２つの制御プロセスがある、すなわちフォームズマネー
ジャーおよびグラフマネージャーである。

フォームズマネージャーは、ユーザーのための選択のリ
ストを備えたポツプアップウィンドウのようなものを含
む、真にスクリーン上に現われるものの詳細のみならず
、すべてのユーザーのＩｌｏを取扱う。フォームズマネ
ージャはまたユーザーアクションをイベントに翻訳しか
つこれらのイベントをグラフマネージャーに送る。

グラフマネージャーはフォームズマネージャーからイベ
ントおよびこれらのイベントがどの属性に関連している
か（イベント毎に１つの属性）を受ける。グラフマネー
ジャーは入力イベントをふるい分け、いくつかをアプリ
ケーションに渡しかつ他の物に働きかける。受信したイ
ベントに基づき、グラフマネージャーはデフォールト値
、新しい値の有効性の確認（エディツト）、および値の
計算を取扱うために適切な手順を呼ぶ。

フォームズマネージャーおよびグラフマネージャーの双
方はデータベースにおけるルックアップテーブルを用い
てどのＤＥＣＬ手順を呼出すかを決定する。

アプリケーションはこのすべての下に存在しグラフマネ
ージャーからのイベントを待ちかつそれらを受けた時に
取扱う。

ＤＥＣＬおよびグラフマネージャー グラフマネージャがデフォールトイベントを受けた時、
それはそれに対してイベントが発生された属性を属性テ
ーブルにおいて探す。もしその属性がそれに関連するデ
フォールト手順を有しておれば、グラフマネージャーは
それを呼ぶ。

デフォールト手順は該属性に対するデフォールト値を（
事によるとデータベース属性値、他のスクリーン値、そ
の他に基づき）決定し、それをスクリーン上に表示する
ためにフォームズマネージャーに与え、かつ戻る。

グラフマネージャーは次に属性によってトリガされてい
る計算手順（すなわち、属性に依存するすべての計算、
例えば“Ｂ”は計算“Ａ＝Ｂ＋Ｃ”におけるトリガであ
る）を探しかつ手順および結果としてトリガされるいず
れかの計算を呼ぶ。グラフマネージャはデフォールトイ
ベントをアプリケーションに渡さない。

グラフマネージャーが新しいイベントを受信すると、そ
れはそれに対してイベントが発生された属性を属性テー
ブルにおいて探す。もし該属性がそれに関連する何らか
のエディツト手順（ゼロまたはそれ以上であろう）を有
しておれば、グラフマネージャーは該エディツト手順を
一度に１つずつ呼ぶ。

もしいずれかの１つのエディツト手順が失敗すると、グ
ラフマネージャーは（すべての入力イベントがグラフマ
ネージャーがそれらを処理できるまで保持される）イベ
ントキューを空にする。失敗したエディツト手順はフォ
ームズマネージャーにエラーを通知しかつフォームズマ
ネージャーに表示のためエラーメツセージを供給してい
る。

もし該属性に対するすべてのエディツト手順が首尾良く
行なわれれば、ユーザーが有効な値を入力している。グ
ラフマネージャーは属性によってトリガされる計算手順
を探しかつ該手順を呼び、そして結果としてトリガされ
るいずれの計算をも呼ぶ。

ある属性に対する計算手順（もしあれば）を呼んだ後、
グラフマネージャーは新しい（ｎｅｗ）イベントをアプ
リケーションに渡す。もしエディツトが失敗すると、新
しいイベントはアプリケーションに渡されない。

グラフマネージャーはそれが受信するすべての他のイベ
ントをアプリケーションに直接渡す。

リストおよびフォームズマネージャー ユーザーが入力可能な（すなわち、ユーザーがデータを
入力することを許容されている）スクリーン上のフィー
ルドを選択する時、グラフマネージャーは属性テーブル
におけるそのフィールドの関連する属性を探し該属性に
関連するリスト手順があるか否かを判定する。もし存在
すれば、フォームズマネージャーは該リスト手順を呼び
、これはオブジェクトのリストを戻す。フォームズマネ
ージャは次にポツプアップ・ウィンドウにおけるリスト
を表示しユーザーが選択されたフィールドのためにそこ
から項目を選択できるようにする。

フォームズマネージャーは、（クロスエディツト手順の
ためのコラムの下のデータベースにおける属性テーブル
に見られる）クロスフィールドエディツト手順のための
クロスエディツト（ｃｒ。

５ｓ−ｅｄｉｔ）イベントのような、他の特別なイベン
トを発生する。

ＤＥＣＬ−詳細な実施例 グラフマネージメント 第１２図は、グラフマネージメントの「グラフ・シーフ
ェンシング」機能を示す。「グラフ・シーフェンシング
」２３０はグラフマネージメントの機能グラフの面を管
理する責任がありかつ最初にＣＦ−ｉｎｉｔ−ｍｓｇを
介してスタートされる。このメツセージはマスク機能グ
ラフに輸入されている情報（例えば、ＰＡＴＩ　ＥＮＴ
−ＩＤ。

ＷＯＲＫＳＴＡＴＩＯＮ−ＮＡＭＥ、他）ばかりでなく
ｇｒａｐｈ、　　ｍｇｔがそれに対して実行しているユ
ーザー機能タイプ（例えば、ＣＥＮＳＵＳ、Ｃ）ＩＡＲ
Ｔ）を含む。「グラフ・シーフェンシング」はＥＮＧ　
ＩＮＥ−ＴＡＢＬＥ−Ｄを見ることによりこのユーザー
機能タイプに対しマスクグラフが何であるかを判定しか
つその実行を始める。

ｇ　ｒ　ａ　ｐ　ｈ、　−ｄはグラフのシーフェンシン
グを制御する。ノードが呼出されかつＩＭＦＯＲＴ−Ｅ
ＸＰＯＲＴ−Ｄに基づき、何らかの輸入変数が（ＳＣ−
ｎｏｄｅ−ｉｎｖｏｋｅを介して）それに渡される。ノ
ードが実行を完了した時、戻りステータスおよびｇｒａ
ｐｈ−ｄが用いられ呼出すべき次のノードを決定する。

マスクグラフにおいてＧＲＡＰＨ−ＥＸＩＴに遭遇する
と、グラフのシーフェンシングは静止しかつ次のＣＦ−
ｉｎｉｔ−ｍｓｇを待つ。

第１３図は、グラフマネージメントの「マネージ入力対
話（Ｍａｎａｇｅ　Ｉｎｐｕｔ　Ｄｉｘｌｏｇ　）　Ｊ
機能を示す。「マネージ入力対話」２３１は（ｃＦ−ｉ
ｎｐｕｔ−ｅｖｅｎｔｓを介して受信された）ユーザ入
力イベントに対する応答を制御する責任を有する。大部
分のイベントは（ｃＦ−ｆｉｌｔｅｒｅｄ−ｉｎｐｕｔ
−ｅｖｅｎｔｓ）アプリケーションに渡される。

ＤＥＦＡＵＬＴおよびＮＥＷはデフォルトまたは計算機
能および単一フィールドエディツト処理を（ＳＣ−ｐｅ
ｒｆｏｒｍ−ｄｅｆａｕｌｔｓおよびＳＣ−ｐｅｒｆｏ
ｒｍ−ｅｄｉ　ｔｓを介して）トリガする。ＤＥＦＡＵ
ＬＴは決してアプリケーションに渡されない。ＮＥＷは
何らかのデフォールト／エディツト処理の後およびもし
それが何らかのエディツト処理を渡せば入力されたフィ
ールドのためにアプリケーションに渡される。

５ＩＧＮ、ＯＫおよびＭＯＲＥはクロスフィールドエデ
ィツトチェックの達成をトリガしかつすべてのエディツ
トが首尾よく行なわれればアプリケーションに渡される
のみである。

ＤＥＦＡＵＬＴまたはＮＥＷイベントが受信された時、
「マネージ入力対話」はＦＭ−ＢＥＧＩＮ−ＵＰＤＡＴ
Ｅを行ない（「デフォールト手順」により行なわれたＦ
Ｍ−ＵＰＤＡＴＥＳの結果として、第１５図を参照）何
らかのフオーム更新を保持する。「マネージ入力対話」
はＦＭ−ＥＮＤ−ＵＰＤＡＴＥを発行しすべてのデフォ
ールト／計算処理が完了した後これらのフオーム更新を
進めることを許容する。

特定の属性に対してデフォールト／計算を行なうことを
指令された時、“Ｃｏｎｔｒｏｌ　　Ｄｅｆａｕｌｔ／
Ｃａ１ｃｓ”２３３は５Ｃ−ｄｅｆａｕ　ｌ　ｔ−１ｎ
ｖｏｋｅを介して（ＡＴＴＲＩ　ＢＵＴＥ−ＤＥＦＡＵ
ＬＴ−Ｄを介して知られている）適切な「デフォールト
手順」を呼出す。これは新しくデフォールトされ／計算
されたフィールドに依存するいずれかのフィールドが（
ＡＴＴＲＩ　ＢＵＴＥ−ＤＥＦＡＵＬＴ−Ｄにおける情
報に基づき）ＳＣ−ｄｅｆａｕｌ　ｔ−１ｎｖｏｋｅｓ
を介してデフォールトされ／計算されるようにする。

「制御エディツト（ｃｏｎｔｒｏｌ　Ｅｄｉｔｓ　）　
Ｊ　２３５は、（ＳＣ−ｐｅｒｆｏｒｍ−ｅｄｉ　ｔｓ
により）特定された属性に単一のフィールドエディツト
を行なうよう指令された時、その属性に対する（ＦＲＯ
Ｍ−ＥＤ　ＩＴ−Ｄから知られた）すべての関連するエ
ディツトが５Ｃ−ｅｄｉ　ｔ−１ｎｖｏｋｅを介して行
なわれるようにする。いずれかの失敗はその属性に対す
るその先のエディツト処理を中止するであろう。もしク
ロスフィールドエディツトを行なうよう指令されれば、
（ＦＭ−ＧＥＴ−ＣＵＲＲＥＮＴ−ＦＯＲＭおよびＣＵ
ＲＲＥＮＴ−ＦＯＲＭを介して呼出された）現在アクテ
ィブなフオームに対するすべてのエディツトは行なわれ
る（ＦＯＲＭ−ＥＤ　ＩＴ−Ｄを介して知られる）。Ｆ
ＯＲＭ−ＥＤ　ＩＴ−Ｄは２つの組の情報、すなわち（
ａ）あるフオームにおける属性に対するすべての単一フ
ィールドのエディツト、および（ｂ）あるフオームに対
するすべてのクロスフィールドエディツト、を含む。

ある属性に対する単一フィールドのエディツトは以下の
順序で呼出される。すなわち、属性タイプに対する継承
ツリーにおける最も原始的な属性タイプに対するすべて
のエディツト、次に次の子供の属性タイプに対するエデ
ィツト、および以下同様。次に、その属性それ自体に対
するすべてのエディツト。与えられたレベルの中でエデ
ィツトは定義の順（すなわち、左から右へ）呼出される
。

第１４図は、「対話ノード（Ｄｉａｌｏｇ　Ｎｏｄｅ　
）　ｊ２４１を示す。対話ノードはフオームマネージャ
と相互作用してデータ表示およびエントリーを制御する
。対話ノード２４１が（ＳＣ−ｎｏｄｅ−ｉｎｖｏｋｅ
を介して）呼出された時、それは（ＱＲ−ｎｏｄｅ−ｄ
を介して）その処理の定義を取出し、かつまた（ＳＣ−
ｎｏｄｅ−ｉｎｖ。

ｋｅを介して）−組の輸入属性および呼出しアークの名
前を受は取る。それは種々のテーブルを用いてそれが（
ＱＲ−ａｐｐ−ｃｏｎｆ　ｉｇ−ｄを介して）どのよう
に対話を制御するかに関しオプションを特定する。

対話ノードはフオームマネージャに種々のフオームで（
ｃＦ−ｉｎｔｅｒａｃｔ　１ｏｎ−ｃｏｎｔｒｏｌおよ
び１ｎｔｅｒａｃｔ　１ｏｎ−ｒｅｓｕｌｔｓを介して
）データを表示するために要求を出しかつｃＦ−ｆ　ｉ
　１ｔｅｒｅｄ−ｉｎｐｕｔｅｖｅｎｔｓを介して種々
のイベント（例えば、選択されたフィールド）の通知を
受ける。対話ノードはこれらのイベントの各々に対しど
のようなアクション（例えば、メニュ一定義変更、特定
フィールドへの進行）が行なわれるべきかを、再びＣＦ
−ｉｎｔｅｒａｃｔ　ｉｏｎ−ｃｏｎｔｒｏｌを介して
特定する。

ユーザ対話の結果として、対話ノードは（ＱＲ−ｏｂｊ
ｅｃｔ−ｄａｔａを介して）オブジェクト例（ｉｎｓｔ
ａｎｃｅ）データを要求し、（ｏｂｊｅｃｔ−ａｃｔｉ
ｏｎｓを介して）そのオブジェクト例データを修正しか
つそれらのオブジェクトアクションを（ＳＣ−ｍｒ−ｅ
ｄ−ｃｏｎ　ｔ　ｒｏ　ｌを介して）データベースに送
られるようにする。それはまた（ｒｕｎｔ　ｉｍｅ−ｓ
ｙｓ−ｃｏｎｔ　ｒｏｌを介して）種々のシステム制御
コマンドを発生することができる。

第１５図は、「デフォールト手順（Ｄｅｌ！ｕｌｔ　Ｐ
ｒｏｃｅ＋Ｉｕ＋ｅｓ）　Ｊノード２４２を示す。デフ
ォールトはある値をフオームに「自動的に」ロードする
方法である。デフォールト値を決定するためのアルゴリ
ズム（デフォールト「ルール」）は「デフォールト手順
」に特定されている。計算もまたデフォールトルールを
介して実行される。

Ｇｒａｐｈ　　ｍｇｔは５Ｃ−ｄｅ　ｆ　ａｕ　ｌ　ｔ
ｉ　ｎｖｏｋｅを介してデフォールト手順を呼出す。

デフォールトルールの記述はＱＲ−ｄｅｆａｕｌｔ−ｄ
を介して取出される。−組の情報がどの種類のオブジェ
クトおよびフィールドに対しそれが呼出されているかを
決定するための手順をイネーブルする呼出しく１ｎｖｏ
ｋｅ）において渡される。デフォールト手順は次にデフ
ォールト値を決定する。

それは（ＱＲ−ｏｂｊｅｃｔ−ｄａｔａを介して）そう
するために他の先に格納されたデータを利用するかもし
れず、またはそれは（ｒｎｏｎｉｔｏｒｄｂを介して）
有効でないモニタデータを使用するかもしれない。ＱＲ
−ａｐｐ−ｃｏｎｆ　ｉｇ−ｄから得られた情報は任意
のオプションを決定するために使用できる。いったんそ
れがデフォールト値を持つと、それはｏｂｊｅｃｔ−ａ
ｃｔｉｏｎｓを介してデータベースに入力される。フオ
ームがＦＭ−ＵＰＤＡＴＥを介してリフレッシュされる
。

第１６図は、「リスト手順（Ｌｉｓｔ　Ｐ「ｏｃｅｄｕ
ｒｅｓ　）」ノード２４３を示す。フィールド（属性）
がユーザによりフオーム上で選択された時、もしそれが
リストを有しておれば、ｆｏｒｍ　　ｍｇｔはそれを表
示されるようにする。リストは属性と関連している。い
くつかの属性は固定されたリストを有し、これらはｆｏ
ｒｍ　　ｍｇｔによって取扱われる。他の属性は先に入
力された他の属性の値にもとづき変わるダイナミックリ
ストを有している。

リスト手順はそれらのダイナミックリストを生成する責
任がある。

ｆｏｒｍ　　ｍｇｔは５Ｃ−１ｉｓｔ−ｉｎｖ。

ｋｅを介してリスト手順を呼出す。リスト手順は次にＱ
Ｒ−１ｉｓｔ−ｄを介してそのルールの記述を取出す。

それはオプションを制御するためにＱＲ−ａｐｐ−ｃｏ
ｎ　ｆ　ｉ　ｇ−ｄまたはＱＲ−。

ｂｊｅｃｔ−ｄａｔａを介して得られた情報を使用する
ことができる。それは次に表示のためのリストの内容が
何であるかを決定しかつそのリストを１ｉｓｔ−ｃｏｎ
ｔｅｎｔｓを介して出力する。

第１７図は、「エディツト手順（Ｅｄｉｔ　Ｐ＋ｏｃｅ
ｄｕ＋ｅｓ）ノード２４４を示す。エディツト手順は属
性に対する有効性の制約を確立するために規定される。

ある属性がそれらの有効性の制約を通るか否かを判定す
るための規則はエディツト手順において具体化されてい
る。各属性はそれに割当てられたゼロからＮのエディツ
ト手順を有することができる。属性は有効であるために
すべてのエディツトを通らなければならない。

Ｇｒａｐｈ　　ｍｇｔは５Ｃ−ｅｄｉｔ−ｉｎｖｏｋｅ
を介してエディツト手順を呼出す。エディツト規則の記
述は次にＱＲ−ｅｄｉｔ−ｄを介して取出される。−組
の情報はどのような種類のオブジェクトおよびフィール
ドに対しそれが呼出されているか（およびそれが単一フ
ィールドに対し呼出されているかあるいはクロスフィー
ルドエディツトに対し呼出されているか）を決定するた
めの手順をイネーブルする呼出しにおいて渡される。

エディツト手順は次に該属性の値が有効か否かを判定す
る。それは（ＱＲ−ｏｂ　ｊ　ｅ　ｃ　ｔ−ｄａ　ｔａ
を介して）そうするために他の予め格納されたデータを
利用することができる。ＱＲ−ａｐｐ−ｃｏｎｆｊｇ−
ｄから得られた情報を任意のオプジョンを決定するため
に使用することができる。

もしその値が有効であれば、５Ｃ−ｅｄｉｔ−ｉｎｖｏ
ｋｅはＡＣＣＥＰＴと共に完了する。もし該フィールド
が有効でなければ（かつ単一フィールドエディツトモー
ドにあれば）、エディツト手順はＦＭ−ＤＯ−ＳＥＬＥ
ＣＴを介してエラーのフィールドの選択を強制し、エラ
ーのフィールドにＦＭ−Ｆ　Ｉ　ＥＬＤ−ＩＮ−ＥＲＲ
ＯＲを介してフラグを立てかつ次に５Ｃ−ｅｄ　ｉ　ｔ
−１ｎｖｏｋｅはりジェツトと共に完了する。

戻る前に、エディツト手順はユーザに情報を表示するオ
プションを有している。それは受領確認される必要がな
いアトバイザリ情報を示すためにＦＭ−ＬＯＣＡＬ−Ｍ
ＳＧを使用することができる。それはユーザが進むこと
ができる前に受領確認されなければならない情報を表示
するためにＦＭ−ＬＯＣＡＬ−ＥＲＲＯＲを使用するこ
とができる。もしクロスフィールドエディツトモードで
あれば、エディツト手順が（ＦＭ−Ｆ　Ｉ　ＥＬＤ−Ｉ
Ｎ−ＥＲＲＯＲを介して）エラーになっているフィール
ドにフラグを立てるのみであるべきでありかつりジェツ
トと共に５Ｃ−ｅｄ　ｉ　ｔ−１ｎｖｏｋｅを完了する
。

第１８Ａ図から第１８Ｄ図までは、付属書類Ｂの擬似コ
ードに対応するフローダイアグラムを示し、ＤＥＣＬの
機能が本発明の好ましい実施例に従って属性とどのよう
に関連しているかを示す。

第１８Ａ図において、入力イベントは判断ボックス５０
０に入る。もし該イベントがデフオール）　（ＤＥＦＡ
ＵＬＴ）であれば、それは第１．８　Ｂ図のルーチンＡ
に進みかつ最終的に経路５０１を介して次の入力イベン
トを取扱うために戻る。もしそうでなければ、それは判
断ボックス５０２に進む。ボックス５０２において、も
しイベントが新しい（ＮＥＷ）のものであれば、それは
第１８Ｃ図のルーチンＢに進みかつ最終的に経路５０３
を介して戻り、ボックス５１０に入る。もしそうでなけ
れば、それは判断ボックス５ｏ４１ご続く。

判断ボックス５０４において、もしイベントがクロスエ
ディツト（ｃＲ，０ＳＳ−ＥＤＩＴ）であれば、それは
第１８Ｄ図のルーチンＣに進み最終的には経路５０１を
介して戻り、次の入力イベントを取扱う。もしそうでな
ければ、それは判断ボックス５０６に続く。

判断ボックス５０６において、もしイベントがＯＫ、Ｍ
ＯＲＥまたは５ＩＧＮであれば、それは判断ボックス５
０８に進み、そこでもしエディツト失敗（Ｅｄｉｔ　　
Ｆａｉｌｅｄ）７ラグがセットされておれば、手順は経
路５０１を通って戻り次の入力イベントを処理するが、
もしそうでなければボックス５１０に進み、そこでイベ
ントが対話ノードに渡される。判断ボックス５０６にお
いて、もしイベントがＯＫ、ＭＯＲＥまたは５ＩＧＮで
なければ、それは判断ボックス５１０に進みかつ次に手
順は経路５０１を介して戻り次の入力イベントを取扱う
。

第１８Ｂ図において、ルーチンＡはボックス５１２に入
ることにより始まり、そこでデフオート（Ｄ　Ｅ　Ｆ　
Ａ　Ｕ　Ｌ　Ｔ）手順が現在の属性に対し属性テーブル
で探される。次に、ルーチンは判断ボックス５１４に入
り、そこでデフォールト手順がその属性に対して存在し
なければ、ルーチンは退出し、かつもしそれが存在すれ
ばルーチンはボックス５１６に進む。ボックス５１６に
おいて、デフォールト手順が呼出され、かつ次にルーチ
ンＡは退出する。

第１８Ｃ図において、ルーチンＢはボックス５１８に入
ることにより始まり、そこで現在のフィールドの属性タ
イプおよび規則（ルール）が属性テーブルにおいて探さ
れる。次に、ボックス５２０において、該属性タイプお
よびその親に対するエディツト（ＥＤＩＴ）規則が属性
タイプテーブルにおいて探される。

次に、ルーチンはループボックス５２４に進み、そこで
さらにエディツト規則がテーブルリストにあれば、ルー
チンはボックス５２６に進みそこでエディツト規則が読
み出されかつルーチンは判断ボックス５２２に進む。判
断ボックス５２２において、もしエディツト規則が通れ
ば、ルーチンはループボックス５２４に戻るが、もしそ
うでなければ、それは退出する。

それ以上のエディツト規則がリストにない時、ルーチン
はエディツト規則ループを去りかつボックス５２８に進
み、そこで現在の属性に対するＣＡＬＣルールが属性テ
ーブルにおいて探される。

次にルーチンはループボックス５３０に進み、そこでさ
らにＣＡＬＣルールがテーブルリストにあれば、それは
ボックス５３２に進み、そこでＣＡＬＣルールが読み出
され、かつ次にループボックス５３０に戻る。それ以上
のＣＡＬＣルールがリストにない時、ルーチンは退出す
る。

第１８Ｄ図において、ルーチンＣはボックス５３４に入
ることにより始まりそこでＥｄｉｔ　　Ｆａｉｌｅｄフ
ラグがクリアされる。次に、ボックス５３６において、
現在のフィールドのＣＲＯ８Ｓ−ＥＤＩＴルールが属性
テーブルにおいて探され、かつルーチンはループボック
ス５３８に進む。

ループボックス５３８において、もしさらにＣＲＯ３Ｓ
−ＥＤＩＴルールがリストにあれば、ルーチンはボック
ス５４０に進むが、もしそうでなければそれは退出する
。ボックス５４０において、特定のＣＲＯ８Ｓ−ＥＤＩ
Ｔルールが呼出される。

次に、ルーチンは判断ボックス５４２に進み、もしＣＲ
Ｏ８Ｓ−ＥＤ　ＩＴルールが通れば、ルーチンは戻りル
ープボックス５３８に入るが、もしそうでなければボッ
クス５４４に進み、そこでＥｄｉｔ　　Ｆａｉｌｅｄフ
ラグがセットされ、それに応じてルーチンＣは退出する
。

当業者には、開示された発明は数多くの方法で修正可能
でありかつ上に特定されかつ説明された好ましい形態以
外の数多くの実施例を取り得ることが明らかであろう。

例えば、グラフマネージャおよびフォームズマネージャ
の間の機能性の分割は種々の方法によって変更可能であ
り、それにより一方が他方により行なわれるものとして
ここに説明された機能を行ないかつその逆を行なうこと
が可能である。

従って、本発明の真の精神および範囲内にある本発明の
すべての修正を添付の請求の範囲によりカバーすること
を意図している。

属性タイプ 親タイプ エディツト 属性タイプテーブル −（’−１（ト）寸いゆトω００−（へ）□□□寸いり
トα−（Ｎ　（’Ｊ　　Ｎ　Ｎ　（’＋　！’−１（’
＋　（’ｌ　　ぐ、ｌ　ｍ　　ｍ　ｍ　ｍ　ｃｑ　ｃｎ
　ｒｑ　ｃｎ　ｍ　ｍＣａ１ｌ　ａｌｌ　ｔｈｅ　ｃｒ
ｏｓｓ　ｅｄｉｔ　ｒｕｌｅｓ　ｆｏｕｎｄ　ｉｎ　ｏ
ｒｄｅｒ。

Ｂｒｅａｋ　（ｎｅｘｔ　ｅｖｅｎｔ）。

Ｃａ５ｅ　ＯＫ： Ｃａ５ｅ　５ＩＯＮ’ −【 １ｓｅ Ｐａｓｓ　ｔｈｅ　ｅｖｅｒｕ　ｏｎ　ｔｏ　ｔｈｅ　
ｄｉａｌｏｇ　ｎｏｄｅ。

Ｂｒｅａｋ　（ｎｅｘｔ　ｅｖｅｎｔ）。

Ｄｅｆａｕｌ＋

【図面の簡単な説明】

第１図は、典型的な病院環境における患者ケア処理を、
−殻内に、図示するブロック図である。 第２図は、本発明の方法を導入したデータ処理システム
の好ましい実施例を示すブロック図である。 第３図は、第１図および第２図に示される自動化診療記
録システムにおける計測されかつ計算された患者のパラ
メータを示す、典型的なフローシート情報スクリーンを
示す説明図である。 第４図は、フォームズマネージャのアプリケーションプ
ログラムおよびデータベースに対する関係を示すブロッ
ク図である。 第５図は、本発明のアブリケーションソフトウエアアー
キテクチャアのブロック図である。 第６Ａ図および第６Ｂ図は、２つの機能グラフを示す説
明図である。 第７図は、対話ノードの構造を示す説明図である。 第８図は、デフォールト手順の構造を示す説明図である
。 第９図は、エディツト手順の構造を示す説明図である。 第１０図は、計算手順の構造を示す説明図である。 第１１図は、リスト手順の構造を示す説明図である。 第１２図は、グラフマネージメントの「グラフ・シーケ
ンシング」機能を示す説明図である。 第１３図は、グラフマネージメントの「マネージ入力対
話」機能を示す説明図である。 第１４図は、「対話ノード」を示す説明図である。 第１５図は、「デフォールト手順」ノードを示す説明図
である。 第１６図は、「リスト手順」ノードを示す説明図である
。 第１７図は、「エディツト手順」ノードを示す説明図で
ある。 第１８Ａ図から第１８Ｄ図までは、付属書類Ｂの擬似コ
ードに対応するフロー図であり、ＤＥＣＬの機能がどの
ようにして本発明の好ましい実施例に従って属性と関連
しているかを示す。 １：ローカルエリアネットワーク、 ２．２２，３２．３４および８５： ワークステーション、 ３；スクリーン、　　　４：ハウジング、５；マウス、 ８．１０，２８，３０：ベツドサイド装置、６２；ファ
イルサーバ、 ６４；ディスク記憶装置、 ８１．８３＋プリンタ、 １１１：フォームズマネージャ、 １１２；入力装置、　　１１３：デイスプレィ、１１４
・アプリケーションプログラム、１１３．１４６：デー
タベース。

Claims (1)

1. 【特許請求の範囲】 １、データが入力されかつ１つまたはそれ以上のエディ
   ット手順により有効化されるデータ処理システムにおけ
   る、前記エディット手順を行なうための方法であって、
   前記方法は、 （ａ）前記入力データを複数の属性の内の１つに分類す
   る段階、 （ｂ）前記複数の属性に対するエディット手順のテーブ
   ルを提供する段階、 （ｃ）与えられた属性が入力された時、前記テーブルを
   チェックするためのルーチンに入りそれが前記属性に対
   する何らかのエディット手順を含んでいるか否かを判定
   し、 ｉ）もし含んでおれば、前記エディット手順を前記属性
   に適用し、そして ｉｉ）もし含んでおらなければ、前記ルーチンを退出す
   る、 段階、 を具備する前記エディット手順を行なうための方法。 ２、前記段階（ａ）において、前記属性は複数の属性タ
   イプの内の１つに分類され、前記段階（ｂ）においてエ
   ディット手順の前記テーブルは前記複数の属性タイプの
   内の少なくとも１つに対して提供され、かつ前記段階（
   ｃ）において前記与えられた属性が入力された時、その
   属性タイプが判定されかつ前記ルーチンが前記テーブル
   をチェックしてそれが前記属性タイプに対する何らかの
   エディット手順を含んでいるか否かを判定する、請求項
   １に記載の方法。 ３、前記段階（ｃ）において、前記テーブルがチェック
   されそれが前記属性の子供のタイプに対する何らかのエ
   ディット手順を含んでいるか否かを判定し、 ｉ）もし含んでおれば、前記エディット手順を前記属性
   および前記属性の子供のタイプに適用し、そして ｉｉ）もし含んでおらなければ、前記ルーチンを退出す
   る、 請求項２に記載の方法。 ４、前記段階（ｂ）において前記テーブルは前記複数の
   属性タイプの内の１つに対する少なくとも２つのエディ
   ット手順を含み、かつ前記段階（ｃ）において前記与え
   られた属性が入力された時、前記テーブルがチェックさ
   れそれが前記属性に対する何らかのエディット手順を含
   むか否かが判定され、かつもし含んでおれば、前記エデ
   ィット手順が所定の順序で前記少なくとも２つの属性に
   適用され、かつ、もし含んでおらなければ、前記ルーチ
   ンが退出される、請求項１に記載の方法。 ５、前記段階（ｃ）における順序は前記テーブルによっ
   て特定される請求項４に記載の方法。 ６、前記段階（ｃ）における順序はエディット手順を前
   記属性タイプの子供のタイプに適用する前にすべての適
   用可能なエディット手順を与えられた属性タイプに適用
   するものである請求項４に記載の方法。 ７、データが入力されかつデフォールト手順によりある
   デフォールト値に設定されるデータ処理システムにおけ
   る、前記デフォールト手順を行なうための方法であって
   、該方法は、 （ａ）前記入力データを複数の属性の内の１つに分類す
   る段階、 （ｂ）前記複数の属性に対するデフォールト手順のテー
   ブルを提供する段階、 （ｃ）与えられた属性が入力された時、前記テーブルを
   チェックするルーチンに入りそれが前記属性に対するデ
   フォールト手順を含むか否かを判定し、 ｉ）もし含んでおれば、前記デフォールト手順を前記属
   性に適用し、かつ ｉｉ）もし含んでおらなければ、前記ルーチンを退出す
   る、 段階、 を具備する前記デフォールト手順を行なうための方法。 ８、データが入力されかつある値が計算手順を用いて計
   算されるデータ処理システムにおける、前記計算手順を
   行なうための方法であって、前記方法は、 （ａ）前記入力データを複数の属性の内の１つに分類す
   る段階、 （ｂ）前記複数の属性に対する計算手順のテーブルを提
   供する段階、 （ｃ）与えられた属性が入力された時、前記テーブルを
   チェックするためのルーチンに入りそれが前記属性に対
   する計算手順を含むか否かを判定し、 ｉ）もし含んでおれば、前記計算手順を前記属性に適用
   し、かつ ｉｉ）もし含んでおらなければ、前記ルーチンを退出す
   る、 段階、 を具備する計算手順を行なうための方法。 ９、前記段階（ｂ）において、前記テーブルにおける前
   記計算手順の内の所定のもののみが前記属性に適用され
   るよう指定される請求項８に記載の方法。 １０、データが入力されかつリストがリスト手順を用い
   て構築されるデータ処理システムにおける、前記リスト
   手順を行なうための方法であって、前記方法は、 （ａ）前記入力データを複数の属性の内の１つに分類す
   る段階、 （ｂ）前記複数の属性に対するリスト手順のテーブルを
   提供する段階、 （ｃ）与えられた属性が入力された時、前記テーブルを
   チェックするルーチンに入りそれが前記属性に対するリ
   スト手順を含むか否かを判定し、ｉ）もし含んでおれば
   、前記リスト手順を前記属性に適用し、かつ ｉｉ）もし含んでおらなければ、前記ルーチンを退出す
   る、 段階、 を具備するリスト手順を行なうための方法。 １１、前記段階（ａ）において、前記属性は複数の属性
   タイプの１つに分類され、前記段階（ｂ）において、前
   記エディット手順のテーブルは前記複数の属性タイプの
   内の少なくとも１つに対する少なくとも１つのクロスエ
   ディット手順に対し提供され、かつ前記段階（ｃ）にお
   いて、前記与えられた属性が入力された時、その属性タ
   イプが判定されかつ前記ルーチンは前記テーブルをチェ
   ックしてそれが前記属性タイプに対するクロスエディッ
   ト手順を含むか否かを判定する、請求項１に記載の方法
   。 １２、データがフォームの１つまたはそれ以上のフィー
   ルドに入力されるデータ処理システムにおける、デフォ
   ールト手順、エディット手順、計算手順、およびリスト
   手順の種々の組合わせがイネーブルされる方法であって
   、該方法は、 （ａ）前記入力データを複数の属性の内の１つに分類す
   る段階、 （ｂ）前記複数の属性に対するデフォールト手順のテー
   ブルを提供する段階、 （ｃ）前記複数の属性に対するエディット手順のテーブ
   ルを提供する段階、 （ｄ）前記複数の属性に対する計算手順のテーブルを提
   供する段階、 （ｅ）前記複数の属性に対するリスト手順のテーブルを
   提供する段階、 （ｆ）与えられた属性が入力された時、前記テーブルを
   チェックするためのルーチンに入りそれらが前記属性に
   対するデフォールト、エディット、計算、またはリスト
   手順を含むか否かを判定し、ｉ）もし含んでおれば、前
   記手順の１つまたはそれ以上を所定の優先度に従って前
   記属性に適用し、かつ ｉｉ）もし含んでおらなければ、前記ルーチンを退出す
   る、 段階、 を具備する前記方法。 １３、前記段階（ｆ）の（ｉ）における優先度は前記テ
   ーブルによって特定される請求項１２に記載の方法。