"所定の分類に従って記録された複数の文書及び文書の各項目に対応する詳細データを記録した記録手段と、その記録手段にアクセスしてそれらの編集を行う編集手段を備えたデータ処理システムであって、前記文書は少なくとも1つの項目を有し、その項目にはアドレス情報が設定され、そのアドレスには可変長データが格納され、前記文書データは統一したデータ様式によって記録され、前記編集手段は文書群全体のデータにアクセス可能とされて、文書群の項目のデータの編集、参照が可能とされていることを特徴とするデータ処理システム。前記文書には個人情報に関する情報が記録され、各可変長データは個人特定情報と関連付けられて記録されていることを特徴とする請求項1記載のデータ処理システム。文書ごとにアクセスを許可するか否かのアクセス権限認証手段が設定されていることを特徴とする請求項1~2いずれか記載のデータ処理システム。編集モードによるアクセスがされている文書には、他のアクセスを禁止するアクセス禁止手段が設けられていることを特徴とする請求項1~3いずれか記載のデータ処理システム。編集したデータに付随して編集者と編集時間が記録される構成とした請求項1~4いずれか記載のデータ処理システム。文書の分類に応じてディスプレイへの表示スタイルを規定するスタイル情報が設定されていることを特徴とする請求項1~5いずれか記載のデータ処理システム。医療、教育、行政、企業いずれも共通の問題に起因する課題があるが、本明細書では、医療の場で用いられる電子カルテに例をとり説明する。電子カルテは膨大なデータを扱うので、データベースDataBaseManagementSystemと呼ばれる、データの記録、参照、検索などを行う専用のソフトウェアを用いる。最も用いられているのは、データを表形式Relationで記録するRDBリレーショナルデータベースRelationalDataBaseである。リレーショナルデータベースは、比較的構造が単純で高速処理が可能であり、SQLSystemicQueryLanguageと呼ばれる標準化された問い合わせ言語が、早期より整備されてきたため、電子カルテは勿論、大量のデータを処理するシステムでは、永く標準的に用いられてきている。表の中の行レコードrecordあるいはタプルtupleは、予め設計された項目のグループからなり、一件データを表す。各項目は、各々定められたデータの長さ固定長を有している。従って、一行のデータ長も固定されている。記録ファイル内では、行の終わりに引き続いて、次の行が先頭から記録される。一行を構成する項目群に、追加や削除などの変更が加わると、一行の長さなどが変化するため、記録ファイルを再構成する必要がある。データが大量に蓄積されたあとでの再構成は、大変な作業量となるため、データベース運用開始時に、綿密な設計が不可欠である。例えば、患者基本情報では、患者ID、名前、フリガナ、性別、誕生日などであるし、薬剤処方システムに必要なデータ項目は、薬品コード、医薬品名、単位、用量、回数、指示などである。看護支援システムでは、プロブレム番号、プロブレム、開始日時、終了日時等などであり、部門システム毎に全く必要項目が異っている。項目立ての異なる部門データを同一のリレーションで処理することは不可能である。従って、項目立ての異なる部門ごとに、別々のリレーションを作成し管理する必要があった図2。従来の電子カルテは、前記の理由により、薬剤処方システム、注射処方システム、看護支援システム、放射線読影支援システム、等など多数の部門システムの集合体として構築されてきた図3。各々の部門システムは、各々独自フォーマットのデータを持ち、他の部門システムとは、HL7などの標準規格を用いてデータの問い合わせ、返答を行うというものである図4。各々の部門システムの独立性は高いので、手分けして開発が可能で、データ交換の標準規格にさえ従っているなら、ユーザー医療機関は、様々な会社の製品を自由に組み合わせて、自院に最も適合した総合システムを、短期間で安価に構築できるはずであった。さらに、数十年前のリレーショナルデータベースは、索引などの機能が弱く、データが増えてくると動作スピードが極端に低下するという問題があった。データを、部門毎に分散蓄積するのは、動作速度を長期に維持する上でも、好ましい形態だった。また、当時の医療機関は、職種間の壁が厚く、職種をまたがっての仕事上の交流は少なかった。従って、部門システムがあれば、その職種のスタッフにとっては、充分に業務に耐えるものであった。このように、先の図3に示したような部門システムの集合体という電子カルテの構造アーキテクチャーarchitectureは、電子カルテの黎明期である20~30年前の技術環境では、自然で最良の解であった。ところが、21世紀に入って状況は一変した。人口高齢化に伴う疾病構造が変化し、多数の疾病を同時に有する高齢者が治療対象の主体となってきた。医師、看護師はもちろん、薬剤師、検査技師、リハビリスタッフ等などの多数の職種が連携してチーム医療に当たるのが当然のこととなった。例えば薬剤師が処方オーダーを処理する際には、医師記事はもちろん、看護師のフォーカスチャート、介護士やリハビリスタッフの業務記録などを参照しながら、副作用の出現の有無をチェックする必要がある。最適の医療、安全管理の面で、多職種間の情報共有が不可欠となってきた。現代の医療はチーム医療が大原則である。医師、看護師はもちろん、リハビリスタッフ、管理栄養士、社会福祉士、検査技師等などがチームを組み、患者に総合的な医療サービスを提供することで、有効性の高い安全な医療サービスを提供できる。このチーム医療が有効に機能するためには、情報の共有が大前提となる。各職種が何を考えているかが、院内のどこにいても即座に把握できることが不可欠である。チーム医療が前提となってくると、種々異なるフォーマットであちこちにデータが分散蓄積されているような、部門システムの集合体である、図4で示したような従来の電子カルテでは、不都合な点が、多々生じてきた。部門システムが過度の高機能化で肥大化し、あるいは異なる会社の製品の組合せであることから、一時点では一つの部門システムしか動作しない電子カルテが少なくない。こうなると他職種の情報参照のためには、その都度参照したい職種の部門システムを、数十秒かけて立ち上げ、データを読み込まねばならない。確認後、今度は自職種の部門システムを再度立ち上げなおして作業再開しなければならない。これでは現実に業務が回らないので、結局未確認のままの見切り発車となりやすい。重要情報の見落としは必発の危険な状況である。部門データの相互参照が困難であるため、スタッフは防衛策として、全ての関連データを職種の部門ごとに重複して記録せざるを得ない。これでは、記録内容が部門間で矛盾が生じたりすることは避けがたい。ある病院では、見落としを避けるために、薬局長が3台のPCを同時に立ち上げ、一台で処方処理、他の2台で同患者の医師記事や注射処方などの参照確認を行っているようだ。複数PCを独占できない職種では、別の部門システムのデータを、自分の部門システムに手作業で打ち込みなおしている。部門システムを2つ同時に立ち上げられないから、コピーペーストcopypasteすることすらできないからである。患者データを端末PCにダウンロードし、ローカルのハードディスクなどに一旦記録した上で処理を進める仕様の電子カルテが多いが、この場合は、PC盗難で患者個人情報の漏洩が起こる危険があることは言うまでもない。電子カルテの優劣を論じる以前に、最も基本的な要件がある。一人の患者のカルテを、同時に複数のスタッフが開いて、医療上の指示オーダーや記事などを同時並行入力できるという機能である。この機能が満足されていないと、困ったことが起こる。誰かが或る患者のカルテを開いたとする。別のスタッフが同じ患者のカルテを開こうとすると、このカルテは、既に使用中です。参照モードで開きますなどの警告が表示される。つまり、2番目以降に開いたスタッフは、其のカルテを読むこと参照は出来るが、オーダーや記事の入力編集はできないというのである。甚だしい製品になると、参照すら出来ない仕様となっている。カルテをスタッフ間で奪いあっていた紙カルテ時代と大して変わらないことになる。平成20年度から、勤務医の負担軽減の一環として診療補助者に加算が付くようになった。病院によっては、診療補助者を外来に配置して、多忙な勤務医の外来入力業務を軽減すべく試行導入が始まっている。同時並行入力機能を欠いた電子カルテでは、医師が診察して医師記事を書いている最中は、診療補助者は、その患者のカルテを編集モードで開けない。このため、医師の指示をメモしておいて、医師の診察が終了してから、改めてその患者のカルテを編集モードで開き、メモしておいた内容を入力することになる。診察の場面と入力の場面がずれるため、煩雑極まり無いことになる。入力の正確さは、期待しがたい。或いは、医師のIDを用いて、記事からオーダーまで全て診療補助者が入力することもありうるが、セキュリティや入力ミス時の法的責任で問題がある事は言うまでもない。かつて山陰地方の或る県立病院で、莫大な補助金を投入して電子カルテの開発が行われたことがあった。その病院の関係者の講演を聴いたことがあるが、フロアとの奇妙な質疑応答があったことを記憶している。日中に医師の指示が変更された時どう対処するかという質問である。電子カルテなのだから、指示を変更したら、その瞬間にすべての表示が書き換えられ、新しい指示に基づいて作業を継続するのは当り前だろう。と発明者は思ったのだが、演者の返答に仰天した。それが大変な問題なのですよ。変更された指示を印刷して、主治医や師長が病室の看護師に届けています。とのことであった。数日間は意味がわからなかったが、根本原因が同時並行入力機能の欠如にあることに漸く気づいた。医師と看護師のPCを両方オンラインにしておくと、必ずカルテの取合いが起こる。これを防ぐため、看護師のノートPCは、朝の段階の指示データをノートPCにダウンロードした後、オフラインとしていたのだ。勤務終了時点でノートPCを再びオンラインにして、この間の記録をサーバーに書き戻すというものだ。指示の変更があっても、オフラインになっている看護師のノートPCには変更が反映されないため、ナースステーションで変更部分を印刷して、主治医や師長が担当看護師の所へ走ることになる。当院の紙カルテ時代の経験では、このような形での指示の途中変更は、通常の4~5倍の頻度でミスが発生していたが、この病院ではどうだったのだろうか。なぜ並行入力ができないのか、技術的に解説する。前述のように、電子カルテシステムを支えているリレーショナルデータベースでは、データを表形式で記録し、操作は、表の中の行単位で行われる。この際、内容の異なる複数のレコードが同じ行に書き込まれるとレコードの競合が起こると、その内の一つを除いて他は消えてしまうため、データベース全体の内容の一貫性が失われ、甚だしい場合はデータベース自体がクラッシュしてしまう。この問題を避けるため、データベースでは、レコードロック機能により、競合が起こりうるレコードを書き換え禁止にしてしまう。或るスタッフが、或る患者のカルテを開くと、このスタッフが編集を行う可能性があるため、このスタッフが当該患者のカルテを開いている間は、この患者のすべてのレコードは、他のスタッフに対してロックされ、参照は可能であるが、編集作業が出来なくなる。これが従来型の電子カルテで並行入力ができなかった理由である。ここで疑問が生じる。何故その患者の全レコードをロックしなければならないのか編集中のレコード一行だけをロックすれば良いではないか本来、編集中の文書レコードだけロックしておけば、クラッシュの危険はない。通常、文書の種類ごとに担当職種が分かれているので、各スタッフが現在編集中の文書のみロックしておけば、他職種の並行入力に支障が出ることは殆どない。部門システムの寄木細工からなる従来の電子カルテでは、部門システムごとにリレーションのデータを管理している。同時に一部門システムしか立ち上立ち上げられず、しかもその部門の当該患者データを端末PCにダウンロードして編集作業を行うような状況では、他の部門システムでの当該患者のデータへの他のスタッフからのアクセス状況が全く把握できない。いわばオフライン同様となっている。ダウンロードされた後に編集を行い、データを書き戻す際に、万一競合書き込みが起こってしまうと、最悪の場合、病院全体の電子カルテシステムがクラッシュする。このため、安全策として、誰かが或る患者のカルテを編集モードで開いたら、その患者の全データをロックせざるを得ないのである。以上述べてきたように、部門ごとにシステムをモジュール化し、モジュール毎にデータとソフトウェアを独立して管理しておき、必要に応じてモジュールを組み合わせるというやり方は、数十年前は最良の解であった。しかし、医療機関での仕事のやり方が変化してゆくにつれ、データがモジュール毎に分割管理されていることが、逆に最大のネックとなってしまった。これは、モジュラリティの罠modularitytrapとして一般的にIT業界で良く知られている事態である。この問題への処方箋は、統合型アーキテクチャーintegratedarchitectureへの移行である。本発明はかかる従来の問題点を解決するためになされたものであって、その目的とするところは、多種多様な文書類を複合参照し、また複数のスタッフが同一案件にかかわる文書類の同時並行編集を可能としチーム医療や組織的な仕事のやり方に貢献できるデータ処理システム提供することにある。前記目的を達成するための手段として請求項1記載のデータ処理システムでは、所定の分類に従って記録された複数の文書及び文書の各項目に対応する詳細データを記録した記録手段と、その記録手段にアクセスしてそれらの編集を行う編集手段を備えたデータ処理システムであって、前記文書は少なくとも1つの項目を有し、その項目にはアドレス情報が設定され、そのアドレスには可変長データが格納され、前記文書データは統一したデータ様式によって記録され、前記編集手段は文書群全体のデータにアクセス可能とされて、文書群の項目のデータの編集、参照が可能とされていることを特徴とする。請求項2記載のデータ処理システムでは請求項1記載のデータ処理システムにおいて、前記文書には個人情報に関する情報が記録され、各可変長データは個人特定情報と関連付けられて記録されていることを特徴とする。請求項3記載のデータ処理システムでは請求項1~2いずれか記載のデータ処理システムにおいて、文書ごとにアクセスを許可するか否かのアクセス権限認証手段が設定されていることを特徴とする。請求項4記載のデータ処理システムでは請求項1~3いずれか記載のデータ処理システムにおいて、編集モードによるアクセスがされている文書には、他のアクセスを禁止するアクセス禁止手段が設けられていることを特徴とする。請求項5記載のデータ処理システムでは請求項1~4いずれか記載のデータ処理システムにおいて、編集したデータに付随して編集者と編集時間が記録される構成とした。請求項6記載のデータ処理システムでは請求項1~5いずれか記載のデータ処理システムにおいて、文書の分類に応じてディスプレイへの表示スタイルを規定するスタイル情報が設定されていることを特徴とする。本発明では、前記構成を採用しているので以下の効果を有する。請求項1記載のデータ処理システムでは、文書は少なくとも1つの項目を有し、その項目にはアドレス情報が設定され、そのアドレスには可変長データが格納されているので、項目とその項目に対応するリレーショナルデータベースが構成される。つまり、文書は項目に設定されたアドレス情報と、そのアドレスに格納された可変長データから構成されるので、必要なデータは可変長データに集約して記録保存される。そして、文書データは統一したデータ様式によって構成されているので、データ全体を一元的に取り扱うことができ、データの参照、編集がスムーズに行われる。請求項2記載のデータ処理システムでは、文書には個人情報に関する情報が記録され、各可変長データは個人特定情報と関連付けられて記録されているので、データ編集中、編集後に誰のデータであるか分からないという事態は起こりえず、個人情報を取り扱う上で適切なデータ処理システムが実現される。請求項3記載のデータ処理システムでは、文書ごとにアクセスを許可するか否かのアクセス権限認証手段が設定されているので、ユーザーの権限に応じた適切な情報管理が行われる。請求項4記載のデータ処理システムでは、編集モードによるアクセスがされている文書には、他のアクセスを禁止するアクセス禁止手段が設けられているので、文書の同時多重書き換えが防止され、文書の統一性が確保される。請求項5記載のデータ処理システムでは、編集したデータに付随して編集者と編集時間が記録される構成としたので、各データについて責任の所在が明確にされる。請求項6記載のデータ処理システムでは、文書の分類に応じてディスプレイへの表示スタイルを規定するスタイル情報が設定されているので、文書の性質に応じた表示スタイルが適用されて表示される。本発明を実施するための最良の形態を説明する。本発明のデータ処理システムは図1に示すように、特定の処理を実行するサーバーと、そのサーバーからのサービスを受けるクライアントで構成され、それらはネットワークシステムを構成し、それぞれのコンピュータには、入力装置、制御装置、記録装置等が備えられている。ネットワーク上には複数のコンピュータが接続されており、それぞれのコンピュータがサーバーの記録装置へ、または各コンピュータの記録装置へアクセスする。主要なデータ文書群はサーバーの記録装置に記録されるが、データの種類によってはクラインアントコンピュータに担当させて記録することも可能である。尚、サーバーはウェブを介して遠隔地に設置しても良い。サーバーやクライアントコンピュータまたはネットワーク上には編集手段が設置されており、クライントコンピュータから発せられた指令によってサーバーの記録手段あるいはネットワークに接続された各記録手段のデータから必要なデータを検索、集計してそれらを編集しユーザーに提示する。データ処理システムには後述するアクセス権限確認手段が設定され、医療現場の各スタッフが現場のコンピュータから権限を確認された上でネットワークに接続する。以下、本発明の具体的実施例を説明する。図5、図6は、患者基本情報と薬剤処方を、各々RDBのリレーション形式とXML形式で表現したものである。先に述べたとおり、リレーショナルデータベースの表リレーションの各々の桝目セルcellは、予め設定された固定長のデータでなければならない。しかし、XML形式のテキストデータは、さまざまな長さをもつ可変長データため、そのままではリレーションに格納できない。そこで、別の記録領域に可変長のXMLデータを記録しておき、リレーションの桝目には、そのXMLデータが記録されている領域を指し示す固定長のアドレスだけを格納する図7。こうすれば、リレーショナルデータベースの枠組みの中でXMLデータを処理できるようになる。このようなデータベースは、XMLリレーショナルデータベースと呼ばれている。実用上のシステムでは、XMLがテキストのままでは処理が遅くなるので、XMLテキストデータを機械処理可能な内部表現バイナリー形式でオブジェクト化したものを記録するXMLオブジェクトリレーショナルデータベースXMLObjectRelationalDataBase。さらに、高速処理するための索引を整備する。索引のデータ量は、本体であるXMLデータの4~6倍に達するという。これにより、現在はXMLデータを、実用に耐える高速で処理することが可能となっている。部門ごとのデータ項目建てが異なっていても、前述のように、一つの文書の全データ項目は、一つのXML形式データファイルに変換できる。部門毎に文書のデータフォーマットが異なっていても、XML化してしまえば、全て一つの可変長XMLファイルに過ぎない。従って、リレーションの一つの枡目に、そのフォーマットの一件文書の全XMLデータを指し示すアドレスを格納すればよい。こうなると、図7に示したように、患者ID、文書カテゴリー、文書作成日時、作成者などの共通項目と、その文書固有のXMLデータを格納する実データ項目という項目建てとすれば、すべての部門システムのデータの項目建ては共通となり、ひとつのリレーションに容易に統合できる。ハードの性能向上と、XMLオブジェクトリレーショナルデータベースの索引の性能向上もあり、電子カルテの全データを統合して、一つのリレーションとして扱ったほうが、現在では利便性に優れるようになってきた。図面について詳しく説明すると、図5は個人に関する情報を一覧表示したものであり、個人名に対応する患者ID、フリガナ、性別、生年月日等を表している。図5の上段は従来のリレーショナルデータベースでの記録形式を示しており、図5下段は上段のデータがXML言語によってどのように記録されているかを表している。図5下段ではのタグで囲まれた領域が患者一名に対応し、その中にID、名前、生年月日等の項目が設定されている。これらのデータは上下に連続して、多数の患者の個人情報を記録している。図6上段は薬剤に関する情報を医薬品ごとに従来のリレーショナルデータベースでの記録形式で一覧表示したものであり、薬剤の態様、用法等単位、用量、回数、指示を表している。これらの一覧データは図5と同様にXML言語で記録され、図6下段は上段のデータがXML言語によってどのように記録されているかを表している。図6下段ではのタグで囲まれた領域が一個の薬剤に対応し、その中に医薬品名、指示等の項目が設定されている。これらのデータは上下に連続して、多数の医薬品の情報を記録している。図7は個人に関する情報を一覧にまとめた表である。この表は記録手段に予め作成して文書として作成保存されるが、必要に応じて図5、図6のそれぞれ下段に表したXMLデータを編集手段によって一覧として作成することができる。編集手段は記録手段にアクセスしてデータの検索、編集等を行う手段であり、記録手段に記録された文書群から必要とする文書の検索、取り出し、一覧作成等を行う。一覧作成は目的に応じて個人単位、あるいは、日時単位、その他の設定が可能である。また、編集手段は記録手段に記録された可変長データの取得、提示、書き換え保存等を行う。図7では一行に患者名とその患者に対応する患者基本情報、薬剤処方等の項目が設定され、その行が上下に多数配置されている。図7では、患者ID、作成者ID、作成日時などの基本項目と、患者基本情報や薬剤処方などの文書主体項目が設定され、それぞれの文書主体の項目にはデータの保存先のアドレスが記録されている。そして、それぞれのアドレスには項目に対応するデータが格納されている。このように、文書主体の項目にはアドレス情報が記録され、そのアドレスには可変長データが格納されているので、すべての元となる文書データ様式は共通統一したデータ様式によって記録され、それらを取捨選択して必要とする表に取りまとめることができる。本実施例では、コンピュータを起動させる時に、またはネットワークにアクセスする時にユーザーのパスワードによる認証がなされる。これはユーザーのアクセス権限を認証する手段であり、このパスワードを入力することにより、ユーザーの特定がなされ、ユーザー特有のアクセスできるデータ範囲も同時に規定される。例えば、ユーザーによっては全てのデータにアクセスできる場合もあるが、薬剤処方、看護記録等の一部のデータのみにしかアクセスできない場合もある。また、アクセス先のデータについては編集及び参照モードの両方でアクセスできる場合や、参照モードのみでしかアクセスできない場合が設定される。本実施例では編集モードによるアクセスが発生している場合には、他のユーザーによる同一文書データへのアクセスを禁止するアクセス禁止手段が設けられている。これはデータが同時に多重に書き換えられて統一性が失われることを防止するためのものであり、例えば、一人のユーザーが、或る患者の患者基本情報文書を編集している場合には、他のユーザーは編集モードによる当該文書データへのアクセスは禁止される。このアクセス禁止手段は文書単位で設定される。設定方法の一例としては文書を表す行頭にフラグを設定し、このフラグがオンである場合には編集モードでの他のユーザーのアクセスが禁止される。フラグが立てられた文書にアクセスしてきたユーザーには編集中であることを表示し、アクセスを拒否または参照モードによるアクセスのみを許諾する。アクセス禁止手段のフラグは、文書ごとに設定される。例えば、図7では患者ID0001患者基本情報にフラグが立っている場合でも、同一患者ID0001の薬剤処方の文書にはフラグが立っていない場合がある。同様に、患者ID0002の薬剤処方にフラグが立っている場合でも、同一患者ID0002の患者基本情報の項目にはフラグが立っていない場合がある。このように、同一患者であってもそのカルテにフラグの立っている文書と立っていない文書が出現し、個人のカルテ全体にアクセス禁止を行うのではなく、文書単位でアクセス制限を行う。これにより編集者によるカルテの取り合いを防止して、文書ごとに独立した編集を可能とする。言い換えると、一つのカルテを複数の文書に分割しているので、文書ごとに独立して書き換え等の編集が可能となっている。本実施例では編集が行われた場合には文書単位で編集者IDと編集日時が記録されるようになっている。これは編集確定と共に、編集者IDと編集日時などが夫々の項目に書き込まれている。SQL文などでの処理命令で簡単に項目を用いた検索処理などが可能なので、より好ましい形態といえるが、敢えて項目を立てず、XMLデータ内に夫々のタグを設け、タグ内に直接書き込んでも良い。本実施例ではXML形式で保存された各個人情報については項目ごとに個人特定情報と関連付けられて記録されている。そのため、文書の項目単位で参照、編集する場合にはその項目に対応するデータの個人名が特定された上で行われる。したがって、データ編集中、編集後に誰のデータであるか分からないという事態は起こりえず、個人情報を取り扱う上で適切なデータ処理システムが実現される。本実施例では、個人情報を取り扱う上での多様な文書を記録し、また多様な文書が編集手段によって作成される。そして、それぞれの文書には分類に応じてディスプレイへの表示スタイルを規定するスタイル情報が設定されている。したがって、基本データはXML様式によって一元管理されているが、編集手段によって編集されたデータは文書の分類に応じたスタイルが選択されて見やすい形式としてユーザーの端末に提示される。従来の部門システムは、図4に示したように、個別にデータを管理し、HL7などの形式でデータの問い合わせ、返答を行うものだったため、多元的な参照は複雑を極めた。しかしデータ構造が一元化されれば、複雑な参照もSQL文を一発叩けば簡単に実現する。また、モジュラー構造では、一つのモジュール内で全てを完結しようとして他のモジュールのデータまで全て持ち込む傾向が見られる。このため、あちこちのモジュールにデータが重複して存在し、その整合性がなくなり易い問題があった。他部門のデータ参照が簡単となると、重複データ自体が不要となり、不整合の問題は自動的に消失する。各部門システムは、もはや独自にデータ管理を行う必要は無く、図8に示すように、一元化されたデータベースデータベースバスdatabaseBUSから必要なデータを参照し、処理結果をデータベースバスに書き込む。書き込まれた変化は、当然ながら、他部門システムに対して、全て自動的に反映されることとなる。リレーショナルデータの一元化により、ある瞬間に、どの文書が誰によって編集中か容易に把握できる。編集中の文書は、その文書にだけ編集禁止フラグを立てロックすればよい。従来の電子カルテで見られた、当該患者の全文書レコードを編集禁止にするといった、不合理かつ過剰な制約は必要なくなる。職種によって編集する文書の種類は各々異なるため、複数の職種が同時に同一患者カルテを開いても、稀にしか同時編集の問題は発生しない。外来では、医師の傍で、診療補助者が口頭指示を同時並行入力できるため、診察の効率、入力の正確性が保たれる。医療機関のみならず、教育、行政、企業においても、文書には、可変長の文書内容データそのもの以外に、以下の文書の属性を示す情報が必須である。1何の案件に関する文書であるか、2どのカテゴリーに属する文書であるか、3誰が作成した文書であるか、4いつ作成編集した文書であるか、である。1の案件を特定するIDは、医療機関であれば患者IDであり、教育機関であれば生徒ID、行政機関であれば住民ID、企業であれば得意先IDなど、あるいは、プロジェクトIDなどがある。いずれにせよ、本文書作成装置を使用する環境で、文書群の括りとして適切なIDを選べばよい。2文書カテゴリーIDは、案件を構成する文書群で、文書の種類を示す。医療では、患者基本情報、薬剤処方箋等などであり、教育では、単位登録申請書、試験成績など、行政では、戸籍謄本、住民票、納税履歴など、企業では、取引履歴、営業履歴、トラブル履歴などがある。文書のカテゴリーによって、記載される内容や書式が異なるのは言うまでもない。3スタッフによって、職位、職種、担当範囲などが異なる。権限外の文書を作成、編集することは勿論、場合によっては参照も許されないことは言うまでもない。パスワードなどでの個人認証を行い、そのスタッフのアクセス権限を特定することは、本文書作成装置の運用において必須である。4文書の作成日時は、しばしば文書の法的な証明力で問題になるところであり、改ざんなどが無い様に、厳重に管理される必要がある。本文書作成装置の運用環境によっては、文書の変更や削除が行われても、元の文書を履歴として保存しておき、変更履歴を何時でも参照できるようにしておくことは有用である。可変長の文書内容データは、実施例では一つのXMLファイルにまとめているが、分量が長大な際は、複数のXMLファイルに分割して記録しても良い。また、後述するように、文書内容データと文書フォーマットなどのように、複数の可変長データとして記録しても良い。前記の文書属性を示す、案件ID、文書カテゴリー、作成者、作成編集時間等は、図7に示すように、リレーショナルデータベースの独立した項目として記録したほうが、後の検索などの際には高速処理が出来るので、より好ましいといえる。しかし、可変長の文書内容データの実体であるXMLデータの索引が充実しているなら、場合によっては、属性を示す任意の項目を、可変長の文書内容XMLデータに内包させても良い。本実施例では、可変長の文書内容データを表現する形式として、最も汎用性が高いと思われるXMLを用いたが、{id:123456name:田中一郎kana:タナカイチロウsex:男birthday:19800102}といったように、タグ名:値のペアを列挙した、JSONと呼ばれる形式でも同じ効果が得られる。また、CSV形式と呼ばれる、値をカンマ,で区切っただけの形式、あるいは、全く内部構造を有さずに文書内容をテキストとしてベタ書きした形式も可能であるが、索引が作りにくいので、必ずしも好ましい形式とは言えない。文書内容データのみならず、文書の印刷書式や、データの制限値などのデータフォーマットなどの情報も重要である。これ等の書式データも可変長データとなるが、文書のカテゴリーによって異なる。通常は、書式データの登録を、同様にして別リレーションで管理し、その書式データIDのみを記録する。しかし、個々の文書によるバリエーションが多彩にわたる場合は、この書式データも、文書内容データと同様に、文書毎に。対応するXML書式ファイルを記録し、そのファイルへのアドレスを記録しても良い本発明は、個人診療所などでは、一台のコンピュータ上で完結することもあるが、通常はサーバーコンピュータと呼ばれるデータ管理コンピュータと、現場に散在する複数のクライアントコンピュータをLANと呼ばれるネットワークで連結した形で提供される。さらに今後は、SaaSあるいはクラウドと呼ばれるように、インターネット上に構築された仮想的なサーバーコンピュータを、インターネットブラウザを介してサービス利用する形態が増加すると思われる。以上、実施例を説明したが、本発明の具体的な構成は前記実施例に限定されるものではなく、発明の要旨を逸脱しない範囲の設計変更等があっても本発明に含まれる。"