文書管理サーバーシステム
【課題】同一サーバーの同一ソフトウェアによって複数の施設に文書管理サービスの提供を可能とし、ソフトウェアの開発、保守費用の低減、記録領域の融通による経費削減、保守作業費用削減、容易な情報共有化を実現する。
【解決手段】所定の分類に従って記録された複数のデータファイルを有したサーバー、サーバーにアクセスしてデータの作成、編集、参照などの文書管理サービスを受けるクライアントからなる文書管理サーバーシステムであって、前記データファイルは統一したデータ様式によって記録され、前記サーバーにはクライアントのユーザーに応じたデータ処理を実行するためのプログラムが設定されており、前記サーバーにはユーザーからのアクセスを識別し、アクセスしてきたユーザーに応じて１つ以上のデータファイルに対して、前記プログラムを適用したデータ処理を行う。
【解決手段】所定の分類に従って記録された複数のデータファイルを有したサーバー、サーバーにアクセスしてデータの作成、編集、参照などの文書管理サービスを受けるクライアントからなる文書管理サーバーシステムであって、前記データファイルは統一したデータ様式によって記録され、前記サーバーにはクライアントのユーザーに応じたデータ処理を実行するためのプログラムが設定されており、前記サーバーにはユーザーからのアクセスを識別し、アクセスしてきたユーザーに応じて１つ以上のデータファイルに対して、前記プログラムを適用したデータ処理を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は複数の異なる施設内で作成、編集、参照される電子的な文書群を、共通のソフトウェアで一元的に管理し、サーバー資源の最小化、ソフトウェアの開発保守費用の低減、さらには必要に応じて施設間の情報共有を円滑化する文書管理サーバーシステムに関する。
【背景技術】
【０００２】
コンピュータの利用技術の拡大に伴い、医療や介護、福祉機関などの医療関連施設は勿論、教育機関、行政機関等においても、作業の効率化や迅速化を目的とし、紙の文書に代えて、コンピュータを利用した文書管理サーバーシステムの導入が進められている。医療機関においては、医師や看護記録などの医療記録、いわゆる電子カルテは勿論、医療上の各指示は、医師により、実施日時と実施すべき指示内容を含む電子的な文書として発行される。この医療上の指示文書に基づき、医療スタッフは医療行為を実施する。 介護施設や福祉施設においても、介護対象者の個人情報や介護計画、介護実施記録などの文書の電子化が急速に進んでいる。教育機関においては、学生の指導履歴、受講記録などの管理を始め、講義記録などの電子化も進んでいる。行政においても、庁内稟議や、入札など案件ごとの一件記録の電子化などが進められている。
このような文書データを管理処理するシステムとして特許文献１〜３の技術が知られている。
【特許文献１】特開２０１０−２０５０４５号公報
【特許文献１】特開２０１０−３１２５号公報
【特許文献２】特開２００５−１８５４９公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
病院や介護施設、学校。行政機関などでは、果たしている機能が異なるため、運用のため管理されている文書の種類は当然異なっている。同じ医療機関を取ってみても、例えば大学病院と外来のみのクリニック、脳外科と精神科では使用されている文書カテゴリーやその項目建ては全く異なるし、さらには同じ業種、業態の医療機関であっても、個別医療機関毎に、文書の種類や各文書内の項目建ては微妙に異なるのが通例である。しかも、医療や社会情勢などの変化に応じて、文書の種類や項目は変化してゆく必要がある。ましてや業種が異なる教育機関や行政機関においては、夫々の文書の種類や項目建てが全く異なることは言うまでもない。
【０００４】
文書管理サーバーシステムにおいては、リレーショナルデータベースが用いられる場合が多い。リレーショナルデータベースの項目建ては、途中変更が困難であるので、事前に厳密に設計することが不可欠である。項目建てが異なれば、当然データベースの構造が異なるので、別個のデータベースとして設計し、それを管理するための文書管理サーバーシステムも、個別に開発、運用するのが当然とされてきた。従って、業種の異なる医療、教育、行政は勿論、同じ業種でも、個々の施設毎に、個別のデータベース、個別の文書管理サーバーシステムを有するのが通常であった。
【０００５】
個々の施設毎に文書管理サーバーシステムを設置すると、以下の問題が生じる。
（１） 個々の文書管理サーバーシステムは、施設毎の一品生産であるため、ソフトウェアの開発や保守管理に多大な時間と費用が発生する。
（２） 個々の文書管理サーバーシステムの記録領域は全て別個であるため、互換性に乏しく、互いに融通することが出来ない。従って、使われることの無い大きな記録領域を個々のシステムが有することになり、無駄な費用が発生する。
（３） 施設ごとのサーバー管理では、保守作業を現地で行う必要があり、待機保守要員の人件費、移動コストが少なからずかかる。
（４） 同じ業種であれば、時に施設間で情報の共有を行う必要があるが、個別の異なる文書管理サーバーシステム間では、共有は困難である。
【０００６】
サーバーをデータセンターに集約し、インターネット経由で文書管理サービスを顧客に提供する、ＡＳＰという形式もある。これでは、前記問題の（３）は解決するが、一つの施設に、対応する一つのサーバーを割り当てる方式であり、他の問題は依然未解決である。
セールスフォースドットコムという企業では、インターネット上に巨大なデータセンター(クラウド)を配置し、多数の顧客企業の営業、在庫管理、支払い管理などの事務作業をインターネットに接続されたＰＣなどのブラウザから利用できる、SaaSという形態のサービスを提供している。この形態では、前記の多くの問題を解決しているものの、あくまで企業の販売に関する事務作業に限定されている。この種の作業は、文書や伝票の種類や項目建てが企業によらず共通しているため、顧客企業毎に、予め提供されている文書や項目の使用について設定を行えば、すぐに使用を開始できる。しかし、文書の構成自体が全く異なる医療や教育、行政などの文書管理は、同一システム上では不可能であることは言うまでもない。
【０００７】
ＳＡＰという企業もある。営業、在庫管理、支払い管理は勿論、原価計算、配送計画などの企業全般にわたる種々の管理機能を集合させたものである。各企業は、提供される無数の機能の中から、必要な機能を選択して設定することで、複雑かつ巨大な企業管理システムを容易に構築できるというものである。このシステムの利点も多いが、同様の理由で、文書の構成自体が全く異なる医療や教育、行政などの文書管理を、同一システム上で運用することは不可能である。また、実際は企業毎に文書や項目建て、処理手順に微妙な差異があり、提供された機能メニューの単純な組み合わせ設定だけでは稼動困難で、適合させるためには、結局多大な費用をかけて個別の開発が必要であるのが実情である。
【０００８】
本発明はかかる従来の問題点を解決するためになされたものであって、その目的とするところは、様々な文書カテゴリーやその項目建ての構成を有する、業種、業態の異なる施設間においても、共通の文書管理手段と施設毎の文書カテゴリー定義手段、文書カテゴリー毎の項目定義手段、施設別文書処理手段を備えることにより、同一サーバーの同一ソフトウェアによって複数の施設に文書管理サービスの提供を可能とし、ソフトウェアの開発、保守費用の低減、記録領域の融通による経費削減、保守作業費用削減、容易な情報共有化を実現することにある。
【課題を解決するための手段】
【０００９】
前記目的を達成するための手段として請求項１記載の文書管理サーバーシステムでは、 所定の分類に従って記録された複数のデータファイルを有したサーバー、サーバーにアクセスしてデータの作成、編集、参照などの文書管理サービスを受けるクライアントからなる文書管理サーバーシステムであって、
前記データファイルは統一したデータ様式によって記録され、
前記サーバーにはクライアントのユーザーに応じたデータ処理を実行するためのプログラムが設定されており、
前記サーバーにはユーザーからのアクセスを識別し、アクセスしてきたユーザーに応じて１つ以上のデータファイルに対して、前記プログラムを適用したデータ処理を行う機能が備えられていることを特徴とする。
【００１０】
請求項２記載の文書管理サーバーシステムでは、請求項１記載の文書管理サーバーシステムにおいて、
前記プログラムには、
（１）ユーザーの求めに応じて所定の項目を文書にまとめる文書カテゴリー定義手段、
（２）前記文書の項目をデータベースのデータとして定義する項目定義手段、
（３）ユーサーのアクセス範囲を規定するアクセス権限管理手段、
が設定されていることを特徴とする。
【００１１】
請求項３記載の文書管理サーバーシステムでは、請求項２記載の文書管理サーバーシステムにおいて、前記プログラムはクライアントのユーザーに共通する共通文書処理手段と、ユーザーに特有のユーザー別文書処理手段を有することを特徴とする。
【００１２】
請求項４記載の文書管理サーバーシステムでは、請求項１〜３いずれか記載の文書管理サーバーシステムにおいて、前記サーバーは、前記統一したデータ様式としてリレーショナルデータベースを備えており、それぞれのデータには、
（１）何の案件に関するデータであるか、（２）どのカテゴリーに属するデータであるか、（３）誰が作成したデータであるか、（４）いつ作成または編集したデータであるかが記録され、
前記リレーショナルデータベースシステムは、文書データ本体として少なくとも一つの項目とその項目に対応するアドレス情報を備え、そのアドレスには可変長データが格納されていることを特徴とする。
【００１３】
請求項５記載の文書管理サーバーシステムでは、請求項１〜３いずれか記載の文書管理サーバーシステムにおいて、前記サーバーは、前記統一したデータ様式としてキーバリューストア型データベースを備えており、それぞれのデータには、
（１）何の案件に関するデータであるか、（２）どのカテゴリーに属するデータであるか、（３）誰が作成したデータであるか、（４）いつ作成または編集したデータであるかが記録され、
前記キーバリューストア型データベースシステムは、文書データ本体として少なくとも一つの項目とその項目に対応する可変長データによって構成されていることを特徴とする。
【００１４】
請求項６記載の文書管理サーバーシステムでは、請求項４または５記載の文書管理サーバーシステムにおいて、前記可変長データは、ＸＭＬ形式またはＪＳＯＮ形式で記録されていることを特長とする。
【００１５】
請求項７記載の文書管理サーバーシステムでは、請求項２〜６いずれか記載の文書管理サーバーシステムにおいて、アクセス権限管理手段には、ユーザーに応じてアクセスが許容される１つ以上のデータファイルが設定されていることを特徴とする。
【００１６】
請求項８記載の文書管理サーバーシステムでは、請求項２〜７いずれか記載の文書管理サーバーシステムにおいて、アクセス権限管理手段には、ユーザーに応じてアクセスが許容されるデータファイル内の文書、及び文書内の項目が設定されていることを特徴とする。
【００１７】
請求項９記載の文書管理サーバーシステムでは、請求項２〜７いずれか記載の文書管理サーバーシステムにおいて、アクセス権限管理手段には、ユーザーに応じて参照モード、または編集モードのうちいずれかのアクセスを許容する機能が備えられていることを特徴とする。
【発明の効果】
【００１８】
本発明では、前記構成を採用しているので以下の効果を有する。
請求項１記載の文書管理サーバーシステムにおいては、サーバーには所定の分類に従って記録された複数のデータファイルが記録されている。このデータファイルはＸＭＬ、ＪＳＯＮ等の統一したデータ様式によって記録されているので一元的な取扱いが可能となる。
サーバーにはクライアントのユーザーに応じたデータ処理を実行するためのプログラム（文書処理手段）が設定されている。このプログラムを介してクライアントからのアクセスを識別し、アクセスしてきたクライアントのユーザーに応じて１つ以上のデータファイルに対して、ユーザー特有のデータ処理が行われる。
【００１９】
請求項２記載の文書管理サーバーシステムにおいては、（１）ユーザーの求めに応じて所定の項目を文書にまとめる文書カテゴリー定義手段が設定されているので、ユーザーが求める情報をデータベースから抽出して提示できる。
（２）前記文書の項目をデータベースのデータとして定義する項目定義手段が設定されているので、文書に対応した項目が抽出され提示される。
項目定義手段は文書を構成する項目群とそれらの属性を定義し、文書カテゴリー定義手段と項目定義手段が合わさって項目立てを有するまとまったひとつの文書が作成される。
（３）ユーサーのアクセス範囲を規定するアクセス権限管理手段が設定されているので、ユーザーに応じて参照、編集、加工できるデータが規定される。
【００２０】
請求項３記載の文書管理サーバーシステムにおいては、プログラムはクライアントのユーザーに共通する共通文書処理手段と、ユーザーに特有のユーザー別文書処理手段を有するので、プログラム構成が明確にされ、プログラム管理が適切に行われる。
【００２１】
請求項４記載の文書管理サーバーシステムにおいては、統一したデータ様式としてのリレーショナルデータベースシステムによって、データ管理が効率的に行われる。
また、全ての文書データには（１）何の案件に関するデータであるか、（２）どのカテゴリーに属するデータであるか、（３）誰が作成したデータであるか、（４）いつ作成または編集したデータであるか、また、文書データ本体として少なくとも一つの項目とその項目に対応するアドレス情報を備え、そのアドレスには可変長データが記録されるので、データの所属を明らかにした上で文書管理が適切に行われる。
【００２２】
請求項５記載の文書管理サーバーシステムにおいては、統一したデータ様式としてのキーバリューストア型データベースによって、データ管理が効率的に行われる。
また、全ての文書データには（１）何の案件に関するデータであるか、（２）どのカテゴリーに属するデータであるか、（３）誰が作成したデータであるか、（４）いつ作成または編集したデータであるか、また文書データ本体として少なくとも一つの項目とその項目に対応する可変長データが記録されるので、データの所属を明らかにした上で文書管理が適切に行われる。
【００２３】
請求項６記載の文書管理サーバーシステムにおいては、可変長データは、ＸＭＬ形式またはＪＳＯＮ形式で記録されているので、統一したデータ様式によって一元管理される。
【００２４】
請求項７記載の文書管理サーバーシステムにおいては、アクセス権限管理手段には、ユーザーに応じてアクセスが許容される１つ以上のデータファイルが設定されているので、アクセス先が明確に規定される。
【００２５】
請求項８記載の文書管理サーバーシステムにおいては、アクセス権限管理手段には、ユーザーに応じてアクセスが許容されるデータファイル内の文書、及び文書内の項目が設定されているので、アクセス先が、さらに詳細に規定される。
【００２６】
請求項９記載の文書管理サーバーシステムにおいては、アクセス権限管理手段には、ユーザーに応じて参照モード、または編集モードのうちいずれかのアクセスを許容する機能が備えられているので、ユーザーの所属、権限等に応じたアクセスモードが設定される。
【発明を実施するための最良の形態】
【００２７】
本発明を実施するための最良の形態を説明する。
本発明の医療情報共有システムの概要を図１に示す。病院Ａには、文書管理サーバーが設置され、ＬＡＮケーブルないし無線ＬＡＮを介して、院内の端末ＰＣ群と連結されている。病院Ａの文書管理サーバーは、ウェブサービス（Web Service）と呼ばれるサービスソケットがあり、端末ＰＣブラウザからの要求に応じて、文書データの送受信を行う。ファイアーウォール、ルーターを介して、インターネット回線に連結されている。
【００２８】
介護施設Ｂでは、同様に端末ＰＣ群がＬＡＮに連結されているが、ルーター、ファイアーウォールを介してインターネット回線に連結されている。介護施設Ｂ内にはサーバーは設置されておらず、端末ＰＣは、インターネット回線を通じて、病院Ａのサーバーと文書データの送受信を行う。相互のインターネットを介しての通信は、ＶＰＮ接続などセキュリティの高い通信がより好ましいが、ＳＳＬなどの暗号化通信でも良い。このように、自施設内にはサ-バーを持たず、インターネット経由でサービスを受けるやり方は、SaaS（Software as ａ Service）と呼ばれている。
【００２９】
学校Ｃも、ルーター、ファイアーウォールを介して同様にインターネット回線に連結されている。学校Ｃ内にもサーバーは設置されておらず、ＬＡＮに接続されている端末ＰＣのブラウザを用い、インターネット回線を通じて、病院Ａのサーバーと、SaaSの形で文書データの送受信を行う。
【００３０】
上記各施設のスタッフは施設内のＰＣからアクセスするが、患者や入所者、利用者なども、自分のＰＣからインターネット経由で同様に文書管理サーバーにアクセスし、付与されているＩＤとパスワードで認証を受け、許可を受けている範囲で自らに関する文書データを参照、編集する。時には、本図の文書管理サーバーとは別個の文書管理サーバーに属する医療機関などから、共通する患者の情報を参照する場合もある。
【００３１】
一個の文書管理サーバーシステムで、性格の異なる複数の施設の文書を管理するためには、（１）夫々の施設で用いられる文書カテゴリーのリストおよび各文書カテゴリーの項目建ての管理手段、（２）各々の施設で用いられる様々なカテゴリーの文書とその項目を処理するための文書処理手段、（３）作成された種々の文書を記録・参照する文書データ記録手段、（４）アクセスしてきたユーザーを認証し、許可された範囲でのみ文書閲覧や作成・編集を可能とする、ユーザー認証、ユーザー毎の文書アクセス権限管理手段、の各手段群が必要である。
以下、本発明の具体的実施例を、各手段群に沿って説明する。
【００３２】
図２は、各施設によって用いられている文書カテゴリーのリストである。診療所、病院などの医療機関、介護施設、学校などの施設の活動に応じて様々な文書カテゴリーが用いられている。また、同じ医療機関という施設類型であっても、共通な文書カテゴリー以外に施設特有の文書カテゴリーが用いられている。夫々の文書カテゴリーは、その文書特有の項目から構成されている。
【００３３】
図３、４は、文書カテゴリーの項目構成例である。図３は医師記録、図４は、患者の日常生活のレベル評価記録の一部を示す。自由記載項目、性別や複数のレベルからの選択などのような択一項目、年齢などの整数値、等など様々な形式の項目がある。
夫々の項目の定義様式については、施設の特性や使用しているシステムの仕様に合わせて、適宜公知の定義様式を選択すればよい。このように、施設によって様々な種類の文書カテゴリー、その文書カテゴリー毎の項目建てが用いられているので、これらを処理してゆくためには、施設毎の文書カテゴリー定義手段、文書カテゴリー毎の項目定義手段が必要である。文書の印刷書式や、データの制限値などのデータフォーマットなどの文書カテゴリー定義情報、項目建て定義情報等の書式データも可変長データとなるが、当然ながら文書のカテゴリーによって異なる。
通常は、書式データの登録を、別リレーションで管理し、その書式データＩＤのみを記録する。しかし、個々の文書によるバリエーションが多彩にわたる場合は、この書式データも、文書内容データと同様に、文書毎に対応するＸＭＬないしＪＳＯＮ形式の書式ファイルを記録し、そのファイルへのアドレスを記録しても良い。
【００３４】
この文書カテゴリー定義手段、文書カテゴリー毎の項目定義手段は、施設に応じて、すなわち、アクセスするユーザーに応じて設定された文書カテゴリーやその項目を定義するプログラムであり、医療機関や教育機関、行政その他企業等のユーザーの求めに応じてデータ処理を実行する。
ある医療機関がデータベースにアクセスすると、その医療機関のユーザーに特有のプログラムを介してデータベースの参照、編集、加工が行われ、行政機関がデータベースにアクセスすると、その行政機関のユーザーに特有のプログラムを介してデータベースの参照、編集、加工が行われる。
ユーザーに対してどのプログラムを適用するかは、ＩＤ、パスワード等によってサーバーが認証して選択適用する。
【００３５】
次に、様々な項目構成を持つ種々の文書カテゴリーの文書データを記録する文書データ記録手段につき説明する。ここでは医療機関における患者基本情報と薬剤処方という２種類の文書カテゴリーの文書データを例に取る。
図５は、夫々の文書データを、リレーショナルデータベースの形式で表現したものである。リレーショナルデータベースでは、個々の項目は固定長データとして記録され、それによる高速処理が可能となっている。その反面、項目建てが異なれば、同一の表(リレーション)として扱うことは困難であるので、別々のリレーションとなる。
【００３６】
図６、図７は、図５の各々のリレーションのデータを、ＸＭＬおよびＪＳＯＮと呼ばれる形式で表現したものである。ＸＭＬ形式およびＪＳＯＮ形式では、データはテキストファイルとなり、ファイルの長さは異なってくる。項目建ては、ＸＭＬ形式では、＜＞で示されるタグで表現される。ＪＳＯＮ形式では、"タグ名"："データ"の形式で表現される。部門ごとのデータ項目建てが異なっていても、一つの文書の全データ項目は、一つのＸＭＬ形式ないしＪＳＯＮ形式のデータファイルに変換できる。たとえ、項目建てや記載形式が異なっていても、ＸＭＬファイル化ないしＪＳＯＮファイル化してしまえば、全て一つの可変長テキストファイルに過ぎない。従って、リレーションの一つの枡目に、ＸＭＬ文書データないしＪＳＯＮ文書データの記録場所を指し示す固定長のアドレスを格納すればよい。
【００３７】
ＸＭＬ形式は、入れ子構造や繰り返し構造などの複雑なデータ構造を表現できるので汎用性が高い反面、処理に時間がかかり、単純な構造のデータに対しては、却って不経済である。このような場合、ＪＳＯＮ形式のように単純に"タグ"と"データ"を"："を挟んで併置させただけの構造のほうが効率的である場合も多い。状況に応じて、適宜両者を使い分ければよい。以下、より実用化が進んでいるＸＭＬ形式を例に採り、解説を進めるがＪＳＯＮ形式でも同様のことが言える。
なお、ＣＳＶ形式と呼ばれる、値をカンマ「，」で区切っただけの形式、あるいは、全く内部構造を有さずに文書内容をテキストとしてベタ書きした形式の文書データファイルでも本発明の実施は可能であり、本発明に含まれるが、個々のデータが何を意味しているのかが分かり難く、また検索用索引が作りにくいので、必ずしも好ましい形式とは言えない。
可変長の文書内容データは、実施例では一つのＸＭＬないしＪＳＯＮファイルにまとめているが、分量が長大な際は、複数のファイルに分割して記録しても良い。また、文書内容データと文書フォーマットなどのように、内容別に複数の可変長データとして記録しても良い。
【００３８】
ここで、図８に示すように、文書ＩＤ、作成者、作成日、文書カテゴリーおよび文書主体であるＸＭＬテキストファイルを示す固定長アドレスからなるリレーションを考える。このようにすれば、文書カテゴリーごとの項目立ての違いはＸＭＬ形式で吸収されるため、全ての文書カテゴリーを同一リレーションで扱うことが容易に可能となる。このようなデータベースは、ＸＭＬリレーショナルデータベースと呼ばれている。実用上のシステムでは、ＸＭＬがテキストのままでは処理が遅くなるので、ＸＭＬテキストデータを機械処理可能な内部表現（バイナリー形式）でオブジェクト化したものを記録する（ＸＭＬオブジェクトリレーショナルデータベース ＸＭＬ Object Relational Data Base）。さらに、高速処理するための索引を整備する。
このように、サーバーのデータベースは、所定の分類に従って記録された複数のデータファイルを有している。
【００３９】
医療機関のみならず、教育、行政、企業においても、文書には、可変長の文書内容データそのもの以外に、以下の文書の属性を示す情報が必須である。（１）何の案件に関する文書であるか、（２）どのカテゴリーに属する文書であるか、（３）誰が作成した文書であるか、（４）いつ作成/編集した文書であるか、である。
（１）の案件を特定するＩＤは、医療機関であれば患者ＩＤであり、教育機関であれば生徒ＩＤ、行政機関であれば住民ＩＤ、企業であれば得意先ＩＤなど、あるいは、プロジェクトＩＤなどがある。いずれにせよ、本文書作成装置を使用する環境で、文書群の括りとして適切なＩＤを選べばよい。
（２）文書カテゴリーＩＤは、案件を構成する文書群で、文書の種類を示す。医療では、患者基本情報、薬剤処方箋等などであり、教育では、単位登録申請書、試験成績など、行政では、戸籍謄本、住民票、納税履歴など、企業では、取引履歴、営業履歴、トラブル履歴などがある。文書のカテゴリーによって、記載される内容や書式が異なるのは言うまでもない。
（３）スタッフによって、職位、職種、担当範囲などが異なる。権限外の文書を作成、編集することは勿論、場合によっては参照も許されないことは言うまでもない。パスワードなどでの個人認証を行い、そのスタッフのアクセス権限を特定することは、本文書作成装置の運用において必須である。
（４）文書の作成日時は、しばしば文書の法的な証明力で問題になるところであり、改ざんなどが無い様に、厳重に管理される必要がある。
【００４０】
ＩＤ、文書カテゴリー、作成者、作成/編集時間等の情報は、図８に示すように、リレーショナルデータベースの独立した項目として記録したほうが、後の検索などの際には高速処理が出来るので、より好ましいといえる。しかし、可変長の文書内容データの実体であるＸＭＬデータの索引が充実しているなら、場合によっては、属性を示す任意の項目を、可変長の文書内容ＸＭＬデータに内包させても良い。
図８では、横一連の文書ＩＤを単位とするデータに（１）何の案件に関する文書であるか、（２）どのカテゴリーに属する文書であるか、（３）誰が作成した文書であるか、（４）いつ作成/編集した文書であるか、の属性情報が付されている。
【００４１】
図９では、上記の統合された文書データ記録手段を用いた文書管理サーバーシステムの好ましい実施例の一つである。文書処理手段では文書カテゴリー毎にウェブサービスのソケットを持ち、端末ＰＣとの文書データ通信を行う。端末ＰＣから、各ウェブサービスソケットを通じて要求があれば、統合された文書データ記録手段に対して検索を行い、文書カテゴリーのリスト、指定された文書カテゴリー内の文書リスト、指定された文書の文書内容データを、端末ＰＣに対して、当該ウェブサービスソケットから送信する。また、文書データの書き込み要求があれば、当該ウェブサービスソケットで端末ＰＣから文書データを受信し、統合された文書データ記録手段に書き込みを実行する。このように、統合された文書データ記録手段は、ウェブサービス処理モジュール間のデータ連携のバスとして機能する（データベースバス）。ウェブサービスを用いることで、施設内外を問わず、インターネットの標準形式で文書データの送受信が可能となる。
【００４２】
図１０に示すように、多施設の統合化された文書データ記録手段においては、文書データに、施設を識別する施設コードが必要であるが、施設毎に文書データ記録手段を分割して管理する際は、施設コードの必要はない。データ量やセキュリティ等の種々の条件を勘案して、適宜構成を決めればよい。
本文書作成装置の運用環境によっては、文書の変更や削除が行われても、元の文書を履歴として保存しておき、変更履歴を何時でも参照できるようにしておくことは有用である
【００４３】
従来は、図１１に示すように、文書カテゴリー毎に、異なるリレーションを夫々管理するための部門システムを別個に作成し、それらの部門システムを集合させることで全体システムを構成していた。別の表現をすれば、文書カテゴリー毎に、文書データを管理する手段と、その文書データを処理する手段からなる部門システムモジュールを多数組み合わせ、端末ＰＣからはＨＬ-７などの通信規格に基づいて、参照や書き込み要求を行うものであった。この従来のやり方では、施設毎に異なる無数の文書カテゴリーを、前記のように統一的に扱うことが困難である。多数の異なるリレーションと、夫々を管理する部門システムが独立しているため、データの一元管理は困難で、データ全体にわたる検索などは困難を極める。誰かが或る患者のカルテを開くと、その間は他のユーザーは当該カルテへのアクセスが制限されるという問題もある。また、ソフトウェアも、施設ごと部門システムモジュール毎に用意する必要があり、統一的な管理は、不可能に近く多額の開発、保守費用がかかっていた。 また従来の部門システムは、個別にデータを管理し、ＨＬ-７などの形式でデータの問い合わせ、返答を行うものだったため、多元的な参照は複雑を極めた。しかし、今回の発明のように、データ構造が一元化されれば、複雑な参照もＳＱＬ文を一発叩けば簡単に実現する。
【００４４】
図１２は、図９の文書処理手段部分を詳細化したものである。
文書処理手段では、前記文書データ記録手段（データファイル）から文書データを読み出す、読み出した文書データを読みやすい形に表示する、文書データを編集して書き込む、或いは新規文書を作成したり、不要に文書をなった削除したりする等などの処理を行う。図３、図４に示したように、多種多様な文書カテゴリーと項目構成があるため、複数の施設毎の文書カテゴリー定義手段、前記文書カテゴリー毎の項目定義手段を備えている。文書カテゴリー毎に、前述のように端末ＰＣと文書データの送受信を行うウェブサービスのソケットを設けている。また、後述するように、認証されたユーザー毎のアクセスコントロールテーブル（Access Control Table）を用いた、ユーザーごとのアクセス管理手段を備えている。
サーバーにはクライアントからのアクセスを識別し、ユーザー毎の文書アクセス管理手段で、どの文書カテゴリーにどこまでアクセス可能かを識別する。アクセスしてきたクライアントに応じてアクセス可能なデータファイルに対して、当該文書カテゴリーの構成項目情報を提供し、当該文書に対する文書処理手段（プログラム）を適用したデータ処理を行う機能が備えられている。
【００４５】
端末ＰＣから文書データ送受信の要求があった場合、先ずＩＤやパスワード入力、或いは生体認証などでユーザーの認証を行う。次いで、当該ユーザーのアクセスコントロールテーブルを検索し、当該する患者および文書カテゴリーに対して、当該アクセス要求が許可されているかを確認する。もし許可されてなければ、その旨のエラーメッセージを送信し、以降の処理は行わない。
当該文書カテゴリーの参照要求が許可されているならば、当該文書データを前記文書データ記録手段から読み出し、当該文書カテゴリー定義手段および文書カテゴリー毎の項目定義手段の定義情報を併用して、文書の表示体裁を整えた後、端末ＰＣに送信する。書き込み要求が許可されているならば、必要に応じ当該文書カテゴリー定義手段および文書カテゴリー毎の項目定義手段の定義情報を併用して受信した文書データの整合性を確認した後、文書データ記録手段に記録する。
【００４６】
ここで、文書処理手段のソフトウェアとしての構成を考える。端末PCからの要求を受け付ける、要求が許可されているかを調べる、文書データを文書データ記録手段から読み出す、当該文書カテゴリー定義手段および文書カテゴリー毎の項目定義手段の定義情報を併用して、文書の表示体裁を整える、編集後の文書データを、文書データ記録手段に書き込む等などの処理は、文書カテゴリーの種類によらず共通の処理である。この共通の処理は、共通文書処理手段に一ヶ所まとめて定義しておけばよい。もしオブジェクト指向プログラミングでソフトウェアが書かれているならば、親オブジェクトに共通処理メソッドとして定義しておけばよい。こうしておけば、従来のように文書カテゴリー毎に別々の部門システムを作成し、同じような処理を、部門システムごとに別途定義する必要はなくなり、ソフトウェアの軽量化、開発や保守の低コスト化が得られる。
【００４７】
図１３（ａ）は、文書処理手段の階層構成を示す。最下層は、通信データの送受信、ファイルへの文書データの読み書き、それらに関してのエラー処理などが該当する。次の層は、ユーザー認証、文書の表示、文書の編集などの最下層の機能を基盤とした、文書カテゴリーに共通する処理が該当する。最上位には、項目の得点を計算する等といった、夫々の文書カテゴリー固有の処理が該当する。このようにひとつのソフトウェアに全ての文書処理機能をまとめても良い。
【００４８】
しかし、医療機関と教育機関などでは、文書カテゴリーが全く異なり、固有の処理も多い。このような場合、文書処理手段を全て一つのソフトウェアにまとめた場合は、ソフトウェアが肥大化しやすく、処理が重くなる危険がある。そのため、図１３（ｂ）に示すように、文書処理手段を、各施設共通の共通文書処理手段と各施設固有の施設別文書処理手段（ユーザー別文書処理手段）に分離し、処理の際の必要に応じて、両者を結合させ、文書処理を行うものである。施設別文書処理手段は単一とは限らず、文書カテゴリーに応じて複数準備しておいて、必要に応じて結合してもよい。また、ある文書を処理する施設別文書処理手段は、単一モジュールとは限らず、複数の文書カテゴリーに共通のモジュールと、当該文書固有の処理モジュールの組み合わせでも良い。必要に応じて施設あるいは文書カテゴリー群ごとにソフトウェアを分割して開発しておき、必要なモジュールのみ実装するようにしても良い。この節の議論は、サーバー側のソフトウェア、SaaS端末或いはクライアントソフトウェアなど、端末ＰＣ側で動作するソフトウェアのいずれでも成り立つことは言うまでもない。
【００４９】
複数の施設にまたがって文書データを管理する際は、同一対象者が複数の施設に文書データを有する場合がある。例えば、ある地域に住む患者が、複数の病院やクリニックに受診して治療を受けている場合である。患者の同意の下に、他の医療機関の診療データを参照できれば、重複検査が不要となり医療費の削減に有用なだけでなく、重要なアレルギーや疾患の情報の見落としが減少し、医療安全の向上に役立つ。同一対象者の複数施設にわたる情報を参照する場合は、全施設の全文書カテゴリーに対してのアクセス権限を、個々のユーザー毎に管理する必要がある。
【００５０】
図１４は、或るユーザーが、文書カテゴリーにどの程度アクセスできるかをまとめたアクセスコントロールテーブル（Access Control Table）を示す。
本発明のアクセス権限管理手段は一例として図１４のテーブルを参照しながら、サーバーのデータベースに対するユーザーのアクセスできる範囲を規定する。
横軸は施設/文書カテゴリー、縦軸は患者番号、学生番号、案件番号など、文書の属する固有ＩＤである。施設によって個別の番号が振られている場合も多いので、実施に当たっては、共通番号などの、別途一意的なＩＤ番号を設定することが望ましい。
コンピュータを起動させる時に、またはネットワークにアクセスする時に、ユーザーのＩＤやパスワードの入力、あるいは生体認証など、それ自体は公知の技術によりユーザー認証がなされる。ユーザーの特定がなされれば、そのユーザーのアクセスできるデータ範囲も同時に規定される。例えば、図１４において、当該認証ユーザーは、病院Ａの医師であったとしよう。病院Ａの患者については、患者基本情報や医師初診時記録などに関しては、参照/編集ともに可能である。しかし看護記録は、職種が異なるので、参照のみとなる。
【００５１】
通常は、当該施設に関連する患者などに関しては同一のアクセス権限が適応される場合が多いが、有名人や政治家など特段の秘密保持が必要な場合は（例えばＩＤ9567）、限定されたスタッフにのみ真のアクセス権限を与え、そのほかのスタッフにはアクセスさせない場合もある。この場合は医師といえども一切参照できない。
他の診療所Ｂや、介護施設Ｃについては、相手側施設の許可と本人の同意があった場合のみ、その患者/入所者についてだけ参照が可能となる。その他の患者/入所者の文書は、当然参照できない。また、その施設のスタッフではないので、当然文書編集は出来ない。
現在はチーム医療が行われ、多数の職種が一人の患者の治療に関わってくる。医療機関内で、或る特定の患者のデータのみをアクセス禁止にすると却って怪しまれる場合は、真実を知らせる訳には行かない医療スタッフには、偽の氏名や生年月日を表示することも有効である。また、予め登録されている施設スタッフが、属する施設の外からアクセスしてきた際は、ＩＤ成りすましの危険がありうるので、個人特定による情報流出を避けるため、患者名や生年月日の表示を、イニシアル表示、年齢表示とするなど曖昧化する場合もある。
本図では、文書カテゴリー単位でのアクセス権限を定義しているが、場合によっては、文書内の項目建てレベルでアクセスの可否を指定しても良い。全対象者についてアクセスコントロールテーブルを実際に作ると膨大なデータ量になるので、通常は、デフォールト値の設定、例外部分の重ね書きなどの方法を用いて、データ量を圧縮する必要がある。要は、特定ユーザーが特定対象者に関する参照を要求してきた際に、その諾否に必要なアクセスコントロール情報が再現できれば良い。
【００５２】
ある地域に住む患者が、複数の病院やクリニックに受診して治療を受けている場合、患者の同意の下に、他の医療機関の診療データを参照できれば、重複検査が不要となり医療費の削減に有用なだけでなく、重要なアレルギーや疾患の情報の見落としが減少し、医療安全の向上に役立つことは前述した。本発明の同一サーバー内に文書データが存在する場合は、照会元のユーザーも既に登録されているので、当該ユーザーのアクセスコントロールテーブルが存在するので、照会先の機関の同意により、アクセス権を設定すればよい。しかし多くの場合は、医療機関ないし医療機関群毎に管理している別の文書管理サーバーシステムに存在する。その際は、照会元のユーザーは、照会先の文書管理サーバーシステムにユーザー登録が無いので、電話やメールなどの方法で依頼し、ユーザー登録を行い、同様に、照会先の機関の同意を得た文書カテゴリーに付きアクセス権を設定する。場合によっては、地域で相互参照可能な機関同士のリストを作成し、予めユーザー登録/アクセス権設定をしておいても良い。
【００５３】
従来の地域カルテ共有システムでは、（１）地域カルテ共有サーバーに、カルテからの抽出情報を蓄積しておいて、参照要求に応える。（２）地域カルテ共有サーバーには、参照元ユーザーの認証、患者が受診している医療機関と、そこでのＩＤ、開示されている文書カテゴリーリストのみを管理。各医療機関は、地域カルテ共有サーバーの認証を受けてきた参照要求に対して、内部カルテの情報を開示用データに変換する医療機関開示サーバーで、参照要求に応える、の両形態が行われている。
【００５４】
先ず、（１）の方式では、地域カルテ共有サーバーにたまる大量のデータの管理費用がかかること、万一個人情報漏洩が起これば甚大な被害が出ることなどの理由から、現在は用いられなくなってきている。（２）の方式が現行の主流となりつつあるが、個々の医療機関毎に、開示用データを適合させるソフトの開発費用、サーバーの導入運営費用等がかかってしまう問題があった。また、図２で示したように、医療機関毎に文書カテゴリーや項目建ては全て異なるため、共有される文書カテゴリーは一部に留まる欠点があった。
本発明を地域カルテ共有システムに適用した場合を考える。他の医療機関のユーザー、或いはカルテ開示を求める患者や家族は、本発明の複数施設の文書管理サーバーシステムに、図１４に示すように、適切なアクセスコントロールテーブルを設定してユーザー登録してしまえば、上記（２）の方式のように、費用のかかる医療機関開示サーバーは不要であり、本発明の文書管理サーバーシステムが直接参照元のユーザーに応答する。アクセス権の設定があれば、いかなる文書カテゴリーも、当該施設本来のユーザーと同様に速やかに参照できる。（２）の方式で必要とされる、開示用にデータの適合性を整えるための事前のソフトウェア開発は不要である。なお、セキュリティ上の心配があれば、本発明の文書管理サーバーシステムとユーザーの間に、一時的に開示データだけを保持する中継サーバーを置いても良い。
【００５５】
文書データ記録手段として、リレーショナルデータベースの各項目に、ＩＤ、文書カテゴリー、作成者、作成日時などの索引キー項目、およびＸＭＬないしＪＳＯＮ形式で記録された文書主体のテキストデータの位置を示すアドレス項目を備えた例を解説してきた。最近クラウド型のデータ記録として注目を集めている、キーバリューストア型のデータベースを用いても、同様の機能を実現することが出来る。図１５において、文書キーは、キーバリューストア型データベースに文書データを新規に記録する際に、システム側で自動的に振られる一意的な文書番号で、記録テーブル内の位置を一意的に表現するものである。リレーショナルデータベースの際と同様、（１）何の案件に関する文書であるかを示すＩＤ、（２）どのカテゴリーに属する文書であるかを示す文書カテゴリー、（３）誰が作成した文書であるかを示す作成者、（４）いつ作成/編集した文書であるかを示す作成日、また、文書データの本体として、少なくとも一つの項目とその項目に対応する可変長データの各情報を最低限記録しておく必要がある。
【００５６】
ＩＤは、当該文書が帰属する患者/学生/案件番号などを示す。
もし、多施設の文書が混在する構成ならば、施設コードも必要である。
文書カテゴリーは、当該文書が属する文書の種類、作成者、作成日は、誰が何時この文書を作成したかを示す。
文書主体では、当該文書の本文が、ＸＭＬ形式、ＪＳＯＮ形式、あるいはＣＳＶないし構造を持たない通常のテキストとして記録されている。
リレーショナルデータベースの例では、升目には固定長のアドレスを入れ、アドレス先に文書の主体を記録する必要があった。
同様の構成をとっても本発明は実施でき、本発明の範囲に含まれるが、ＧｏｏｇｌｅのBigtableなどの例では、各升目に入るデータは可変長データを許容するので、その升目の中に文書テキスト全文を直接記録することが、より好ましい実施例といえよう。
勿論、必要に応じて、複数の升目に分割記録することも可能である。
【００５７】
ＩＤから作成日までの項目は、索引項目であり、シングルキー索引やコンポジットキー索引などと呼ばれる様々な索引を予め作成しておき、条件検索して文書キーを求め、テーブル内の論理的位置から物理的位置を求め、目的とする文書主体のテキストテータを得るものである。状況に応じて様々な索引項目が必要であるが、最低限の索引項目として、前記（１）何の案件に関する文書であるか、（２）どのカテゴリーに属する文書であるか、（３）誰が作成した文書であるか、（４）いつ作成/編集した文書であるかの各項目は必須である。これらの項目を使用して、シングルプロパティ インデックス、或いは組み合わせてのコンポジット インデックスなどの索引を予め作成しておき、検索に備えると良い。
【００５８】
以上、実施例を説明したが、本発明の具体的な構成は前記実施例に限定されるものではなく、発明の要旨を逸脱しない範囲の設計変更等があっても本発明に含まれる。
文書管理サーバーは、図では一医療機関内に一台設置されているものとして説明したが、複数台でクラスターを形成し、併せて一台の仮想サーバーを構成している場合、複数の医療機関やデータセンターで相互にバックアップを行い、全体で、いわゆる「プライベートクラウド」を形成している場合などがある。場合によっては、（１）データ記録と処理の全てのサーバー機能をAmazonやGoogleのようなパブリッククラウド上に設営し、一切のハードウェア資源を手元に持たない場合、（２）或いは、データ記録は手元のサーバー、サーバー群に確保しておいて、ウェブを介してクラウド上のサーバー上で文書データの読み出し、編集などの処理のみを行う場合も、状況によってはありうる。
本発明の文書管理サーバーシステムは、一台のサーバーを占有する必要は無く、他のシステムと並存/共有しても良い。
インターネットを介した好ましい通信様式として、ウェブサービスを用いて説明したが、互換性などの問題から、敢えてＨＬ-7などの旧式の通信様式を用いても良い。
本発明の文書管理サーバーシステムは、ある時点では一施設のデータのみで、複数施設のデータを直接管理していない場合でも、必要に応じて追加施設のデータを管理しうるソフトウェア、ハードウェアの構成にあれば、本発明に含まれる。
実施例として、医療機関の例を用いたが、教育機関、行政機関でも全く同様の議論が可能であり、本発明に含まれる。ＩＤとしては、患者や生徒、住民などの人間に対するものだけでなく、事案番号など、文書群の括りになるものであれば、本発明が応用できる。
【図面の簡単な説明】
【００５９】
【図１】文書管理サーバーシステムのネットワークの説明図である。
【図２】文書カテゴリー構成の違いを示す説明図である。
【図３】特定のユーザーにおける文書を構成する項目の説明図である。
【図４】他の特定のユーザーにおける文書を構成する項目の説明図である。
【図５】リレーショナルデータベースの説明図である。
【図６】図５上段の図をＸＭＬおよびＪＳＯＮ形式で表わした場合の説明図である。
【図７】図５下段の図をＸＭＬおよびＪＳＯＮ形式で表わした場合の説明図である。
【図８】ＸＭＬリレーショナルデータベースの説明図である。
【図９】文書管理サーバーシステムの概略構成図である。
【図１０】多施設の統合化された文書データ記録手段の概略構成図である。
【図１１】従来例に係る文書管理サーバーシステムの概略構成図である。
【図１２】文書処理手段の説明図である。
【図１３】文書処理手段の階層構成とモジュール化構成を示す説明図である。
【図１４】アクセスコントロールテーブルの説明図である。
【図１５】キーバリューストア型のデータベースを用いた例を示す説明図である。
【技術分野】
【０００１】
本発明は複数の異なる施設内で作成、編集、参照される電子的な文書群を、共通のソフトウェアで一元的に管理し、サーバー資源の最小化、ソフトウェアの開発保守費用の低減、さらには必要に応じて施設間の情報共有を円滑化する文書管理サーバーシステムに関する。
【背景技術】
【０００２】
コンピュータの利用技術の拡大に伴い、医療や介護、福祉機関などの医療関連施設は勿論、教育機関、行政機関等においても、作業の効率化や迅速化を目的とし、紙の文書に代えて、コンピュータを利用した文書管理サーバーシステムの導入が進められている。医療機関においては、医師や看護記録などの医療記録、いわゆる電子カルテは勿論、医療上の各指示は、医師により、実施日時と実施すべき指示内容を含む電子的な文書として発行される。この医療上の指示文書に基づき、医療スタッフは医療行為を実施する。 介護施設や福祉施設においても、介護対象者の個人情報や介護計画、介護実施記録などの文書の電子化が急速に進んでいる。教育機関においては、学生の指導履歴、受講記録などの管理を始め、講義記録などの電子化も進んでいる。行政においても、庁内稟議や、入札など案件ごとの一件記録の電子化などが進められている。
このような文書データを管理処理するシステムとして特許文献１〜３の技術が知られている。
【特許文献１】特開２０１０−２０５０４５号公報
【特許文献１】特開２０１０−３１２５号公報
【特許文献２】特開２００５−１８５４９公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
病院や介護施設、学校。行政機関などでは、果たしている機能が異なるため、運用のため管理されている文書の種類は当然異なっている。同じ医療機関を取ってみても、例えば大学病院と外来のみのクリニック、脳外科と精神科では使用されている文書カテゴリーやその項目建ては全く異なるし、さらには同じ業種、業態の医療機関であっても、個別医療機関毎に、文書の種類や各文書内の項目建ては微妙に異なるのが通例である。しかも、医療や社会情勢などの変化に応じて、文書の種類や項目は変化してゆく必要がある。ましてや業種が異なる教育機関や行政機関においては、夫々の文書の種類や項目建てが全く異なることは言うまでもない。
【０００４】
文書管理サーバーシステムにおいては、リレーショナルデータベースが用いられる場合が多い。リレーショナルデータベースの項目建ては、途中変更が困難であるので、事前に厳密に設計することが不可欠である。項目建てが異なれば、当然データベースの構造が異なるので、別個のデータベースとして設計し、それを管理するための文書管理サーバーシステムも、個別に開発、運用するのが当然とされてきた。従って、業種の異なる医療、教育、行政は勿論、同じ業種でも、個々の施設毎に、個別のデータベース、個別の文書管理サーバーシステムを有するのが通常であった。
【０００５】
個々の施設毎に文書管理サーバーシステムを設置すると、以下の問題が生じる。
（１） 個々の文書管理サーバーシステムは、施設毎の一品生産であるため、ソフトウェアの開発や保守管理に多大な時間と費用が発生する。
（２） 個々の文書管理サーバーシステムの記録領域は全て別個であるため、互換性に乏しく、互いに融通することが出来ない。従って、使われることの無い大きな記録領域を個々のシステムが有することになり、無駄な費用が発生する。
（３） 施設ごとのサーバー管理では、保守作業を現地で行う必要があり、待機保守要員の人件費、移動コストが少なからずかかる。
（４） 同じ業種であれば、時に施設間で情報の共有を行う必要があるが、個別の異なる文書管理サーバーシステム間では、共有は困難である。
【０００６】
サーバーをデータセンターに集約し、インターネット経由で文書管理サービスを顧客に提供する、ＡＳＰという形式もある。これでは、前記問題の（３）は解決するが、一つの施設に、対応する一つのサーバーを割り当てる方式であり、他の問題は依然未解決である。
セールスフォースドットコムという企業では、インターネット上に巨大なデータセンター(クラウド)を配置し、多数の顧客企業の営業、在庫管理、支払い管理などの事務作業をインターネットに接続されたＰＣなどのブラウザから利用できる、SaaSという形態のサービスを提供している。この形態では、前記の多くの問題を解決しているものの、あくまで企業の販売に関する事務作業に限定されている。この種の作業は、文書や伝票の種類や項目建てが企業によらず共通しているため、顧客企業毎に、予め提供されている文書や項目の使用について設定を行えば、すぐに使用を開始できる。しかし、文書の構成自体が全く異なる医療や教育、行政などの文書管理は、同一システム上では不可能であることは言うまでもない。
【０００７】
ＳＡＰという企業もある。営業、在庫管理、支払い管理は勿論、原価計算、配送計画などの企業全般にわたる種々の管理機能を集合させたものである。各企業は、提供される無数の機能の中から、必要な機能を選択して設定することで、複雑かつ巨大な企業管理システムを容易に構築できるというものである。このシステムの利点も多いが、同様の理由で、文書の構成自体が全く異なる医療や教育、行政などの文書管理を、同一システム上で運用することは不可能である。また、実際は企業毎に文書や項目建て、処理手順に微妙な差異があり、提供された機能メニューの単純な組み合わせ設定だけでは稼動困難で、適合させるためには、結局多大な費用をかけて個別の開発が必要であるのが実情である。
【０００８】
本発明はかかる従来の問題点を解決するためになされたものであって、その目的とするところは、様々な文書カテゴリーやその項目建ての構成を有する、業種、業態の異なる施設間においても、共通の文書管理手段と施設毎の文書カテゴリー定義手段、文書カテゴリー毎の項目定義手段、施設別文書処理手段を備えることにより、同一サーバーの同一ソフトウェアによって複数の施設に文書管理サービスの提供を可能とし、ソフトウェアの開発、保守費用の低減、記録領域の融通による経費削減、保守作業費用削減、容易な情報共有化を実現することにある。
【課題を解決するための手段】
【０００９】
前記目的を達成するための手段として請求項１記載の文書管理サーバーシステムでは、 所定の分類に従って記録された複数のデータファイルを有したサーバー、サーバーにアクセスしてデータの作成、編集、参照などの文書管理サービスを受けるクライアントからなる文書管理サーバーシステムであって、
前記データファイルは統一したデータ様式によって記録され、
前記サーバーにはクライアントのユーザーに応じたデータ処理を実行するためのプログラムが設定されており、
前記サーバーにはユーザーからのアクセスを識別し、アクセスしてきたユーザーに応じて１つ以上のデータファイルに対して、前記プログラムを適用したデータ処理を行う機能が備えられていることを特徴とする。
【００１０】
請求項２記載の文書管理サーバーシステムでは、請求項１記載の文書管理サーバーシステムにおいて、
前記プログラムには、
（１）ユーザーの求めに応じて所定の項目を文書にまとめる文書カテゴリー定義手段、
（２）前記文書の項目をデータベースのデータとして定義する項目定義手段、
（３）ユーサーのアクセス範囲を規定するアクセス権限管理手段、
が設定されていることを特徴とする。
【００１１】
請求項３記載の文書管理サーバーシステムでは、請求項２記載の文書管理サーバーシステムにおいて、前記プログラムはクライアントのユーザーに共通する共通文書処理手段と、ユーザーに特有のユーザー別文書処理手段を有することを特徴とする。
【００１２】
請求項４記載の文書管理サーバーシステムでは、請求項１〜３いずれか記載の文書管理サーバーシステムにおいて、前記サーバーは、前記統一したデータ様式としてリレーショナルデータベースを備えており、それぞれのデータには、
（１）何の案件に関するデータであるか、（２）どのカテゴリーに属するデータであるか、（３）誰が作成したデータであるか、（４）いつ作成または編集したデータであるかが記録され、
前記リレーショナルデータベースシステムは、文書データ本体として少なくとも一つの項目とその項目に対応するアドレス情報を備え、そのアドレスには可変長データが格納されていることを特徴とする。
【００１３】
請求項５記載の文書管理サーバーシステムでは、請求項１〜３いずれか記載の文書管理サーバーシステムにおいて、前記サーバーは、前記統一したデータ様式としてキーバリューストア型データベースを備えており、それぞれのデータには、
（１）何の案件に関するデータであるか、（２）どのカテゴリーに属するデータであるか、（３）誰が作成したデータであるか、（４）いつ作成または編集したデータであるかが記録され、
前記キーバリューストア型データベースシステムは、文書データ本体として少なくとも一つの項目とその項目に対応する可変長データによって構成されていることを特徴とする。
【００１４】
請求項６記載の文書管理サーバーシステムでは、請求項４または５記載の文書管理サーバーシステムにおいて、前記可変長データは、ＸＭＬ形式またはＪＳＯＮ形式で記録されていることを特長とする。
【００１５】
請求項７記載の文書管理サーバーシステムでは、請求項２〜６いずれか記載の文書管理サーバーシステムにおいて、アクセス権限管理手段には、ユーザーに応じてアクセスが許容される１つ以上のデータファイルが設定されていることを特徴とする。
【００１６】
請求項８記載の文書管理サーバーシステムでは、請求項２〜７いずれか記載の文書管理サーバーシステムにおいて、アクセス権限管理手段には、ユーザーに応じてアクセスが許容されるデータファイル内の文書、及び文書内の項目が設定されていることを特徴とする。
【００１７】
請求項９記載の文書管理サーバーシステムでは、請求項２〜７いずれか記載の文書管理サーバーシステムにおいて、アクセス権限管理手段には、ユーザーに応じて参照モード、または編集モードのうちいずれかのアクセスを許容する機能が備えられていることを特徴とする。
【発明の効果】
【００１８】
本発明では、前記構成を採用しているので以下の効果を有する。
請求項１記載の文書管理サーバーシステムにおいては、サーバーには所定の分類に従って記録された複数のデータファイルが記録されている。このデータファイルはＸＭＬ、ＪＳＯＮ等の統一したデータ様式によって記録されているので一元的な取扱いが可能となる。
サーバーにはクライアントのユーザーに応じたデータ処理を実行するためのプログラム（文書処理手段）が設定されている。このプログラムを介してクライアントからのアクセスを識別し、アクセスしてきたクライアントのユーザーに応じて１つ以上のデータファイルに対して、ユーザー特有のデータ処理が行われる。
【００１９】
請求項２記載の文書管理サーバーシステムにおいては、（１）ユーザーの求めに応じて所定の項目を文書にまとめる文書カテゴリー定義手段が設定されているので、ユーザーが求める情報をデータベースから抽出して提示できる。
（２）前記文書の項目をデータベースのデータとして定義する項目定義手段が設定されているので、文書に対応した項目が抽出され提示される。
項目定義手段は文書を構成する項目群とそれらの属性を定義し、文書カテゴリー定義手段と項目定義手段が合わさって項目立てを有するまとまったひとつの文書が作成される。
（３）ユーサーのアクセス範囲を規定するアクセス権限管理手段が設定されているので、ユーザーに応じて参照、編集、加工できるデータが規定される。
【００２０】
請求項３記載の文書管理サーバーシステムにおいては、プログラムはクライアントのユーザーに共通する共通文書処理手段と、ユーザーに特有のユーザー別文書処理手段を有するので、プログラム構成が明確にされ、プログラム管理が適切に行われる。
【００２１】
請求項４記載の文書管理サーバーシステムにおいては、統一したデータ様式としてのリレーショナルデータベースシステムによって、データ管理が効率的に行われる。
また、全ての文書データには（１）何の案件に関するデータであるか、（２）どのカテゴリーに属するデータであるか、（３）誰が作成したデータであるか、（４）いつ作成または編集したデータであるか、また、文書データ本体として少なくとも一つの項目とその項目に対応するアドレス情報を備え、そのアドレスには可変長データが記録されるので、データの所属を明らかにした上で文書管理が適切に行われる。
【００２２】
請求項５記載の文書管理サーバーシステムにおいては、統一したデータ様式としてのキーバリューストア型データベースによって、データ管理が効率的に行われる。
また、全ての文書データには（１）何の案件に関するデータであるか、（２）どのカテゴリーに属するデータであるか、（３）誰が作成したデータであるか、（４）いつ作成または編集したデータであるか、また文書データ本体として少なくとも一つの項目とその項目に対応する可変長データが記録されるので、データの所属を明らかにした上で文書管理が適切に行われる。
【００２３】
請求項６記載の文書管理サーバーシステムにおいては、可変長データは、ＸＭＬ形式またはＪＳＯＮ形式で記録されているので、統一したデータ様式によって一元管理される。
【００２４】
請求項７記載の文書管理サーバーシステムにおいては、アクセス権限管理手段には、ユーザーに応じてアクセスが許容される１つ以上のデータファイルが設定されているので、アクセス先が明確に規定される。
【００２５】
請求項８記載の文書管理サーバーシステムにおいては、アクセス権限管理手段には、ユーザーに応じてアクセスが許容されるデータファイル内の文書、及び文書内の項目が設定されているので、アクセス先が、さらに詳細に規定される。
【００２６】
請求項９記載の文書管理サーバーシステムにおいては、アクセス権限管理手段には、ユーザーに応じて参照モード、または編集モードのうちいずれかのアクセスを許容する機能が備えられているので、ユーザーの所属、権限等に応じたアクセスモードが設定される。
【発明を実施するための最良の形態】
【００２７】
本発明を実施するための最良の形態を説明する。
本発明の医療情報共有システムの概要を図１に示す。病院Ａには、文書管理サーバーが設置され、ＬＡＮケーブルないし無線ＬＡＮを介して、院内の端末ＰＣ群と連結されている。病院Ａの文書管理サーバーは、ウェブサービス（Web Service）と呼ばれるサービスソケットがあり、端末ＰＣブラウザからの要求に応じて、文書データの送受信を行う。ファイアーウォール、ルーターを介して、インターネット回線に連結されている。
【００２８】
介護施設Ｂでは、同様に端末ＰＣ群がＬＡＮに連結されているが、ルーター、ファイアーウォールを介してインターネット回線に連結されている。介護施設Ｂ内にはサーバーは設置されておらず、端末ＰＣは、インターネット回線を通じて、病院Ａのサーバーと文書データの送受信を行う。相互のインターネットを介しての通信は、ＶＰＮ接続などセキュリティの高い通信がより好ましいが、ＳＳＬなどの暗号化通信でも良い。このように、自施設内にはサ-バーを持たず、インターネット経由でサービスを受けるやり方は、SaaS（Software as ａ Service）と呼ばれている。
【００２９】
学校Ｃも、ルーター、ファイアーウォールを介して同様にインターネット回線に連結されている。学校Ｃ内にもサーバーは設置されておらず、ＬＡＮに接続されている端末ＰＣのブラウザを用い、インターネット回線を通じて、病院Ａのサーバーと、SaaSの形で文書データの送受信を行う。
【００３０】
上記各施設のスタッフは施設内のＰＣからアクセスするが、患者や入所者、利用者なども、自分のＰＣからインターネット経由で同様に文書管理サーバーにアクセスし、付与されているＩＤとパスワードで認証を受け、許可を受けている範囲で自らに関する文書データを参照、編集する。時には、本図の文書管理サーバーとは別個の文書管理サーバーに属する医療機関などから、共通する患者の情報を参照する場合もある。
【００３１】
一個の文書管理サーバーシステムで、性格の異なる複数の施設の文書を管理するためには、（１）夫々の施設で用いられる文書カテゴリーのリストおよび各文書カテゴリーの項目建ての管理手段、（２）各々の施設で用いられる様々なカテゴリーの文書とその項目を処理するための文書処理手段、（３）作成された種々の文書を記録・参照する文書データ記録手段、（４）アクセスしてきたユーザーを認証し、許可された範囲でのみ文書閲覧や作成・編集を可能とする、ユーザー認証、ユーザー毎の文書アクセス権限管理手段、の各手段群が必要である。
以下、本発明の具体的実施例を、各手段群に沿って説明する。
【００３２】
図２は、各施設によって用いられている文書カテゴリーのリストである。診療所、病院などの医療機関、介護施設、学校などの施設の活動に応じて様々な文書カテゴリーが用いられている。また、同じ医療機関という施設類型であっても、共通な文書カテゴリー以外に施設特有の文書カテゴリーが用いられている。夫々の文書カテゴリーは、その文書特有の項目から構成されている。
【００３３】
図３、４は、文書カテゴリーの項目構成例である。図３は医師記録、図４は、患者の日常生活のレベル評価記録の一部を示す。自由記載項目、性別や複数のレベルからの選択などのような択一項目、年齢などの整数値、等など様々な形式の項目がある。
夫々の項目の定義様式については、施設の特性や使用しているシステムの仕様に合わせて、適宜公知の定義様式を選択すればよい。このように、施設によって様々な種類の文書カテゴリー、その文書カテゴリー毎の項目建てが用いられているので、これらを処理してゆくためには、施設毎の文書カテゴリー定義手段、文書カテゴリー毎の項目定義手段が必要である。文書の印刷書式や、データの制限値などのデータフォーマットなどの文書カテゴリー定義情報、項目建て定義情報等の書式データも可変長データとなるが、当然ながら文書のカテゴリーによって異なる。
通常は、書式データの登録を、別リレーションで管理し、その書式データＩＤのみを記録する。しかし、個々の文書によるバリエーションが多彩にわたる場合は、この書式データも、文書内容データと同様に、文書毎に対応するＸＭＬないしＪＳＯＮ形式の書式ファイルを記録し、そのファイルへのアドレスを記録しても良い。
【００３４】
この文書カテゴリー定義手段、文書カテゴリー毎の項目定義手段は、施設に応じて、すなわち、アクセスするユーザーに応じて設定された文書カテゴリーやその項目を定義するプログラムであり、医療機関や教育機関、行政その他企業等のユーザーの求めに応じてデータ処理を実行する。
ある医療機関がデータベースにアクセスすると、その医療機関のユーザーに特有のプログラムを介してデータベースの参照、編集、加工が行われ、行政機関がデータベースにアクセスすると、その行政機関のユーザーに特有のプログラムを介してデータベースの参照、編集、加工が行われる。
ユーザーに対してどのプログラムを適用するかは、ＩＤ、パスワード等によってサーバーが認証して選択適用する。
【００３５】
次に、様々な項目構成を持つ種々の文書カテゴリーの文書データを記録する文書データ記録手段につき説明する。ここでは医療機関における患者基本情報と薬剤処方という２種類の文書カテゴリーの文書データを例に取る。
図５は、夫々の文書データを、リレーショナルデータベースの形式で表現したものである。リレーショナルデータベースでは、個々の項目は固定長データとして記録され、それによる高速処理が可能となっている。その反面、項目建てが異なれば、同一の表(リレーション)として扱うことは困難であるので、別々のリレーションとなる。
【００３６】
図６、図７は、図５の各々のリレーションのデータを、ＸＭＬおよびＪＳＯＮと呼ばれる形式で表現したものである。ＸＭＬ形式およびＪＳＯＮ形式では、データはテキストファイルとなり、ファイルの長さは異なってくる。項目建ては、ＸＭＬ形式では、＜＞で示されるタグで表現される。ＪＳＯＮ形式では、"タグ名"："データ"の形式で表現される。部門ごとのデータ項目建てが異なっていても、一つの文書の全データ項目は、一つのＸＭＬ形式ないしＪＳＯＮ形式のデータファイルに変換できる。たとえ、項目建てや記載形式が異なっていても、ＸＭＬファイル化ないしＪＳＯＮファイル化してしまえば、全て一つの可変長テキストファイルに過ぎない。従って、リレーションの一つの枡目に、ＸＭＬ文書データないしＪＳＯＮ文書データの記録場所を指し示す固定長のアドレスを格納すればよい。
【００３７】
ＸＭＬ形式は、入れ子構造や繰り返し構造などの複雑なデータ構造を表現できるので汎用性が高い反面、処理に時間がかかり、単純な構造のデータに対しては、却って不経済である。このような場合、ＪＳＯＮ形式のように単純に"タグ"と"データ"を"："を挟んで併置させただけの構造のほうが効率的である場合も多い。状況に応じて、適宜両者を使い分ければよい。以下、より実用化が進んでいるＸＭＬ形式を例に採り、解説を進めるがＪＳＯＮ形式でも同様のことが言える。
なお、ＣＳＶ形式と呼ばれる、値をカンマ「，」で区切っただけの形式、あるいは、全く内部構造を有さずに文書内容をテキストとしてベタ書きした形式の文書データファイルでも本発明の実施は可能であり、本発明に含まれるが、個々のデータが何を意味しているのかが分かり難く、また検索用索引が作りにくいので、必ずしも好ましい形式とは言えない。
可変長の文書内容データは、実施例では一つのＸＭＬないしＪＳＯＮファイルにまとめているが、分量が長大な際は、複数のファイルに分割して記録しても良い。また、文書内容データと文書フォーマットなどのように、内容別に複数の可変長データとして記録しても良い。
【００３８】
ここで、図８に示すように、文書ＩＤ、作成者、作成日、文書カテゴリーおよび文書主体であるＸＭＬテキストファイルを示す固定長アドレスからなるリレーションを考える。このようにすれば、文書カテゴリーごとの項目立ての違いはＸＭＬ形式で吸収されるため、全ての文書カテゴリーを同一リレーションで扱うことが容易に可能となる。このようなデータベースは、ＸＭＬリレーショナルデータベースと呼ばれている。実用上のシステムでは、ＸＭＬがテキストのままでは処理が遅くなるので、ＸＭＬテキストデータを機械処理可能な内部表現（バイナリー形式）でオブジェクト化したものを記録する（ＸＭＬオブジェクトリレーショナルデータベース ＸＭＬ Object Relational Data Base）。さらに、高速処理するための索引を整備する。
このように、サーバーのデータベースは、所定の分類に従って記録された複数のデータファイルを有している。
【００３９】
医療機関のみならず、教育、行政、企業においても、文書には、可変長の文書内容データそのもの以外に、以下の文書の属性を示す情報が必須である。（１）何の案件に関する文書であるか、（２）どのカテゴリーに属する文書であるか、（３）誰が作成した文書であるか、（４）いつ作成/編集した文書であるか、である。
（１）の案件を特定するＩＤは、医療機関であれば患者ＩＤであり、教育機関であれば生徒ＩＤ、行政機関であれば住民ＩＤ、企業であれば得意先ＩＤなど、あるいは、プロジェクトＩＤなどがある。いずれにせよ、本文書作成装置を使用する環境で、文書群の括りとして適切なＩＤを選べばよい。
（２）文書カテゴリーＩＤは、案件を構成する文書群で、文書の種類を示す。医療では、患者基本情報、薬剤処方箋等などであり、教育では、単位登録申請書、試験成績など、行政では、戸籍謄本、住民票、納税履歴など、企業では、取引履歴、営業履歴、トラブル履歴などがある。文書のカテゴリーによって、記載される内容や書式が異なるのは言うまでもない。
（３）スタッフによって、職位、職種、担当範囲などが異なる。権限外の文書を作成、編集することは勿論、場合によっては参照も許されないことは言うまでもない。パスワードなどでの個人認証を行い、そのスタッフのアクセス権限を特定することは、本文書作成装置の運用において必須である。
（４）文書の作成日時は、しばしば文書の法的な証明力で問題になるところであり、改ざんなどが無い様に、厳重に管理される必要がある。
【００４０】
ＩＤ、文書カテゴリー、作成者、作成/編集時間等の情報は、図８に示すように、リレーショナルデータベースの独立した項目として記録したほうが、後の検索などの際には高速処理が出来るので、より好ましいといえる。しかし、可変長の文書内容データの実体であるＸＭＬデータの索引が充実しているなら、場合によっては、属性を示す任意の項目を、可変長の文書内容ＸＭＬデータに内包させても良い。
図８では、横一連の文書ＩＤを単位とするデータに（１）何の案件に関する文書であるか、（２）どのカテゴリーに属する文書であるか、（３）誰が作成した文書であるか、（４）いつ作成/編集した文書であるか、の属性情報が付されている。
【００４１】
図９では、上記の統合された文書データ記録手段を用いた文書管理サーバーシステムの好ましい実施例の一つである。文書処理手段では文書カテゴリー毎にウェブサービスのソケットを持ち、端末ＰＣとの文書データ通信を行う。端末ＰＣから、各ウェブサービスソケットを通じて要求があれば、統合された文書データ記録手段に対して検索を行い、文書カテゴリーのリスト、指定された文書カテゴリー内の文書リスト、指定された文書の文書内容データを、端末ＰＣに対して、当該ウェブサービスソケットから送信する。また、文書データの書き込み要求があれば、当該ウェブサービスソケットで端末ＰＣから文書データを受信し、統合された文書データ記録手段に書き込みを実行する。このように、統合された文書データ記録手段は、ウェブサービス処理モジュール間のデータ連携のバスとして機能する（データベースバス）。ウェブサービスを用いることで、施設内外を問わず、インターネットの標準形式で文書データの送受信が可能となる。
【００４２】
図１０に示すように、多施設の統合化された文書データ記録手段においては、文書データに、施設を識別する施設コードが必要であるが、施設毎に文書データ記録手段を分割して管理する際は、施設コードの必要はない。データ量やセキュリティ等の種々の条件を勘案して、適宜構成を決めればよい。
本文書作成装置の運用環境によっては、文書の変更や削除が行われても、元の文書を履歴として保存しておき、変更履歴を何時でも参照できるようにしておくことは有用である
【００４３】
従来は、図１１に示すように、文書カテゴリー毎に、異なるリレーションを夫々管理するための部門システムを別個に作成し、それらの部門システムを集合させることで全体システムを構成していた。別の表現をすれば、文書カテゴリー毎に、文書データを管理する手段と、その文書データを処理する手段からなる部門システムモジュールを多数組み合わせ、端末ＰＣからはＨＬ-７などの通信規格に基づいて、参照や書き込み要求を行うものであった。この従来のやり方では、施設毎に異なる無数の文書カテゴリーを、前記のように統一的に扱うことが困難である。多数の異なるリレーションと、夫々を管理する部門システムが独立しているため、データの一元管理は困難で、データ全体にわたる検索などは困難を極める。誰かが或る患者のカルテを開くと、その間は他のユーザーは当該カルテへのアクセスが制限されるという問題もある。また、ソフトウェアも、施設ごと部門システムモジュール毎に用意する必要があり、統一的な管理は、不可能に近く多額の開発、保守費用がかかっていた。 また従来の部門システムは、個別にデータを管理し、ＨＬ-７などの形式でデータの問い合わせ、返答を行うものだったため、多元的な参照は複雑を極めた。しかし、今回の発明のように、データ構造が一元化されれば、複雑な参照もＳＱＬ文を一発叩けば簡単に実現する。
【００４４】
図１２は、図９の文書処理手段部分を詳細化したものである。
文書処理手段では、前記文書データ記録手段（データファイル）から文書データを読み出す、読み出した文書データを読みやすい形に表示する、文書データを編集して書き込む、或いは新規文書を作成したり、不要に文書をなった削除したりする等などの処理を行う。図３、図４に示したように、多種多様な文書カテゴリーと項目構成があるため、複数の施設毎の文書カテゴリー定義手段、前記文書カテゴリー毎の項目定義手段を備えている。文書カテゴリー毎に、前述のように端末ＰＣと文書データの送受信を行うウェブサービスのソケットを設けている。また、後述するように、認証されたユーザー毎のアクセスコントロールテーブル（Access Control Table）を用いた、ユーザーごとのアクセス管理手段を備えている。
サーバーにはクライアントからのアクセスを識別し、ユーザー毎の文書アクセス管理手段で、どの文書カテゴリーにどこまでアクセス可能かを識別する。アクセスしてきたクライアントに応じてアクセス可能なデータファイルに対して、当該文書カテゴリーの構成項目情報を提供し、当該文書に対する文書処理手段（プログラム）を適用したデータ処理を行う機能が備えられている。
【００４５】
端末ＰＣから文書データ送受信の要求があった場合、先ずＩＤやパスワード入力、或いは生体認証などでユーザーの認証を行う。次いで、当該ユーザーのアクセスコントロールテーブルを検索し、当該する患者および文書カテゴリーに対して、当該アクセス要求が許可されているかを確認する。もし許可されてなければ、その旨のエラーメッセージを送信し、以降の処理は行わない。
当該文書カテゴリーの参照要求が許可されているならば、当該文書データを前記文書データ記録手段から読み出し、当該文書カテゴリー定義手段および文書カテゴリー毎の項目定義手段の定義情報を併用して、文書の表示体裁を整えた後、端末ＰＣに送信する。書き込み要求が許可されているならば、必要に応じ当該文書カテゴリー定義手段および文書カテゴリー毎の項目定義手段の定義情報を併用して受信した文書データの整合性を確認した後、文書データ記録手段に記録する。
【００４６】
ここで、文書処理手段のソフトウェアとしての構成を考える。端末PCからの要求を受け付ける、要求が許可されているかを調べる、文書データを文書データ記録手段から読み出す、当該文書カテゴリー定義手段および文書カテゴリー毎の項目定義手段の定義情報を併用して、文書の表示体裁を整える、編集後の文書データを、文書データ記録手段に書き込む等などの処理は、文書カテゴリーの種類によらず共通の処理である。この共通の処理は、共通文書処理手段に一ヶ所まとめて定義しておけばよい。もしオブジェクト指向プログラミングでソフトウェアが書かれているならば、親オブジェクトに共通処理メソッドとして定義しておけばよい。こうしておけば、従来のように文書カテゴリー毎に別々の部門システムを作成し、同じような処理を、部門システムごとに別途定義する必要はなくなり、ソフトウェアの軽量化、開発や保守の低コスト化が得られる。
【００４７】
図１３（ａ）は、文書処理手段の階層構成を示す。最下層は、通信データの送受信、ファイルへの文書データの読み書き、それらに関してのエラー処理などが該当する。次の層は、ユーザー認証、文書の表示、文書の編集などの最下層の機能を基盤とした、文書カテゴリーに共通する処理が該当する。最上位には、項目の得点を計算する等といった、夫々の文書カテゴリー固有の処理が該当する。このようにひとつのソフトウェアに全ての文書処理機能をまとめても良い。
【００４８】
しかし、医療機関と教育機関などでは、文書カテゴリーが全く異なり、固有の処理も多い。このような場合、文書処理手段を全て一つのソフトウェアにまとめた場合は、ソフトウェアが肥大化しやすく、処理が重くなる危険がある。そのため、図１３（ｂ）に示すように、文書処理手段を、各施設共通の共通文書処理手段と各施設固有の施設別文書処理手段（ユーザー別文書処理手段）に分離し、処理の際の必要に応じて、両者を結合させ、文書処理を行うものである。施設別文書処理手段は単一とは限らず、文書カテゴリーに応じて複数準備しておいて、必要に応じて結合してもよい。また、ある文書を処理する施設別文書処理手段は、単一モジュールとは限らず、複数の文書カテゴリーに共通のモジュールと、当該文書固有の処理モジュールの組み合わせでも良い。必要に応じて施設あるいは文書カテゴリー群ごとにソフトウェアを分割して開発しておき、必要なモジュールのみ実装するようにしても良い。この節の議論は、サーバー側のソフトウェア、SaaS端末或いはクライアントソフトウェアなど、端末ＰＣ側で動作するソフトウェアのいずれでも成り立つことは言うまでもない。
【００４９】
複数の施設にまたがって文書データを管理する際は、同一対象者が複数の施設に文書データを有する場合がある。例えば、ある地域に住む患者が、複数の病院やクリニックに受診して治療を受けている場合である。患者の同意の下に、他の医療機関の診療データを参照できれば、重複検査が不要となり医療費の削減に有用なだけでなく、重要なアレルギーや疾患の情報の見落としが減少し、医療安全の向上に役立つ。同一対象者の複数施設にわたる情報を参照する場合は、全施設の全文書カテゴリーに対してのアクセス権限を、個々のユーザー毎に管理する必要がある。
【００５０】
図１４は、或るユーザーが、文書カテゴリーにどの程度アクセスできるかをまとめたアクセスコントロールテーブル（Access Control Table）を示す。
本発明のアクセス権限管理手段は一例として図１４のテーブルを参照しながら、サーバーのデータベースに対するユーザーのアクセスできる範囲を規定する。
横軸は施設/文書カテゴリー、縦軸は患者番号、学生番号、案件番号など、文書の属する固有ＩＤである。施設によって個別の番号が振られている場合も多いので、実施に当たっては、共通番号などの、別途一意的なＩＤ番号を設定することが望ましい。
コンピュータを起動させる時に、またはネットワークにアクセスする時に、ユーザーのＩＤやパスワードの入力、あるいは生体認証など、それ自体は公知の技術によりユーザー認証がなされる。ユーザーの特定がなされれば、そのユーザーのアクセスできるデータ範囲も同時に規定される。例えば、図１４において、当該認証ユーザーは、病院Ａの医師であったとしよう。病院Ａの患者については、患者基本情報や医師初診時記録などに関しては、参照/編集ともに可能である。しかし看護記録は、職種が異なるので、参照のみとなる。
【００５１】
通常は、当該施設に関連する患者などに関しては同一のアクセス権限が適応される場合が多いが、有名人や政治家など特段の秘密保持が必要な場合は（例えばＩＤ9567）、限定されたスタッフにのみ真のアクセス権限を与え、そのほかのスタッフにはアクセスさせない場合もある。この場合は医師といえども一切参照できない。
他の診療所Ｂや、介護施設Ｃについては、相手側施設の許可と本人の同意があった場合のみ、その患者/入所者についてだけ参照が可能となる。その他の患者/入所者の文書は、当然参照できない。また、その施設のスタッフではないので、当然文書編集は出来ない。
現在はチーム医療が行われ、多数の職種が一人の患者の治療に関わってくる。医療機関内で、或る特定の患者のデータのみをアクセス禁止にすると却って怪しまれる場合は、真実を知らせる訳には行かない医療スタッフには、偽の氏名や生年月日を表示することも有効である。また、予め登録されている施設スタッフが、属する施設の外からアクセスしてきた際は、ＩＤ成りすましの危険がありうるので、個人特定による情報流出を避けるため、患者名や生年月日の表示を、イニシアル表示、年齢表示とするなど曖昧化する場合もある。
本図では、文書カテゴリー単位でのアクセス権限を定義しているが、場合によっては、文書内の項目建てレベルでアクセスの可否を指定しても良い。全対象者についてアクセスコントロールテーブルを実際に作ると膨大なデータ量になるので、通常は、デフォールト値の設定、例外部分の重ね書きなどの方法を用いて、データ量を圧縮する必要がある。要は、特定ユーザーが特定対象者に関する参照を要求してきた際に、その諾否に必要なアクセスコントロール情報が再現できれば良い。
【００５２】
ある地域に住む患者が、複数の病院やクリニックに受診して治療を受けている場合、患者の同意の下に、他の医療機関の診療データを参照できれば、重複検査が不要となり医療費の削減に有用なだけでなく、重要なアレルギーや疾患の情報の見落としが減少し、医療安全の向上に役立つことは前述した。本発明の同一サーバー内に文書データが存在する場合は、照会元のユーザーも既に登録されているので、当該ユーザーのアクセスコントロールテーブルが存在するので、照会先の機関の同意により、アクセス権を設定すればよい。しかし多くの場合は、医療機関ないし医療機関群毎に管理している別の文書管理サーバーシステムに存在する。その際は、照会元のユーザーは、照会先の文書管理サーバーシステムにユーザー登録が無いので、電話やメールなどの方法で依頼し、ユーザー登録を行い、同様に、照会先の機関の同意を得た文書カテゴリーに付きアクセス権を設定する。場合によっては、地域で相互参照可能な機関同士のリストを作成し、予めユーザー登録/アクセス権設定をしておいても良い。
【００５３】
従来の地域カルテ共有システムでは、（１）地域カルテ共有サーバーに、カルテからの抽出情報を蓄積しておいて、参照要求に応える。（２）地域カルテ共有サーバーには、参照元ユーザーの認証、患者が受診している医療機関と、そこでのＩＤ、開示されている文書カテゴリーリストのみを管理。各医療機関は、地域カルテ共有サーバーの認証を受けてきた参照要求に対して、内部カルテの情報を開示用データに変換する医療機関開示サーバーで、参照要求に応える、の両形態が行われている。
【００５４】
先ず、（１）の方式では、地域カルテ共有サーバーにたまる大量のデータの管理費用がかかること、万一個人情報漏洩が起これば甚大な被害が出ることなどの理由から、現在は用いられなくなってきている。（２）の方式が現行の主流となりつつあるが、個々の医療機関毎に、開示用データを適合させるソフトの開発費用、サーバーの導入運営費用等がかかってしまう問題があった。また、図２で示したように、医療機関毎に文書カテゴリーや項目建ては全て異なるため、共有される文書カテゴリーは一部に留まる欠点があった。
本発明を地域カルテ共有システムに適用した場合を考える。他の医療機関のユーザー、或いはカルテ開示を求める患者や家族は、本発明の複数施設の文書管理サーバーシステムに、図１４に示すように、適切なアクセスコントロールテーブルを設定してユーザー登録してしまえば、上記（２）の方式のように、費用のかかる医療機関開示サーバーは不要であり、本発明の文書管理サーバーシステムが直接参照元のユーザーに応答する。アクセス権の設定があれば、いかなる文書カテゴリーも、当該施設本来のユーザーと同様に速やかに参照できる。（２）の方式で必要とされる、開示用にデータの適合性を整えるための事前のソフトウェア開発は不要である。なお、セキュリティ上の心配があれば、本発明の文書管理サーバーシステムとユーザーの間に、一時的に開示データだけを保持する中継サーバーを置いても良い。
【００５５】
文書データ記録手段として、リレーショナルデータベースの各項目に、ＩＤ、文書カテゴリー、作成者、作成日時などの索引キー項目、およびＸＭＬないしＪＳＯＮ形式で記録された文書主体のテキストデータの位置を示すアドレス項目を備えた例を解説してきた。最近クラウド型のデータ記録として注目を集めている、キーバリューストア型のデータベースを用いても、同様の機能を実現することが出来る。図１５において、文書キーは、キーバリューストア型データベースに文書データを新規に記録する際に、システム側で自動的に振られる一意的な文書番号で、記録テーブル内の位置を一意的に表現するものである。リレーショナルデータベースの際と同様、（１）何の案件に関する文書であるかを示すＩＤ、（２）どのカテゴリーに属する文書であるかを示す文書カテゴリー、（３）誰が作成した文書であるかを示す作成者、（４）いつ作成/編集した文書であるかを示す作成日、また、文書データの本体として、少なくとも一つの項目とその項目に対応する可変長データの各情報を最低限記録しておく必要がある。
【００５６】
ＩＤは、当該文書が帰属する患者/学生/案件番号などを示す。
もし、多施設の文書が混在する構成ならば、施設コードも必要である。
文書カテゴリーは、当該文書が属する文書の種類、作成者、作成日は、誰が何時この文書を作成したかを示す。
文書主体では、当該文書の本文が、ＸＭＬ形式、ＪＳＯＮ形式、あるいはＣＳＶないし構造を持たない通常のテキストとして記録されている。
リレーショナルデータベースの例では、升目には固定長のアドレスを入れ、アドレス先に文書の主体を記録する必要があった。
同様の構成をとっても本発明は実施でき、本発明の範囲に含まれるが、ＧｏｏｇｌｅのBigtableなどの例では、各升目に入るデータは可変長データを許容するので、その升目の中に文書テキスト全文を直接記録することが、より好ましい実施例といえよう。
勿論、必要に応じて、複数の升目に分割記録することも可能である。
【００５７】
ＩＤから作成日までの項目は、索引項目であり、シングルキー索引やコンポジットキー索引などと呼ばれる様々な索引を予め作成しておき、条件検索して文書キーを求め、テーブル内の論理的位置から物理的位置を求め、目的とする文書主体のテキストテータを得るものである。状況に応じて様々な索引項目が必要であるが、最低限の索引項目として、前記（１）何の案件に関する文書であるか、（２）どのカテゴリーに属する文書であるか、（３）誰が作成した文書であるか、（４）いつ作成/編集した文書であるかの各項目は必須である。これらの項目を使用して、シングルプロパティ インデックス、或いは組み合わせてのコンポジット インデックスなどの索引を予め作成しておき、検索に備えると良い。
【００５８】
以上、実施例を説明したが、本発明の具体的な構成は前記実施例に限定されるものではなく、発明の要旨を逸脱しない範囲の設計変更等があっても本発明に含まれる。
文書管理サーバーは、図では一医療機関内に一台設置されているものとして説明したが、複数台でクラスターを形成し、併せて一台の仮想サーバーを構成している場合、複数の医療機関やデータセンターで相互にバックアップを行い、全体で、いわゆる「プライベートクラウド」を形成している場合などがある。場合によっては、（１）データ記録と処理の全てのサーバー機能をAmazonやGoogleのようなパブリッククラウド上に設営し、一切のハードウェア資源を手元に持たない場合、（２）或いは、データ記録は手元のサーバー、サーバー群に確保しておいて、ウェブを介してクラウド上のサーバー上で文書データの読み出し、編集などの処理のみを行う場合も、状況によってはありうる。
本発明の文書管理サーバーシステムは、一台のサーバーを占有する必要は無く、他のシステムと並存/共有しても良い。
インターネットを介した好ましい通信様式として、ウェブサービスを用いて説明したが、互換性などの問題から、敢えてＨＬ-7などの旧式の通信様式を用いても良い。
本発明の文書管理サーバーシステムは、ある時点では一施設のデータのみで、複数施設のデータを直接管理していない場合でも、必要に応じて追加施設のデータを管理しうるソフトウェア、ハードウェアの構成にあれば、本発明に含まれる。
実施例として、医療機関の例を用いたが、教育機関、行政機関でも全く同様の議論が可能であり、本発明に含まれる。ＩＤとしては、患者や生徒、住民などの人間に対するものだけでなく、事案番号など、文書群の括りになるものであれば、本発明が応用できる。
【図面の簡単な説明】
【００５９】
【図１】文書管理サーバーシステムのネットワークの説明図である。
【図２】文書カテゴリー構成の違いを示す説明図である。
【図３】特定のユーザーにおける文書を構成する項目の説明図である。
【図４】他の特定のユーザーにおける文書を構成する項目の説明図である。
【図５】リレーショナルデータベースの説明図である。
【図６】図５上段の図をＸＭＬおよびＪＳＯＮ形式で表わした場合の説明図である。
【図７】図５下段の図をＸＭＬおよびＪＳＯＮ形式で表わした場合の説明図である。
【図８】ＸＭＬリレーショナルデータベースの説明図である。
【図９】文書管理サーバーシステムの概略構成図である。
【図１０】多施設の統合化された文書データ記録手段の概略構成図である。
【図１１】従来例に係る文書管理サーバーシステムの概略構成図である。
【図１２】文書処理手段の説明図である。
【図１３】文書処理手段の階層構成とモジュール化構成を示す説明図である。
【図１４】アクセスコントロールテーブルの説明図である。
【図１５】キーバリューストア型のデータベースを用いた例を示す説明図である。
【特許請求の範囲】
【請求項１】
所定の分類に従って記録された複数のデータファイルを有したサーバー、サーバーにアクセスしてデータの作成、編集、参照などの文書管理サービスを受けるクライアントからなる文書管理サーバーシステムであって、
前記データファイルは統一したデータ様式によって記録され、
前記サーバーにはクライアントのユーザーに応じたデータ処理を実行するためのプログラムが設定されており、
前記サーバーにはユーザーからのアクセスを識別し、アクセスしてきたユーザーに応じて１つ以上のデータファイルに対して、前記プログラムを適用したデータ処理を行う機能が備えられていることを特徴とする文書管理サーバーシステム。
【請求項２】
前記プログラムには、
（１）ユーザーの求めに応じて所定の項目を文書にまとめる文書カテゴリー定義手段、
（２）前記文書の項目をデータベースのデータとして定義する項目定義手段、
（３）ユーサーのアクセス範囲を規定するアクセス権限管理手段、
が設定されていることを特徴とする請求項１記載の文書管理サーバーシステム。
【請求項３】
前記プログラムはクライアントのユーザーに共通する共通文書処理手段と、ユーザーに特有のユーザー別文書処理手段を有することを特徴とする請求項２記載の文書管理サーバーシステム。
【請求項４】
前記サーバーは、前記統一したデータ様式としてリレーショナルデータベースを備えており、それぞれのデータには、
（１）何の案件に関するデータであるか、（２）どのカテゴリーに属するデータであるか、（３）誰が作成したデータであるか、（４）いつ作成または編集したデータであるかが記録され、
前記リレーショナルデータベースシステムは、文書データ本体として少なくとも一つの項目とその項目に対応するアドレス情報を備え、そのアドレスには可変長データが格納されていることを特徴とする請求項１〜３いずれか記載の文書管理サーバーシステム。
【請求項５】
前記サーバーは、前記統一したデータ様式としてキーバリューストア型データベースを備えており、それぞれのデータには、
（１）何の案件に関するデータであるか、（２）どのカテゴリーに属するデータであるか、（３）誰が作成したデータであるか、（４）いつ作成または編集したデータであるかが記録され、
前記キーバリューストア型データベースシステムは、文書データ本体として少なくとも一つの項目とその項目に対応する可変長データによって構成されていることを特徴とする請求項１〜３いずれか記載の文書管理サーバーシステム。
【請求項６】
前記可変長データは、ＸＭＬ形式またはＪＳＯＮ形式で記録されていることを特長とする請求項４または５記載の文書管理サーバーシステム。
【請求項７】
アクセス権限管理手段には、ユーザーに応じてアクセスが許容される１つ以上のデータファイルが設定されていることを特徴とする請求項２〜６いずれか記載の文書管理サーバーシステム。
【請求項８】
アクセス権限管理手段には、ユーザーに応じてアクセスが許容されるデータファイル内の文書、及び文書内の項目が設定されていることを特徴とする請求項２〜７いずれか記載の文書管理サーバーシステム。
【請求項９】
アクセス権限管理手段には、ユーザーに応じて参照モード、または編集モードのうちいずれかのアクセスを許容する機能が備えられていることを特徴とする請求項２〜７いずれか記載の文書管理サーバーシステム。
【請求項１】
所定の分類に従って記録された複数のデータファイルを有したサーバー、サーバーにアクセスしてデータの作成、編集、参照などの文書管理サービスを受けるクライアントからなる文書管理サーバーシステムであって、
前記データファイルは統一したデータ様式によって記録され、
前記サーバーにはクライアントのユーザーに応じたデータ処理を実行するためのプログラムが設定されており、
前記サーバーにはユーザーからのアクセスを識別し、アクセスしてきたユーザーに応じて１つ以上のデータファイルに対して、前記プログラムを適用したデータ処理を行う機能が備えられていることを特徴とする文書管理サーバーシステム。
【請求項２】
前記プログラムには、
（１）ユーザーの求めに応じて所定の項目を文書にまとめる文書カテゴリー定義手段、
（２）前記文書の項目をデータベースのデータとして定義する項目定義手段、
（３）ユーサーのアクセス範囲を規定するアクセス権限管理手段、
が設定されていることを特徴とする請求項１記載の文書管理サーバーシステム。
【請求項３】
前記プログラムはクライアントのユーザーに共通する共通文書処理手段と、ユーザーに特有のユーザー別文書処理手段を有することを特徴とする請求項２記載の文書管理サーバーシステム。
【請求項４】
前記サーバーは、前記統一したデータ様式としてリレーショナルデータベースを備えており、それぞれのデータには、
（１）何の案件に関するデータであるか、（２）どのカテゴリーに属するデータであるか、（３）誰が作成したデータであるか、（４）いつ作成または編集したデータであるかが記録され、
前記リレーショナルデータベースシステムは、文書データ本体として少なくとも一つの項目とその項目に対応するアドレス情報を備え、そのアドレスには可変長データが格納されていることを特徴とする請求項１〜３いずれか記載の文書管理サーバーシステム。
【請求項５】
前記サーバーは、前記統一したデータ様式としてキーバリューストア型データベースを備えており、それぞれのデータには、
（１）何の案件に関するデータであるか、（２）どのカテゴリーに属するデータであるか、（３）誰が作成したデータであるか、（４）いつ作成または編集したデータであるかが記録され、
前記キーバリューストア型データベースシステムは、文書データ本体として少なくとも一つの項目とその項目に対応する可変長データによって構成されていることを特徴とする請求項１〜３いずれか記載の文書管理サーバーシステム。
【請求項６】
前記可変長データは、ＸＭＬ形式またはＪＳＯＮ形式で記録されていることを特長とする請求項４または５記載の文書管理サーバーシステム。
【請求項７】
アクセス権限管理手段には、ユーザーに応じてアクセスが許容される１つ以上のデータファイルが設定されていることを特徴とする請求項２〜６いずれか記載の文書管理サーバーシステム。
【請求項８】
アクセス権限管理手段には、ユーザーに応じてアクセスが許容されるデータファイル内の文書、及び文書内の項目が設定されていることを特徴とする請求項２〜７いずれか記載の文書管理サーバーシステム。
【請求項９】
アクセス権限管理手段には、ユーザーに応じて参照モード、または編集モードのうちいずれかのアクセスを許容する機能が備えられていることを特徴とする請求項２〜７いずれか記載の文書管理サーバーシステム。
【図１】
【図２】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図３】
【図４】
【図２】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図３】
【図４】
【公開番号】特開２０１３−６５２１６（Ｐ２０１３−６５２１６Ａ）
【公開日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【出願番号】特願２０１１−２０３８６６（Ｐ２０１１−２０３８６６）
【出願日】平成２３年９月１７日（２０１１．９．１７）
【出願人】（５０１３９３７４８）
【Ｆターム（参考）】
【公開日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【出願日】平成２３年９月１７日（２０１１．９．１７）
【出願人】（５０１３９３７４８）
【Ｆターム（参考）】
[ Back to top ]