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