WO2019111885A1 - 医療・介護支援システムにおけるサービス構築支援方法及びシステム - Google Patents

Abstract

医療・介護支援システムに組み込んだアプリケーション・プログラムが提供する新サービスの内容を、患者若しくは要介護者、又は医療従事者若しくは介護従事者の必要に応じて細かく調整可能なサービス構築支援方法を提供するために、アプリケーション・フレームワーク(200)を利用して開発されたアプリケーション(220)の医療・介護支援システム(30)への組み込み時に、アプリケーション(220)にアプリケーションＩＤを割り当て、且つ当該アプリケーションＩＤをグループＩＤに関連づけて記憶することで、アプリケーション(220)が提供する新サービスを、アプリケーションＩＤが関連づけられたグループのグループ・メンバーに限定して選択的に利用可能とした。また、アプリケーション(220)に搭載された特定機能を、管理者設定で、前記グループに係る患者又は医療従事者の必要に応じて設定されるようにした。

Description

医療・介護支援システムにおけるサービス構築支援方法及びシステム

　本発明は、医療・介護支援システムにおけるサービス構築支援方法及びシステムに関し、さらに言えば、ユーザー端末からの要求に応じて、通信ネットワークを介して特定の患者又は要介護者に係る医療・介護情報を前記ユーザー端末で閲覧可能にすることで、前記患者又は前記要介護者への医療・介護サービスの提供を支援する医療・介護支援システムにおいて、同システム上で動作するアプリケーション・プログラム（以下、「アプリケーション」又は「アプリ」ともいう）を組み込むことで、同システムが提供している医療・介護サービスに新たなサービスを構築して提供するのを支援する方法と、その方法を実施するシステムに関する。

　本出願人は、医療・介護サービスの対象者（つまり患者又は要介護者）毎にグループを生成し、当該グループのグループ・メンバー間で前記対象者に係る医療・介護情報を共有できるようにした医療・介護支援システムについて特許出願をしている（特許文献１参照）。この医療・介護支援システムは、医療・介護サービスの対象者（患者又は要介護者）毎に生成されたグループに、前記医療・介護サービスの１又は複数のユーザー（患者又は要介護者だけでなく医療従事者又は介護従事者を含む）を選択的にグループ・メンバーとして所属させると共に、前記グループに係る前記対象者の医療・介護情報を前記グループ・メンバーに限定して閲覧可能としており、そうすることによって、前記対象者のプライバシーを確保しながら前記対象者に係る医療・介護情報を前記グループ・メンバー間で共有できる、という特徴と利点を有している。この医療・介護支援システムでは、通信ネットワークを介して、個々の患者又は要介護者に関する医療情報や介護情報の閲覧や入出力、メッセージの送受信等をユーザー端末で実行可能としており、専門分野が異なる医師や看護師、栄養士、ケアマネージャー、ヘルパー等の多職種の医療従事者や介護従事者が相互に連携してより良質の医療サービスや介護サービスを提供できるように支援することが可能である。

　ここで、上述した「医療・介護情報」とは、医療・介護サービスの対象者である個々の対象者すなわち患者又は要介護者の医療又は介護に係わる情報すべてを意味する。

　また、特定のプラットフォーム上で動作するアプリケーションの開発を容易にするために設けられるアプリケーション・フレームワークは、以前から知られている。例えば、特許文献２には、ブランド拡大のためのモバイル・アプリケーション・フレームワークを作成するシステムが開示されている。このシステムは、ネットワークへのインターフェースと、開発者から与えられるブランディング・コンテンツを編成して前記モバイル・アプリケーション・フレームワークを作成するためのリソースと、少なくとも一人のユーザーが少なくとも1つのモバイル機器から前記モバイル・アプリケーション・フレームワークにアクセスするためのアプリケーションとを備えており、前記モバイル・アプリケーション・フレームワークは、ブランディング機能の複数の事前定義済みカテゴリにアクセスするためのナビゲーションメニューと、前記事前定義済みカテゴリ内の個々の機能へのアクセスを提供するサブメニューとを含み、前記事前定義済みカテゴリは、対象となる産業区分に応じたブランド拡大のために割り当てられる（請求項１、段落００１４～００２５、図１～図６参照）。

　さらに、特許文献３には、スマートフォン向けのアプリケーション（ゲーム）で特定の機能を実行するためのプログラムコードを予め製作して開発者に提供することにより、スマートフォン向けのアプリケーションを容易に開発できるようにすると共に、開発期間を短縮できるように考案した、ネットワーク基盤のプラットフォーム・システムが開示されている。このプラットフォーム・システムは、スマートフォン向けアプリケーション・フレームワークと、前記アプリケーション・フレームワークを基盤に開発したスマートフォン向けアプリケーションに搭載されるべき特定機能のＵＩ（ユーザー・インターフェース）画面の認識コードを提供するフレームワーク提供サーバー、前記アプリケーションを配布するストアサーバー、そして、前記フレームワーク提供サーバーからスマートフォン向けアプリケーション・フレームワークが提供されて、開発者のキー入力に応じてスマートフォン向けアプリケーションを生成すると共に、前記アプリケーション・フレームワークに具現されている特定の機能を前記アプリケーションに搭載して、前記アプリケーションを開発者のキー入力により前記ストアサーバーに登録するクライアント端末を含む（請求項１、４、５、１０、段落００２８～００６１、図１～図３参照）。

特開２０１５－１５０１０号公報 特表２０１３－５２１５４６号公報 特開２０１３－１４３１２５号公報

　しかし、上述した特許文献１の医療・介護支援システムには、対応すべきニーズがあることが判明した。それは、医療や介護の現場では、同システムが提供している医療・介護サービス（以下、これらのサービスを「既存サービス」ということがある）に対して、近年、患者や要介護者や医療従事者（つまり既存サービスのユーザー）への提供が望まれる新サービス（以下、これらのサービスを「付加サービス」ということがある）、例えば服薬管理サービスや糖尿病等の疾病の治療支援サービスなどが多く提案されて来ているのに、そのような付加サービスを既存サービスのユーザーに提供するのが容易でないことである。

　具体的に言うと、特許文献１の医療・介護支援システムが提供する既存の医療・介護サービスに、この種の付加サービス（新サービス）を追加しようとすると、その付加サービスを実現する機能をその医療・介護支援システムに追加しなければならないが、追加が望まれる付加サービスは多種類あるため、また、この種の付加サービスに対するニーズは今後も継続して生じると予想されるため、付加サービスを追加するたびに新たに開発作業を行うことが必要になり、開発コストの高騰を招くことになる。したがって、この手法は現実的ではない。そこで、この医療・介護支援システム上で動作するアプリケーションを、必要に応じて外部企業等に開発してもらい、そのアプリケーションを特許文献１の医療・介護支援システムに組み込むことによって前記付加サービスを逐次、追加提供できるようにすることが考えられる。

　しかし、特許文献１の医療・介護支援システムが提供する医療・介護サービスは、医療・介護サービスの対象者（つまり患者又は要介護者）毎にグループを生成し、前記対象者のプライバシーを確保しながら前記グループのグループ・メンバー間で前記対象者に係る医療・介護情報を共有できるようにしたものであるから、その医療・介護サービス（既存サービス）に追加される付加サービスを提供するアプケリーションは、同システムの上述した特徴と利点を活かせるものであることが必要である。また、同システムの特徴と利点を活かしたアプリケーションを外部企業に開発してもらうことを考えると、アプリケーションをできるだけ容易に開発できる環境を用意することも必要である。

　アプリケーション開発環境に係る上記ニーズを満たすためには、上述した特許文献２や特許文献３に開示されたアプリケーション・フレームワークを設けるという発想は、有益である。しかし、特許文献２や特許文献３に開示されたアプリケーション・フレームワークの目的やそれが対象としているプラットフォームは、特許文献１の医療・介護支援システムのものとは大きく異なっているから、特許文献１の医療・介護支援システム用に特許文献２や特許文献３のアプリケーション・フレームワークの発想を直接的に利用することは困難である。

　本発明は、上述した事情を考慮してなされたものであり、その目的とするところは、「医療・介護サービスの対象者（つまり患者又は要介護者）毎に生成されたグループに、前記医療・介護サービスの１又は複数のユーザー（患者又は要介護者だけでなく医療従事者又は介護従事者を含む）を選択的にグループ・メンバーとして所属させると共に、前記グループに係る前記対象者の医療・介護情報を前記グループ・メンバーに限定して閲覧可能とすることで、前記対象者のプライバシーを確保しながら前記対象者に係る医療・介護情報を前記グループ・メンバー間で共有できる」という特徴を持つ医療・介護支援システムに、必要に応じてアプリケーション・プログラムを組み込むことで、同システムが提供している医療・介護サービスに容易に種々の新サービスを付加することが可能である、医療・介護支援システムにおけるサービス構築支援方法及びシステムを提供することにある。

　本発明の他の目的は、前記医療・介護支援システム上で動作し且つ同システムの特徴を活かすことが可能なアプリケーション・プログラムを効率的に開発することができ、しかも、前記医療・介護支援システムに組み込まれた後に前記アプリケーション・プログラムが提供する新サービスの内容を、医療・介護サービスの対象者である患者又は要介護者、あるいは医療・介護サービスを提供する医療従事者又は介護従事者の必要に応じて、細かく調整することが可能である、医療・介護支援システムにおけるサービス構築支援方法及びシステムを提供することにある。

　本発明のさらに他の目的は、前記医療・介護サービスの対象者（患者又は要介護者）毎に生成されたグループのグループ・メンバーが、１又は複数のアプリケーション・プログラムにより提供される１又は複数の新サービスの利用の開始及び停止を、必要に応じてダイナミックに調整することができる、医療・介護支援システムにおけるサービス構築支援方法及びシステムを提供することにある。

　本発明のさらに他の目的は、前記医療・介護サービスの対象者（患者又は要介護者）毎に生成されたグループのグループ・メンバーが、１又は複数のアプリケーション・プログラムにより提供される複数の新サービスを必要に応じて選択的に利用する際に、前記医療・介護支援システムへのログイン及びログアウトの操作を繰り返す必要がない、医療・介護支援システムにおけるサービス構築支援方法及びシステムを提供することにある。

　本発明のさらに他の目的は、１又は複数のアプリケーション・プログラムにより提供される１又は複数の新サービスが既存の医療・介護サービスに付加されることで、相乗効果が引き起こされ、結果として、１又は複数の新サービスと既存の医療・介護サービスが別個に提供される場合よりも高い効果が期待できる、医療・介護支援システムにおけるサービス構築支援方法及びシステムを提供することにある。

　ここに明記しない本発明のさらに他の目的は、以下の説明及び添付図面から明らかである。

　（１）　本発明の第１の観点によれば、医療・介護支援システムにおけるサービス構築支援方法が提供される。この方法は、
　ユーザー端末からの要求に応じて、通信ネットワークを介して患者又は要介護者に係る医療・介護情報を前記ユーザー端末で閲覧可能にすることで、前記患者又は前記要介護者への医療・介護サービスの提供を支援する医療・介護支援システムにおいて、新サービスを構築するのを支援する方法であって、
　前記ユーザー端末を介して前記医療・介護サービスを利用するユーザーに対して、ユーザー識別情報（例えばユーザーＩＤ）を割り当てて記憶し、
　前記ユーザーとしての前記患者又は前記要介護者に対してサービス受給者識別情報（例えば患者ＩＤ）を割り当てると共に、当該サービス受給者識別情報を前記ユーザー識別情報に関連づけて記憶し、
　前記ユーザーとしての医療従事者又は介護従事者に対して事業従事者識別情報（例えば医療従事者ＩＤ）を割り当てると共に、当該事業従事者識別情報を前記ユーザー識別情報に関連づけて記憶し、
　前記ユーザー端末からの指示に応じて、前記サービス受給者識別情報に関連させて固有のグループ識別情報（例えばグループＩＤ）を持つグループを生成し、
　前記ユーザー端末からの指示に応じて、前記グループに１又は複数の前記ユーザーを選択的にグループ・メンバーとして所属させることで、前記グループに係る前記サービス受給者識別情報に対応する前記患者又は前記要介護者の医療・介護情報を、前記ユーザー端末を介して前記グループ・メンバーの間で共有可能とし、
　１又は複数の特定機能を提供するアプリケーション・フレームワークを前記医療・介護支援システム上に設けて、新サービスを提供するアプリケーション・プログラムを開発者端末から前記アプリケーション・フレームワークを利用して開発できるようにし、
　前記アプリケーション・フレームワークを利用して開発され且つ前記１又は複数の特定機能が搭載されたアプリケーション・プログラムを、前記医療・介護支援システムに組み込む際には、当該アプリケーション・プログラムに対して固有のアプリケーション識別情報（例えばアプリケーションＩＤ）を割り当てると共に、当該アプリケーション識別情報を１又は複数の前記グループ識別情報に関連づけて記憶し、それによって当該アプリケーション・プログラムにより提供される１又は複数の新サービスを、当該アプリケーション識別情報が関連づけられた前記１又は複数のグループ識別情報を持つ前記１又は複数のグループに所属する前記グループ・メンバーに限定して、前記ユーザー端末を介して利用可能とし、
　前記アプリケーション・プログラムは、当該アプリケーション・プログラムに搭載された前記１又は複数の特定機能が、所定の管理者が所定の管理者設定を実行することで前記医療・介護支援システム上で利用可能となるように構成されると共に、前記管理者設定では、当該アプリケーション・プログラムが持つ前記アプリケーション識別情報が関連づけられた前記１又は複数のグループに係る前記患者又は前記要介護者、あるいは、当該グループに係る前記医療従事者又は前記介護従事者の必要に応じて、前記１又は複数の特定機能が設定されるように構成され、
　前記グループの各々に所属する前記グループ・メンバーは、当該グループが持つ前記グループ識別情報に関連づけられた複数の前記アプリケーション識別情報を持つ複数のアプリケーション・プログラムが提供する複数の新サービスを、必要に応じて前記ユーザー端末上で指示することにより選択的に利用可能であることを特徴とするものである。

　本発明の第１の観点による医療・介護支援システムにおけるサービス構築支援方法では、前記医療・介護支援システム上に前記１又は複数の特定機能を提供する前記アプリケーション・フレームワークを設けて、前記１又は複数の新サービスを提供する前記１又は複数のアプリケーション・プログラムを前記アプリケーション・フレームワークを利用して開発できるようにしている。また、前記アプリケーション・フレームワークを利用して開発され且つ前記１又は複数の特定機能が搭載されたアプリケーション・プログラムを、前記医療・介護支援システムに組み込む際には、当該アプリケーション・プログラムに対して前記アプリケーション識別情報を割り当てると共に、当該アプリケーション識別情報を１又は複数の前記グループ識別情報に関連づけて記憶し、それによって当該アプリケーション・プログラムにより提供される１又は複数の新サービスを、当該アプリケーション識別情報が関連づけられた前記１又は複数のグループ識別情報を持つ前記１又は複数のグループに所属する前記グループ・メンバーに限定して、前記ユーザー端末を介して利用可能としている。よって、前記１又は複数のアプリケーションを前記医療・介護支援システムに組み込むことで、同システムが提供している医療・介護サービスに容易に種々の新サービスを付加することができる。

　また、前記アプリケーション・フレームワークを利用して開発され且つ前記１又は複数の特定機能が搭載されたアプリケーション・プログラムを、前記医療・介護支援システムに組み込む際には、当該アプリケーション・プログラムに対して前記アプリケーション識別情報を割り当てると共に、当該アプリケーション識別情報を１又は複数の前記グループ識別情報に関連づけて記憶し、それによって当該アプリケーション・プログラムにより提供される１又は複数の新サービスを、当該アプリケーション識別情報が関連づけられた前記１又は複数のグループ識別情報を持つ前記１又は複数のグループに所属する前記グループ・メンバーに限定して、前記ユーザー端末を介して利用可能としている。このため、「医療・介護サービスの対象者（患者又は要介護者）毎に生成されたグループに、前記医療・介護サービスの１又は複数のユーザー（患者又は要介護者だけでなく医療従事者又は介護従事者を含む）を選択的にグループ・メンバーとして所属させると共に、前記グループに係る前記対象者の医療・介護情報を前記グループ・メンバーに限定して閲覧可能とすることで、前記対象者のプライバシーを確保しながら前記対象者に係る医療・介護情報を前記グループ・メンバー間で共有できる」という前記医療・介護支援システムの特徴を活かすことが可能である。

　さらに、前記医療・介護支援システム上に前記アプリケーション・フレームワークを設けて、前記１又は複数のアプリケーションを前記アプリケ-ション・フレームワークを利用して開発できるようにしているため、前記医療・介護支援システム上で動作し且つ同システムの上記特徴を活かすことが可能なアプリケーション・プログラムを効率的に開発することができる。しかも、前記アプリケーション・プログラムは、当該アプリケーション・プログラムに搭載された前記１又は複数の特定機能が、前記管理者が前記管理者設定を実行することで前記医療・介護支援システム上で利用可能となるように構成されると共に、前記管理者設定では、当該アプリケーション・プログラムが持つ前記アプリケーション識別情報が関連づけられた１又は複数の前記グループに係る前記患者又は前記要介護者、あるいは、当該グループに係る前記医療従事者又は前記介護従事者の必要に応じて、前記１又は複数の特定機能の細部（実施条件）が設定されるように構成されているため、前記医療・介護支援システムに組み込まれた後に前記アプリケーション・プログラムが提供する新サービスの内容を、前記医療・介護サービスの対象者である前記患者又は前記要介護者、あるいは前記医療・介護サービスを提供する前記医療従事者又は前記介護従事者の必要に応じて、細かく調整することが可能である。

　さらに、前記アプリケーション・プログラムを前記医療・介護支援システムに組み込む際には、当該アプリケーション・プログラムに対して前記アプリケーション識別情報を割り当てると共に、当該アプリケーション識別情報を１又は複数の前記グループ識別情報に関連づけて記憶し、それによって当該アプリケーション・プログラムにより提供される１又は複数の新サービスを、当該アプリケーション識別情報が関連づけられた前記１又は複数のグループ識別情報を持つ前記１又は複数のグループに所属する前記グループ・メンバーに限定して、前記ユーザー端末を介して利用可能としている。このため、前記医療・介護サービスの対象者（前記患者又は前記要介護者）毎に生成された前記グループの前記グループ・メンバーが、前記１又は複数のアプリケーション・プログラムにより提供される１又は複数の新サービスの利用の開始及び停止を、必要に応じてダイナミックに調整することができる。

　さらに、前記グループの各々に所属する前記グループ・メンバーは、当該グループが持つ前記グループ識別情報に関連づけられた複数の前記アプリケーション識別情報を持つ複数のアプリケーション・プログラムが提供する複数の新サービスを、必要に応じて前記ユーザー端末上で指示することにより選択的に利用可能であるため、前記医療・介護サービスの前記対象者（前記患者又は前記要介護者）毎に生成された前記グループの前記グループ・メンバーが、前記１又は複数のアプリケーション・プログラムにより提供される前記複数の新サービスを必要に応じて選択的に利用する際に、前記医療・介護支援システムへのログイン及びログアウトの操作を繰り返す必要がない。

　さらに、前記アプリケーション・プログラムにより提供される前記１又は複数の新サービスを利用することで、当該アプリケーション・プログラムが持つ前記アプリケーション識別情報が関連づけられた前記１又は複数のグループに係る前記グループ・メンバーに提供される情報（アプリケーション関連情報）を、当該１又は複数のグループに係る前記患者又は前記要介護者の前記医療・介護情報と共に閲覧可能であるため、前記アプリケーション関連情報と前記医療・介護情報とが別個に存在していたときには気づかなかったことに気づくことが多くなる。つまり、前記１又は複数のアプリケーション・プログラムにより提供される前記１又は複数の新サービスが既存の医療・介護サービスに加わることで、相乗効果が引き起こされることが多くなる。その結果、前記１又は複数の新サービスと既存の医療・介護サービスが別個に提供される場合よりも高い効果が期待できる。

　（２）　本発明の第１の観点による医療・介護支援システムにおけるサービス構築支援方法の好ましい例では、前記アプリケーション・プログラムは、前記管理者設定に加えて、必要なユーザー設定を実行することで前記医療・介護支援システム上で利用可能となるように構成され、
　前記ユーザー設定は、当該アプリケーション・プログラムが持つ前記アプリケ-ション識別情報が関連づけられた前記１又は複数のグループに係る前記ユーザーのいずれかが実行するように構成される。

　（３）　本発明の第１の観点による医療・介護支援システムにおけるサービス構築支援方法の他の好ましい例では、前記アプリケーション・プログラムは、当該アプリケーション・プログラムの目的を達成するために必要な、前記アプリケーション・フレームワークが提供する前記１又は複数の特定機能の組み合わせを記述したものとされる。

　（４）　本発明の第１の観点による医療・介護支援システムにおけるサービス構築支援方法のさらに他の好ましい例では、前記グループの各々に関連づけられた前記１または複数のアプリケーション・プログラムは、当該アプリケーション・プログラムが提供する前記新サービスのために必要なサービス要素情報を、前記ユーザー端末上において、所定のスケジュールに沿って、当該グループに係る前記患者または前記要介護者の前記医療・介護情報が閲覧可能なタイムラインに順に表示し、
　前記サービス要素情報に応答する必要がある場合には、応答情報を前記ユーザー端末から前記タイムラインに表示するか、前記医療・介護システムに送信することで応答するように構成される。

　前記「サービス要素情報」としては、前記グループの前記グループ・メンバーに対する１又は複数の質問情報又は提示情報を含んでもよい。ここで、「質問情報」とは、何らかの質問を含む情報であり、「提示情報」とは、何らかのメッセージを提示する情報だけを含む（質問を含まない）情報である。前記「応答情報」とは、前記サービス要素情報（例えば前記質問情報）に対する応答として生成される情報である。

　（５）　本発明の第１の観点による医療・介護支援システムにおけるサービス構築支援方法のさらに他の好ましい例では、前記アプリケーション・フレームワークが、前記１又は複数の特定機能を実現する手段として、所定の都度情報を記憶する機能を提供する第１モジュールと、所定の外部情報を収集して記憶する機能を提供する第２モジュールと、質疑応答の機能を提供する第３モジュールと、コンテンツ情報を記憶する機能を提供する第４モジュール（ノート・モジュール、レコード・モジュール、ヒアリング・モジュール、ブック・モジュール）とを備える。

　（６）　本発明の第１の観点による医療・介護支援システムにおけるサービス構築支援方法のさらに他の好ましい例では、前記アプリケーション・フレームワークが目的の異なる複数のユニットを含んでおり、前記１又は複数の特定機能が前記複数のユニットの各々に設けられる。

　（７）　本発明の第２の観点によれば、医療・介護支援システムにおけるサービス構築支援システムが提供される。このシステムは、
　ユーザー端末からの要求に応じて、通信ネットワークを介して患者又は要介護者に係る医療・介護情報を前記ユーザー端末で閲覧可能にすることで、前記患者又は前記要介護者への医療・介護サービスの提供を支援する医療・介護支援システムにおいて、新サービスを構築するのを支援するシステムであって、
　前記ユーザー端末を介して前記医療・介護サービスを利用するユーザーに対して、ユーザー識別情報（例えばユーザーＩＤ）を割り当てて記憶するユーザー識別情報記憶手段（例えばユーザー情報記憶部）と、
　前記ユーザーとしての前記患者又は前記要介護者に対してサービス受給者識別情報（例えば患者ＩＤ）を割り当てると共に、当該サービス受給者識別情報を前記ユーザー識別情報に関連づけて記憶するサービス受給者識別情報記憶手段（例えば患者情報記憶部）と、
　前記ユーザーとしての医療従事者又は介護従事者に対して事業従事者識別情報（例えば医療従事者ＩＤ）を割り当てると共に、当該事業従事者識別情報を前記ユーザー識別情報に関連づけて記憶する事業従事者識別情報記憶手段（例えば医療従事者情報記憶部）と、
　前記ユーザー端末からの指示に応じて、前記サービス受給者識別情報に関連させて固有のグループ識別情報（例えばグループＩＤ）を持つグループを生成するグループ管理手段（例えばグループ管理部）と、
　前記ユーザー端末からの指示に応じて、前記グループに１又は複数の前記ユーザーを選択的にグループ・メンバーとして所属させることで、前記グループに係る前記サービス受給者識別情報に対応する前記患者又は前記要介護者の医療・介護情報を、前記ユーザー端末を介して前記グループ・メンバーの間で共有可能とするグループ・メンバー選定手段（例えばグループ管理部）と、
　１又は複数の特定機能を提供するアプリケーション・フレームワークを前記医療・介護支援システム上に設けて、新サービスを提供するアプリケーション・プログラムを開発者端末から前記アプリケーション・フレームワークを利用して開発できるようにするフレームワーク管理手段（例えばフレームワーク管理部）と、
　前記アプリケーション・フレームワークを利用して開発され且つ前記１又は複数の特定機能が搭載されたアプリケーション・プログラムを、前記医療・介護支援システムに組み込む際には、当該アプリケーション・プログラムに対して固有のアプリケーション識別情報（例えばアプリケーションＩＤ）を割り当てると共に、当該アプリケーション識別情報を１又は複数の前記グループ識別情報に関連づけて記憶し、それによって当該アプリケーション・プログラムにより提供される１又は複数の新サービスを、当該アプリケーション識別情報が関連づけられた前記１又は複数のグループ識別情報を持つ前記１又は複数のグループに所属する前記グループ・メンバーに限定して、前記ユーザー端末を介して利用可能とするアプリケーション管理手段（例えばアプリケーション管理部）とを備え、
　前記アプリケーション・プログラムは、当該アプリケーション・プログラムに搭載された前記１又は複数の特定機能が、所定の管理者が所定の管理者設定を実行することで前記医療・介護支援システム上で利用可能となるように構成されると共に、前記管理者設定では、当該アプリケーション・プログラムが持つ前記アプリケ-ション識別情報が関連づけられた前記１又は複数のグループに係る前記患者又は前記要介護者、あるいは、当該グループに係る前記医療従事者又は前記介護従事者の必要に応じて、前記１又は複数の特定機能が設定されるように構成され、
　前記グループの各々に所属する前記グループ・メンバーは、当該グループが持つ前記グループ識別情報に関連づけられた複数の前記アプリケーション識別情報を持つ複数のアプリケーション・プログラムが提供する複数の新サービスを、必要に応じて前記ユーザー端末上で指示することにより選択的に利用可能であることを特徴とするものである。

　本発明の第２の観点による医療・介護支援システムにおけるサービス構築支援システムでは、前記フレームワーク管理手段により、前記医療・介護支援システム上に前記１又は複数の特定機能を提供する前記アプリケーション・フレームワークを設けて、前記１又は複数の新サービスを提供する前記１又は複数のアプリケーション・プログラムを前記アプリケーション・フレームワークを利用して開発できるようにしている。また、前記アプリケーション・フレームワークを利用して開発され且つ前記１又は複数の特定機能が搭載されたアプリケーション・プログラムを、前記医療・介護支援システムに組み込む際には、当該アプリケーション・プログラムに対して前記アプリケーション識別情報を割り当てると共に、当該アプリケーション識別情報を１又は複数の前記グループ識別情報に関連づけて記憶し、それによって当該アプリケーション・プログラムにより提供される１又は複数の新サービスを、当該アプリケーション識別情報が関連づけられた前記１又は複数のグループ識別情報を持つ前記１又は複数のグループに所属する前記グループ・メンバーに限定して、前記ユーザー端末を介して利用可能としている。よって、前記１又は複数のアプリケーションを前記医療・介護支援システムに組み込むことで、同システムが提供している医療・介護サービスに容易に種々の新サービスを付加することができる。

　また、前記アプリケーション・フレームワークを利用して開発され且つ前記１又は複数の特定機能が搭載されたアプリケーション・プログラムを、前記医療・介護支援システムに組み込む際には、前記アプリケーション管理手段により、当該アプリケーション・プログラムに対して前記アプリケーション識別情報を割り当てると共に、当該アプリケーション識別情報を１又は複数の前記グループ識別情報に関連づけて記憶し、それによって当該アプリケーション・プログラムにより提供される１又は複数の新サービスを、当該アプリケーション識別情報が関連づけられた前記１又は複数のグループ識別情報を持つ前記１又は複数のグループに所属する前記グループ・メンバーに限定して、前記ユーザー端末を介して利用可能としている。このため、「医療・介護サービスの対象者（患者又は要介護者）毎に生成されたグループに、前記医療・介護サービスの１又は複数のユーザー（患者又は要介護者だけでなく医療従事者又は介護従事者を含む）を選択的にグループ・メンバーとして所属させると共に、前記グループに係る前記対象者の医療・介護情報を前記グループ・メンバーに限定して閲覧可能とすることで、前記対象者のプライバシーを確保しながら前記対象者に係る医療・介護情報を前記グループ・メンバー間で共有できる」という前記医療・介護支援システムの特徴を活かすことが可能である。

　さらに、前記医療・介護支援システム上に前記アプリケ-ション・フレームワークを設けて、前記１又は複数のアプリケーションを前記アプリケーション・フレームワークを利用して開発できるようにしているため、前記医療・介護支援システム上で動作し且つ同システムの上記特徴を活かすことが可能なアプリケーション・プログラムを効率的に開発することができる。しかも、前記アプリケーション・プログラムは、当該アプリケーション・プログラムに搭載された前記１又は複数の特定機能が、前記管理者が前記管理者設定を実行することで前記医療・介護支援システム上で利用可能となるように構成されると共に、前記管理者設定では、当該アプリケーション・プログラムが持つ前記アプリケ-ション識別情報が関連づけられた１又は複数の前記グループに係る前記患者又は前記要介護者、あるいは、当該グループに係る前記医療従事者又は前記介護従事者の必要に応じて、前記１又は複数の特定機能の細部（実施条件）が設定されるように構成されているため、前記医療・介護支援システムに組み込まれた後に前記アプリケーション・プログラムが提供する新サービスの内容を、前記医療・介護サービスの対象者である前記患者又は前記要介護者、あるいは前記医療・介護サービスを提供する前記医療従事者又は前記介護従事者の必要に応じて、細かく調整することが可能である。

　さらに、前記アプリケーション・プログラムを前記医療・介護支援システムに組み込む際には、前記アプリケーション管理手段により、当該アプリケーション・プログラムに対して前記アプリケーション識別情報を割り当てると共に、当該アプリケーション識別情報を１又は複数の前記グループ識別情報に関連づけて記憶し、それによって当該アプリケーション・プログラムにより提供される１又は複数の新サービスを、当該アプリケーション識別情報が関連づけられた前記１又は複数のグループ識別情報を持つ前記１又は複数のグループに所属する前記グループ・メンバーに限定して、前記ユーザー端末を介して利用可能としている。このため、前記医療・介護サービスの対象者（前記患者又は前記要介護者）毎に生成された前記グループの前記グループ・メンバーが、前記１又は複数のアプリケーション・プログラムにより提供される１又は複数の新サービスの利用の開始及び停止を、必要に応じてダイナミックに調整することができる。

　さらに、前記グループの各々に所属する前記グループ・メンバーは、当該グループが持つ前記グループ識別情報に関連づけられた複数の前記アプリケーション識別情報を持つ複数のアプリケーション・プログラムが提供する複数の新サービスを、必要に応じて前記ユーザー端末上で指示することにより選択的に利用可能であるため、前記医療・介護サービスの前記対象者（前記患者又は前記要介護者）毎に生成された前記グループの前記グループ・メンバーが、前記１又は複数のアプリケーション・プログラムにより提供される前記複数の新サービスを必要に応じて選択的に利用する際に、前記医療・介護支援システムへのログイン及びログアウトの操作を繰り返す必要がない。

　さらに、前記アプリケーション・プログラムにより提供される前記１又は複数の新サービスを利用することで、当該アプリケーション・プログラムが持つ前記アプリケーション識別情報が関連づけられた前記１又は複数のグループに係る前記グループ・メンバーに提供される情報（アプリケーション関連情報）を、当該１又は複数のグループに係る前記患者又は前記要介護者の前記医療・介護情報と共に閲覧可能であるため、前記アプリケーション関連情報と前記医療・介護情報とが別個に存在していたときには気づかなかったことに気づくことが多くなる。つまり、前記１又は複数のアプリケーション・プログラムにより提供される前記１又は複数の新サービスが既存の医療・介護サービスに加わることで、相乗効果が引き起こされることが多くなる。その結果、前記１又は複数の新サービスと既存の医療・介護サービスが別個に提供される場合よりも高い効果が期待できる。

　（８）　本発明の第２の観点による医療・介護支援システムにおけるサービス構築支援システムの好ましい例では、前記アプリケーション・プログラムは、前記管理者設定に加えて、必要なユーザー設定を実行することで前記医療・介護支援システム上で利用可能となるように構成され、
　前記ユーザー設定は、当該アプリケーション・プログラムが持つ前記アプリケーション識別情報が関連づけられた前記１又は複数のグループに係る前記ユーザーのいずれかが実行するように構成される。

　（９）　本発明の第２の観点による医療・介護支援システムにおけるサービス構築支援システムの他の好ましい例では、前記アプリケーション・プログラムは、当該アプリケーション・プログラムの目的を達成するために必要な、前記アプリケーション・フレームワークが提供する前記１又は複数の特定機能の組み合わせを記述したものとされる。

　（１０）　本発明の第１の観点による医療・介護支援システムにおけるサービス構築支援システムのさらに他の好ましい例では、前記グループの各々に関連づけられた前記１または複数のアプリケーション・プログラムは、当該アプリケーション・プログラムが提供する前記新サービスのために必要なサービス要素情報を、前記ユーザー端末上において、所定のスケジュールに沿って、当該グループに係る前記患者または前記要介護者の前記医療・介護情報が閲覧可能なタイムラインに順に表示し、
　前記サービス要素情報に応答する必要がある場合には、応答情報を前記ユーザー端末から前記タイムラインに表示するか、前記医療・介護システムに送信することで応答するように構成される。

　前記「サービス要素情報」としては、前記グループの前記グループ・メンバーに対する１又は複数の質問情報又は提示情報を含んでもよい。ここで、「質問情報」とは、何らかの質問を含む情報であり、「提示情報」とは、何らかのメッセージを提示する情報だけを含む（質問を含まない）情報である。前記「応答情報」とは、前記サービス要素情報（例えば前記質問情報）に対する応答として生成される情報である。

　（１１）　本発明の第１の観点による医療・介護支援システムにおけるサービス構築支援システムのさらに他の好ましい例では、前記アプリケーション・フレームワークが、前記１又は複数の特定機能を実現する手段として、所定の都度情報を記憶する機能を提供する第１モジュールと、所定の外部情報を収集して記憶する機能を提供する第２モジュールと、質疑応答の機能を提供する第３モジュールと、コンテンツ情報を記憶する機能を提供する第４モジュール（ノート・モジュール、レコード・モジュール、ヒアリング・モジュール、ブック・モジュール）とを備える。

　（１２）　本発明の第１の観点による医療・介護支援システムにおけるサービス構築支援システムのさらに他の好ましい例では、前記アプリケーション・フレームワークが目的の異なる複数のユニットを含んでおり、前記１又は複数の特定機能が、前記複数のユニットの各々に設けられる。

　（１３）　なお、本発明において、前記「サービス要素情報」とは、前記アプリケーションによって提供される前記新サービスを構成するために必要な要素情報を意味し、例えば、前記新サービスを提供（実現）するために前記タイムラインに表示される質問情報と提示情報である。例えば、後述する図３７～図４１に記載されている各種投稿メッセージがこれに該当する。

　前記「応答情報」とは、前記アプリケーションによって提供される前記新サービスを構成するために「サービス要素情報」に対する応答として表示又は送信される情報を意味し、例えば、前記新サービスを提供（実現）するために前記タイムラインに応答として表示される情報や、前記医療・介護支援システムに応答として送信される情報である。例えば、後述する図４２～図４５に記載されている各種回答メッセージや、図４６～図４７に記載されている各種回答メッセージが該当する。

　前記「アプリケーション・フレームワーク」とは、各々が１又は複数の特定機能を提供する機能ブロック群を少なくとも含んでいると共に、前記機能ブロック群の少なくとも１つを利用することで前記医療・介護支援システム上で動作する所望のアプリケーション・プログラムを開発できるように構成されたソフトウェアを意味する。

　前記「アプリケーション・プログラム（アプリケーション）」とは、前記アプリケーション・フレームワークによって提供される前記機能ブロック群の少なくとも１つが搭載されていると共に、前記医療・介護支援システム上で動作することで同システムが提供する前記医療・介護サービスに対して何らかの新サービスを追加提供するプログラムを意味する。

　前記「新サービス」とは、前記アプリケーション・プログラムが提供するサービスで、前記医療・介護支援システムが提供する前記医療・介護サービスに対して追加されるサービスを意味する。例えば、医療関係では、（ａ）服薬管理、生活習慣改善、糖尿病服薬支援、チーム医療支援、褥瘡ケア、リハビリ支援等、種々のケア（治療）に関連する医療サービスや、（ｂ）多職種従事者間の連携窓口として機能する各種コーディネーション、相談受付、アドバイス、情報提供等、コミュニティ作成・運用に関連する医療サービスがある。介護関係では、（ｃ）訪問介護、訪問看護、在宅リハビリ支援、在宅入浴支援、認知症対応支援等、種々の介護に関連する介護サービス等がある。

　前記「アプリケーション関連情報」とは、前記アプリケーション・プログラムが提供する新サービスを利用することによって、当該アプリケーション・プログラムが持つ前記アプリケーション識別情報が関連づけられた前記１又は複数のグループに係る前記グループ・メンバーに提供される情報を意味する。

　本発明の第１の観点による医療・介護支援システムにおけるサービス構築支援方法と第２の観点による医療・介護支援システムにおけるサービス構築支援システムによれば、以下の（ａ）～（ｅ）の効果が得られる。

　（ａ）　「医療・介護サービスの対象者（つまり患者又は要介護者）毎に生成されたグループに、前記医療・介護サービスの１又は複数のユーザー（患者又は要介護者だけでなく医療従事者又は介護従事者を含む）を選択的にグループ・メンバーとして所属させると共に、前記グループに係る前記対象者の医療・介護情報を前記グループ・メンバーに限定して閲覧可能とすることで、前記対象者のプライバシーを確保しながら前記対象者に係る医療・介護情報を前記グループ・メンバー間で共有できる」という特徴を持つ医療・介護支援システムに、必要に応じてアプリケーション・プログラムを組み込むことで、同システムが提供している医療・介護サービスに容易に種々の新サービスを付加することが可能である。

　（ｂ）　前記医療・介護支援システム上で動作し且つ同システムの特徴を活かすことが可能なアプリケーション・プログラムを効率的に開発することができ、しかも、前記医療・介護支援システムに組み込まれた後に前記アプリケーション・プログラムが提供する新サービスの内容を、医療・介護サービスの対象者である患者又は要介護者、あるいは医療・介護サービスを提供する医療従事者又は介護従事者の必要に応じて、細かく調整することが可能である。

　（ｃ）　医療・介護サービスの対象者（患者又は要介護者）毎に生成されたグループのグループ・メンバーが、１又は複数のアプリケーション・プログラムにより提供される１又は複数の新サービスの利用の開始及び停止を、必要に応じてダイナミックに調整することができる。

　（ｄ）　医療・介護サービスの対象者（患者又は要介護者）毎に生成されたグループのグループ・メンバーが、１又は複数のアプリケーション・プログラムにより提供される複数の新サービスを必要に応じて選択的に利用する際に、前記医療・介護支援システムへのログイン及びログアウトの操作を繰り返す必要がない。

　（ｅ）　１又は複数のアプリケーション・プログラムにより提供される１又は複数の新サービスが既存の医療・介護サービスに付加されることで、相乗効果が引き起こされ、結果として、１又は複数の新サービスと既存の医療・介護サービスが別個に提供される場合よりも高い効果が期待できる。

本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムの利用状態を示す概念図である。 図１に示した医療支援システムに参加している患者、患者関係者、医療従事者及び医療関連施設の相互関係を示す説明図である。 図１に示した医療支援システムの内部構成を示す機能ブロック図である。 図１に示した医療支援システムに使用されているテーブルの構成例を示す図で、（ａ）はユーザーテーブル、（ｂ）は患者テーブル、（ｃ）は医療従事者テーブル、（ｄ）は医療関連施設テーブルである。 図１に示した医療支援システムに使用されているテーブルの構成例を示す図で、（ａ）は医療関連施設患者テーブル、（ｂ）は疾患テーブル、（ｃ）はグループテーブル、（ｄ）はグループ参加テーブルである。 図１に示した医療支援システムに使用されているテーブルの構成例を示す図で、（ａ）は招待リクエストテーブル、（ｂ）はタイムラインテーブル、（ｃ）は医療情報共有ルールテーブル、（ｄ）はＮＦＣ端末管理ルールテーブルである。 図１に示した医療支援システムに使用されているテーブルの構成例を示す図で、（ａ）はメッセージ送信予約テーブル、（ｂ）は患者属性テーブルである。 図１に示した医療支援システムに使用されている全テーブル間の関係を示す説明図である。 図１に示した医療支援システムによって形成されるタイムラインの、患者別疾患毎に生成される表示領域と、その表示領域にアクセスできる人の関係を示す説明図ある。 図１に示した医療支援システムよりなるプラットフォームと、本発明の一実施形態に係るサービス構築支援システムで生成されるアプリケーション・フレームワークと、アプリケーションとの関係を示す概念図である。 図１に示した医療支援システムと、本発明の一実施形態に係るサービス構築支援システムで生成されるアプリケーション・フレームワークと、開発者端末との関係を示す概念図である。 図１に示した医療支援システムと、本発明の一実施形態に係るサービス構築支援システムで生成されるアプリケーション・フレームワークと、開発者端末との関係を示す概念図である。 図１に示した医療支援システムと、本発明の一実施形態に係るサービス構築支援システムで生成されるアプリケーション・フレームワークと、アプリケーションとの関係を示す概念図である。 図１に示した医療支援システムと本発明の一実施形態に係るサービス構築支援システムの内部構造の概略を示す機能ブロック図である。 本発明の一実施形態に係るサービス構築支援システムの内部構造の詳細を示す機能ブロック図である。 （ａ）は図１に示した医療支援システムに使用されているユーザーテーブルの構成例を示す図、（ｂ）は本発明の一実施形態に係るサービス構築支援システムで使用される開発者テーブルの構成例を示す図、（ｃ）はそのサービス構築支援システムで使用される開発者所属組織テーブルの構成例を示す図、（ｄ）はそのサービス構築支援システムで使用されるアプリケーションテーブルの構成例を示す図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、特定患者の「ホーム画面」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、特定患者の「グループのタイムラインの表示画面（医療従事者側）」の例を示す説明図である。 図１８の画面でオプション起動ボタンをクリックした場合に表示される、特定患者の「医療従事者側のオプション選択画面」の例を示す説明図で、アプリケーション選択タブが選択された状態を示している。 図１８の画面でオプション起動ボタンをクリックした場合に医療従事者側のタイムラインに表示される、特定患者の「医療従事者側のオプション選択画面」の例を示す説明図で、リクエスト選択タブが選択された状態を示している。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、特定患者の「グループのタイムライン（患者側）の表示画面」の例を示す説明図である。 図２１の画面でアプリケーション起動ボタンをクリックした場合に表示される、特定患者の「患者側のアプリケーション選択画面」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、「システム管理者用のアプリケーション管理画面（基本情報設定）」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、「システム管理者用のアプリケーション管理画面（医薬品設定）」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、「システム管理者用のアプリケーション管理画面（追加機能設定）」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、「システム管理者用のアプリケーション管理画面（追加機能・質問設定）」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、「システム管理者用のアプリケーション管理画面（追加機能・質問設定）」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、「システム管理者用のアプリケーション管理画面（追加機能・質問設定）」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、「システム管理者用のアプリケーション管理画面（追加機能・患者ノート設定）」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、「システム管理者用のアプリケーション管理画面（追加機能・糖尿病アドバイス設定）」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、「システム管理者用のアプリケーション管理画面（追加機能・検査記録事項設定）」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、「システム管理者用のアプリケーション管理画面（投稿事項・時期等設定）」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、「システム管理者用のアプリケーション管理画面（投稿事項・時期等設定）」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、「システム管理者用のアプリケーション管理画面（検査値設定）」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、「システム管理者用のアプリケーション管理画面（開始日設定）」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、「システム管理者用のアプリケーション管理画面（アプリケーション選択）」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、特定患者の「グループのタイムライン（患者側）の表示画面」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、特定患者の「グループのタイムライン（患者側）の表示画面」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、特定患者の「グループのタイムライン（患者側）の表示画面」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、特定患者の「グループのタイムライン（患者側）の表示画面」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、特定患者の「グループのタイムライン（患者側）の表示画面」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、特定患者の「グループのタイムライン（患者側）に表示される回答画面」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、特定患者の「グループのタイムライン（患者側）に表示される回答画面」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、特定患者の「グループのタイムライン（患者側）に表示される回答の選択肢画面」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、特定患者の「グループのタイムライン（患者側）の表示される回答画面」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、特定患者の「グループのタイムライン（医療従事者側）の表示画面」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムが組み込まれた医療支援システムにアプリケーションをインストールした場合の、特定患者の「グループのタイムライン（医療従事者側）の表示画面」の例を示す説明図である。 本発明の一実施形態に係るサービス構築支援システムのアプリケーション開発時の動作を示すフローチャートである。 本発明の一実施形態に係るサービス構築支援システムのアプリケーション利用時の動作を示すフローチャートである。

　以下、添付図面を参照しながら、本発明の好適な実施形態について説明する。

　（医療支援サービスの利用形態）
　本発明の一実施形態に係るサービス構築支援システム１００が組み込まれている医療支援システム３０が提供する医療支援サービスを利用する際の全体構成を、図１に示す。

　以下の説明では、個々の患者を区別する場合は「患者Ｐ１」、「患者Ｐ２」、「患者Ｐ３」と表記し、個々の患者を区別しない場合は「患者Ｐ」と表記する。同様に、個々の医療従事者を区別する場合は「医療従事者Ｍ１」、「医療従事者Ｍ２」などと表記し、区別しない場合は「医療従事者Ｍ」と表記する。個々の患者関係者を区別する場合は「患者関係者Ｒ１」、「患者関係者Ｒ２」などと表記し、区別しない場合は「患者関係者Ｒ」と表記する。個々の医療関連施設を区別しない場合は、「医療関連施設Ｆ」と表記し、区別する場合は、「医療関連施設Ｆ１」、「医療関連施設Ｆ２」などと表記する。個々のグループを区別しない場合は、「グループＧ」と表記し、区別する場合は、「グループＧ１１」、「グループＧ１２」などと表記する。

　図１に示すように、この医療支援サービスは、その利用を希望する患者Ｐ、患者関係者Ｒ又は医療従事者Ｍが、所定の方法でユーザー登録をした後、患者Ｐが所有する患者端末１０や、医療従事者Ｍが操作する医療従事者端末１１、あるいは、患者関係者Ｒが所有する患者関係者端末１２（以下、これらの端末をまとめて「ユーザー端末」ということがある）から、通信ネットワークであるインターネット２０を介して利用するようになっている。

　ユーザー登録をした患者Ｐ、患者関係者Ｒ又は医療従事者Ｍは、この医療支援サービスの「ユーザー」となる。この医療支援サービスは、医療支援システム３０によって実現されているから、この医療支援サービスの「ユーザー」は医療支援システム３０の「ユーザー」と言うこともできる。ユーザー登録をしていない患者Ｐ、患者関係者Ｒ又は医療従事者Ｍは、この医療支援サービスを利用できない。

　いずれかのユーザー端末１０、１１又は１２からインターネット２０を介して医療支援システム３０に指示を送ると、医療支援システム３０内に設置されたハードウェアとソフトウェアの動作により、後述する「ユーザー登録」や「グループの生成」、「グループへの招待」、「メッセージの送受信（コミュニケーション）」、「かかりつけ登録」、「医療情報の閲覧」といった種々の動作や機能が実行される。また、そうすることで、患者一人ひとりの医療情報や交換されたメッセージを、患者Ｐのプライバシーを守りながら、複数の医療従事者Ｍの間で、もしくは患者Ｐと医療従事者Ｍの間で、又は患者Ｐと医療従事者Ｍと患者関係者Ｒの間で共有することが可能となり、その共有された医療情報やメッセージに基づいて個々の患者Ｐに、より良質の医療サービスを提供できるようになる。

　患者端末１０と患者関係者端末１２は、通常、携帯電話やスマートフォンのような携帯端末とされ、個々の患者Ｐや患者関係者Ｒが自分専用の端末を所有するが、デスクトップ型あるいはノート型のパーソナル・コンピューター（パソコン）や、タッチパネル型の端末も使用可能である。医療従事者端末１１は、医療関連施設に設置されることが多いので、通常はデスクトップ型あるいはノート型のパソコンとされるが、タッチパネル型の端末や携帯端末も使用可能であることは言うまでもない。要するに、これらの端末１０、１１及び１２は、インターネット２０を介して医療支援システム３０との間で情報の送信、受信及び表示ができる端末装置であればよく、その形態や構成は問わない。

　個々の患者Ｐは、一つ以上の疾患を患っており、特定の医療関連施設Ｆにおいてそこに所属する医療従事者Ｍから診断・治療等の医療サービスを受けている。説明を簡単にするため、本実施形態では、２人の患者Ｐ１及びＰ２のみがこの医療支援サービスを利用している場合を想定しているが、実際はもっと多くの患者Ｐが利用することは言うまでもない。実際、後述するサービス構築支援システム１００に係る説明では、糖尿病の患者Ｐ３が、特定の医療関連施設Ｆにおいてそこに所属する医療従事者Ｍから診断・治療等の医療サービスを受けている場合について述べている。

　患者関係者Ｒとは、個々の患者Ｐの家族や親戚、友人、知人など、何らかの形で患者Ｐと関係のある人を指す。医療従事者Ｍであっても、ある患者Ｐの家族や親戚、友人あるいは知人等である場合は、その患者Ｐの患者関係者Ｒになり得る。ここでは、８人の患者関係者Ｒ１、Ｒ２、Ｒ３、Ｒ４、Ｒ５、Ｒ６、Ｒ７及びＲ８が参加している場合を想定しているが、患者Ｐの事情に応じて、もっと多くの、あるいはもっと少ない患者関係者Ｒが利用することがあるのは言うまでもない。

　医療従事者Ｍとは、医師、看護士等の医療関連施設Ｆにおいて医療に従事している人を指す。医療従事者Ｍは、専門分野を持つクリニック（小規模の医院）や病院（中規模・大規模の医療施設）、訪問看護ステーション等の各種の医療関連施設Ｆに所属して、その医療関連施設Ｆで患者Ｐに対して診断・治療等の医療サービスを提供する。ここでは、８人の医療従事者Ｍ１、Ｍ２、Ｍ３、Ｍ４、Ｍ５、Ｍ６、Ｍ７及びＭ８のみが参加している場合を想定しているが、実際はもっと多くの、あるいはもっと少ない医療従事者Ｍが参加することは言うまでもない。

　医療関連施設Ｆとは、医療従事者Ｍにより患者Ｐに対して医療サービスが提供される施設、例えば、小規模の医院（クリニック）やそれよりも規模の大きい病院、訪問看護ステーションなどを指す。診断・治療・看護・ケア・検査・手術・相談等、何らかの医療サービスが提供される施設であれば足り、その形態や規模は問わない。

　また、図１では、患者Ｐと医療従事者Ｍと患者関係者Ｒがそれぞれ端末１０、１１及び１２を所有しているとして描いているが、本発明はこれに限定されない。患者Ｐと患者関係者Ｒと医療従事者Ｍは、それぞれ、一意に識別できる識別情報（ユーザーＩＤ）を持ち、同じ端末から医療支援システム３０にログインしても区別されることから、同じ端末を複数の人が共用しても支障は生じない。

　図１には、システム管理者Ａと、システム管理者Ａが操作する管理者端末１４と、サービス構築支援システム１００とが示されている。サービス構築支援システム１００は、その詳細は後述するが、医療支援システム３０上にアプリケーション・フレームワーク２００を生成するために設けられたものであり、医療支援システム３０と連携して動作するようになっている。システム管理者Ａは、医療支援システム３０の動作全般を管理するために選任されており、自己の管理者端末１４を用いてインターネット２０を介して医療支援システム３０にアクセスして必要な処理を行うことができる。システム管理者Ａは、医療支援システム３０だけでなく、サービス構築支援システム１００の管理も行う。なお、本実施形態では、システム管理者Ａは、アプリケーション・フレームワーク２００を利用して開発されたアプリケーション・プログラム２２０に対する「管理者設定」という処理（これについては後述する）も行うように設定されている。

　図２は、医療支援システム３０を利用している、換言すれば、医療支援システム３０のユーザーである患者Ｐ１及びＰ２、患者関係者Ｒ１～Ｒ８、及び医療従事者Ｍ１～Ｍ８の相互関係を示す説明図である。

　医療支援システム３０では、個々の患者Ｐの疾患毎にグループＧが登録される。つまり、個々の患者Ｐが持つ疾患それぞれについて別個のグループＧが形成されるのである。各グループＧに参加している人（参加者）（つまりグループ・メンバー）は、通常、患者Ｐ本人の他に、患者Ｐが治療等を受けている医療関連施設Ｆに所属する担当の医療従事者Ｍを少なくとも一人含み、さらに、必要に応じて追加された患者関係者Ｒを含む。したがって、各グループＧのグループ・メンバーは、患者Ｐ本人と、担当の医療従事者Ｍ及び患者関係者Ｒから構成されるのが一般的である。

　各グループＧに参加している医療従事者Ｍが所属する医療関連施設Ｆのいずれか一つは、そのグループＧ（ひいては患者Ｐ）に対して「かかりつけ登録」されるのが通常である。「かかりつけ登録」された医療関連施設Ｆは、グループＧに係る患者Ｐの疾患の治療方針全般について主たる責任を負う。

　しかし、グループ・メンバーの構成は、そのような場合に限定されない。例えば、患者Ｐと一人又は複数の医療従事者Ｍだけがグループ・メンバーである（患者関係者Ｒを含まない）場合もあるし、複数の医療従事者Ｍだけがグループ・メンバーである（患者Ｐも患者関係者Ｒも含まない）場合もある。前者は、例えば、患者Ｐが患者関係者Ｒに対して自己の医療情報を知らせたくないようなときに生じる。後者は、患者Ｐの治療に関わっている複数の医療従事者Ｍの間で患者Ｐの医療情報を共有したいが、患者Ｐには知らせたくないようなときに生じる。なお、患者Ｐをグループ・メンバーに含まない場合は、医療支援システム３０上で患者Ｐから医療情報の共有に対する承認を得ることができないため、別途、医療支援システム３０外で得るようにする。例えば、書面等で承認を得るようにすればよい。むろん、書面等をデジタル化したものを患者Ｐが承認するプロセスのみを、医療支援システム３０に便宜的に追加してもよい。なお、患者Ｐから医療情報の共有に対する承認を得るためのサブシステムを別個に医療支援システム３０に組み込むようにしてもよいことは言うまでもない。

　各グループＧの患者Ｐ本人を除く参加者（グループ・メンバー）は、医療従事者Ｍであると患者関係者Ｒとを問わず、「サポーター」と呼ばれる。何らかの形で患者Ｐをサポートする人たちだからである。したがって、各グループＧのグループ・メンバーは、患者Ｐを含む場合は、患者Ｐ本人と、少なくとも一人のサポーターから構成されると言うことができる。患者Ｐを含まない場合は、複数のサポーターのみから構成されると言うことができる。

　図２から明らかなように、患者Ｐ１は、三つの疾患（ここでは糖尿病、高脂血症、痛風とする）を患っていて、患者Ｐ１の三つの疾患毎にグループＧ１１、Ｇ１２及びＧ１３が生成されており、各グループＧに対して医療関連施設Ｆが関連づけられている。具体的に言えば、糖尿病治療用のグループＧ１１に対してはクリニックＦ１がかかりつけ登録され、高脂血症治療用のグループＧ１２に対してはクリニックＦ２がかかりつけ登録され、痛風治療用のグループＧ１３に対しては、病院Ｆ３がかかりつけ登録されている。このように、ここでは、患者Ｐ１は、三つのグループＧ１１、Ｇ１２及びＧ１３に所属している。後述するように、グループＧ１１、Ｇ１２及びＧ１３には、かかりつけ登録されたクリニックＦ１、クリニックＦ２及び病院Ｆ３にそれぞれ所属する医療従事者Ｍも所属している。

　患者Ｐ２は、二つの疾患（ここではアルツハイマー、高血圧とする）を患っていて、患者Ｐ２の二つの疾患毎にグループＧ２１及びＧ２２が生成されており、各グループに対して医療関連施設Ｆが関連づけられている。具体的に言えば、アルツハイマー治療用のグループＧ２１に対しては病院Ｆ３がかかりつけ登録され、高血圧治療用のグループＧ２２に対しては訪問看護ステーションＦ４がかかりつけ登録されている。このように、ここでは、患者Ｐ２は、二つのグループＧ２１及びＧ２２に所属している。後述するように、グループＧ２１及びＧ２２には、かかりつけ登録された病院Ｆ３及び訪問看護ステーションＦ４にそれぞれ所属する医療従事者Ｍも所属している。

　上述したように、グループＧ１１は患者Ｐ１の糖尿病治療用グループ、グループＧ１２は患者Ｐ１の高脂血症治療用グループ、グループＧ１３は患者Ｐ１の痛風治療用グループである。また、グループＧ２１は患者Ｐ２のアルツハイマー治療用グループ、グループＧ２２は患者Ｐ２の高血圧治療用グループである。このように、グループＧは、個々の患者Ｐが持つ疾患毎に作られるので、各グループＧ内では、特定の患者Ｐの特定の疾患に関する医療情報が共有されるため、当該疾患の治療等に対して高い支援効果が期待でき、結果としてより良質の医療サービスが提供できるようになる。

　医療従事者Ｍ１は、医師で、クリニックＦ１に所属しており、患者Ｐ１の糖尿病治療用グループＧ１１及び痛風治療用グループＧ１３にサポーターとして所属している。医療従事者Ｍ２は、看護師で、医療従事者Ｍ１と同じクリニックＦ１に所属しており、患者Ｐ１の糖尿病治療用グループＧ１１にサポーターとして所属している。

　医療従事者Ｍ３は、医師で、クリニックＦ２に所属しており、患者Ｐ１の高脂血症治療用グループＧ１２にサポーターとして所属している。医療従事者Ｍ４は、看護師で、医療従事者Ｍ３と同じクリニックＦ２に所属しており、患者Ｐ１の高脂血症治療用グループＧ１２にサポーターとして所属している。

　医療従事者Ｍ５は、医師で、病院Ｆ３に所属しており、患者Ｐ１の糖尿病治療用グループＧ１３にサポーターとして所属している。医療従事者Ｍ６は、医師で、医療従事者Ｍ５と同じ病院Ｆ３に所属しており、患者Ｐ１の糖尿病治療用グループＧ１１と患者Ｐ２のアルツハイマー治療用グループＧ２１及び高血圧治療用グループＧ２２にサポーターとして所属している。

　医療従事者Ｍ７は、看護師で、訪問看護ステーションＦ４に所属しており、患者Ｐ２のアルツハイマー治療用グループＧ２１にサポーターとして所属している。医療従事者Ｍ８は、看護師で、医療従事者Ｍ７と同じ訪問看護ステーションＦ４に所属しており、患者Ｐ２の高血圧治療用グループＧ２２にサポーターとして所属している。

　以上述べたように、医療支援システム３０では、患者Ｐ１が持つ三つの疾患（ここでは糖尿病、高脂血症、痛風）毎にグループＧ１１、Ｇ１２及びＧ１３が形成されており、これらのグループＧ１１、Ｇ１２及びＧ１３のそれぞれに、クリニックＦ１、クリニックＦ２及び病院Ｆ３が、かかりつけ登録されている。したがって、クリニックＦ１に所属する医療従事者Ｍ１とＭ２が、主治医として、患者Ｐ１のグループＧ１１の疾患（ここでは糖尿病）の治療等を担当する。クリニックＦ２に所属する医療従事者Ｍ３とＭ４が、主治医として、患者Ｐ１のグループＧ１２の疾患（ここでは高脂血症）の治療等を担当する。病院Ｆ３に所属する医療従事者Ｍ５とＭ６が、主治医として、患者Ｐ１のグループＧ１３の疾患（ここでは痛風）の治療等を担当する。

　同様に、患者Ｐ２持つ二つの疾患（ここではアルツハイマー、高血圧）毎にグループＧ２１及びＧ２２が形成されており、これらのグループＧ２１及びＧ２２のそれぞれに、病院Ｆ３及び訪問看護ステーションＦ４が、かかりつけ登録されている。したがって、病院Ｆ３に所属する医療従事者Ｍ５とＭ６が、主治医として、患者Ｐ２のグループＧ２１の疾患（ここではアルツハイマー）の治療等を担当する。訪問看護ステーションＦ４に所属する医療従事者Ｍ７とＭ８が、主治医として、患者Ｐ２のグループＧ２２の疾患（ここでは高血圧）の治療等を担当する。

　各グループＧ内における上述した医療情報の共有やコミュニケーション（メッセージ交換）を実現するのに必要な各種機能は、後述するように、患者端末１０、医療従事者端末１１又は患者関係者端末１２からの要請や指示に応じて、医療支援システム３０が提供する。

　（医療支援システムの構成及び機能）
　次に、本実施形態の医療支援システム３０の構成と機能について、図３を参照しながら説明する。図３は、医療支援システム３０の内部構成を示す機能ブロック図である。

　本実施形態の医療支援システム３０は、図３に示すように、ユーザー管理部３１０と、グループ管理部３２０と、認証部３４０と、通信制御部３５０を備えている。

　通信制御部３５０は、医療支援システム３０の外部に設けられた通信ネットワークとしてのインターネット２０を介して、医療支援システム３０と複数のユーザー端末（つまり患者端末１０、医療従事者端末１１及び患者関係者端末１２）との間で、情報の送受信を可能とするセクションである。通信制御部３５０の通信制御プロセスは、公知の方法で実行されるので、その説明は省略する。

　認証部３４０は、ユーザー端末１０、１１又は１２からインターネット２０を介して医療支援システム３０にアクセスしてきた人が、当該医療支援システム３０でユーザー登録を受けた正規ユーザーであるか否かの認証を行うセクションである。

　認証部３４０は、通信制御部３５０を介して、医療支援システム３０の外部に設けられたインターネット２０に接続されている。ユーザー管理部３１０とグループ管理部３２０は、認証部３４０において所定の認証を得ることを条件として、医療支援システム３０の外部にある患者端末１０、医療従事者端末１１及び患者関係者端末１２との間で情報の送受信を行う。そして、認証部３４０において正規ユーザーとして認証された場合に限り、その人によるユーザー管理部３１０とグループ管理部３２０へのアクセスが許可される。そうして初めて、そのユーザーは、医療支援システム３０が提供する医療支援サービスを利用することが可能となる。

　次に、ユーザー管理部３１０について説明する。

　ユーザー管理部３１０は、医療関連施設Ｆから提供される医療サービスを利用する個々のユーザー、あるいは、そのユーザーを支援するユーザー、すなわち患者Ｐ、医療従事者Ｍ及び患者関係者Ｒの登録（ユーザー登録）と、登録したユーザーの管理を行うセクションである。ユーザー管理部３１０は、登録部３１１、ユーザー情報記憶部３１２、患者情報記憶部３１３、医療従事者情報記憶部３１４、医療関連施設情報記憶部３１５及び疾患情報記憶部３１６を有している。

　登録部３１１は、その動作を制御するソフトウェアから形成され、ユーザー管理部３１０におけるユーザー登録全般に関わる動作を制御する。例えば、医療支援システム３０にアクセスしてきたユーザー端末１０、１１又は１２に、所定のユーザー登録画面（図１６Ａを参照）を表示し、当該医療支援サービスの利用を希望する人（利用希望者）に対して、所定の個人情報を入力・送信するよう促す。それに応じて、ユーザー端末１０、１１又は１２から所定の個人情報が医療支援システム３０まで送信されて来ると、その個人情報をその利用希望者の「ユーザー情報」としてユーザー情報記憶部３１２に記憶する。また、登録部３１１は、必要に応じて、ユーザー情報記憶部３１２に記憶されたユーザー情報を読み出して利用し、また、ユーザー情報の修正・消去等も行う。

　ユーザー情報記憶部３１２は、ハードディスク等の情報記憶媒体と、その情報記憶媒体への情報の記録、再生、消去等の動作を制御するソフトウェアから形成され、登録部３１１の指示に応じて、ユーザー情報、すなわち、ユーザーとしての患者Ｐ、医療従事者Ｍ及び患者関係者Ｒの必要情報を記憶する。この時、個々のユーザーに、一意的に識別できる「ユーザー識別情報」（ユーザーＩＤ）を割り当てる。ユーザー情報は、例えば、図４（ａ）に示すようなユーザーテーブルの形式で記憶される。

　患者情報記憶部３１３は、ハードディスク等の情報記憶媒体と、その情報記憶媒体への情報の記録、再生、消去等の動作を制御するソフトウェアから形成され、登録部３１１の指示に応じて、患者Ｐの個人情報を記憶する。この時、個々の患者Ｐに一意的に識別可能な「患者ＩＤ」を割り当てる。この「患者ＩＤ」は、「患者識別情報」であり、「サービス受給者識別情報」でもある。患者Ｐの個人情報は、例えば、図４（ｂ）に示すような患者テーブルの形式で記憶される。

　医療従事者情報記憶部３１４は、ハードディスク等の情報記憶媒体と、その情報記憶媒体への情報の記録、再生、消去等の動作を制御するソフトウェアから形成され、登録部３１１の指示に応じて、医療従事者Ｍの個人情報を記憶する。この時、個々の医療従事者Ｍに一意的に識別可能な「医療者ＩＤ」を割り当てる。この「医療者ＩＤ」は、「医療従事者識別情報」であり、「事業従事者識別情報」でもある。医療従事者Ｍの個人情報は、例えば、図４（ｃ）に示すような医療従事者テーブルの形式で記憶される。

　医療関連施設情報記憶部３１５は、ハードディスク等の情報記憶媒体と、その情報記憶媒体への情報の記録、再生、消去等の動作を制御するソフトウェアから形成され、登録部３１１の指示に応じて、医療関連施設Ｆの必要情報を記憶する。この時、個々の医療関連施設Ｆに一意的に識別可能な「医療関連施設ＩＤ」を割り当てる。この「医療関連施設ＩＤ」は、「医療関連施設識別情報」である。医療関連施設Ｆの必要情報は、例えば、図４（ｄ）に示すような医療関連施設テーブルの形式で記憶される。

　疾患情報記憶部３１６は、ハードディスク等の情報記憶媒体と、その情報記憶媒体への情報の記録、再生、消去等の動作を制御するソフトウェアから形成され、登録部３１１の指示に応じて、疾患情報を記憶する。この時、個々の疾患に一意的に識別可能な「疾患ＩＤ」を割り当てる。この「疾患ＩＤ」は、「疾患識別情報」である。疾患情報は、例えば、図５（ｂ）に示すような疾患テーブルの形式で記憶される。

　次に、グループ管理部３２０について説明する。

　グループ管理部３２０は、医療支援システム３０において、個々の患者Ｐの疾患毎に登録・形成されるグループＧを管理するセクションである。例えば、グループの新規登録のほか、グループ・メンバーの情報の記憶、招待リクエストやタイムラインやメッセージの制御、かかりつけ登録等々、多くの機能を実行する。グループ管理部３２０は、登録部３２１、グループ情報記憶部３２２、グループ・メンバー情報記憶部３２３、招待リクエスト制御部３２４、招待リクエスト情報記憶部３２５、タイムライン制御部３２６、メッセージ制御部３２７、かかりつけ施設情報記憶部３２８、共有同意情報記憶部３２９、患者実在性検証部３３０、認証部３３１、そしてアプリケーション保存部３３２を有している。なお、アプリケーション保存部３３２は、後述するサービス構築支援システム１００（アプリケーション・フレームワーク２００）のために、医療支援システム３０に追加されたものである。

　登録部３２１は、その動作を制御するソフトウェアから形成され、医療従事者Ｍ又は患者Ｐの要請に応じて、個々の患者Ｐの疾患毎にグループＧを生成し、登録する。また、医療従事者Ｍ又は患者Ｐの要請に応じて、後述する「かかりつけ登録」（具体的には、患者Ｐと疾患と医療関連施設Ｆの関連付け）に係るプロセスも実行する。

　医療従事者Ｍの要請によりグループＧが生成されるのは、医療従事者Ｍが「患者グループ登録」をする場合である。「患者グループ登録」とは、医療従事者Ｍが所属する医療関連施設Ｆが治療等をしている患者Ｐとその疾患を、医療支援システム３０に登録することを指す。このとき、医療従事者Ｍは、自分が所属する医療関連施設Ｆが治療等をしている患者Ｐとその疾患を指定して、医療支援システム３０に登録するが、これは、その医療従事者Ｍが所属する医療関連施設Ｆ内で、患者Ｐの医療情報を共有できるようにするためである。登録部３２１は、「患者グループ登録」に同期して自動的にグループＧを生成し、生成されたグループＧに係る情報をグループ情報記憶部３２２に記憶する。

　こうして生成されたグループＧの当初のグループ・メンバーは、予め決められたメンバー（デフォルトメンバー）が自動的に招待されている場合を除き、ゼロである。「患者グループ登録」をした医療従事者Ｍも、「患者グループ登録」の対象となった患者Ｐも、グループ・メンバーにはなっていない。「患者グループ登録」をした医療従事者Ｍがグループ・メンバーになるには、自分自身に向けて招待リクエストを送信し、自分で承認する必要がある。同様に、「患者グループ登録」の対象となった患者Ｐがグループ・メンバーになるには、患者Ｐ宛に招待リクエストを送信し、承認してもらう必要がある。

　患者Ｐの要請によりグループＧが生成されるのは、患者Ｐが「かかりつけ登録」を要請する場合である。このとき、患者Ｐは、自分が治療等を受けている、あるいは、受けようとしている医療関連施設Ｆのうちの一つを選んで、「かかりつけ登録」を要請し、医療関連施設Ｆに承認してもらうようにする。これは、その患者Ｐが、主として治療を受けることを希望し、且つ、治療方針全般について主たる責任を持つ医療関連施設Ｆを指定するためである。登録部３２１は、「かかりつけ登録」に同期して自動的にグループＧを生成し、生成されたグループＧに係る情報（グループ情報）をグループ情報記憶部３２２に記憶する。なお、「かかりつけ登録」では、具体的には、患者Ｐと疾患と医療関連施設Ｆの関連付けが行われる。

　こうして生成されたグループＧにおいても、デフォルトメンバーが自動的に招待されている場合を除き、当初のグループ・メンバーはゼロである。「かかりつけ登録」を要請した患者Ｐも、「かかりつけ登録」の対象となった医療関連施設Ｆの医療従事者Ｍも、グループ・メンバーにはなっていない。「かかりつけ登録」を要請した患者Ｐがグループ・メンバーになるには、自分自身に招待リクエストを送信し、自分で承認する必要がある。同様に、「かかりつけ登録」に係る医療従事者Ｍがグループ・メンバーになるには、「かかりつけ登録」を要請した患者Ｐが、医療従事者Ｍ宛に招待リクエストを送信し、承認してもらう必要がある。

　グループ情報記憶部３２２は、ハードディスク等の情報記憶媒体と、その情報記憶媒体への情報の記録、再生、消去等の動作を制御するソフトウェアから形成され、グループ情報、すなわち、各グループＧがどの患者Ｐのどのような疾患に関するものであり、また、どの医療関連施設Ｆを「かかりつけ施設」として登録しているかを示す情報を記憶する。「グループ情報」は、例えば、図５（ｃ）のようなグループテーブルとの形式で記憶される。

　グループ・メンバー情報記憶部３２３は、ハードディスク等の情報記憶媒体と、その情報記憶媒体への情報の記録、再生、消去等の動作を制御するソフトウェアから形成される。グループ・メンバー情報記憶部３２３は、グループ・メンバー情報、すなわち、各グループＧの所有者とも言える患者Ｐ本人と、各グループＧに患者Ｐのサポーターとして参加している医療従事者Ｍや患者関係者Ｒに係る情報を記憶する。「グループ・メンバー情報」は、例えば、図５（ｄ）のようなグループ参加テーブルの形式で記憶される。

　招待リクエスト制御部３２４は、その動作を制御するソフトウェアから形成され、個々のグループＧに参加して欲しい非グループ・メンバー（すなわち、患者Ｐ、医療従事者Ｍ又は患者関係者Ｒ）を特定して、それらの非グループ・メンバーに対して送られる「招待リクエスト」を制御する。招待リクエスト制御部３２４は、ユーザーすなわち医療従事者Ｍ又は患者Ｐ又は患者関係者Ｒの指示に応じて、特定された非グループ・メンバーに対して、招待リクエストを電子メールの形で送信する。また、招待リクエストを受信したユーザーからの返信（招待リクエストを承認したか否かを示す）を受信する。

　招待リクエストは、所望のグループＧに参加してグループ・メンバーになって欲しいユーザーに対して送られる、電子メール形式の招待状である。招待リクエストの送信は、患者Ｐ、医療従事者Ｍ、患者関係者Ｒのいずれも可能であるが、グループＧへの参加を希望するユーザーに招待リクエストを送信する前に、所定の管理者の「許可」を受ける必要がある。これは、招待しようとしているユーザーがグループ・メンバーとしてふさわしいか否か、そのユーザーの参加により何らかの支障が生じないか等の点を考慮して、管理者が決定する。この管理者には、「医療従事者側管理者」と「患者側管理者」がある。「医療従事者側管理者」は、招待リクエストの送信を「許可」又は「拒否」する権限を有する医療従事者Ｍ（ユーザーでもある）であり、医療関連施設Ｆ毎に、あるいは、グループ毎に設定される。「医療従事者側管理者」としては、例えば、クリニックの院長や事務長などが指定される。「患者側管理者」は、患者Ｐ本人（ユーザーでもある）か、患者Ｐの家族や友人等で患者Ｐから招待リクエストの送信を「許可」又は「拒否」する権限を与えられたユーザーであり、患者Ｐ毎に、あるいは、グループ毎に設定される。「患者側管理者」としては、例えば、患者Ｐの親や配偶者や子、親しい友人などが指定される。

　通常は、医療従事者Ｍが招待リクエストを送信する場合でも、患者Ｐ又は患者関係者Ｒが招待リクエストを送信する場合でも、「医療従事者側管理者」と「患者側管理者」の双方の許可が得られないと招待リクエストを送信できない、と規定される。つまり、医療従事者Ｍ側の事情と患者Ｐ側の事情の双方を考慮したうえで、招待リクエストの送信の許否を決定するように設定する。これは、グループ・メンバーになると、患者Ｐの医療情報やメッセージを閲覧できるようになるため、だれがグループ・メンバーになるかは患者Ｐと医療従事者Ｍの双方に及ぼす影響が大きいからである。しかし、これに限定されるものではない。「医療従事者側管理者」と「患者側管理者」のいずれか一方の許可が得られれば、招待リクエストを送信できるようにしてもよいし、「医療従事者側管理者」のみの許可が得られれば、招待リクエストを送信できるようにしてもよい。この点は、必要あるいは要望に応じて決めることができる。

　このように、医療支援システム３０では、招待リクエストの送信が「完了」する（「招待の完了」）ためには、「医療従事者側管理者」及び「患者側管理者」の少なくとも一方の「許可」が必要であり、グループ・メンバーの追加によって問題が生じないようになっている。

　「医療従事者側管理者」及び「患者側管理者」の双方、又は、その少なくとも一方の「許可」を受けて送信された招待リクエストを受け取ったユーザーは、その招待リクエストで指定されたグループＧに参加する場合は、その招待を「承認」すればよい。そうすると、自動的に、グループ・メンバーとして追加される。グループＧに参加しない場合は、その招待を「拒絶」すればよい。このように、招待リクエストを受け取ったユーザーは、招待を「承認」するか否かを決めることで、グループＧへの参加・不参加を選択することができる。

　招待を承認したユーザーは、グループＧのメンバーとなるが、患者Ｐ以外のグループ・メンバー（具体的には医療従事者Ｍと患者関係者Ｒ）はすべて、患者Ｐのサポーターとなる。グループ・メンバーの間では、患者Ｐが選択した共有ルールに従って、患者Ｐの医療情報やメッセージが共有される。したがって、例えば、他の医療関連施設Ｆの医療従事者Ｍから自己の疾患に対するセカンド・オピニオンをもらいたい場合や、患者Ｐが自己の疾患に関する治療経過等について知っておくことを望む家族や親戚、友人等の患者関係者Ｒがいる場合には、このような人々に対して招待リクエストが送信される。こうすることで、医療関連施設Ｆの患者Ｐの特定疾患についての医療情報を、一意性を担保しながら、他の医療関連施設の医療従事者を含む複数の医療従事者Ｍや、患者関係者Ｒ、患者Ｐ本人と共有することができる。

　「医療従事者側管理者」及び「患者側管理者」の設定は、招待リクエスト情報記憶部３２５に記憶される。「医療従事者側管理者」及び「患者側管理者」による「許可」プロセスは、招待リクエスト制御部３２４が実行する。招待リクエストの生成及び送信と、招待リクエスト受信者からの返信の受信は、招待リクエスト制御部３２４が実行する。

　招待リクエスト情報記憶部３２５は、ハードディスク等の情報記憶媒体と、その情報記憶媒体への情報の記録、再生、消去等の動作を制御するソフトウェアから形成される。招待リクエスト情報記憶部３２５は、要請に応じて招待リクエスト制御部３３１が生成する「招待リクエスト情報」、すなわち、誰が誰に対して招待リクエストを送るのかを示す各種情報と、管理者による招待リクエストの許否に関する情報を記憶する。また、招待リクエストの受信者からの返信内容（招待リクエストの承認又は許否）と、「医療従事者側管理者」及び「患者側管理者」の設定も記憶する。「招待リクエスト情報」は、例えば、図６（ａ）に示した招待リクエストテーブルの形式で記憶される。

　なお、図６（ａ）の招待リクエストテーブルに「招待先パスフレーズ」が含まれているのは、招待リクエストを受け取った人が、正規の招待先であるか否か、換言すれば、本人であるか否かを、このパスフレーズで確認するためである。招待リクエストを受け取った人が、その招待リクエストに係る招待元のグループに参加するためには、招待リクエストの電子メール中に記載されているＵＲＬにアクセスして、そこで表示される招待リクエスト承認画面中に、パスフレーズを入力する必要がある。入力されたパスフレーズが、招待リクエストテーブルに格納されている「招待先パスフレーズ」と一致しないと、そのグループには参加できないようになっているから、これで招待先の本人認証が容易にできるのである。

　タイムライン制御部３２６は、その動作を制御するソフトウェアから形成されており、各グループＧに対して割り当てられる「タイムライン」（すなわち情報表示領域）を制御する。具体的には、新たに生成されたグループＧに対して、「タイムライン」と呼ばれる情報表示領域を割り当て、共有される医療情報をそのタイムラインに所定の順序で（例えば投稿された時刻順に）表示させる。表示する情報と、その表示時刻等のパラメータは、医療従事者端末１１からインターネット２０を介してグループ管理部３３０に送られるので、タイムライン制御部３３５は、そのパラメータに従って、送られてきた情報をタイムラインに表示させる。

　タイムラインの一例を図９に示す。このタイムライン５１は、患者Ｐ１の糖尿病治療のグループＧ１１用に生成されたものであり、全員共有エリア５１ａと医療従事者共有エリア５１ｂを備えている。全員共有エリア５１ａには、グループＧ１１のメンバー全員が共有する情報が表示される。医療従事者共有エリア５１ｂには、グループＧ１１の医療従事者Ｍだけが共有する情報が表示される。したがって、全員共有エリア５１ａに表示される医療情報は、グループＧ１１のメンバー全員が共有可能であり、患者Ｐ１のほか、クリニックＦ１に所属する医療従事者Ｍ１及びＭ２と、病院Ｆ３に所属する医療従事者Ｍ６と、患者関係者Ｒ１、Ｒ２及びＲ４が、自由に投稿・閲覧可能である。これとは異なり、医療従事者共有エリア５１ｂに表示される医療情報は、グループＧ１１医療従事者のみが共有可能であり、クリニックＦ１に所属する医療従事者Ｍ１及びＭ２と、病院Ｆ３に所属する医療従事者Ｍ６が、自由に投稿・閲覧可能である。

　メッセージ制御部３２７は、その動作を制御するソフトウェアから形成されており、一人のグループ・メンバーから他のグループ・メンバーに宛てられたメッセージの送信・受信を制御する。この制御には、例えば、図７（ａ）に示したメッセージ送信予約テーブルが使用される。

　図７（ｂ）に示した患者属性テーブルは、個々の患者Ｐの属性が記憶されるものであり、メッセージ制御部３３６が所定のメッセージを一部の患者Ｐに選択的に送信する際に使用される。

　かかりつけ施設情報記憶部３２８は、ハードディスク等の情報記憶媒体と、その情報記憶媒体への情報の記録、再生、消去等の動作を制御するソフトウェアから形成される。かかりつけ施設情報記憶部３２８は、登録部３２１が実行する「かかりつけ登録」（患者Ｐと疾患と医療関連施設Ｆの関連付け）プロセスで利用され、生成される「かかりつけ施設情報」を記憶する。かかりつけ登録についての詳細は、上述した特許文献１に記載されているので、称略する。「かかりつけ施設情報」は、例えば、図５（ａ）に示すような医療関連施設患者テーブルの形式で記憶される。

　登録部３２１は、上記の医療情報共有の照会画面において、所定の共有ルール選択画面を表示し、共有ルール、すなわち医療情報の共有範囲を選択するよう促す。例えば、共有ルールの選択肢は二つとされ、一つは「かかりつけ登録に係る医療関連施設Ｆの内部のみで共有」、他の一つは「かかりつけ登録に係る医療関連施設Ｆの内部と、かかりつけ登録に係る患者Ｐ本人とを含む、グループ・メンバー全員で共有」とされる。いずれかの共有ルールが選択されると、登録部３２１は、「共有に同意する」旨の回答と、選択された共有ルールとを共有同意情報記憶部３２９に記憶する。共有ルールを三つ以上設定してもよいことは言うまでもない。

　共有同意情報記憶部３２９は、ハードディスク等の情報記憶媒体と、その情報記憶媒体への情報の記録、再生、消去等の動作を制御するソフトウェアから形成され、登録部３２１によって生成された、「自己の医療情報の共有に同意する」旨の意思表示（共有同意情報）と、選択された共有ルールとを記憶する。共有同意情報と選択された共有ルールは、例えば、図６（ｃ）に示す医療情報共有テーブルの形式で記憶される。

　患者実在性検証部３３０は、その動作を制御するソフトウェアから形成されており、「かかりつけ登録を要請して来た患者Ｐが実在するか否か」、換言すれば、「その患者Ｐが本人であり、他人のなりすましではないかどうか」を検証する。この患者実在性検証プロセスは、上述したかかりつけ登録プロセスを開始する前に行うのが好ましい。図６（ｄ）に、ＮＦＣ端末を管理するために作成されたＮＦＣ端末テーブルの一例を示す。

　認証部３３１は、その動作を制御するソフトウェアから形成されており、ユーザー端末を介して、医療支援システム３０の特定のグループＧにアクセスして来た患者Ｐ、医療従事者Ｍ又は患者関係者Ｒが、そのグループＧの正規のメンバーであるか否か、換言すれば、そのグループＧのタイムラインにアクセスする権限があるか否かをチェックする。そして、正規のメンバーであることが確認されれば、そのグループＧのタイムラインにアクセスすることを許可する。正規のメンバーでないと確認されれば、そのグループＧのタイムラインにアクセスすることを拒否する。

　アプリケーション保存部３３２は、後述するサービス構築支援システム１００のために追加されたものであり、ハードディスク等の情報記憶媒体と、その情報記憶媒体への情報の記録、再生、消去等の動作を制御するソフトウェアから形成されている。アプリケーション保存部３３２は、アプリケーション・フレームワーク２００（これはサービス構築支援システム１００が生成する）を利用して開発されるすべてのアプリケーション２２０を構成するファイル（アプリケーション構成ファイル）それ自体と、それらアプリケーション２２０で利用される情報を記憶するセクションである。アプリケーション保存部３３２は、アプリケーション２２０を開発した開発者端末１３から医療支援システム３０にアップロードされ且つインストールされたすべてのアプリケーション２２０（つまりアプリケーション２２０のアプリケーション構成ファイル）を保存するが、それ以外に、各アプリケーション２２０の実行時に使用される設定情報（例えば管理者設定に係る情報や、ユーザー設定により提供される情報）なども保存するようになっている。

　医療支援システム３０で使用される上述した各種テーブルは、図８に示すような関係を持つ。

　（医療支援システムの動作）
　以上の構成を持つ医療支援システム３０では、医療情報とメッセージの共有のために、個々の患者Ｐの疾患毎にグループＧが登録・生成される。グループＧの作成は、上述したように、医療従事者Ｍによる患者グループ登録、又は、患者Ｐによるかかりつけ登録によって行われる。また、グループＧのグループ・メンバーは、デフォルトメンバーを除き、必要に応じて患者Ｐや医療従事者Ｍ、患者関係者Ｒを招待することで追加され、また、必要に応じてグループＧから削除される。医療支援システム３０のこれら動作の詳細は特許文献１に記載されているが、これらは本実施形態に係るサービス構築支援システム１００とは関係がないため、それらの説明は省略する。

　また、医療支援システム３０のユーザー登録、新規患者登録、新規医療従事者登録等の動作についての説明も、同じ理由により、省略する。

　（アプリケーション・フレームワークの構成）
　次に、本発明の一実施形態に係るサービス構築支援システム１００によって生成されるアプリケーション・フレームワーク２００の構成について、図１０～図１３を参照しながら説明する。

　以下の説明では、アプリケーション・フレームワーク２００を用いて所望のアプリケーション２２０を開発する個々の開発者を区別する場合は「開発者Ｄ１」、「開発者Ｄ２」などと表記し、区別しない場合は「開発者Ｄ」と表記する。なお、開発者Ｄが操作する開発者端末１３（図１１、図１２参照）と、医療支援システム３０のシステム管理者Ａが操作する管理者端末１４（図１参照）は、上述したユーザー端末（つまり患者端末１０、医療従事者端末１１又は患者関係者端末１２）と同様に、携帯電話やスマートフォンのような携帯端末でもよいし、デスクトップ型あるいはノート型のパーソナル・コンピューター（パソコン）でもよいし、タッチパネル型の端末でもよい。その形態や構成は問わない。

　アプリケーション・フレームワーク２００は、図１０及び図１１に示すように、プラットフォームとしての医療支援システム３０の上に構築されるものであり、インターネット２０を介して複数の開発者端末１３がアプリケーション・フレームワーク２００に接続可能とされている。開発者Ｄ１～Ｄ５は、それぞれ、自己の開発者端末１３を操作してインターネット２０を介してアプリケーション・フレームワーク２００にアクセスし、アプリケーション・フレームワーク２００中に用意されている特定機能を適宜使用することで、医療支援システム３０上で動作する所望のアプリケ-ション（アプリケーション・プログラム）２２０を効率的に開発することが可能である。

　アプリケーション・フレームワーク２００を利用して開発されたアプリケーション２２０（つまりアプリケーション２２０を構成するファイル）は、開発者端末１３からインターネット２０を介して医療支援システム３０にアップロードされ、所定のインストール処理を経て同システム３０の内部に、具体的には、グループ管理部３２０内に設けられたアプリケーション保存部３３２（図３参照）に保存される。その後は、そのアプリケーション２２０が提供するサービス（新医療サービス）を医療支援システム３０から利用することが可能となる。その新医療サービスの詳細（例えば、服薬支援アプリの場合なら、患者にどのような質問をするか、どのような検査データを収集するか等）は、医療支援システム３０のシステム管理者の設定に応じて決定されるようになっている。その新医療サービスの利用を希望する医療支援システム３０のユーザー（すなわち患者Ｐ、医療従事者Ｍ又は患者関係者Ｒ）は、自己のユーザー端末（すなわち患者端末１０、医療従事者端末１１又は患者関係者端末１２）に表示されるアプリ選択画面（例えば図１９、図２０、図２２参照）で、自己の希望するアプリケーション２２０のアイコンを選択（クリック）するだけでよい。それだけで、自己のユーザー端末１０、１１又は１２からその新医療サービスを利用できるようになる。なお、アップロードされたアプリケーション２２０（つまりアプリケーション構成ファイル）は、医療支援システム３０の内部ではなく、サービス構築支援システム１００の内部に保存してもよいことは言うまでもない。

　アプリケーション・フレームワーク２００の内部構成は、図１２及び図１３に示すとおりである。図１２はアプリケーション・フレームワーク２００を利用したアプリケーション２２０の開発時の状態を示し、図１３はそうして開発したアプリケーション２２０の利用時の状態を示している。両図に示すように、アプリケーション・フレームワーク２００には、目的に応じて異なる機能を有する２つのユニット２１０ａ及び２１０ｂが設けられている。

　ここでは、説明を簡単にするために２つのユニット２１０ａ及び２１０ｂを設けた例を示しているが、本発明はこれには限定されない。これらユニットの総数は、１つでもよいし、３つ以上でもよく、必要に応じて任意に設定できることは言うまでもない。

　ユニット２１０ａは、「ケア・ユニット」として構成されており、例えば、服薬管理、生活習慣改善、糖尿病服薬支援、チーム医療支援、褥瘡ケア、リハビリ支援等の種々のケア（治療）に関連する付加的な医療サービスを、アプリケーション２２０を用いて医療支援システム３０上に効率的に構築できるように、また、同サービスを医療支援システム３０のユーザーにリーズナブルな価格で提供できるようにするために用意されている。この種の付加的な医療サービスの提供が可能になれば、医療現場を支援するために医療関係者の多職種連携（つまり、医師、看護師、栄養士、ケアマネージャー、ヘルパー等の多職種従事者間の連携）を実現できるようになるからである。そこで、ケア・ユニット２１０ａには、この種のサービスを提供する種々のアプリケーション２２０の開発に効果的に利用できるように、特定機能を持つ４つの共用機能モジュール（特定機能モジュール）が設けられている。これらモジュールについては後述する。

　ユニット２１０ｂは、「コミュニティ・ユニット」として構成されており、例えば、多職種従事者間の連携窓口として機能する各種コーディネーションや相談受付、アドバイス、情報提供等、コミュニティ作成・運用に関連する付加的な医療サービスを、アプリケーション２２０を用いて医療支援システム３０上に効率的に構築し、同サービスを医療支援システム３０のユーザーにリーズナブルな価格で提供できるようにするために用意されている。この種の付加的な医療サービスの提供が可能になれば、在宅医療相談窓口、介護相談窓口、地域包括支援、医療コーディネート等、医療・介護の分野における連携窓口機能を実現できるようになる。そこで、コミュニティ・ユニット２１０ｂには、この種のサービスを提供する種々のアプリケーション２２０の開発に効果的に利用できるように、「ケア・ユニット」とは異なる複数の共用機能モジュール（特定機能モジュール）（図示せず）が設けられている。

　コミュニティ・ユニット２１０ｂは、その目的（サービス）に応じて、ケア・ユニット２１０ａの共用機能モジュールとは異なる共用機能モジュールを備えているが、両ユニット２１０ａ及び２１０ｂの違いはそれだけであり、アプリケーション・フレームワーク２００における両ユニット２１０ａ及び２１０ｂの役割は同じであるので、ここではコミュニティ・ユニット２１０ｂの共用機能モジュールについての説明は省略する。

　次に、ケア・ユニット２１０ａの内部構成について、図１２及び図１３を参照しながら説明する。

　ケア・ユニット２１０ａは、図１２及び図１３に示すように、ノート・モジュール２１１、レコード・モジュール２１２、ヒアリング・モジュール２１３、そしてブック・モジュール２１４という４つの共用機能モジュールを備えている。これらのモジュール２１１、２１２、２１３及び２１４は、服薬管理、生活習慣改善、糖尿病服薬支援、チーム医療支援、褥瘡ケア、リハビリ支援等の種々のケア（治療）に関連する付加的な医療サービスを提供する種々のアプリケーション２２０用に設けられたものであり、それらアプリケーション２２０の開発を容易化する手段として用意されている。これらのモジュール２１１、２１２、２１３及び２１４は、ケア・ユニット２１０ａ用として開発されたすべてのアプリケーション２２０で共用される。

　すなわち、これらのモジュール２１１、２１２、２１３及び２１４を必要に応じて適宜組み合わせることで、所望の新サービスを提供するアプリケーション２２０が得られるようになっている。例えば、患者に対して症状や服薬状況、食生活などについて問診を行いたい場合は、ヒアリング・モジュール２１３を使用する旨の設定をすると共に、問診に使用する質問群の内容を同モジュール２１３内で順次設定していくだけで、問診用の質問群を容易に開発することができる。具体的に言えば、例えば、質問の対象としては、誰に対して何について問うのか、問う対象は何にするのか等を容易に設定することができる。また、それら質問群に対する回答についても同様である。例えば、回答を多肢選択式で求めるのか、それとも、コメントないしメッセージの形式で求めるのか、といった点を容易に設定することができる。さらに、それら質問群を誰に対してどのような時刻（タイミング）で提示するのか、それら質問群の公開範囲はどのようにするのか、回答者の範囲をどこに設定するのか、といった点も、同様に設定することができる。

　ノート・モジュール２１１は、医療支援システム３０のユーザーが、必要になったその都度、所望の情報を所定の記憶手段（具体的には、医療支援システム３０のアプリケーション保存部３３２）に記録する機能を開発者Ｄに提供するためのモジュールである。この機能は、医療支援システム３０（医療支援サービス）のユーザー（例えば医療従事者Ｍ）が、必要に応じて所望の情報をノートに記録するのと同様の動作を可能とする。具体例を挙げると、この機能をアプリケーション２２０内に記述すれば、その実行時に、例えば、図２５に示した「合併症、その他症状」の機能の設定に対応する内容を、特定の医療従事者Ｍに対し、自己の所属するグループＧのタイムライン（医療従事者側）上で入力するように促し、前記内容が入力されるとその入力内容をアプリケーション保存部３３２に自動記憶する、という動作を容易に実現することができる（これは、後述する「ユーザー設定プロセス」において実行される）。すると、そのアプリケ-ション２２０において医療支援システム３０が持つタイムラインへのメッセージ投稿（表示）機能を用いることで、所望の時刻に、「合併症、その他症状」の見出しとその入力内容（つまり「ユーザー設定プロセス」で設定した内容）を同グループＧのタイムライン（患者側）に投稿して表示させる、という動作を、非常に容易に実現することができる。

　アプリケーション２２０に組み込まれたノート・モジュール２１１の機能を使用するには、初期設定が必要であるため、使用開始時に医療支援システム３０のシステム管理者Ａによる「管理者設定プロセス」において所定の初期設定が実行される。また、当該機能の使用開始後に必要に応じて行われる設定変更（この設定変更は通常、ユーザー例えば医療従事者Ｍからの要望または指示によって行われる）も、同管理者Ａによる「管理者設定プロセス」において実行される。この時、設定変更を希望するユーザー（例えば医療従事者Ｍ）は、同管理者Ａにその旨を依頼し、その依頼を受けた同管理者Ａが「管理者設定プロセス」を再度実行することで、依頼者の希望どおりの設定変更が行われる。

　ここで、「タイムライン（医療従事者側）」は、グループ・メンバーの中で医療従事者Ｍのみが閲覧可能であり、図９の医療従事者共有エリア５１ｂに対応する。また、「タイムライン（患者側）」は、グループ・メンバー全員が閲覧可能であり、図９の全員共有エリア５１ａに対応する。これは、以下の説明においても同様である。

　レコード・モジュール２１２は、外部から与えられる所定の情報（外部情報）を自動的に取り込んで所定の記憶手段（具体的には医療支援システム３０のアプリケーション保存部３３２）に記録する機能を開発者Ｄに提供するためのモジュールである。この機能は、医療支援システム３０のユーザー（例えば医療従事者Ｍ）が必要とする所定の外部情報（例えば、検査機関から送られる各種検査情報）を、所望のタイミングで自動収集して医療支援システム３０内に記録するという動作を可能とする。具体例を挙げると、この機能をアプリケーション２２０内に記述すれば、その実行時に、例えば、図２５に示した「検査の記録」の機能設定で指定された検査項目に係る情報（検査情報）を、外部にある所定の情報源（例えばデータベース）から読み出して、アプリケーション保存部３３２に自動記憶する、という動作を容易に実現することができる（前記検査項目の指定は、後述する「ユーザー設定プロセス」において実行される）。すると、そのアプリケーション２２０において医療支援システム３０が持つメッセージ投稿機能を用いることで、所望の時刻に、「検査の記録」の見出しと該当する検査情報を同グループＧのタイムライン（医療従事者側）に投稿して表示させる、という動作を、非常に容易に実現することができる。なお、前記検査情報としては、例えば、指定された患者Ｐの生命に関する最も基本的な情報であるバイタルサインがある。バイタルサインとは、例えば、脈拍あるいは心拍数、呼吸(数)、血圧、体温の４つを指すことが多く、これらの数値情報から、患者Ｐの現在状況を把握・表現することが可能である。また、治療の前後あるいはその途中に行われる診断に含まれる項目、例えば、体重、血圧、血糖値、ＨｂＡ１ｃなども該当する。前記検査情報以外の外部情報についても、同様の取り込み・記録が可能であることは言うまでもない。

　アプリケーション２２０に組み込まれたレコード・モジュール２１２の機能を使用するには、ノート・モジュール２１１の場合と同様に、初期設定が必要であるため、使用開始時にシステム管理者Ａによる「管理者設定プロセス」において所定の初期設定が実行される。また、当該機能の使用開始後に必要に応じて行われる設定変更も、同管理者Ａによる「管理者設定プロセス」において実行される。

　ヒアリング・モジュール２１３は、所定の対象者への一連の質疑応答（例えば患者に対する問診）を行うための機能を開発者Ｄに提供するためのモジュールである。この機能は、所望のタイミングで医療支援システム３０のユーザー（例えば医療従事者Ｍ）が所定の対象者（例えば患者Ｐ）に一連の質問を行うことで、それら質問に対応する所望の情報（例えば、患者Ｐの最近の体調や症状に関する情報）を回答として入手し記録するという動作を可能とする。そのために、ヒアリング・モジュール２１３には、一連の質問の見本（質問テンプレート群）と回答の見本（回答テンプレート群）とが用意されており、それらのテンプレート群を利用すれば、所望の質問文とそれに適した回答様式を簡単に作ることができるようになっている。具体例を挙げると、ヒアリング・モジュール２１３の機能をアプリケーション２２０内に記述すれば、その実行時に、例えば、図２５に示した「気になる症状の確認」、「食生活の確認」等の機能設定で、それらのタイトルに対応して予め用意された質問群（質問テンプレート群）に基づいて、所望の質問文が自動作成され、それらの質問文（質問情報）を、医療支援システム３０が持つメッセージ投稿機能を用いて、所望のタイミングで、対象者である患者Ｐの所属するグループＧのタイムライン（患者側）に投稿して回答するように促す、という動作を容易に実現することができる。そして、該当する患者Ｐから回答が入力されると、医療支援システム３０の機能を使って、その回答の内容（回答情報）をアプリケーション保存部３３２に自動記憶する、という動作を容易に実現することができる。前記質問情報の指定と前記回答情報用の回答様式の指定は、後述する「ユーザー設定プロセス」において実行される。

　アプリケーション２２０に組み込まれたヒアリング・モジュール２１３の機能を使用するには、ノート・モジュール２１１及びレコード・モジュール２１２の場合と同様に、初期設定が必要であるため、使用開始時にシステム管理者Ａによる「管理者設定プロセス」において所定の初期設定が実行される。また、当該機能の使用開始後に行われる設定変更も、必要に応じて、同管理者Ａによる「管理者設定プロセス」において実行される。

　ブック・モジュール２１４は、種々の情報をファイル形式で「コンテンツ」として所定の記憶手段（具体的にはアプリケーション保存部３３２）に記憶する機能を開発者Ｄに提供するためのモジュールである。この機能は、医療支援システム３０の特定のユーザー（例えば患者Ｐ、医療従事者Ｍ又は患者関係者Ｒ）に役立つ情報（有益情報）を「コンテンツ」としてまとめた種々の形式のファイル（例えばｐｄｆ、ｘｌｓ、ｄｏｃ、ｊｐｇ、ｍｐ４等）を予め記憶しておき、医療支援システム３０が持つメッセージ投稿機能を用いることで、所望のタイミングで、指定されたコンテンツを特定のグループＧのタイムライン（患者側）に投稿して表示させる、という動作を、容易に実現することができる。具体例を挙げると、この機能をアプリケーション２２０内に記述すれば、その実行時に、例えば、図２５に示した「糖尿病アドバイス（食事）」、「糖尿病アドバイス（運動）」等の機能設定で、それらのタイトルに対応して予め用意されたコンテンツ（ファイル）を、医療支援システム３０が持つメッセージ投稿機能を用いて、所望のタイミングで、対象者である患者Ｐの所属するグループＧのタイムライン（患者側）に投稿して表示するという動作を、容易に実現することができる。これにより、例えば該当する患者Ｐまたは患者関係者Ｒは最適なタイミングで容易に有益な情報を入手することが可能となる。前記コンテンツ（ファイル）の用意・記憶と指定は、後述する「ユーザー設定プロセス」において実行される。

　アプリケーション２２０に組み込まれたブック・モジュール２１４の機能を使用するには、ノート・モジュール２１１、レコード・モジュール２１２及びヒアリング・モジュール２１３の場合と同様に、初期設定が必要であるため、使用開始時にシステム管理者Ａによる「管理者設定プロセス」において所定の初期設定が実行される。また、当該機能の使用開始後に行われる設定変更も、必要に応じて、同管理者Ａによる「管理者設定プロセス」において実行される。

　上述したノート・モジュール２１１、レコード・モジュール２１２、ヒアリング・モジュール２１３及びブック・モジュール２１４は、ここでは、いずれも、いずれかのアプリケーション２２０から所定の指示またはリクエストを受けると、予め定められたプログラムを自動実行するボット（ＢＯＴ）を用いて実現されているが、本発明はこれに限定されるものではない。プラットフォームとなる医療支援システム３０から独立した状態で、アプリケーション２２０や医療支援システム３０から送られる指示やリクエストに応じて所定の機能を自動実行する任意の自動実行プログラムが利用可能である。その自動実行プログラムは、ソフトウェアでもよいし、ハードウェアに書き込まれたものでもよい。これらのモジュール２１１、２１２、２１３及び２１４がそれぞれ持っている前記特定機能を提供できるもので足りる。

　上述したケア・ユニット２１０ａは、上述した共用機能モジュール２１１、２１２、２１３及び２１４以外に、基本機能部２１５を備えている。

　基本機能部２１５は、上述した４つの機能モジュール２１１、２１２、２１３及び２１４が持つ前記特定機能以外の、ケア・ユニット２１０ａの基本的な機能を実行するセクションである。例えば、基本機能部２１５は、開発者端末１３からモジュール２１１、２１２、２１３又は２１４の前記特定機能をアプリケーション２２０で利用するために必要な処理と、アプリケーション２２０内でモジュール２１１、２１２、２１３又は２１４の前記特定機能を呼び出して使用するために必要な処理を実行する。基本機能部２１５は、また、アプリケーション２２０の開発時には、モジュール２１１、２１２、２１３及び２１４（アプリケーション・フレームワーク２００）と医療支援システム３０と開発者端末１３との連携に必要な処理を実行し、アプリケーション２２０の利用時には、モジュール２１１、２１２、２１３及び２１４（アプリケーション・フレームワーク２００）と医療支援システム３０とユーザー端末１０、１１又は１２（つまりアプリケーション２２０）との連携に必要な所定の処理を実行する。

　（サービス構築支援システムの構成）
　続いて、本発明の一実施形態に係るサービス構築支援システム１００の構成について、図１４及び図１５を参照しながら説明する。サービス構築支援システム１００は、上述した構成を持つアプリケーション・フレームワーク２００を医療支援システム３０上に生成すると共に、アプリケーション・フレームワーク２００と医療支援システム３０との連携を実現することで、アプリケーション２２０の開発の効率化と医療支援システム３０での新規な医療サービス（付加サービス）の構築の容易化を実現するものである。

　サービス構築支援システム１００は、医療支援システム３０と連携動作できるように構成されていれば、どのような構成であってもよい。すなわち、同システム１００は、医療支援システム３０の内部にそれと一体的に構成(配置)されていてもよいし、医療支援システム３０の外部にそれとは別個に構成(配置)されていてもよい。また、医療支援システム３０が組み込まれたサーバー装置（図示せず）の内部に一緒に構成(配置)されていてもよいし、医療支援システム３０が組み込まれたサーバー装置とは別のサーバー装置に構成(配置)されて、インターネット２０や他のネットワークを介して相互通信ができるようにされていてもよい。

　サービス構築支援システム１００は、図１４及び図１５に示すように、アプリケーション管理部１１０、ユニット管理部１２０、モジュール管理部１３０、フレームワーク管理部１４０という４つのセクションを備えており、医療支援システム３０と連携して動作するようになっている。

　アプリケーション管理部１１０は、サービス構築支援システム１００によって生成されるアプリケーション・フレームワーク２００を利用するアプリケーション２２０とその開発者Ｄの管理を行うセクションである。つまり、アプリケーション・フレームワーク２００を利用して開発されたアプリケーション２２０の登録（アプリケーション登録）と、そのアプリケーション２２０の開発者Ｄとしての登録（開発者登録）とを行い、また、こうして登録されたアプリケーション２２０及び開発者Ｄに係る情報の管理を行う。ここでは、医療支援システム３０のユーザーでなければ開発者登録ができないようになっているため、開発者Ｄは先に医療支援システム３０のユーザー登録を行い、その後に開発者登録を行う。これは、アプリケーション開発希望者（例えば製薬企業、病院等に所属するまたはそこから委託を受けた技術者）が開発するのは、医療支援システム３０が提供する医療サービスよりも高度の医療サービスを同システム３０の機能を利用して提供するためのアプリケーション２２０だからである。このため、アプリケーション開発希望者は、まず医療支援システム３０のユーザー登録を行い、その後に開発者登録を行う、というように、二段階で登録手続を行うようになっている。このような機能を持つアプリケーション管理部１１０は、登録部１１１とアプリケーション情報記憶部１１２とを有している。

　登録部１１１は、その動作を制御するソフトウェアから形成され、アプリケーション管理部１１０におけるユーザー登録、開発者登録及びアプリケーション登録の全般に関わる動作と、アプリケーション登録後に医療支援システム３０にインストールされたアプリケーション２２０の実行に係わる動作とを制御する。例えば、登録部１１１は、アプリケーション・フレームワーク２００を利用してアプリケーション２２０を開発したいと望む開発者Ｄ（アプリケーション開発希望者）からのアプリケーション開発リクエストを待機し、同リクエストを受け取ると、その開発者Ｄの開発者端末１３に所定のユーザー登録画面（図示せず）を表示し、所定の個人情報を入力して医療支援システム３０のユーザー登録をするよう促す。それに応じて、開発者端末１３から所定の個人情報がサービス構築支援システム１００に送信されて来ると、その個人情報をその開発者Ｄに係る「ユーザー情報」及び「開発者情報」としてアプリケーション情報記憶部１１２に記憶する。こうして、ユーザー登録及び開発者登録が完了する。続いて、登録部１１１は、同開発者端末１３に所定のアプリケーション登録画面（図示せず）を表示し、所定のアプリケーション情報（例えばアプリケーションの名称や用途・目的など）を入力してアプリケーション登録をするよう促す。それに応じて、同開発者端末１３から所定のアプリケーション情報がサービス構築支援システム１００に送信されて来ると、そのアプリケーション情報をその開発者Ｄに係る「アプリケーション情報」としてアプリケ-ション情報記憶部１１２に記憶する。こうして、アプリケーション登録が完了する。

　ユーザー登録と開発者登録とアプリケーション登録を完了した開発者Ｄは、アプリケーション・フレームワーク２００を利用して所望のアプリケーション２２０を開発する。アプリケーション２２０の用途・目的によって、アプリケーション・フレームワーク２００中に設けられたケア・ユニット２１０ａとコミュニティ・ユニット２１０ｂのいずれを利用するかは、自動的に決定される。例えば、アプリケーション２２０が糖尿病服薬支援を目的（用途）とするものである場合は、ケア・ユニット２１０ａを利用することが自動的に決定され、したがって、開発者Ｄはケア・ユニット２１０ａに設けられているノート・モジュール２１１、レコード・モジュール２１２、ヒアリング・モジュール２１３及びブック・モジュール２１４が提供する４つの特定機能を利用して、自己のアプリケーション２２０を開発することになる。他方、アプリケーション２２０が例えば、多職種従事者間の連携窓口として機能するコーディネーションを目的（用途）とするものである場合は、コミュニティ・ユニット２１０ｂを利用することが自動的に決定され、したがって、開発者Ｄはケア・ユニット２１０ｂに設けられているモジュール群（図示せず）が提供する複数の特定機能を利用して、自己のアプリケーション２２０を開発することになる。

　ユーザー登録と開発者登録とアプリケーション登録を完了した開発者Ｄが、アプリケーション・フレームワーク２００を利用して自身が開発したアプリケーション２２０（アプリケーション登録済み）をサービス構築支援システム１００（医療支援システム３０）にアップロードしたいと望む時は、その旨のリクエスト（アップロード要求）を同システム１００に送る。登録部１１１は、アップロード要求を受け取ると、その開発者Ｄの開発者端末１３に所定のアップロード画面（図示せず）を表示し、新規開発されたアプリケーション２２０をアップロードするよう促す。それに応じて、開発者端末１３から新アプリケーション２２０（アプリケーション構成ファイル）がサービス構築支援システム１００にアップロードされて来ると、登録部１１１は、新アプリケーション２２０（アプリケーション構成ファイル）を医療支援システム３０のアプリケーション保存部３３２に記憶すると共に、所定の処理を行って新アプリケーションを医療支援システム３０に組み込み（インストールし）、利用可能とする。こうして、新アプリケーション２２０のアップロード・組み込み処理が完了する。

　登録部１１１は、必要に応じて、アプリケーション情報記憶部１１２に記憶された「ユーザー情報」や「開発者情報」や「アプリケーション情報」を読み出して利用したり、修正・消去したりする等の動作も実行する。

　アプリケーション情報記憶部１１２は、ハードディスク等の情報記憶媒体と、その情報記憶媒体への情報の記録、再生、消去等の動作を制御するソフトウェアから形成され、上述した「ユーザー情報」、「開発者情報」及び「アプリケーション情報」と、他の必要な情報（アプリケーションの目的・用途など）を記憶する。

　上述した「ユーザー情報」、「開発者情報」及び「アプリケーション情報」の登録は、例えば、図１６（ａ）のユーザーテーブル、図１６（ｂ）の開発者テーブル、図１６（ｃ）の開発者所属組織テーブル、図１６（ｄ）のアプリケーションテーブルを用いて行われる。

　この場合、ユーザー登録時には、アプリケーション開発希望者に割り当てられたユーザーＩＤと共にパスワード等の関連情報が、図１６（ａ）に示すようにユーザーテーブルに記憶される。このユーザーテーブルは、開発者Ｄの情報が新たに追加されている以外は、図４（ａ）に示したものと同じである。

　開発者登録時には、アプリケーション開発希望者に割り当てられた開発者識別情報（開発者ＩＤ）及びその関連情報と、そのアプリケーション開発希望者が所属する組織に割り当てられた所属組織識別情報（所属組織ＩＤ）及びその関連情報が、図１６（ｂ）の開発者テーブルと図１６（ｃ）の開発者所属組織テーブルにそれぞれ記憶される。

　この場合、アプリケーション登録時には、アプリケーション２２０に割り当てられたアプリケーション識別情報（アプリケーションＩＤ）と、それを開発する開発者Ｄの開発者ＩＤと、そのアプリケーションを利用可能なグループＧのグループＩＤと、そのアプリケーションが登録された年月日（登録日）と、そのアプリケーションがどのグループＧにおいて利用可能状態にあるか否かを示す情報（ステータス情報）が、図１６（ｄ）のアプリケーションテーブルに記憶される。このステータス情報は、アプリケーション登録時にはアプリケーションの開発が完了していないため、「無効」として保存される。そして、アプリケーションがアップロード及びインストールされて医療支援システム３０で利用可能な状態になると、「無効」から「有効」に書き換えられる。

　アプリケーション登録については、各々のアプリケーションＩＤが複数のグループＩＤと関連付けて記憶されていることが重要である。すなわち、図１６（ｄ）のアプリケーションテーブルでは、アプリケーションＩＤが「１」のアプリケーション２２０（アプリケーション１）が２つのグループＩＤ「１０００３」及び「１０００４」に関連付けられ、アプリケーションＩＤが「２」のアプリケーション２２０（アプリケーション２）が２つのグループＩＤ「１０００３」及び「１０００５」に関連付けられている。これは、アプリケーション１は、グループＩＤ「１０００３」及び「１０００４」を持つ２つのグループＧにおいて有効（実行可能）であることを意味し、アプリケーション２は、グループＩＤ「１０００３」及び「１０００５」を持つ２つのグループＧにおいて有効（実行可能）であることを意味する。これをグループＩＤ「１０００３」のグループＧの側から見れば、２つのアプリケーション１及びアプリケーション２が同時に有効（実行可能）になっているということであり、言い換えれば、グループＩＤ「１０００３」のグループＧに属するグループ・メンバー（医療従事者Ｍ、患者Ｐ又は患者関係者Ｒ）は、アプリケーション１とアプリケーション２を選択的に利用可能であると共に、双方のアプリケーション１及び２を併行して利用することも可能ということである。したがって、グループＩＤ「１０００３」のグループＧに属するグループ・メンバーは、１つのユーザーＩＤで、アプリケーション１を利用した後にアプリケーション２を利用したり、アプリケーション２を利用した後にアプリケーション１を利用したりすることができる。アプリケーション１及び２の利用開始及び利用停止は、後述するように、そのグループＧのタイムライン上で利用開始または利用停止を指示するだけで可能なので、そのグループＧのグループ・メンバーは、利用するアプリケーションが変わる毎に医療支援システム３０へのログアウトとログインを繰り返す手間が不要であり、アプリケーションの開発とその利用への心理的障壁が低い、という利点がある。

　なお、図１６（ａ）に示すユーザーテーブルは、医療支援システム３０のアプリケーション保存部３３２に記憶されるが、これは図４（ａ）に示したユーザーテーブル（これは医療支援システム３０のユーザー情報記憶部３１２に記憶されている）のコピーである。両テーブルは同期していて、常に両テーブル内の情報が一致するようになっている。図１６（ｂ）に示す開発者テーブルと、図１６（ｃ）に示す開発者所属組織テーブルと、図１６（ｄ）に示すアプリケーションテーブルも、アプリケーション保存部３３２に記憶されている。

　また、この実施形態では、アプリケーション登録がユーザー登録及び開発者登録と同時に行われるようにしているが、本発明はこれには限定されない。アプリケーション登録をユーザー登録や開発者登録をする際には行わず、アプリケーション２２０が完成した後、アップロードされて医療支援システム３０に組み込まれる（インストールされる）段階で、アプリケーション登録を行うようにしてもよい。また、アプリケーション登録をした後に、アプリケーション２２０を利用できる（つまり登録されたアプリケーションＩＤに関連づけられたグループＩＤを持つ）グループＧを追加したり、削除したりすることも可能であることは言うまでもない。

　次に、ユニット管理部１２０について説明する。

　ユニット管理部１２０は、サービス構築支援システム１００に設けられたケア・ユニット２１０ａとコミュニティ・ユニット２１０ｂを管理するセクションである。例えば、両ユニット２１０ａ及び２１０ｂが持つ機能（ユニット機能）の制御やインターフェースの制御、両ユニット２１０ａ及び２１０ｂと開発者端末１３あるいはユーザー端末１０、１１又は１２との相互アクセスの制御等に加え、新たなユニットの新規登録やユニット２１０ａ又は２１０ｂの削除やその内容変更といった各種機能を実行する。このような機能を持つユニット管理部１２０は、登録部１２１と機能制御部１２２を備えている。

　登録部１２１は、その動作を制御するソフトウェアと、ハードディスク等の情報記憶手段から形成されており、新たなユニットを作成して追加登録したり、既存のユニット２１０ａ又は２１０ｂを削除したり、既存のユニット２１０ａ又は２１０ｂに係る登録情報を修正する等の処理を行う。登録されたユニット２１０ａ及び２１０ｂに係る情報は、登録部１２１の内部の記憶領域に記憶される。新たなユニットの新規登録の際には、登録部１２１は、ユニット情報、すなわち、そのユニットがどのようなジャンル（例えば、ケア、コミュニティ、副作用マネジメント等）に属し、どのような機能モジュールを持つか、といった情報を同記憶領域に記憶する。ユニットの総数の制限はないため、必要に応じて何個でも作成することができる。

　機能制御部１２２は、その動作を制御するソフトウェアから形成され、ケア・ユニット２１０ａ及びコミュニティ・ユニット２１０ｂに与えられた機能（ユニット機能）を制御する。具体的には、アプリケーション・フレームワーク２００内に設けられたユニット２１０ａ及び２１０ｂと、開発者端末１３あるいはユーザー端末１０、１１又は１２の間の相互アクセス制御等を行い、開発者端末１３あるいはユーザー端末１０、１１又は１２（アプリケーション２２０）からユニット２１０ａ又は２１０ｂが提供する特定機能を利用可能とする。

　次に、モジュール管理部１３０について説明する。ここでは、ケア・ユニット２１０ａの内部に設けられた４つの機能モジュール２１１，２１２，２１３，２１４についてのみ説明し、コミュニケーション・ユニット２１０ｂのそれについては省略する。

　モジュール管理部１３０は、ケア・ユニット２１０ａ及びコミュニティ・ユニット２１０ｂの各々の内部に設けられた機能モジュール群を管理するセクションである。モジュール管理部１３０は、ケア・ユニット２１０ａのノート・モジュール２１１、レコード・モジュール２１２、ヒアリング・モジュール２１３及びブック・モジュール２１４と、コミュニティ・ユニット２１０ｂのモジュール群（図示せず）の動作やそれらの利用状況を管理する。このような機能を持つモジュール管理部１３０は、ノート・モジュール制御部１３１と、レコード・モジュール制御部１３２と、ヒアリング・モジュール制御部１３３と、ブック・モジュール制御部１３４と、登録部１３５を備えている。

　ノート・モジュール制御部１３１は、アプリケーション・フレームワーク２００内のノート・モジュール２１１の動作を制御するソフトウェアから形成されている。ノート・モジュール制御部１３１は、アプリケーション開発時には、開発者端末１３からの要請に応じて、例えば、所定のノート・モジュール利用画面（図示せず）を開発者端末１３に表示したり、ノート・モジュール２１１に用意されている「必要に応じて所望の情報をノートに記録するように記録する」という機能を容易に利用できるように、例えば、記録すべき情報、記録すべきタイミング、記録すべき人、その情報のタイトル等を指定する画面（図示せず）を開発者端末１３に表示したりする。また、アプリケーション利用時には、ノート・モジュール２１１の機能が開発者端末１３で開発されたアプリケーション２２０に組み込まれるので、ノート・モジュール制御部１３１は、そのアプリケーション２２０の記述に沿って、例えば、指定されたタイミングで、記録すべき人のユーザー端末１０、１１又は１２の画面上で指定された情報を入力するよう促したり、こうして入力・記録された情報を、必要に応じて、指定された人のユーザー端末１０、１１又は１２の画面に表示したり、入力された情報を指定された場所（例えばアプリケ-ション保存部３３２）に記録（保存）したりする。

　レコード・モジュール制御部１３２は、アプリケーション・フレームワーク２００内のレコード・モジュール２１２の動作を制御するソフトウェアから形成されている。レコード・モジュール制御部１３２は、アプリケーション開発時には、開発者端末１３からの要請に応じて、例えば、所定のレコード・モジュール利用画面（図示せず）を開発者端末１３に表示したり、レコード・モジュール２１２に用意されている「必要とする外部情報（例えば検査情報）を所望のタイミングで自動収集して記録する」という機能を容易に利用できるように、例えば、自動収集・記録すべき情報、タイミング、情報源、保存先、そのタイトル等を指定する画面（図示せず）を、開発者端末１３に表示したりする。また、アプリケーション利用時には、ノート・モジュール２１１の機能が開発者端末１３で開発されたアプリケーション２２０に組み込まれるので、レコード・モジュール制御部１３２は、そのアプリケーション２２０の記述に沿って、例えば、指定された情報源から指定されたタイミングで指定された情報を自動収集して指定された場所（例えばアプリケーション保存部３３２）に記録（保存）したりする。

　ヒアリング・モジュール制御部１３３は、アプリケーション・フレームワーク２００内のヒアリング・モジュール２１３の動作を制御するソフトウェアから形成されている。ヒアリング・モジュール制御部１３３は、アプリケーション開発時には、開発者端末１３からの要請に応じて、例えば、所定のヒアリング・モジュール利用画面（図示せず）を開発者端末１３に表示したり、ヒアリング・モジュール２１３に用意されている「所定の対象者への一連の質問（例えば問診）を行う」という機能を容易に利用できるように、例えば、使用する質問テンプレートの指定や、その質問テンプレートに加えるべき修正の指定や、作成した質問とそのタイトルを表示すべき人の指定や、作成した質問に対する回答をすべき人や、回答様式等を指定する質問作成画面（図示せず）を、開発者端末１３に表示したりする。また、アプリケーション利用時には、ヒアリング・モジュール２１３の機能が開発者端末１３で開発されたアプリケーション２２０に組み込まれるので、ヒアリング・モジュール制御部１３３は、そのアプリケーション２２０の記述に沿って、例えば、作成された質問を指定された人のユーザー端末１０、１１又は１２の画面に表示したり、表示された質問に対して入力された回答を指定された場所（例えばアプリケーション保存部３３２）に記録（保存）したりする。

　ブック・モジュール制御部１３４は、アプリケーション・フレームワーク２００内のブック・モジュール２１４の動作を制御するソフトウェアから形成されている。ブック・モジュール制御部１３４は、アプリケーション開発時には、開発者端末１３からの要請に応じて、例えば、所定のブック・モジュール利用画面（図示せず）を開発者端末１３に表示したり、ブック・モジュール２１４に用意されている「種々の情報をファイル形式でコンテンツとして記憶する」という機能を容易に利用できるように、例えば、「コンテンツ」として保存すべきファイルとそのタイトルを指定するファイル指定画面を、どの人のユーザー端末１０、１１又は１２に表示するかを指定する画面を開発者端末１３に表示したりする。また、アプリケーション利用時には、ブック・モジュール２１４の機能が開発者端末１３で開発されたアプリケーション２２０に組み込まれるので、ブック・モジュール制御部１３４は、そのアプリケーション２２０の記述に沿って、例えば、所定のファイル指定画面を指定されたユーザー端末１０、１１又は１２に表示したり、そのファイル指定画面で指定されたファイルに含まれるコンテンツを、必要に応じて、指定されたユーザー端末１０、１１又は１２に表示したり、アップロードされたコンテンツファイルを指定された場所（例えばアプリケーション保存部３３２）に記録（保存）したりする。

　登録部１３５は、その動作を制御するソフトウェアと、ハードディスク等の情報記憶手段から形成されており、ユニット２１０ａ及び２１０ｂ毎に新たなモジュールを作成して追加登録したり、ユニット２１０ａに用意された４つの既存のモジュール１３１、１３２、１３３又は１３４やユニット２１０ｂに用意された既存のモジュール（図示せず）を削除したり、既存のモジュールに係る登録情報を修正する等の処理を行う。登録されたユニット２１０ａ内の既存モジュール２１１、２１２、２１３及び２１４とユニット２１０ｂ内の既存モジュールに係る情報は、登録部１３５の内部の記憶領域に記憶される。新たなモジュールの新規登録の際には、登録部１３５は、モジュール情報、すなわち、そのモジュールがどのような機能を持つか、どのような目的に使用されるか、といった情報を同記憶領域に記憶する。ユニット内に設けるモジュールの総数の制限はないため、必要に応じて何個でも作成することができる。

　フレームワーク管理部１４０は、アプリケーション管理部１１０、ユニット管理部１２０及びモジュール管理部１３０の動作を制御するソフトウェアと、ハードディスク等の情報記憶手段から形成されている。フレームワーク管理部１４０は、アプリケーション・フレームワーク２００の全体動作を管理しており、アプリケーション・フレームワーク２００の内部に設置されているアプリケーション管理部１１０とユニット管理部１２０とモジュール管理部１３０の連携に係る情報を保存し、それらの情報を用いてアプリケーション・フレームワーク２００としての所定の機能が発揮されるようにしている。

　（サービス構築支援システムの動作）
　次に、以上の構成を持つ本実施形態のサービス構築支援システム１００の動作について、図４８及び図４９のフローチャートを参照しながら説明する。

　（アプリケーション開発時）
　本実施形態では、アプリケーション・フレームワーク２００を利用して医療支援システム３０上で動作するアプリケーション２２０を開発したいと望む開発者Ｄ（アプリケーション開発希望者）は、自己の開発者端末１３から、インターネット２０を通じてサービス構築支援システム１００にアクセスし、その旨のリクエスト、すなわち「アプリケーション開発リクエスト」を同システム１００あてに送信するようになっている。したがって、図４８に示すように、サービス構築支援システム１００は、常に、開発者端末１３から送られるアプリケーション開発リクエストの受信を待機している（ステップＳ１）。

　サービス構築支援システム１００がアプリケーション開発リクエストを受信すると、アプリケーション管理部１１０の登録部１１１が、そのリクエストを送信した開発者Ｄの開発者端末１３に所定のユーザー登録画面（図示せず）を表示し、所定の個人情報を入力して医療支援システム３０のユーザー登録を先にするよう促す（ステップＳ２）。それに応じて、同開発者端末１３から所定の個人情報がサービス構築支援システム１００に送信されて来ると、その個人情報をその開発者Ｄに係る「ユーザー情報」及び「開発者情報」としてアプリケーション情報記憶部１１２に記憶する。こうして、ユーザー登録及び開発者登録が完了する（ステップＳ３）。ユーザー登録及び開発者登録で記憶される情報は、例えば、図１６（ａ）、（ｂ）及び（ｃ）のユーザーテーブル、開発者テーブル及び開発者所属組織テーブルに記載のとおりである。

　続いて、登録部１１１は、同開発者端末１３に所定のアプリケーション登録画面（図示せず）を表示し、所定のアプリケーション情報を入力してアプリケーション登録をするよう促す（ステップＳ４）。それに応じて、同開発者端末１３から所定のアプリケーション情報がサービス構築支援システム１００に送信されて来ると、そのアプリケーション情報をその開発者Ｄに係る「アプリケーション情報」としてアプリケーション情報記憶部１１２に記憶する。こうしてアプリケーション登録が完了する（ステップＳ５）。その後は、サービス構築支援システム１００は、開発が完了して新アプリケーション２２０のアップロード要求が同開発者端末１３から送られてくるのを待機する（ステップＳ６）。アプリケーション登録で記憶される情報は、例えば、図１６（ｄ）のアプリケーションテーブルに記載のとおりである。

　上記のようにしてユーザー登録及び開発者登録とアプリケーション登録が完了すると、アプリケーション・フレームワーク２００の機能を利用できるようになるので、上記開発者Ｄは、自己の開発者端末１３からアプリケーション・フレームワーク２００にアクセスし、開発しようとしているアプリケーション２２０が所属するジャンルに属するユニット、例えばケア・ユニット２１０ａの機能を利用して、新アプリケーション２２０を効率的に開発することができる。つまり、上記開発者Ｄは、ケア・ユニット２１０ａに用意されているノート・モジュール２１１、レコード・モジュール２１２、ヒアリング・モジュール２１３及びブック・モジュール２１４の機能を新アプリケーション２２０に適宜組み込むことで、それらモジュール２１１、２１２、２１３及び２１４が提供する機能に係わる記述を大幅に簡略化でき、したがって、その新アプリケーション２２０の開発を大きく効率的することができるのである。

　具体的に言うと、前記新アプリケーション２２０では、（ａ）その目的（例えば糖尿病服薬支援）を達成するために、４つのモジュール２１１、２１２、２１３及び２１４の特定機能をどのような順序でどのように組み合わせて所望の質問情報や提示情報を作成するか、そして、（ｂ）それらモジュール２１１、２１２、２１３及び２１４の特定機能を実施する際に、どのような情報を指定・追加するか（例えば質問に使用する薬品名とその摂取量や、収集・記録する検査項目、各項目に付けるタイトル等）、前記の情報の指定・追加を誰に依頼するか（例えばシステム管理者Ａか特定のユーザーか）、こうして作成した質問情報や提示情報をどのタイムラインにどのような順序・タイミングで投稿（表示）するか、といった点について記述することで、前記新アプリケーション２２０においてプログラミング言語を使って記述する箇所を大幅に減少させることができるのである。ここで、「質問情報」とは、特定のユーザーに対する何らかの質問を含む情報であり、「提示情報」とは、特定のユーザーに提示する何らかのメッセージ等の情報を含み、且つ質問を含まない情報である。

　ユーザー登録と開発者登録を完了した上記開発者Ｄが、アプリケーション・フレームワーク２００を利用して自身が開発した新アプリケーション２２０（アプリケーション登録済み）をアップロードしたいと望む時は、その旨の要求（アップロード要求）をサービス構築支援システム１００に送る必要がある。同システム１００がアップロード要求を受け取ると、登録部１１１は、同開発者Ｄの開発者端末１３に所定のアップロード画面（図示せず）を表示し、新アプリケーション２２０をアップロードするよう促す（ステップＳ７）。それに応じて、同開発者端末１３から新アプリケーション２２０のファイル（アプリケーション構成ファイル）がサービス構築支援システム１００にアップロードされて来ると、登録部１１１は、新アプリケーション２２０のデータを医療支援システム３０のアプリケーション保存部３３２に記憶すると共に、所定のインストール処理を行って新アプリケーションを医療支援システム３０に組み込んで、同システム３０上で利用可能とする（ステップＳ８）。こうして、新アプリケーション２２０のアップロード・組み込み処理が完了する。このようにして医療支援システム３０に組み込まれた新アプリケーション２２０は、当該新アプリケーション２２０が関連づけられた１又は複数のグループＧに属するグループ・メンバーであれば、必要な「管理者設定プロセス」及び「ユーザー設定プロセス」を実行して必要な初期設定を完了させた後に、自己のユーザー端末１０、１１又は１２からいつでも利用することが可能となる。

　なお、上記のようにして医療支援システム３０に組み込まれた新アプリケーション２２０が提供する新サービスは、医療支援システム３０内に同システム３０で提供される既存の医療サービスに対する付加的な医療サービス（付加サービス）として、また、オプションとして、医療支援システム３０に登録される。その後は、医療支援システム３０のユーザー（患者Ｐ、患者関係者Ｒ又は医療従事者Ｍ）は、いつでも、自己のユーザー端末１０、１１又は１２から、自己の希望に応じてその付加サービス（新サービス）を利用したり、利用を止めたりできるようになる。

　（アプリケーション利用時）
　図４８のステップＳ８において新アプリケーション２２０の医療支援システム３０への組み込み処理が完了すると、サービス構築支援システム１００のアプリケーション管理部１１０の登録部１１１は、図４９に示すように、医療支援システム３０のシステム管理者Ａの管理者端末１４（図１参照）に所定の初期設定画面（例えば図２３～図３５参照）を表示して、組み込まれた新アプリケーション２２０の初期設定を行うよう、システム管理者Ａに促す（ステップＳ１１）。これは、システム管理者Ａにより「管理者設定プロセス」で行われる新アプリケーション２２０の第１段階の初期設定である。それに応じて、システム管理者Ａが管理者端末１４で必要な設定をしたりして所定の「管理者設定プロセス」を実行すると、登録部１１１は、その設定内容に基づいて、新アプリケーション２２０に組み込まれた４つのモジュール２１１、２１２、２１３及び２１４に対する「管理者設定（管理者初期設定）」を行なう（ステップＳ１２）。さらに、登録部１１１は、所定のアプリケーション選択画面（例えば図１９、図２０、図２２参照）に新アプリケーション２２０を示すアイコン（新アプリケーション・アイコン）を追加する（ステップＳ１３）。その後は、登録部１１１は、ユーザー端末１０、１１又は１２による新アプリケーション・アイコンの選択、つまり、新アプリケーション２２０が提供する新サービスの利用要求が届くのを待機する（ステップＳ１４）。

　以上のようにして利用可能となった新アプリケーション２２０が提供する新サービスについての利用要求が、いずれかのユーザーから届くと、登録部１１１は、その新アプリケーション２２０で指定されたユーザー端末１０、１１又は１２に初期設定画面（例えば図４６～図４７参照）を表示し、組み込まれた新アプリケーション２２０の初期設定を行うよう、指定ユーザーに促す（ステップＳ１５）。これは、指定ユーザーにより「ユーザー設定プロセス」で行われる前記新アプリケーション２２０の第２段階の初期設定である。それに応じて、前記指定ユーザーが自己のユーザー端末１０、１１又は１２で、必要な情報を入力したり必要な設定をしたりして「ユーザー設定プロセス」を実行すると、登録部１１１は、その設定内容に基づいて、前記新アプリケーション２２０に組み込まれた４つのモジュール２１１、２１２、２１３及び２１４に対する「ユーザー設定（ユーザー初期設定）」を行なう（ステップＳ１６）。このようにして「管理者初期設定」及び「ユーザー初期設定」が完了すると、それらの設定内容に基づいて前記新アプリケーション２２０の実行が可能となるので、登録部１１１は、前記新アプリケーション２２０の実行を開始する。つまり、その新アプリケーション２２０が提供する新サービスの指定されたユーザーへの提供を開始するのである（ステップＳ１７）。

　こうして前記新アプリケーション２２０の実行（前記新サービスの提供）が開始されると、例えば、前記新サービスについての利用要求を送ったユーザーが所属するグループＧのタイムラインに、所定の質問情報や提示情報を投稿・表示したり、同タイムライン上で同グループＧの指定ユーザーにより投稿された回答情報を保存したり、といった一連の処理が、実行中の前記新アプリケーション２２０の指示するところに沿って順次、実行される。こうしてすべての処理が実行されると、前記新アプリケーション２２０は動作を終了する（ステップＳ１８）。以上のようにして、前記新サービス（付加サービス）は、前記新アプリケーション２２０の実行中に前記グループＧに属する指定ユーザーに対して提供される。

　例えば、前記新アプリケーション２２０により、前記グループＧのタイムラインに、所定の質問情報や提示情報が所定のスケジュールにしたがって順次投稿・表示され、指定されたユーザーとしての患者Ｐと患者関係者Ｒに所定の情報（例えば起こりうる合併症やその他症状、検査結果）を所望のタイミングで通知することができる。また、同タイムラインに投稿された質問情報（例えば気になる症状や食生活や残薬の確認）に対して、前記グループに係る患者Ｐ又は患者関係者Ｒが回答情報を提供すると、その回答情報は同タイムラインに投稿・表示されると同時に自動的に記憶されるので、同グループＧの医療従事者Ｍがその回答情報を確認することが可能となる。その結果、医療支援システム３０が提供している既存の医療サービスに対して、容易に種々の新サービス（例えば服薬支援サービス）を構築して付加的に提供することができ、しかも、それら新サービスにおいても同システム３０の特徴、すなわち、「医療サービスの対象者（患者）毎に生成されたグループに、前記医療サービスの１又は複数のユーザー（患者だけでなく医療従事者を含む）を選択的にグループ・メンバーとして所属させると共に、前記グループに係る前記対象者の医療情報を前記グループ・メンバーに限定して閲覧可能とすることで、前記対象者のプライバシーを確保しながら前記対象者に係る医療情報を前記グループ・メンバー間で共有できる」という特徴を活かすことが可能となる。

　（アプリケーションにより提供される新サービスの利用形態）
　次に、以上のようにして新アプリケーション２２０により提供される付加サービスの具体的な利用形態の一例について、図１７～図４７を参照しながら説明する。

　図１７は、サービス構築支援システム１００に新アプリケーション２２０を開発者端末１３からアップロードしてインストールし、使用可能となった状態で、医療支援システム３０が提示する「ホーム画面」のタイムラインの例を示す。この「ホーム画面」に表示されている複数のメッセージの中から、特定の患者Ｐ３（ここでは山本ＸＸさんで、糖尿病の治療を受けている）に対するメッセージを、患者Ｐ３（山本ＸＸさん）の主治医である医療従事者Ｍがクリックすると、患者Ｐ３の糖尿病治療グループＧ３１が選択され、その医療従事者Ｍの医療従事者端末１１に図１８に示すようなグループＧ３１Ｇのタイムライン（医療従事者側）が表示される。このタイムライン（医療従事者側）は、図９のグループＧ１１のタイムラインの医療従事者共有エリア５１ｂに対応し、患者Ｐ３の糖尿病治療グループＧ３１のグループ・メンバーである医療従事者Ｍだけが閲覧可能であり、患者Ｐ３やその患者関係者Ｒは閲覧できない。図１８の表示画面には、「オプション」ボタン（オプション起動ボタン）が表示されている。そこで、前記医療従事者Ｍが「オプション」ボタンをクリックすると、図１９に示すアプリケーション選択用のオプション選択画面（医療従事者側）か、図２０に示すリクエスト選択用のオプション選択画面（医療従事者側）が、同医療従事者端末１１に表示される。図１９のオプション選択画面は、同画面で「アプリ」タブを選択した場合に表示され、図２０のオプション選択画面は、「リクエスト」タブを選択することで表示される。

　患者Ｐ３の糖尿病治療グループＧ３１のグループ・メンバーである医療従事者Ｍは、図１９のオプション選択画面（医療従事者側）から、同画面に表示されている「生活習慣改善」、「服薬管理」、「糖尿病服薬支援」という３つの付加サービス（これらは該当するアプリケーション２２０が提供する）のうちの１つ又はそれ以上を選択して利用することができる。また、図２０のオプション選択画面（医療従事者側）から、同画面に表示されている「入院」、「退院」、「往診」、「連携」という４つの付加サービス（これらも該当するアプリケーション２２０が提供する）のうちの１つ又はそれ以上を選択して利用することができる。

　他方、図１７の「ホーム画面」で、患者Ｐ３に対するメッセージを、患者Ｐ３自身がクリックすると、患者Ｐ３の糖尿病治療グループＧ３１が選択され、山本さんの患者端末１０に図２１に示すような同グループＧ３１のタイムライン（患者側）が表示される。このタイムライン（患者側）は、図９のグループＧ１１のタイムラインの全員共有エリア５１ａに対応し、患者Ｐ３のグループＧ３１のグループ・メンバー全員（患者Ｐ３、患者関係者Ｒ及び医療従事者Ｍ）が閲覧可能である。この画面には、「アプリ」ボタン（アプリ起動ボタン）が表示されている。そこで、「アプリ」ボタンをクリックすると図２２に示すアプリケーション選択用のオプション選択画面（患者側）が、患者Ｐ３の患者端末１０に表示される。

　患者Ｐ３は、図２２のアプリケーション選択画面（患者側）から、同画面に表示されている「生活習慣改善」、「服薬管理」、「糖尿病服薬支援」という３つの付加サービス（これらは該当するアプリケーション２２０が提供する）のうちの１つ又はそれ以上を選択して利用することができる。なお、この画面は患者側に表示されたものであるから、医療従事者側の画面に表示されていた「入院」、「退院」、「往診」、「連携」という４つの付加サービスは表示されず、したがって、当然のことであるが、患者Ｐ３はこれらの付加サービスは利用することができない。

　患者Ｐ３のグループＧ３１のグループ・メンバーである患者関係者Ｒも、図２２のアプリケーション選択画面（患者側）から、同画面に表示されている「生活習慣改善」、「服薬管理」、「糖尿病服薬支援」という３つの付加サービスのうちの１つまたはそれ以上を選択して利用することができる。

　このように、アップロードされたすべてのアプリケーション２２０が、医療支援システム３０に組み込まれて一体化されることで、それらアプリケーション２２０により提供されるサービスは、適用される（利用可能とする）１又は複数のグループＧに関連づけてから医療支援システム３０内に「付加サービス」として登録される。このため、これらのアプリケーション２２０が利用可能とされている１又は複数のグループＧに属するユーザー（患者Ｐ、患者関係者Ｒ又は医療従事者Ｍ）は、自己の利用している医療サービスで紹介されている「付加サービス」の利用を希望する場合、自己のユーザー端末１０、１１又は１２に表示される該当する「付加サービス」のボタン（アイコン）を選択してクリックするだけで、その「付加サービス」の利用が可能となる。また、利用する付加サービスの切り替えや利用停止も、同様のアイコンをクリックするだけで容易に行える。

　よって、以上のような構成及び機能を持つサービス構築支援システム１００によれば、種々の付加サービスを提供するアプリケーション２２０を効率よく開発して医療支援システム３０に組み込むことができ、しかも、組み込んだ付加サービスを、医療従事者Ｍに適合する付加サービスと、患者Ｐや患者関係者Ｒに適合する付加サービスに分けて、個別に追加提供することが容易である。付加サービスを利用する側も、必要に応じて、自己のユーザー端末１０、１１又は１２上で、オプション選択画面やアプリケーション選択画面に表示される該当ボタンをクリックするだけで、自分の希望する付加サービスを選択的に利用したりその利用を止めたりできるので、非常に便利かつ効果的である。

　次に、上述したような、アプリケーション２２０により付加サービスをユーザーが利用可能な状態にするために必要な、上述した「管理者設定」と「ユーザー設定」について、図２３～図３６を参照しながら詳細に説明する。ここでは、一例として、患者Ｐ３（山本ＸＸさん）の糖尿病治療グループＧ３１において、「糖尿病服薬支援」という付加サービスを利用可能とする場合を採り上げることにする。これにより、ケア・ユニット２１０ａ内のノート・モジュール２１１、レコード・モジュール２１２、ヒアリング・モジュール２１３及びブック・モジュール２１４が、アプリケーション２２０内でどのように動作するか（つまりそれらモジュールの具体的利用形態）がいっそう明瞭になる。

　図２３は、サービス構築支援システム１００が組み込まれた医療支援システム３０に、「糖尿病服薬支援」という付加サービスを提供するアプリケ-ション２２０をインストールした場合に、医療支援システム３０のシステム管理者Ａが、「システム管理者用のアプリケーション管理画面」においてその基本情報を設定するための「管理者設定プロセス」を実行するときの表示例を示す。この「管理者設定プロセス」が実行されると、それに応じて、サービス構築支援システム１００の登録部１１１により「管理者初期設定（第１段階の初期設定）」が実行されるので、「管理者設定プロセス」で設定されたとおりに、アプリケ-ション２２０の第１段階の初期設定が完了する。

　図２３より明らかなように、システム管理者Ａにより、アプリケーション２２０の名称は「糖尿病服薬支援」に設定され、そのカテゴリは「服薬」に指定され、アプリケーション２２０において質問内容等の項目を設定する権限は前記システム管理者Ａと、患者Ｐ３（山本ＸＸさん）の主治医（医療従事者Ｍ）である小山医師と、小山医師が所属する医療関連施設Ｆに属しない外部の医療従事者（外部スタッフ）に与えられている。また、次の診察日が設定され、治療経過の要点を記載する経過サマリーの使用が設定され、当該アプリケーション２２の説明として、「服薬確認（１週間）」の機能が追加され、所定の検査項目の測定値を記録する「検査の記録」が有効化されている。さらに、当該アプリケーション２２の利用可能タイムラインとして、患者Ｐ３のグループＧ３１の患者側タイムラインが指定されていることから、この糖尿病服薬支援サービスを提供するために必要とされる情報、つまり「アプリケーション要素情報」は、グループＧ３１の患者側タイムラインに投稿されており、したがってグループＧ３１のグループ・メンバー全員が閲覧可能となっている。

　図２４は、「システム管理者用のアプリケーション管理画面」において、この糖尿病服薬支援サービスで使用可能な医薬品の設定を行うときの表示例を示す。同図では、患者Ｐ３が糖尿病治療のために摂取する７種の医薬品とその摂取量が設定されているが、これは糖尿病服薬支援アプリケーション２２０によって規定されている事項である。実際に摂取する医薬品は、時期に応じてこれらの医薬品の中から選定・変更することになる。（選定する医薬品の変更も、システム管理者Ａにより実行される「管理者設定プロセス」で行われる。）さらに、同アプリケーション２２０によって提供されている服薬時間通知用の「お薬アラーム」は、患者Ｐ３のグループＧ３１のタイムライン（患者側）に自動投稿されるように設定され、また、同アプリケーション２２０によって提供されている「お薬カレンダー」も、使用するように設定されている。

　図２５は、「システム管理者用のアプリケーション管理画面」において、追加機能の設定を行うときの表示例を示す。この例では、「合併症、その他症状」というタイトルのノート機能と、「気になる症状の確認」というタイトルのヒアリング機能と、「運動習慣の確認」というタイトルのヒアリング機能と、「食生活の確認」というタイトルのヒアリング機能と、「残薬の確認」というタイトルのヒアリング機能と、「糖尿病アドバイス（食事）」というタイトルのブック機能と、「糖尿病アドバイス（運動）」というタイトルのブック機能と、「糖尿病アドバイス（知識／リスク管理）」というタイトルのブック機能と、「相互作用の確認」というタイトルのヒアリング機能と、「服薬確認（１週間）」というタイトルのヒアリング機能と、「検査の記録」というタイトルのレコード機能という、合計１１個の機能が、糖尿病服薬支援アプリケーション２２０によって提供されている。これは、同アプリケーション２２０が、ノート・モジュール２１１、レコード・モジュール２１２，ヒアリング・モジュール２１３及びブック・モジュール２１４が提供するノート機能、レコード機能、ヒアリング機能及びブック機能という４つの特定機能を用いて作成されていることを示す。この例からは、これら４つの特定機能が当該アプリケーション２２０において実際にどのように利用されるかが明らかになる。

　図２５に示された１１個の機能は、糖尿病服薬支援アプリケーション２２０が提供する糖尿病服薬支援サービスで活用できるようにするために、システム管理者Ａによる第１段階の初期設定をすることが必要である。また、これらの機能の中には、システム管理者Ａによる第１段階の初期設定」に加えて、さらに指定されたユーザーによる第２段階の初期設定をすることが必要なものがある。

　まず、「合併症、その他症状」というノート機能では、システム管理者Ａによる第１段階の初期設定（管理者初期設定）は、（ａ）図２５のアプリケーション管理画面で当該機能を利用するように設定することと、（ｂ）図２９のアプリケーション管理画面で、ノートタイトルを例えば「患者ノート」に設定すると共に、その「患者ノート」に記録する事項（記録項目）を個別に指定することである。この２点を設定すれば、管理者初期設定は完了である。こうして管理者初期設定を完了した後にその設定内容を変更したい場合は、システム管理者Ａに「管理者設定プロセス」を再度実行してもらえば、そのような設定変更が可能となる。

　しかし、「合併症、その他症状」というノート機能では、糖尿病の合併症と糖尿病のその他症状をユーザーとしての医療従事者Ｍが入力して設定するというユーザー初期設定（第２段階の初期設定）がさらに必要である。このため、この場合には、管理者初期設定（第１段階の初期設定）によって、あるいは、当該アプリケーション２２０内での指定によって、特定された医療従事者Ｍの医療従事者端末１２で患者Ｐ３のグループＧ３１の医療従事者側タイムラインが表示され、そのタイムライン上に図４６に示すような情報入力画面が表示されるようになっている。そこで、その特定された医療従事者Ｍが、その情報入力画面上の記入欄に糖尿病の合併症と糖尿病のその他症状を入力して「送信する」ボタンをクリックすれば、ユーザー初期設定が完了する。こうして入力・送信された情報は、医療支援システム３０のアプリケ-ション保存部３３２に保存される。こうして管理者初期設定とユーザー初期設定が完了すると、「合併症、その他症状」というノート機能が当該アプリケーション２２０において利用可能となる。

　「気になる症状の確認」というタイトルのヒアリング機能については、管理者初期設定は、（ａ）図２５のアプリケーション管理画面で当該機能を利用するように設定すること、（ｂ）図２６のアプリケーション管理画面で、機能タイトルと通知スケジュールと補足説明の各項目を設定すると共に、提示する質問を登録すること、（ｃ）図２７のアプリケーション管理画面で、回答タイプ及び回答ルール、質問タイトル、回答項目、追加メッセージ及びその公開範囲を設定すること、（ｄ）図２８のアプリケーション管理画面で、回答タイプ及び回答ルール、質問タイトル、回答項目を設定することである。この４点を設定すれば、管理者初期設定は完了である。ユーザー初期設定は不要であるから、これにより、「気になる症状の確認」というヒアリング機能が当該アプリケーション２２０において利用可能となる。

　「運動習慣の確認」、「食生活の確認」及び「残薬の確認」というタイトルのヒアリング機能については、管理者初期設定は、（ａ）図２５のアプリケーション管理画面で当該機能を利用するように設定することのほか、（ｂ）図２７～図２９に近似したアプリケーション管理画面（図示せず）で、ヒアリングの内容（運動習慣、食生活、残薬）に応じて適宜、機能タイトルと通知スケジュールと補足説明の設定、質問の登録、回答タイプ及び回答ルールの設定、質問タイトルの設定、回答項目の設定等を行うことである。これらの設定等がすべて行われれば、管理者初期設定は完了である。ユーザー初期設定は不要であるから、これにより、これら３つのヒアリング機能が当該アプリケーション２２０において利用可能となる。

　「糖尿病アドバイス（食事）」というタイトルのブック機能については、管理者初期設定は、（ａ）図２５のアプリケーション管理画面で当該機能を利用するように設定すること、（ｂ）図３０のアプリケーション管理画面で、ブックタイトルの設定と送信するアドバイス（コンテンツ）の選択（指定）及び必要な修正を行うことである。この２点を設定すれば、管理者初期設定は完了である。

　「糖尿病アドバイス（食事）」というタイトルのブック機能については、管理者初期設定に加えて、アドバイス（コンテンツ）を記述したファイル（これは所定フォーマットに沿って作成されている）を医療従事者Ｍがアップロードする、というユーザー初期設定がさらに必要である。この場合、システム管理者Ａの指定によって、あるいは、当該アプリケーション２２０内での指定によって特定された医療従事者Ｍの医療従事者端末１２において、患者Ｐ３のグループＧ３１の医療従事者側タイムラインが表示され、そのタイムライン上に図４７に示すようなファイルアップロード画面が表示される。そこで、その指定された医療従事者Ｍがその画面上で、ブックタイトルを入力し、さらにアドバイス（コンテンツ）を記述したファイルをアップロードすれば、ユーザー初期設定が完了する。これにより、「糖尿病アドバイス（食事）」というブック機能は、当該アプリケーション２２０において利用可能となる。

　「糖尿病アドバイス（運動）」及び「糖尿病アドバイス（知識／リスク管理）」というタイトルのブック機能については、管理者初期設定は、（ａ）図２５のアプリケーション管理画面で当該機能を利用するように設定すること、（ｂ）図３０と同様のアプリケーション管理画面で、ブックの内容（運動、知識／リスク管理）に応じて適宜、ブックタイトルの設定と送信するアドバイス（コンテンツ）の選択（指定）及び必要な修正を行うことである。この２点を設定すれば、管理者初期設定は完了である。

　「糖尿病アドバイス（運動）」及び「糖尿病アドバイス（知識／リスク管理）」というタイトルのブック機能については、上述した管理者初期設定に加えて、「糖尿病アドバイス（食事）」のブック機能と同様に、アドバイス（コンテンツ）を記述したファイル（これは所定フォーマットに沿って作成されている）を医療従事者Ｍがアップロードするというユーザー初期設定が必要である。この場合、患者Ｐ３のグループＧ３１の医療従事者側タイムラインに、図４７と同じファイルアップロード画面が表示される。そこで、その特定された医療従事者Ｍがその画面上で、ブックの内容（運動、知識／リスク管理）に応じて適宜、アドバイス（コンテンツ）を記述したファイルをアップロードすれば、ユーザー初期設定が完了する。これにより、これら２つのブック機能は、当該アプリケーション２２０において利用可能となる。

　「検査の記録」というタイトルのレコード機能については、管理者初期設定は、（ａ）図２５のアプリケーション管理画面で当該機能を利用するように設定すること、（ｂ）図３１のアプリケーション管理画面で、レコードタイトルの設定と記録する検査項目の選択（指定）を行うことである。この２点を設定すれば、管理者初期設定は完了である。ユーザー初期設定は不要であるから、これにより、このレコード機能が当該アプリケーション２２０において利用可能となる。なお、検査情報の情報源の指定は、他のアプリケーション管理画面（図示せず）にて行われる。

　図３２及び図３３は、当該アプリケーション２２０の設定変更について、システム管理者Ａが作成した「新しい設定のお知らせ」の一例を示している。この「新しい設定のお知らせ」は、管理者初期設定によって、または管理者初期設定及びユーザー初期設定によって行われた当該アプリケーション２２０中の上記機能群の初期設定、あるいは、その初期設定からの設定変更、あるいは、その設定変更での設定からのさらなる設定変更を、患者Ｐ３のグループＧ３１のグループ・メンバー全員に知らせるために、当該グループ・メンバー全員が閲覧できるグループＧ３１のタイムライン（患者側）に投稿される。この「新しい設定のお知らせ」は、図３２及び図３３から分かるように、当該アプリケーション２２０が提供する「糖尿病服薬支援」という新サービスについて、（ａ）利用期間が２０１７年１２月１日から任意の終了日までであること、（ｂ）当該新サービスにおいて情報を記録（入力）したり質問に回答したりする権限（記録・回答権限）が、患者本人（患者Ｐ）、患者家族・友人（患者関係者Ｒ）及び医療・介護職（医療従事者Ｍと介護従事者）にあること、（ｃ）使用する薬とその服薬時刻の指定及び検査値の表示、（ｄ）患者ノート上に所定の検査の測定値が記録されること、（ｅ）通知スケジュールに記載される合併症、その他症状の公開範囲が山本さんのグループＧのグループ・メンバー全員であること、そして、（ｆ）気になる症状の確認と検査の記録と残薬の確認を行う日時が指定（変更）されたことを、通知するものである。

　図３４は、図３２に示した「新しい設定のお知らせ」の中の「検査値」欄に入力される各検査項目の値を設定するための、「システム管理者用のアプリケーション管理画面」である。「管理者設定プロセス」を実行する際に、システム管理者Ａは、この画面上で、ＨｂＡ１ｃ、体重、ＬＤＬコレステロールという３つの検査項目に関する初期値、目標値、基準値上限、基準値下限を入力・設定し、さらに、これらの検査値を患者にもアラートする（警告する）かどうかを設定することができる。これは管理者初期設定に該当する。

　図３５は、図３２に示した「新しい設定のお知らせ」の中の「利用期間」欄に入力される当該サービスの利用開始日を設定するための、「システム管理者用のアプリケーション管理画面」である。「管理者設定プロセス」を実行する際に、システム管理者Ａは、この画面上で当該サービスの利用開始日を設定することができる。これも管理者初期設定に該当する。

　図３６は、医療支援システム３０にインストールされたアプリケ-ション２２０群のアイコンリストを示す「システム管理者用のアプリケーション管理画面」である。システム管理者Ａは、上述した糖尿病服薬支援アプリケーション２２０だけでなく、それ以外の希望するアプリケーション２２０も任意に選択して個別に管理できることが分かる。システム管理者Ａは、医療支援システム３０でどのようなアプリケーション２２０を利用可能とするかを、この画面から管理することが可能である。

　図３７～図４５は、上述した糖尿病服薬支援アプリケーション２２０が提供する糖尿病服薬支援サービスを受ける際に、患者Ｐ３の糖尿病治療グループＧ３１のタイムライン（患者側）に表示される画面の例を示す。

　図３７は、上述した糖尿病服薬支援サービスの利用開始を伝えるメッセージ（提示情報）が、患者Ｐ３の糖尿病治療グループＧ３１のタイムライン（患者側）に投稿（表示）された状態を示す画面である。このメッセージは、医療支援システム３０のメッセージ投稿機能を利用して実現されている。図３７から分かるように、このグループＧ３１に属するグループ・メンバーは、患者Ｐ３本人、患者Ｐ３の主治医（医療従事者Ｍ）、そして、患者Ｐ３の家族（患者関係者Ｒ）の合計３名であり、全員がそのメッセージを閲覧可能となっている。これは、図１６（ｄ）に示すアプリケーションテーブルに示すように、上述した糖尿病服薬支援アプリケーション２２０（アプリケーションＩＤ＝１）が、患者Ｐ３の糖尿病治療グループＧ（グループＩＤ＝１０００３）と関連付けられているからであり、また、図２３の「システム管理者用のアプリケーション管理画面」に示すように、「利用範囲設定」の項目で「患者側タイムライン」が選択されているからである。

　図３７の糖尿病服薬支援サービス利用開始メッセージには、「患者ノート」の項目に「合併症、その他症状」の文字と「確認する。」の文字が表示されており、「確認する。」の文字をクリックすると、「合併症、その他症状」の内容が別ウィンドウで表示されるので、患者Ｐ３本人と患者Ｐ３の家族（患者関係者Ｒ）は、それを読み取ることによって容易に合併症やその他症状を確認できるようになっている。図３８は、その「合併症、その他症状」の内容が、患者Ｐ３のグループＧ３１のタイムラインに投稿された状態を示す。このようにタイムライン上でも読むことができる。これらは、「合併症、その他症状」というタイトルの上記ノート機能（図２５参照）を用いて実現されている。該当する症状がある場合は、図３８の画面から担当の医療従事者Ｍに返信（回答）することができる。その返信に使用される回答画面の例を図４２に示す。この回答画面において、２つのラジオボタンのいずれか一方を選択し、メッセージ入力欄に適当なメッセージを記入すればよい。

　図３７のサービス利用開始メッセージの「お薬の用法・用量」の項目には、図２４の「システム管理者用のアプリケーション管理画面」で指定した医薬品とその用法が反映されている。

　図３７のサービス利用開始メッセージの「検査値」の項目には、図３１の「システム管理者用のアプリケーション管理画面」で指定した検査の記録項目が反映されている。

　図３９は、上述した糖尿病服薬支援サービスにおいて、「気になる症状の確認」及び「食生活の確認」という２つの質問メッセージが、患者Ｐ３のグループＧ３１のタイムライン（患者側）に投稿された状態を示す。これらの質問メッセージは、上述した「気になる症状の確認」及び「食生活の確認」という２つのヒアリング機能と、医療支援システム３０のメッセージ投稿機能を利用して実現されている。同図から分かるように、各々の質問メッセージ上に表示された「回答する」ボタンをクリックすることで、患者Ｐ３又はその家族（患者関係者Ｒ）がそれらの質問に回答することができる。「気になる症状の確認」という質問に対する回答に使用される回答画面の例を図４３に示す。この回答画面は記述式になっており、メッセージ入力欄に適当なメッセージを記入でき、ファイルのアップロードも可能である。また、「食生活の確認」という質問に対する回答に使用される回答画面の例を図４４に示す。この回答画面は４個の選択肢から１個を選ぶ多肢選択式になっている。

　図４０は、上述した糖尿病服薬支援サービスにおいて、「残薬の確認」及び「運動週間の確認」という２つの質問メッセージが、患者Ｐ３のグループＧ３１のタイムライン（患者側）に投稿された状態を示す画面である。これらの質問メッセージは、上述した「残薬の確認」及び「運動週間の確認」という２つのヒアリング機能と、医療支援システム３０のメッセージ投稿機能を利用して実現されている。同図から分かるように、各々の質問メッセージ上に表示された「回答する」ボタンをクリックすることで、患者Ｐ３又はその家族（患者関係者Ｒ）がそれらの質問に回答することができる。「残薬の確認」という質問に対する回答に使用される回答画面の例を図４５に示す。この回答画面は記述式になっており、メッセージ入力欄に適当なメッセージを記入でき、ファイルのアップロードも可能である。

　図４１は、上述した糖尿病服薬支援サービスにおいて、「食事上の注意」という提示メッセージと、「服薬確認」という質問メッセージが、患者Ｐ３のグループＧ３１のタイムライン（患者側）に投稿された状態を示す画面である。「食事上の注意」のメッセージは、上述した「糖尿病アドバイス（食事）」というブック機能と、医療支援システム３０のメッセージ投稿機能を利用して実現されている。「服薬確認」という質問メッセージは、上述した「服薬確認」というヒアリング機能と、医療支援システム３０のメッセージ投稿機能を利用して実現されている。同図から分かるように、「服薬確認」の質問メッセージ上に表示された「回答する」ボタンをクリックすることで、患者Ｐ３又はその家族（患者関係者Ｒ）がその質問に回答することができる。

　（サービス構築支援システムにより得られる利点）
　以上詳細に説明したように、本発明の一実施形態に係るサービス構築支援システム１００では、フレームワーク管理部１４０により、医療支援システム３０上に上述した４つの特定機能（４つのモジュール２１１、２１２、２１３及び２１４が提供する機能）を提供するアプリケーション・フレームワーク２００を設けて、種々の新サービス（例えば糖尿病服薬支援）を提供するアプリケーション２２０をアプリケーション・フレームワーク２００を利用して開発できるようにしている。また、アプリケーション・フレームワーク２００を利用して開発され且つ同フレームワーク２００が提供する前記特定機能が搭載されたアプリケーション２２０（例えば糖尿病服薬支援用アプリケーション）を、医療支援システム３０に組み込む際には、当該アプリケーション２２０に対して固有のアプリケーションＩＤを割り当てると共に、当該アプリケーションＩＤを１又は複数のグループＩＤに関連づけて記憶し、それによって当該アプリケーション２２０により提供される「糖尿病服薬支援」という新サービスを、当該アプリケーションＩＤが関連づけられた１又は複数のグループＩＤを持つ１又は複数のグループＧに所属するグループ・メンバーに限定して、彼らのユーザー端末１０、１１又は１２を介して利用可能としている。よって、アプリケーション２２０を医療支援システム３０に組み込むことで、同システム３０が提供している医療サービスに容易に種々の新サービスを付加することができる。

　また、アプリケーション・フレームワーク２００を利用して開発され且つ前記特定機能が搭載されたアプリケーション２２０を、医療支援システム３０に組み込む際には、アプリケーション管理部１１０により、当該アプリケーション２２０に対してアプリケーションＩＤを割り当てると共に、当該アプリケーションＩＤを１又は複数のグループＩＤに関連づけて記憶し、それによって当該アプリケーション２２０により提供される新サービスを、当該アプリケーションＩＤが関連づけられた１又は複数のグループＩＤを持つ１又は複数のグループＧに所属するグループ・メンバーに限定して、彼らのユーザー端末１０、１１又は１２を介して利用可能としている。このため、「医療・介護サービスの対象者（患者又は要介護者）毎に生成されたグループＧに、医療サービスの１又は複数のユーザー（患者Ｐだけでなく医療従事者Ｍを含む）を選択的にグループ・メンバーとして所属させると共に、前記グループＧに係る前記対象者の医療情報を前記グループ・メンバーに限定して閲覧可能とすることで、前記対象者のプライバシーを確保しながら前記対象者に係る医療情報を前記グループ・メンバー間で共有できる」という医療支援システム３０の特徴を活かすことが可能である。

　さらに、医療支援システム３０上にアプリケーション・フレームワーク２００を設けて、種々のアプリケーション２２０をアプリケーション・フレームワーク２００を利用して開発できるようにしているため、医療支援システム３０上で動作し且つ同システム３０の上記特徴を活かすことが可能なアプリケーション２２０を効率的に開発することができる。しかも、前記アプリケーション２２０は、当該アプリケーション２２０に搭載された前記４つの特定機能が、システム管理者Ａが「管理者設定」を実行することで、また必要に応じて「ユーザー設定」をさらに実行することで、医療支援システム３０上において利用可能となるように構成されると共に、前記「管理者設定」及び前記「ユーザー設定」では、当該アプリケーション２２０が持つアプリケーションＩＤが関連づけられた１又は複数のグループＧに係る患者Ｐ、あるいは、当該グループＧに係る医療従事者Ｍの必要に応じて、前記特定機能の細部（実施条件）が設定されるように構成されているため、医療支援システム３０に組み込まれた後に前記アプリケーション２２０が提供する新サービスの内容を、前記医療サービスの対象者である患者Ｐ、あるいは同医療サービスを提供する医療従事者Ｍの必要に応じて、細かく調整することが可能である。

　さらに、アプリケーション２２０を医療支援システム３０に組み込む際には、アプリケーション管理部１１０により、当該アプリケーション２２０に対して固有のアプリケーションＩＤを割り当てると共に、当該アプリケーションＩＤを１又は複数のグループＩＤに関連づけて記憶し、それによって当該アプリケーション２２０により提供される新サービスを、当該アプリケーションＩＤが関連づけられた１又は複数のグループＩＤを持つ１又は複数のグループＧに所属するグループ・メンバーに限定して、当該グループ・メンバーのユーザー端末１０、１１又は１２を介して利用可能としている。このため、前記医療サービスの対象者（患者Ｐ）毎に生成されたグループＧのグループ・メンバーが、アプリケーション２２０により提供される新サービスの利用の開始及び停止を、必要に応じてダイナミックに調整することができる。

　さらに、グループＧの各々に所属するグループ・メンバーは、当該グループＧが持つグループＩＤに関連づけられた複数のアプリケーションＩＤを持つ複数のアプリケーション２２０が提供する複数の新サービスを、必要に応じて自己のユーザー端末１０、１１又は１２上で指示することにより選択的に利用可能であるため、前記医療サービスの対象者（患者Ｐ）毎に生成されたグループＧのグループ・メンバーが、前記アプリケーション・プログラムにより提供される複数の新サービスを必要に応じて選択的に利用する際に、医療支援システム３０へのログイン及びログアウトという煩わしい操作を繰り返す必要がない。

　さらに、アプリケーション２２０により提供される新サービスを利用することで、当該アプリケーション２２０が持つアプリケーションＩＤが関連づけられた１又は複数のグループＧに係るグループ・メンバーに提供される情報（アプリケーション関連情報）を、当該１又は複数のグループＧに係る患者Ｐの医療情報と共に閲覧可能であるため、前記アプリケーション関連情報と前記医療情報とが別個に存在していたときには気づかなかったことに気づくことが多くなる。つまり、前記アプリケーション２２０により提供される新サービスが既存の医療サービスに加わることで、相乗効果が引き起こされることが多くなる。その結果、前記新サービスと既存の医療サービスが別個に提供される場合よりも高い効果が期待できる。

　（変形例）
　上述した実施形態は本発明を具体化した例を示すものである。したがって、本発明はこの実施形態に限定されるものではなく、本発明の趣旨を外れることなく種々の変形が可能であることは言うまでもない。

　例えば、上述した実施形態では、１つのユニット内にノート・モジュール２１１、レコード・モジュール２１２、ヒアリング・モジュール２１３及びブック・モジュール２１４という４つの機能モジュールを設けた例を示しているが、本発明はこれに限定されない。これら以外の機能モジュールを追加して設けてもよいし、これらモジュールのいくつかを削除してもよいことは言うまでもない。１つのユニット内に設けられる機能モジュールの総数に制限はない。また、各機能モジュールが提供する特定機能も、必要に応じて適宜変更することが可能である。

　また、上述した実施形態では、医療支援システム３０が提供する医療サービスに対して、アプリケーション２２０を用いて新たに付加的な医療サービスを提供する場合について述べているが、本発明はこれに限定されない。アプリケーション２２０を用いて新たに付加的な介護サービスを提供するようにしてもよい。また、介護支援システムが提供する介護サービスに対して、アプリケーションを用いて新たに付加的な介護サービスや医療サービスを提供する場合にも、本発明は適用可能である。さらに、医療・介護支援システムが提供する医療サービス及び介護サービスに対して、アプリケーション２２０を用いて新たに付加的な医療サービス及び／又は介護サービスを提供する場合にも、本発明は適用可能である。

　本発明を要介護者に対して介護サービスを提供する介護支援システムや、患者又は要介護者に対して医療サービス及び介護サービスの双方を提供する医療・介護支援システムに適用する場合、上述した実施形態において、患者Ｐが要介護者と、患者関係者Ｒが要介護者関係者と、医療従事者Ｍが介護従事者と、医療関連施設Ｆが介護関連施設とそれぞれ読み替えられる。要介護者は、いずれかの介護関連施設に所属する介護従事者Ｍから、訪問又は施設内介護、入浴介護、リハビリ等の介護サービスを受けている人を言う。介護従事者とは、介護福祉士、ケアマネージャー、ヘルパー等、何らかの介護事業に従事している人を言う。介護関連施設としては、特別養護老人ホーム、介護付有料老人ホーム等、種々の種類や規模の施設がある。これらの場合においても、上述した本発明の効果が得られることは明らかである。

　本発明は、患者に対して医療サービスを提供する医療支援システムや、要介護者に対して介護サービスを提供する介護支援システム、さらには、患者又は要介護者に対して医療サービス及び介護サービスの双方を提供する医療・介護支援システムにも適用が可能である。本発明は、これらのシステムが提供している医療サービス及び／又は介護サービスに対し、必要に応じて種々の新サービスを付加することが望まれる分野に広く適用可能である。

１０　患者端末
１１　医療者端末
１２　患者関係者端末
１３　開発者端末
１４　管理者端末
２０　インターネット
３０　医療支援システム
５１　タイムライン
５１ａ　全員共有エリア
５１ｂ　医療従事者共有エリア
１００　サービス構築支援システム
１１０　アプリケーション管理部
１１１　登録部
１１２　アプリケーション情報記憶部
１２０　ユニット管理部
１２１　登録部
１２２　機能制御部
１３０　モジュール管理部
１３１　ノート・モジュール制御部
１３２　レコード・モジュール制御部
１３３　ヒアリング・モジュール制御部
１３４　ブック・モジュール制御部
１３５　登録部
１４０　フレームワーク管理部
２００　アプリケーション・フレームワーク
２１０ａ　ケア・ユニット
２１０ｂ　コミュニティ・ユニット
２１１　ノート・モジュール
２１２　レコード・モジュール
２１３　ヒアリング・モジュール
２１４　ブック・モジュール
２１５　基本機能部
２２０　アプリケーション
３１０　ユーザー管理部
３１１　登録部
３１２　ユーザー情報記憶部
３１３　患者情報記憶部
３１４　医療従事者情報記憶部
３１５　医療関連施設情報記憶部
３１６　疾患情報記憶部
３２０　グループ管理部
３２１　登録部
３２２　グループ情報記憶部
３２３　グループ・メンバー情報記憶部
３２４　招待リクエスト制御部
３２５　招待リクエスト情報記憶部
３２６　タイムライン制御部
３２７　メッセージ制御部
３２８　かかりつけ施設情報記憶部
３２９　共有同意情報記憶部
３３０　患者実在性検証部
３３１　認証部
３３２　アプリケーション保存部
３４０　認証部
３５０　通信制御部
Ｆ　医療関連施設
Ｆ１　クリニック
Ｆ２　クリニック
Ｆ３　病院
Ｆ４　訪問看護ステーション
Ｇ　グループ
Ｇ１１　患者Ｐ１の糖尿病治療用グループ
Ｇ１２　患者Ｐ１の高脂血症治療用グループ
Ｇ１３　患者Ｐ１の痛風治療用グループ
Ｇ２１　患者Ｐ２のアルツハイマー治療用グループ
Ｇ２２　患者Ｐ２の高血圧治療用グループ
Ｇ３１　患者Ｐ３の糖尿病治療用グループ
Ｍ　医療従事者
Ｍ１、Ｍ２、Ｍ３、Ｍ４、Ｍ５、Ｍ６、Ｍ７、Ｍ８　医療従事者
Ｐ　患者
Ｐ１、Ｐ２、Ｐ３　患者
Ｒ　患者関係者
Ｒ１、Ｒ２、Ｒ３、Ｒ４、Ｒ５、Ｒ６、Ｒ７、Ｒ８　患者関係者
Ａ　システム管理者
Ｄ　開発者

Claims (12)

1. 　ユーザー端末からの要求に応じて、通信ネットワークを介して患者又は要介護者に係る医療・介護情報を前記ユーザー端末で閲覧可能にすることで、前記患者又は前記要介護者への医療・介護サービスの提供を支援する医療・介護支援システムにおいて、新サービスを構築するのを支援する方法であって、
   　前記ユーザー端末を介して前記医療・介護サービスを利用するユーザーに対して、ユーザー識別情報を割り当てて記憶し、
   　前記ユーザーとしての前記患者又は前記要介護者に対してサービス受給者識別情報を割り当てると共に、当該サービス受給者識別情報を前記ユーザー識別情報に関連づけて記憶し、
   　前記ユーザーとしての医療従事者又は介護従事者に対して事業従事者識別情報を割り当てると共に、当該事業従事者識別情報を前記ユーザー識別情報に関連づけて記憶し、
   　前記ユーザー端末からの指示に応じて、前記サービス受給者識別情報に関連させて固有のグループ識別情報を持つグループを生成し、
   　前記ユーザー端末からの指示に応じて、前記グループに１又は複数の前記ユーザーを選択的にグループ・メンバーとして所属させることで、前記グループに係る前記サービス受給者識別情報に対応する前記患者又は前記要介護者の医療・介護情報を、前記ユーザー端末を介して前記グループ・メンバーの間で共有可能とし、
   　１又は複数の特定機能を提供するアプリケーション・フレームワークを前記医療・介護支援システム上に設けて、新サービスを提供するアプリケーション・プログラムを開発者端末から前記アプリケーション・フレームワークを利用して開発できるようにし、
   　前記アプリケーション・フレームワークを利用して開発され且つ前記１又は複数の特定機能が搭載されたアプリケーション・プログラムを、前記医療・介護支援システムに組み込む際には、当該アプリケーション・プログラムに対して固有のアプリケーション識別情報を割り当てると共に、当該アプリケーション識別情報を１又は複数の前記グループ識別情報に関連づけて記憶し、それによって当該アプリケーション・プログラムにより提供される１又は複数の新サービスを、当該アプリケーション識別情報が関連づけられた前記１又は複数のグループ識別情報を持つ前記１又は複数のグループに所属する前記グループ・メンバーに限定して、前記ユーザー端末を介して利用可能とし、
   　前記アプリケーション・プログラムは、当該アプリケーション・プログラムに搭載された前記１又は複数の特定機能が、所定の管理者が所定の管理者設定を実行することで前記医療・介護支援システム上で利用可能となるように構成されると共に、前記管理者設定では、当該アプリケーション・プログラムが持つ前記アプリケーション識別情報が関連づけられた前記１又は複数のグループに係る前記患者又は前記要介護者、あるいは、当該グループに係る前記医療従事者又は前記介護従事者の必要に応じて、前記１又は複数の特定機能が設定されるように構成され、
   　前記グループの各々に所属する前記グループ・メンバーは、当該グループが持つ前記グループ識別情報に関連づけられた複数の前記アプリケーション識別情報を持つ複数のアプリケーション・プログラムが提供する複数の新サービスを、必要に応じて前記ユーザー端末上で指示することにより選択的に利用可能であることを特徴とする、医療・介護支援システムにおけるサービス構築支援方法。
2. 　前記アプリケーション・プログラムは、前記管理者設定に加えて、必要なユーザー設定を実行することで前記医療・介護支援システム上で利用可能となるように構成され、
   　前記ユーザー設定は、当該アプリケーション・プログラムが持つ前記アプリケ-ション識別情報が関連づけられた前記１又は複数のグループに係る前記ユーザーのいずれかが実行するように構成されている請求項１に記載のサービス構築支援方法。
3. 　前記アプリケーション・プログラムは、当該アプリケーション・プログラムの目的を達成するために必要な、前記アプリケーション・フレームワークが提供する前記１又は複数の特定機能の組み合わせを記述したものとされている請求項１または２に記載のサービス構築支援方法。
4. 　前記グループの各々に関連づけられた前記１または複数のアプリケーション・プログラムは、当該アプリケーション・プログラムが提供する前記新サービスのために必要なサービス要素情報を、前記ユーザー端末上において、所定のスケジュールに沿って、当該グループに係る前記患者または前記要介護者の前記医療・介護情報が閲覧可能なタイムラインに順に表示し、
   　前記サービス要素情報に応答する必要がある場合には、応答情報を前記ユーザー端末から前記タイムラインに表示するか、前記医療・介護システムに送信することで応答するように構成されている請求項１～３のいずれかに記載のサービス構築支援方法。
5. 　前記アプリケーション・フレームワークが、前記１又は複数の特定機能を実現する手段として、所定の都度情報を記憶する機能を提供する第１モジュールと、所定の外部情報を収集して記憶する機能を提供する第２モジュールと、質疑応答の機能を提供する第３モジュールと、コンテンツ情報を記憶する機能を提供する第４モジュールとを備えている請求項１～４のいずれかに記載のサービス構築支援方法。
6. 　前記アプリケーション・フレームワークが目的の異なる複数のユニットを含んでおり、前記１又は複数の特定機能が前記複数のユニットの各々に設けられている請求項１～５のいずれかに記載のサービス構築支援方法。
7. 　ユーザー端末からの要求に応じて、通信ネットワークを介して患者又は要介護者に係る医療・介護情報を前記ユーザー端末で閲覧可能にすることで、前記患者又は前記要介護者への医療・介護サービスの提供を支援する医療・介護支援システムにおいて、新サービスを構築するのを支援するシステムであって、
   　前記ユーザー端末を介して前記医療・介護サービスを利用するユーザーに対して、ユーザー識別情報を割り当てて記憶するユーザー識別情報記憶手段と、
   　前記ユーザーとしての前記患者又は前記要介護者に対してサービス受給者識別情報を割り当てると共に、当該サービス受給者識別情報を前記ユーザー識別情報に関連づけて記憶するサービス受給者識別情報記憶手段と、
   　前記ユーザーとしての医療従事者又は介護従事者に対して事業従事者識別情報を割り当てると共に、当該事業従事者識別情報を前記ユーザー識別情報に関連づけて記憶する事業従事者識別情報記憶手段と、
   　前記ユーザー端末からの指示に応じて、前記サービス受給者識別情報に関連させて固有のグループ識別情報を持つグループを生成するグループ管理手段と、
   　前記ユーザー端末からの指示に応じて、前記グループに１又は複数の前記ユーザーを選択的にグループ・メンバーとして所属させることで、前記グループに係る前記サービス受給者識別情報に対応する前記患者又は前記要介護者の医療・介護情報を、前記ユーザー端末を介して前記グループ・メンバーの間で共有可能とするグループ・メンバー選定手段と、
   　１又は複数の特定機能を提供するアプリケーション・フレームワークを前記医療・介護支援システム上に設けて、新サービスを提供するアプリケーション・プログラムを開発者端末から前記アプリケーション・フレームワークを利用して開発できるようにするフレームワーク管理手段と、
   　前記アプリケーション・フレームワークを利用して開発され且つ前記１又は複数の特定機能が搭載されたアプリケーション・プログラムを、前記医療・介護支援システムに組み込む際には、当該アプリケーション・プログラムに対して固有のアプリケーション識別情報を割り当てると共に、当該アプリケーション識別情報を１又は複数の前記グループ識別情報に関連づけて記憶し、それによって当該アプリケーション・プログラムにより提供される１又は複数の新サービスを、当該アプリケーション識別情報が関連づけられた前記１又は複数のグループ識別情報を持つ前記１又は複数のグループに所属する前記グループ・メンバーに限定して、前記ユーザー端末を介して利用可能とするアプリケーション管理手段とを備え、
   　前記アプリケーション・プログラムは、当該アプリケーション・プログラムに搭載された前記１又は複数の特定機能が、所定の管理者が所定の管理者設定を実行することで前記医療・介護支援システム上で利用可能となるように構成されると共に、前記管理者設定では、当該アプリケーション・プログラムが持つ前記アプリケーション識別情報が関連づけられた前記１又は複数のグループに係る前記患者又は前記要介護者、あるいは、当該グループに係る前記医療従事者又は前記介護従事者の必要に応じて、前記１又は複数の特定機能が設定されるように構成され、
   　前記グループの各々に所属する前記グループ・メンバーは、当該グループが持つ前記グループ識別情報に関連づけられた複数の前記アプリケーション識別情報を持つ複数のアプリケーション・プログラムが提供する複数の新サービスを、必要に応じて前記ユーザー端末上で指示することにより選択的に利用可能であることを特徴とする、医療・介護支援システムにおけるサービス構築支援システム。
8. 　前記アプリケーション・プログラムは、前記管理者設定に加えて、必要なユーザー設定を実行することで前記医療・介護支援システム上で利用可能となるように構成され、
   　前記ユーザー設定は、当該アプリケーション・プログラムが持つ前記アプリケーション識別情報が関連づけられた前記１又は複数のグループに係る前記ユーザーのいずれかが実行するように構成されている請求項７に記載のサービス構築支援システム。
9. 　前記アプリケーション・プログラムは、当該アプリケーション・プログラムの目的を達成するために必要な、前記アプリケーション・フレームワークが提供する前記１又は複数の特定機能の組み合わせを記述したものとされている請求項７または８に記載のサービス構築支援システム。
10. 　前記グループの各々に関連づけられた前記１または複数のアプリケーション・プログラムは、当該アプリケーション・プログラムが提供する前記新サービスのために必要なサービス要素情報を、前記ユーザー端末上において、所定のスケジュールに沿って、当該グループに係る前記患者または前記要介護者の前記医療・介護情報が閲覧可能なタイムラインに順に表示し、
    　前記サービス要素情報に応答する必要がある場合には、応答情報を前記ユーザー端末から前記タイムラインに表示するか、前記医療・介護システムに送信することで応答するように構成されている請求項７～９のいずれかに記載のサービス構築支援システム。
11. 　前記アプリケーション・フレームワークが、前記１又は複数の特定機能を実現する手段として、所定の都度情報を記憶する機能を提供する第１モジュールと、所定の外部情報を収集して記憶する機能を提供する第２モジュールと、質疑応答の機能を提供する第３モジュールと、コンテンツ情報を記憶する機能を提供する第４モジュールとを備えている請求項７～１０のいずれかに記載のサービス構築支援システム。
12. 　前記アプリケーション・フレームワークが目的の異なる複数のユニットを含んでおり、前記１又は複数の特定機能が、前記複数のユニットの各々に設けられている請求項７～１１のいずれかに記載のサービス構築支援システム。

Images