(57)【要約】  アプリケーションプログラムインタフェース（ＡＰＩ）が、健康統合ネットワーク内のデータの要求、保存および他の方法によるアクセスのために提供される。当該ＡＰＩは、集中的に保存されたデータへの安全でシームレスなアクセスを、認証／権限付与と、ＸＭＬ等の拡張言語フォーマットで要求を受信してＸＭＬフォーマットで結果として得られるデータを返送する能力とを提供することによって容易にする。当該データは、そのデータに関連する変換、スタイル及び／又はスキーマ情報を有してもよく、それらは結果として得られるＸＭＬの中で返送され、かつ／または、ＡＰＩによって予めデータに適用されてもよい。当該ＡＰＩは、ＨＴＴＰ上のＸＭＬ及びソフトウェア開発キット（ＳＤＫ）を含む多くの環境アーキテクチャにおいて使用することができる。
2010508610.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションプログラムインタフェース（ＡＰＩ）（２００）において、
複数の異なるデバイス又はアプリケーション（３０２）からの健康関連データに対する要求を受信する受信コンポーネント（２０２）と、
前記要求を処理して、要求された前記健康関連データのサブセットを健康統合ネットワーク（３０４）から収集する解釈コンポーネント（２０４）であって、前記健康統合ネットワークは、各々が健康関連データを保存する複数の異なるデータ保存部（４０４、４０６、４０８）を備えるものである解釈コンポーネント（２０４）と、
スキーマを使用して、前記デバイス又はアプリケーション（３０２）に返送するために、収集された前記健康関連データの一部を選択する変換コンポーネント（２０８）と
を備えることを特徴とするアプリケーションプログラムインタフェース（ＡＰＩ）（２００）。
【請求項２】
前記スキーマの少なくとも一部は、前記健康関連データに対する前記要求の中で特定されていることを特徴とする請求項２に記載のインタフェース。
【請求項３】
前記変換コンポーネントは、前記健康関連データの選択された前記一部のデータタイプのスタイル情報を前記健康統合ネットワークから読み出して、前記デバイス又はアプリケーションへの返送の際に前記スタイル情報を前記健康関連データの選択された前記一部に適用することを特徴とする請求項１に記載のインタフェース。
【請求項４】
データを要求するアプリケーションが前記要求において特定されるデータアクセスのタイプに関して十分な信用証明を有するかを判定する権限付与コンポーネントをさらに備えることを特徴とする請求項１に記載のインタフェース。
【請求項５】
前記権限付与コンポーネントは、前記アプリケーションを操作するユーザが前記要求において特定されるデータアクセスのタイプに関して十分な信用証明を有するか否かを判定することを特徴とする請求項４に記載のインタフェース。
【請求項６】
イベントまたは閾値超過の発生の少なくとも１つの際に、接続されたアプリケーションにデータを送信する更新コンポーネントをさらに備えることを特徴とする請求項１に記載のインタフェース。
【請求項７】
前記要求はＨＴＴＰ接続を通じて拡張マークアップ言語（ＸＭＬ）フォーマットで受信されることを特徴とする請求項１に記載のインタフェース。
【請求項８】
ＸＭＬフォーマットで受信された前記要求は、少なくとも１つのルーチンコール及び前記ルーチンコールに対する少なくとも１つのパラメータを特定することを特徴とする請求項７に記載のインタフェース。
【請求項９】
前記複数のデータ保存部の少なくとも１つは、高度に分散されており、前記複数のデータ保存部の少なくとも１つは、高度に分散された前記データ保存部内のレコードに対する位置情報を保持することを特徴とする請求項１に記載のインタフェース。
【請求項１０】
共通の一組のルーチンを判定して、アプリケーションによる使用のために前記共通の一組のルーチンを公開するルーチンパッケージングコンポーネントさらに備えることを特徴とする請求項１に記載のインタフェース。
【請求項１１】
個人の健康関連データと情報をやりとりする方法であって、
第１のアプリケーション又はデバイスから、健康関連データレコードの一部に対応する要求を受信するステップと、
前記要求に基づいて健康統合ネットワークにデータを要求するステップと、
前記データにスキーマを適用して、前記データの選択された部分で構成された結果を作成するステップと
を含むことを特徴とする方法。
【請求項１２】
前記結果を前記第１のアプリケーション又はデバイスに送信するステップをさらに含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記選択された部分は、健康関連データレコードの一部に対する前記要求内で特定されることを特徴とする請求項１１に記載の方法。
【請求項１４】
第２のデバイス又はアプリケーションから、健康関連データレコードの前記一部に対する異なる要求を受信するステップをさらに含み、
前記第２のデバイス又はアプリケーションは前記第１のデバイス又はアプリケーションと異なるアーキテクチャにおいて動作することを特徴とする請求項１１に記載の方法。
【請求項１５】
前記要求は、健康関連データの前記一部を前記健康統合ネットワーク内に保存することであることを特徴とする請求項１１に記載の方法。
【請求項１６】
前記要求の少なくとも一部に基づいてイベントを第２のデバイス又はアプリケーションに送信するステップをさらに含むことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記要求は、拡張マークアップ言語（ＸＭＬ）ドキュメントで構成されていることを特徴とする請求項１１に記載の方法。
【請求項１８】
前記ＸＭＬドキュメントは、要求されたルーチンによって必要とされる少なくとも１つのパラメータをさらに含むことを特徴とする請求項１７に記載の方法。
【請求項１９】
前記第１のデバイス又はアプリケーションは個人健康デバイスであることを特徴とする請求項１１に記載の方法。
【請求項２０】
健康関連データにアクセスするシステムであって、
複数のデバイス及びアプリケーション（３０２）からの個人の健康関連データに対する要求を受信して（２０２）応答する（２１０）手段と、
前記要求に関連する保存されたデータのサブセットを取得する（２０２）手段と、
前記保存されたデータの前記サブセットに少なくとも１つのスキーマを適用して（２０８）、前記保存されたデータの一部の要求された選択のみを返送する手段と
を備えることを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、健康統合プラットフォームＡＰＩに関する。
【背景技術】
【０００２】
コンピュータ及びネットワーク技術の、高コストで低性能なデータ処理システムから低コストで高性能な通信、問題解決及びエンターテイメントシステムへの進化は、コスト効果がありかつ時間を節約できる手段を提供し、通信、請求の支払い、ショッピング、情報の供給及び収集等の日々の仕事を行う負担を軽減してきた。例えば、有線または無線技術によってインターネットに接続されているコンピューティングシステムは、世界中に配置されたウェブサイト及びサーバからの大量の情報にほぼ瞬時にアクセスするためのチャンネルをユーザに提供する。このようなシステムは、ユーザに情報収集を許容するだけではなく様々なソースに情報を提供することも許容する。従って、オンラインのデータ保存および管理がますます盛んになってきている。
【０００３】
例えば、共同ソーシャルネットワーキングウェブサイトは、世界中に広がっている。これらのサイトは、年齢、性別、通った学校、卒業したクラス、勤務先等の個人情報を含むリモートに保存されたプロフィールを生成することをユーザに許容する。当該サイトは、他のユーザを探す試行において、前述の特徴を検索することを他のユーザに許容する。これによって、類似の興味を持つ仲間を見つけたりまたは高校から長い間音信不通だった友人を探したりするのである。他のさらに実用的な例として、銀行取引ウェブサイトは、支払うべき請求に関係する情報をリモートに保存可能とする。この特徴を使用することで、ユーザは、ユーザの銀行預金口座から支払われる請求支払を自動的にスケジューリング可能となる。支払がスケジューリングされていた場合、これらは自動的に引き落とされる。このことは、会計バランス及び請求支払を同時に電子的に管理することをユーザに許容し、ユーザが会計を小切手帳簿に手書きで書きこむ手間を省く。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
この国及び全世界において非常に関心のある他の分野は、個人の健康及びフィットネス（ｆｉｔｎｅｓｓ）である。個人の健康目標の設定及び達成並びに私たちの健康システムに存在する非効率性に関する非常に様々な話題等の多くの非常に異なる関心を、この分野において議論することができる。例えば、今日、病気に対する薬品治療を受けることを希望する個人は、まず、かかりつけ医に会わなければならない。医者に会う前に、患者は何度も健康保険カード（ｈｅａｌｔｈ  ｉｎｓｕｒａｎｃｅ  ｃｏｖｅｒａｇｅ  ｃａｒｄ）を見せるよう求められるであろう。この訪問の間に、医者は通常患者の処方箋を記載する。その後、患者は、目的の達成のためその処方箋を薬局に持参し、この時も再度健康保険カードを提示する必要があり得る。薬局は、処方箋の薬を調剤し、保険契約を知らせ、保険金額を控除し、かつ差額の支払いの上で処方薬を渡す。これらの手作業の手続は、時間を浪費し、面倒かつ非効率的である。
【課題を解決するための手段】
【０００５】
以下は、本明細書に記載されているいくつかの態様の基礎的な理解を提供するものである。このまとめは、外延的な要約ではなく、また本明細書に記載されている重要／重大な要素を特定すること又は本明細書に記載されている様々な態様の範囲を画定することを意図していない。このまとめの唯一の目的は、後に提供されるより詳細な説明の前置きとして、いくつかの概念を単純な形式で提供することである。
【０００６】
健康統合ネットワーク（ｈｅａｌｔｈ  ｉｎｔｅｇｒａｔｉｏｎ  ｎｅｔｗｏｒｋ）と通信するためのアプリケーションプログラムインタフェース（ＡＰＩ）であって、アプリケーションが前記ＡＰＩを使用して、個人の健康及びフィットネスに関連するデータを、取得、保存及び他の方法でアクセスまたは変更可能なＡＰＩが提供される。前記ＡＰＩは、拡張マークアップ言語（ＸＭＬ）等の拡張可能な言語フォーマットでアプリケーションと通信して、新たなコードの実装を要求することなく要求ＸＭＬまたは応答ＸＭＬ（ｔｈｅ  ｒｅｑｕｅｓｔｉｎｇ  ｏｒ  ｒｅｓｐｏｎｄｉｎｇ  ＸＭＬ）に変更が生じることのできるオープンなシステムを容易にする。しかしさらに、前記ＡＰＩは、ＸＭＬスキーマの準拠（ｃｏｍｐｌｉａｎｃｅ）を要求してオープンなシステムを動作可能に維持するのに必要な共通フォーマットのレベルを維持することができる。前記ＡＰＩを介して要求可能、保存可能及び返送可能なデータは、自己記述的であってもよく、関連するスキーマだけではなくデータのインテリジェントなレンダリングを容易にする変換およびスタイル情報を有してもよい。前記ＡＰＩは、アプリケーションの認証／権限付与のレイヤー（ｌａｙｅｒ）を提供し、ユーザに異なるレベルにおいてデータにアクセスすることを提供し得る。
【０００７】
例えば、システムに保存されるデータは、血圧測定値、保険情報、処方箋、家族歴、個人の病歴、診断結果、アレルギー、Ｘ線写真、血液検査等の健康関連データとすることができる。さらに、前記データは、エクササイズのルーティン、エクササイズの目標、ダイエット（ｄｉｅｔ）、エクササイズルーティンに基づく仮想遠征（ｖｉｒｔｕａｌ  ｅｘｐｅｄｉｔｉｏｎ）、コンペ（ｃｏｍｐｅｔｉｔｉｏｎ）等のフィットネス関連のものとすることができる。前記ＡＰＩは、保存、取得及びアクセスのためにこれらのデータ全てにアクセスすることを促進する。アプリケーションはこれらのデータにアクセスして、前記データに値を加えることが可能であり、例えば、あるアプリケーションは、ユーザの保険情報を入力することを保険会社に許可することができ、また、ユーザの医者訪問の際に医院がこの情報にアクセスしてユーザが保険カードを提示する必要を減らすことができる。この例をさらに詳しくみると、医者は、ユーザのアカウントの下に処方箋の情報を入力でき、薬局は、この情報及び保険情報を取得して処方薬を調剤し、ユーザが処方箋受け取りの際に保険証および処方箋の紙を提示する必要を軽減できる。従って、前記ＡＰＩは、個人の健康及びフィットネスに関連するデータへの有益なアクセスを提供して、健康及びフィットネス分野に価値を与え、現在のプロセスの無駄を省くことができる。
【０００８】
上述及び関連した目標の達成のため、特定の実例の態様が本明細書において以下の説明及び添付図面に関連して説明される。これらの態様は、実施可能な様々な方法を示唆し、、これらの全ては本明細書の範囲内にあることが意図される。他の利点及び新規な特徴は、図面とともに考慮すれば以下の詳細な説明から明らかであろう。
【図面の簡単な説明】
【０００９】
【図１】要求とバックエンドデータコンポーネントとの間のデータ通信のためにＡＰＩを使用することを容易とする例示的システムのブロック図である。
【図２】例示的なＡＰＩのブロック図である。
【図３】アプリケーションと健康統合ネットワークとの間のデータ通信のためにＡＰＩを使用することを容易とする例示的システムのブロック図である。
【図４】個人健康情報の通信を容易とする例示的システムのブロック図である。
【図５】ＡＰＩからの個人健康情報の要求を容易とする例示的システムのブロック図である。
【図６】ソフトウェア開発キット（ＳＤＫ）を使用してＡＰＩからの個人健康情報の要求を容易にする例示的システムのブロック図である。
【図７】例示的ＡＰＩのブロック図である。
【図８】ＡＰＩを使用した健康統合ネットワークへのデータの要求に関する例示的フロー図である。
【図９】アプリケーションからの個人健康情報に対する要求の処理に関する例示的フロー図である。
【図１０】適切な動作環境を示した全体ブロック図である。
【図１１】例示的コンピューティング環境の概略ブロック図である。
【発明を実施するための形態】
【００１０】
アプリケーションプログラムインタフェース（ＡＰＩ）は、健康統合ネットワークへのアクセスを促進するために提供される。ＡＰＩは、アプリケーションからの要求を受信して処理し、健康統合ネットワーク内のデータの取得、保存、変更または他の方法によるアクセスをすることが可能であり、認証／権限付与機能を提供することができる。ＡＰＩは、拡張マークアップ言語（ＸＭＬ）スキーマに従ったＸＭＬ等の拡張可能データ形式（ｅｘｔｅｎｓｉｂｌｅ  ｄａｔａ  ｆｏｒｍ）で要求を受信することができる。加えて、このＡＰＩは、そのような要求に対して、ＸＭＬスキーマに従って要求に関する情報のデータセットを表すＸＭＬにより応答することができる。このＡＰＩは、多数のデバイス及びアプリケーションと動作し、利用容易、完全かつ軽量なＡＰＩにより、個人の健康及びフィットネスに関連するデータのための中央記憶装置を効果的に形成する。アプリケーションは、システムデータタイプを使用できるほか、それら独自のタイプを指定することができ、それらのデータタイプを他のアプリケーションと共有してアプリケーションをまたがる操作を促進することができるが、そのようなオープンエンドシステム（ｏｐｅｎ  ｅｎｄｅｄ  ｓｙｓｔｅｍ）は存在しない。アプリケーションとＡＰＩとの間の通信のために使用される拡張可能データ形式は、ほぼ任意の種類の情報が、いかにしてそのデータが保存されるのか、いかに変形（ｔｒａｎｓｆｏｒｍｅｄ）、定型化（ｓｔｙｌｉｚｅｄ）および／または体系化（ｓｃｈｅｍａｔｉｚｅｄ）されうるのかが記載されたデータと共に保存されることを許容することで、このことを達成する。データは、非構造化または非体系化された形においても保存や取得され得ることが理解されるべきである。
【００１１】
ここで、本開示の様々な態様が添付図面を参照して説明される。全体を通して同様の参照番号は同様または対応する要素を参照する。しかしながら、図面及びそれに関連する詳細な説明は、特許請求の範囲を開示された特定の形式に限定することを意図していないことを理解されたい。むしろ、特許請求の範囲に記載された主題の精神および範囲内のすべての変形形態、均等形態および代替形態が包含されることが意図されている。
【００１２】
ここで図面を参照すると、図１はデータの保存及び取得を促進するするシステム１００を図示していて、それらは健康統合ネットワークに参加するために使用することができる。要求コンポーネント１０２は、データ取得、データ保存等のＡＰＩ１０４に対する要求を特定する。ＡＰＩ１０４は、要求を解釈してバックエンドデータコンポーネント１０６に要求に基づいてクエリーを行う。その後、バックエンドデータコンポーネント１０６は、ＡＰＩ１０４に応答することができ、ＡＰＩ１０４は、少なくとも要求コンポーネント１０２に結果を返すことができる。要求コンポーネント１０２は、例えば要求をすることによってＡＰＩ１０４と通信可能な任意のデバイスとすることができる。実行できる要求としては、これらに限定するわけではないが、要求コンポーネント１０２の認証／権限付与、データの保存、データの取得、データの変更、並びに、例えばデータ単位の追加、及び、データのフォーマット、ユーザインタフェース及びデータのレイアウト等に関するスタイル及びスキーマの取得及び適用等の任意のデータに対する価値追加サービス（ｖａｌｕｅ−ａｄｄ  ｓｅｒｖｉｃｅ）を挙げることができる。
【００１３】
ＡＰＩ１０４は、要求コンポーネント１０２からの要求を解釈するために使用され、バックエンドデータコンポーネント１０６との通信を容易にする。要求コンポーネント１０２によって送信された要求は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）上のＸＭＬを介して行われるコール、ＡＰＩ１０４に直接的に行われるコール、および／またはＡＰＩ１０４の周囲のラッパー（ｗｒａｐｐｅｒ）に行われるコールとすることができる。ＸＭＬの使用は、構造が変更可能であり、かつ、データの解釈に新たなコードを必要としない拡張可能データモデルを可能にする。このことは、ＸＭＬの自己記述能力（ｓｅｌｆ−ｄｅｓｃｒｉｂｉｎｇ  ａｂｉｌｉｔｙ）に起因し、特にＸＭＬスキーマとともに使用される場合にそうである。加えて、ＡＰＩ１０４は、バックエンドデータコンポーネント１０６上にセキュリティの層を形成して、権限が付与された要求コンポーネントのみがバックエンドデータコンポーネント１０６内の特定のデータにアクセスすることを許容することを可能にする。本発明によれば、バックエンドデータコンポーネント１０６は、個人の健康関連データを保管することができ、これは情報の膨大な保存を含む。このような情報は、比較的静的な情報（例えば、身長、体重、病歴（本人および家族）、病気、アレルギー、保険等）、事象特有な情報（例えば、トレーニング計画（ｗｏｒｋｏｕｔ  ｒｅｇｉｍｅｎ）、トレーニングバイタル（ｖｉｔａｌ）及び統計、現在の薬剤処方箋、医学的診断等）、完全に動的な情報（例えば、血圧、心拍数、ダイエット等）等とすることができる。ＡＰＩ１０４は、当事者の要望または医者の命令等に基づいて、この情報の全てへのアクセスの許可および制限を特定の個人に対して可能である。
【００１４】
さらに、ＡＰＩコンポーネント１０４は、イベントをトリガするため、リアルタイム更新（例えば、コールバックファンクションを介して等）を提供するため、警告を受信するため等に利用可能である。さらに、要求コンポーネント１０２は、イベントまたは警告を受信可能である。このようなイベントまたは警告は、閾値をまたいだデータの入力（例えば高い血圧）、必要なデータの不在（例えば血糖値測定値の欠落）、現実世界の事象の発生、節目または目標の達成、データの期限切れ等の際に発生することができる。従って、本明細書に記載された本発明は、個人の健康に関連するデータの集中型の保存及びアクセスを提供して、このようなデータの有利な追跡およびこのようなデータが価値を有する当事者間の合理化されたデータ通信を可能にする。さらに、ＡＰＩ１０４から要求コンポーネント１０２に返送または返信された値は、オリジナルのコールに対する応答コール（例えば、ソフトウェア開発キットを使用している場合）、ＨＴＴＰ上のＸＭＬ等である。
【００１５】
図２を参照すると、本発明によるＡＰＩ２００が示されていて、データの取得、保存、変更または他の方法によるアクセスを促進する様々なコンポーネントを有する。ＡＰＩ２００は、データアクセスの要求を受信する受信コンポーネント２０２と、要求を解釈して所望のデータ及び関連する任意のデータ及び／又はメタデータ（当該データに関するデータ）を収集する解釈コンポーネント（ｉｎｔｅｒｐｒｅｔｅｒ  ｃｏｍｐｏｎｅｎｔ）２０４とを有することができる。ＡＰＩ２００は、権限付与コンポーネント２０６も備え、要求エンティティに権限付与／認証ルールを適用して、所望の要求を達成するのに十分なアクセスを要求エンティティが有することを保証することができる。ＡＰＩ２００は、変換（ｔｒａｎｓｆｏｒｍａｔｉｏｎ）コンポーネント２０８を備え、要求された際に、変換（ｔｒａｎｓｆｏｒｍａｔｉｏｎ）、解釈（ｔｒａｎｓｌａｔｉｏｎ）、スタイル及び／又はスキーマをデータに適用することができる。変換２０８は、要求エンティティが所望の変換を行うことができるように、結果として得られるデータを適切かつ／または利用可能な変換情報とパッケージングすることもできる。ＡＰＩ２００は、返送（ｒｅｔｕｒｎ）コンポーネント２１０を利用して、所望のデータ及び任意の添付データを要求エンティティに返送することができる。更新コンポーネント２１２を提供してアプリケーションがＡＰＩ２００に付随（ａｔｔａｃｈ）することを許容し、通信チャンネルを開くこと及び自動的に情報の更新を受信することを可能にする。さらに、ＡＰＩ２００は、インテリジェントルーチンを生成するルーチンパッケージングコンポーネント２１４を提供してＡＰＩ２００の使用を容易にすることができる。
【００１６】
ＡＰＩ２００の使用において、デバイス、アプリケーション、アプリケーションを実行しているデバイス、アプリケーションを有するシステムに結びつけられたレガシーデバイス等の要求エンティティは、ＡＰＩ２００に対するデータ要求を開始することが可能であり、それらは受信コンポーネント２０２によって受信される。当該要求は、たとえば処方箋情報等、個人の健康および／またはフィットネス関連データにアクセスするためのものであり得る。受信コンポーネント２０２が、要求を受信して、それを解釈コンポーネント２０４に送信する。解釈コンポーネント２０４は、例えばデータの取得、データの保存またはデータの変更のためといった要求のタイプを判定して、要求されているレコードまたはタイプを判定する。解釈コンポーネント２０４は、権利付与コンポーネント２０６を利用して、要求エンティティが、与えられた要求のタイプに関する要求されたデータにアクセスするために十分な権限（ｐｒｉｖｉｌｅｇｅ）を有するかを判定する。例えば、ある当事者は、配偶者の医療診断を変更するために十分なアクセス権または閲覧するために十分なアクセス権すら持っていないこともあり得る。権限付与ルールは、データが直接関係する個人、医療プロフェッショナル等を含む多くの当事者によって設定することができる。エンティティがアクセス拒否された場合、返送コンポーネント２１０は、結果として得られるエラー通知を（例えば、ＸＭＬフォーマットで）要求エンティティに返送することができる。
【００１７】
アクセスが許可された場合、解釈コンポーネント２０４は関連するデータにアクセス可能であり、処方箋の例では、処方箋名（ｐｒｉｃｓｒｉｐｔｉｏｎ  ｎａｍｅ）、タイプコード、説明書、量、医者の署名付き処方箋の画像等を含むことができる。その後、この情報は、変換コンポーネント２０８に送信され、変換コンポーネント２０８が、要求エンティティによって要求された情報および任意の要求された変換を判定することができる。例えば、要求エンティティが処方箋の画像を要求しない可能性がある。変換コンポーネント２０８はスキーマを適用して、当該画像以外の全てを解釈コンポーネント２０４から送信された命令から取り込み、テキスト情報だけを送信するよりも著しく広いバンド幅を必要とするであろう画像を送信する必要が緩和される。加えて、例えば、要求エンティティは処方箋に関するタイプコードの変換を必要とする可能性があって、当該コードは抗炎症性の薬剤を示す場合があり当該要求エンティティがこの情報をユーザに表示するべきである。有効成分および／または副作用の説明が、タイプコードに基づいて返送される可能性がある。変換２０８は、要求された場合にはこれらの情報も収集することができる。所望の全ての情報が収集された後、返送コンポーネント２１０は当該データを、要求されたフォーマット、例えば拡張マークアップ言語または任意の返送タイプで要求エンティティに返送する。返送されたデータのレイアウトを記載する添付のスキーマも返送することができる。
【００１８】
更新コンポーネント２１２は、例えばパイプ（ｐｉｐｅ）等の通信チャンネルがアプリケーション（または他の受信コンポーネント）とＡＰＩ２０２との間で開かれている他のタイプのデータアクセスを提供することができる。データが健康統合ネットワーク等の下部（ｕｎｄｅｒｌｙｉｎｇ）システムを流れるとき、アプリケーションがデータに結合する（ａｔｔａｃｈ  ｔｏ）権限を有するならば、更新コンポーネント２１２は、接続されたアプリケーションに特定のデータを自動的に通知（または警告）することができる。この更新コンポーネント２１２は、特定の閾値を超えるイベント又はデータのリアルタイムの発生に基づいて、警告を種々のユーザに送信可能なイベントベースのシステムを容易にする。例えば、血圧が多くの（閾値を超えた）一貫した高い血圧測定値を受信した場合、イベントが医者のオフィスに送信されて報告し、予約を要求する。当該情報は、血圧測定器に返送されて高い測定値の数をユーザに報告し、彼らの医者に予約の要求が既に為されたことを報告することもできる。更新コンポーネント２１２を使用することによって利用可能な多くの類似のシナリオが存在し得る。同様に、例えば、デバイスがコンスタントな更新を送信するものである場合、開いたチャンネルは健康統合ネットワークに自動的にデータを提供することができる。例えば、ユーザによって操作されているトレッドミルは、セッション中に一定の心拍数を測定し、チャンネルを開いてこの情報及び例えばトレーニングルーチンに関連する他の情報をリアルタイムに健康統合ネットワークへ更新し得る。開いたチャンネルは必要ないことが理解されるべきである。むしろ、ＡＰＩ２００は、たとえば自動的にアプリケーション（コールバックタイプファンクション等）上のＡＰＩ２００をコールして警告または更新を通知することができる。
【００１９】
ルーチンパッケージングコンポーネント２１４は、多くの異なる機能を提供し、ＡＰＩ２００を使用してサードパーティのアプリケーションを生成するアプリケーション開発者を補助する。例えば、ルーチンパッケージングコンポーネント２１４は、一般的に使用される一組のルーチンを単一のコールにまとめるか又はそれらをパッケージ化された状態で提示して、ＡＰＩ２００を使用するのに本当に必要なものを開発者に与える。さらに、健康統合ネットワーク等の下部（ｕｎｄｅｒｌｙｉｎｇ）システムに一般的に使用されるＸＭＬ及び関連するスキーマを生成するためのルーチンが提供され、当該ネットワーク内に保存されるべきデータタイプ及び種々のレコード等が生成される。さらに、ルーチンのパッケージングまたは追加的な使用容易なルーチンの生成を判定するために人工知能が使用され得る。形成されたこれらのルーチンは、開発者に提供された、必ずしも一緒に保存する必要のない関連するデータを取得するための単一のコール等のいくらか高度なタスクを実行する単一のコールとすることができる。例えば、ＧｅｔＬａｓｔＥｘｅｒｃｉｓｅＲｏｕｔｉｎｅを生成して、ユーザの最後のエクササイズセッション情報およびこの時刻周辺で測定された任意の心拍数を取得することができる。上述のように、これらの機能はしばしば一緒にコールされるということを（例えば、人工知能を使用して）判定し、その後、このデータを一緒に必要とする可能性のあるアプリケーション開発者の作業を用意にするために、このデータにアクセスする単一ルーチンを生成することができる。上述したシナリオは、単に例示であるので本発明はそのように限定されないことを理解すべきである。
【００２０】
図３は、システム３００を示す。システム３００は、アプリケーション３０２からのデータ保存、取得等の要求を解釈するためのＡＰＩ１０４の使用を容易にする。ＡＰＩ１０４は、アプリケーション３０２からの要求に基づいて健康統合ネットワーク３０４にクエリーを行い、健康統合ネットワーク３０４からの応答に基づいてアプリケーション３０２にデータを返送する。アプリケーション３０２は、コンピュータその他のデバイス上で実行されるソフトウェアアプリケーション、デバイス自体、例えばレガシーデバイスコンテクストにおいてコンピュータ又はアプリケーションに結合されたデバイス等とすることができる。例示的デバイスには、出力を有するデバイス（例えば、血圧測定器、体重計、血液／糖分レベル測定器、ＩＶ、ペースメーカー、聴診器、レントゲン等）、個人フィットネストラッキングデバイス（心拍数計付時計、万歩計（登録商標）、自転車装備（速度計、高度計、走行距離計等）、ストップウォッチ等）並びに個人用及び医療用のユーザインタフェースを含む他のアプリケーションのような任意の医療または個人健康デバイスが含まれる。従って、医者は、患者特有の情報を、処方箋、診断書またはその他のカルテから手動で保存でき、個人は、ダイエット、トレーニング計画、医療保険等の情報を保存可能である。データはどのようなタイプでもよく、関連したタイプの定義、データのレイアウトを記述したスキーマ及びデータがどの様に提示され得るかを記述したスタイルパラメータを有してもよい。アプリケーション３０２を上述のように接続してＡＰＩ１０４に直接的に要求を行うことができるが、更新機能の利点を有する開いたチャンネル（ｏｐｅｎ  ｃｈａｎｎｅｌ）（またはパイプ）接続で接続してもよいことが理解されるべきである。
【００２１】
一例として、患者は、アプリケーション３０２を使用して保険および薬剤情報を入力することができる。アプリケーション３０２は、これを、健康統合ネットワーク３０４への保存を要求可能なＡＰＩ１０４に送ることができる。その後、患者が医院に行くと、受付係は、ＡＰＩ１０４を使用して情報を要求する同一また別個のアプリケーション３０２を介して保険情報を取得することができる。ＡＰＩ１０４は、健康統合ネットワーク３０４から患者の保険情報を取得し、それをＡＰＩ１０４に送信し、ＡＰＩ１０４はそれをアプリケーション３０２に送信する。このことは、患者に保険カードを要求する受付係の負担を軽減する。続いて、面会中に、医者は、同一または別のアプリケーション３０２を使用して患者の医療処方箋を入力する。この処方箋は、ＡＰＩ１０４を介して健康統合ネットワーク３０４内に保存される。この時点で、処方薬の調剤を要求する同一または別のアプリケーション３０２を実行している患者の薬局に警告を送信することができる。あるいは、患者が薬局に行って処方薬の調剤を要求することが可能であり、情報は健康統合ネットワーク３０４内に保存されているので薬局は患者から処方箋を入手する必要がない。薬局はアプリケーション３０２を使用してＡＰＩ１０４にアクセスし、健康統合ネットワーク３０４からその患者に関する処方箋及び保険データを取得することが可能である。
【００２２】
別の実施例において、アプリケーション３０２は、血圧測定器のようなデバイスでもよく、それはＡＰＩ１０４に個人の血圧を保存することを要求することができる。当該血圧がここ５回の測定値にわたり高いと判断された場合、当該血圧測定器はＡＰＩ１０４から警告を受信し、この事実を当該個人に通知することができる。さらに、当該個人に関係する医院のアプリケーション３０２は、この情報をＡＰＩ１０４からの警告を介して受信して、連続した高い血圧測定値を医者に通知することができ、当該医者または個人トレーナーは、たとえば患者のトレーニング計画を調整して、いくつかの追加の心血管関連のセッション（cardiovascular session）を含め、食事における塩分を減らすことも可能である。ＡＰＩ１０４は、上述の例に限定されることはなく、実際、データ及び健康統合ネットワーク３０４に関連した様々な方法を実施することが可能であり、それにはデータ検査方法（ｄａｔａ  ａｕｄｉｔｉｎｇ  ｍｅｔｈｏｄ）が含まれる。加えて、アプリケーション３０２は、ＡＰＩ１０４から送信されたメッセージがパブリック及び／又はプライベートキーにより暗号化されることを指定可能であり、この場合、アプリケーション３０２はデータを復号するプライベートキーを有する。このようにして、当該システムの内部で通信されるデータに関して更なるセキュリティが提供されて、プライバシー及び信頼性が保証される。さらに、アプリケーション３０２は、メッセージに有効期限値（ｔｉｍｅ−ｔｏ−ｌｉｖｅ  ｖａｌｕｅ）を設定して、所与の期間内に応答が受信されない場合に当該メッセージが失効することを許容することができる。これに関連して、アプリケーション３０２は、メッセージが復帰（ｃｏｍｅ  ｂａｃｋ）するのを待つ必要はない。むしろ、例えば、アプリケーション３０２が他の場所でより迅速に当該情報を発見可能な場合、当該メッセージは失効し得る。
【００２３】
図４を参照すると、健康統合ネットワーク内の情報へのアクセスを容易にする例示的システム４００が示されている。アプリケーション３０２は、健康関連データの表示または特定の少なくとも１つが可能である。アプリケーション３０２は、ソフトウェアアプリケーション、ソフトウェアアプリケーションを実行する電子デバイス、電子デバイス単体、ソフトウェアアプリケーションを実行するデバイスに接続可能なレガシーデバイス等を含む多くの異なるタイプとすることのできることが理解されるべきである。当該アプリケーションは、ＡＰＩ１０４を利用して、健康統合ネットワーク３０４内のデータを要求および保存することができる。ＡＰＩ１０４は、同様または異なるタイプの複数のアプリケーション３０２と同期的または非同期的に通信し得る。ＡＰＩ１０４は、要求を解釈して処理する際に使用するソフトウェア層４０２も有することができる。ソフトウェア層４０２は、図示のように分離するか、又はＡＰＩ１０４、健康統合ネットワーク３０４またはその両方内に組み込むことができる。アプリケーション３０２からの要求の解釈および処理において、ソフトウェア層４０２は、任意の必要なデータのため又は必要なデータを保存するために健康統合ネットワーク３０４にアクセスして、当該要求を達成し得る。ソフトウェア層４０２は、健康統合ネットワーク３０４からデータをアセンブルし、ビジネスモデルまたはプロセスをデータとともに適用し、データをキャッシュし、かつ／または、変換もしくは追加情報を当該データへ適用する／加える、といったデータに対する付加価値（ｖａｌｕｅ−ａｄｄ）を提供することができる。集中型の健康統合ネットワーク３０４に接続された複数のＡＰＩ１０４及びソフトウェア層４０２が存在してもよく、集中型の健康統合ネットワーク３０４は、単一のシステムでも複数のシステム、プラットフォーム等にわたって分散していてもよいことが理解されるべきである。
【００２４】
健康統合ネットワーク３０４は、複数のデータ保存部（ｄａｔａ  ｓｔｏｒｅ）を備えることができ、それらには、レコードデータベース４０４、ディレクトリデータベース４０６及びディクショナリデータベース４０８が含まれる。加えて、健康統合ネットワーク３０４は、データ管理及び移動を容易にする多くの他のシステム及び／又は層を備えてもよい。さらに、当該データベースは、他のＡＰＩ及びアプリケーションが各データベースの複数のバージョンを利用可能であり、かつ／またはデータベースの他のバージョンがバックアップソースを利用可能であるように、冗長なものであってもよい。加えて、当該データベースは、様々な物理的データ保存部の間で論理的に分割され、大量にアクセスを受けるシステムに対する効率的なアクセスを許容することができる。さらに、当該データベースは、ＸＭＬのように階層ベース（ｈｉｅｒａｒｃｈｉｃａｌｌｙ  ｂａｓｅｄ）であってもよく、かつ／または相関ベース（ｒｅｌａｔｉｏｎａｌｌｙ  ｂａｓｅｄ）であってもよい。レコードデータベース４０４は、高度に分散され、複数のユーザの個人的健康関連データレコードを備えていてもよい。当該レコードは、異なるフォーマットであってもよく、単なるデータ、データ及び関連するタイプ情報、（例えばＸＳＬスキーマ等の関連するスキーマを用いる）自己記述データ、（例えばスタイルシートを用いる）関連するテンプレートを有するデータ、単位を有するデータ（変換命令を有するデータ等）、バイナリデータ（画像、レントゲン等）等の任意の種類のデータ（単一のインスタンス、構造化されたもの又は構造化されていないもの）を含むことができる。さらに、レコードデータベース４０４は、トラッキング及び復旧目的のために、レコードに対して行われた変更のオーディットトレールを保持可能である。さらに、前述の情報の任意のデータタイプ又は関連するインスタンスは、以下に説明されるディクショナリデータベース４０８等の異なる（ｄｉｓｐａｒａｔｅ）データベース内に保存することができる。レコードデータベース４０４は、性能、ユーザ（同じ会社、家族等）の論理的なグループ分けを含む多数の要素に基づいて分割（ｐａｒｔｉｔｉｏｎｅｄ）、分散（ｄｉｓｔｒｉｂｕｔｅｄ）および／またはセグメント化（ｓｅｇｍｅｎｔｅｄ）することができる。
【００２５】
ディレクトリデータベース４０６は、ユーザアカウントデータ等の情報を保存することができ、それらは、ユーザネーム、認証証明、ユーザに関するレコードの存在情報等を含む。ディレクトリデータベース４０６は、レコード自体に関する情報を保存することもでき、この情報には、レコードが属するユーザ、（分散レコードデータベース４０４構造において）当該レコードが保存されている場所、当該レコードに関する権限付与ルール等が含まれる。例えば、ユーザは、配偶者が彼／彼女のフィットネス関連データにアクセスできるが、医療健康関連情報にはアクセスできないように定めることができる。このようにして、ユーザは、適切な人（配偶者、医者、保険会社、個人トレーナー等）またはアプリケーション／デバイス（血圧計、ペースメーカー、フィットネスウォッチ等）に、関連するデータへのアクセスを許容しつつ彼／彼女のデータを保護可能である。加えて、ディレクトリデータベース４０６は、アプリケーション３０２の設定に関連するデータを含み、健康統合ネットワーク３０４と情報をやりとりする（ｉｎｔｅｒａｃｔ）ことができる。アプリケーション３０２は、健康統合ネットワーク３０４に登録することを必要とされ、従って、ディレクトリデータベース４０６内のアプリケーションデータが当該登録情報を含む可能性がある。
【００２６】
ディクショナリデータベース４０８は、健康統合ネットワーク３０４、及び、ＡＰＩ１０４及びソフトウェア層４０２等の要求エンティティに使用される語彙定義に関連した情報を保持することができる。このような定義は、データタイプ定義および異なるデータタイプをどの様に表示するか又はどのようにそれらを変換するかに関する情報を含む。加えて、ディクショナリデータベース４０８は、表示レイアウト及びテンプレート等に関する情報も保持することができる。さらに、ディクショナリデータベース４０８は、基準（ｓｔａｎｄａｒｄ）等を用いてコードを定義する種々の検索テーブルを保持することができる。例えば、ディクショナリデータベース４０８は、国立健康統計センター（ＮＣＨＳ）によって公開された国際疾病分類第９版（ＩＤＣ−９）をサポートすることができる。これらのコードは、種々の病気および診断を特定する。従って、医者は、健康統合ネットワーク３０４内のユーザのカルテにこれらのコードの１つを入力することができ、ディクショナリデータベース４０８は、ソフトウェア層４０４（またはＡＰＩ１０４）が、このコードを医学上の呼称、および／または、異なる、他の、もしくは追加の診断に関わる情報等のユーザがより理解できるものに変換することを許容する。ディクショナリデータベース４０８は、（ＩＤＣ−９コード等の）コードの複数形、短縮形等の他のメタデータを検索するために使用することができる。それは、フィートとメートル、華氏と摂氏、ポンドとキログラム等の異なる測定単位間の変換を可能にする情報も保持することができる。
【００２７】
一実施形態において、２以上のアプリケーションであり得るアプリケーション３０２は、例えば、ＡＰＩ１０４へのコールを行い、データの要求、保存または変更等をすることができる。ＡＰＩ１０４は、ソフトウェア層４０２を使用して、アプリケーション３０２によってなされたコールを処理する。その後、ソフトウェア層４０２は、所望のデータのために自身の内部キャッシュまたは健康統合ネットワーク３０４にクエリーを行うことができる。加えて又は代替的に、ソフトウェア層４０２は、所望のデータのためにデータベース４０４、４０６及び４０８の１つ又は複数に直接にクエリーを行うことができる。ソフトウェア層４０２は、健康統合ネットワーク３０４から全てのデータが取得されるまで、連続的または非同期的にデータに対してクエリーを行うことができ。ついで、ソフトウェア層４０２は、取得した他のデータを使用してデータの一部を操作してアプリケーション３０２に要望されている結果を生成し、その結果をＡＰＩ１０４を介してアプリケーション３０２に返送することができる。例えば、アプリケーション３０２は、ＡＰＩ１０４をコールすることによってユーザの血圧測定値を要求することができ、ＡＰＩ１０４はソフトウェア４０２と通信して所望の測定値を示すことができる。ソフトウェア層４０２は、直接に又は健康統合ネットワーク３０４を介して、血圧測定値の場所を取得するためにディレクトリデータベース４０６に、スキーマ、スタイル及び血圧タイプに関する一般なタイプの情報を取得するためにディクショナリデータベース４０８に、実測値を入手するためにレコードデータベース４０４にクエリを行うことができる。ソフトウェア層４０２は、当該スキーマを使用して当該レコードを収縮期血圧および拡張期血圧を示す２つの整数（心拍数も入り得る）として解釈して、これらの値をＡＰＩ１０４を介してアプリケーション３０２へ返送し得るか、またはスタイル、単位もしくは他のテンプレートを当該値に適用して、当該結果がストリング、ＸＭＬ、ＨＴＭＬ、画像等のどれであっても当該結果を返送する。加えて、ソフトウェア４０２は、変換、スタイル及び／又はスキーマ情報と共にＡＰＩ１０４を介して生のデータをアプリケーション３０２へ返送して、アプリケーション３０２がこれらを任意に適用することを許容することができる。ソフトウェア層４０２は、未来のアクセスのために当該結果をキャッシュメモリに保存し得る。記載された本発明は、上述の例／実施形態に限定されるものではなく、むしろこれらは健康統合ネットワークとインタフェースをとるＡＰＩ１０４の多くの可能な実施形態の１つであると理解されるべきである。
【００２８】
図５を参照すると、本明細書に記載された本発明の実施形態によるシステム５００が示されている。システム５００は、アプリケーション３０２を備え、アプリケーション３０２は、健康統合ネットワーク３０４からのデータの取得、保存、変更または他の方法によるアクセスのうちの少なくとも１つを行うために要求する。当該要求は、ＸＭＬフォーマットで要求を特定するＨＴＴＰプロトコルを使用してインターネットを介してＡＰＩ１０４に送信することができる。当該ＡＰＩは、ＸＭＬインタプリタ５０４を備え、ＸＭＬインタプリタ５０４はアプリケーション３０２により送信された当該要求から要求パラメータを得る。データに対する要求は、上述したようにＸＭＬ形式でＡＰＩ１０４に提供することができ、ＸＭＬインタプリタ５０４は、有効な要求とみなされるために、ＸＭＬがＸＭＬスキーマに従うことを要求することができる。例えば、要求は、アプリケーションの権利付与／認証またはセキュリティトークンタイプのための署名、パラメータのリスト（メソッド名を含んでもよい。）、個人ＩＤ（要求する人が情報を検索されるユーザと異なる場合、例えば医者が患者のレコードにアクセスする場合）、レコードＩＤ（例えば、レコードが操作されている場合）、ユーザに対する認証トークン、言語指定、国指定、メッセージ生成時刻および失効時刻、並びに／又は当該メソッドによって要求される任意のパラメータ等の情報を指定することができる。本発明の実施形態に従ってＡＰＩに送信されるサンプルのＸＭＬ要求は、以下のようなものが考えられる。
【００２９】
【表１】
2010508610.tif 000003
【００３０】
この例において、sigタグは、要求中のアプリケーション証明のプライベートキーに関するデータの暗号化に関連する情報を含み、paramsセクションは要求の詳細を示す。特に、methodタグは、メソッド名、様々な入力および上述において列挙したものを特定する。特に、infoセクションは、コールされるメソッドによって要求されるパラメータを含む。この場合において、GetThingsは、読み出される情報（体重、血圧、薬剤等）タイプを特定するtype-id及び２以上のセクションがある場合にどのセクションが返送されるべきなのかを特定するセクションパラメータを要求する。他のinfo要素が提供されて適切なデータが要求されることを保証できることを理解されたい。従って、ＸＭＬ  ＡＰＩコールは、健康統合ネットワーク内に存在する追加の情報およびタイプを含むように拡張可能である。開示された本発明は、ＨＴＴＰを使用したＸＭＬ要求に限定されず、むしろ、これはアプリケーションがＡＰＩを介して健康統合ネットワークと通信する多くの方法の単なる１つであると理解されるべきである。
【００３１】
レコードデータ要求への応答は、ＸＭＬ形式であり、インターネットを介してＨＴＴＰでＡＰＩ１０４からアプリケーション３０２に返送することができる。これらの応答は、状態コード（数値的および記述的）、結果として得られる単位を伴う任意のデータ（この例において「シング（ｔｈｉｎｇ）」と称され、以下で説明される。）、スタイル、スキーマ等を含むことができる。例えば、本明細書に記述された本発明によるＡＰＩコールからの応答は、以下のようなものが考えられる。
【００３２】
【表２】
2010508610.tif 000004
【００３３】
本明細書に記載された本発明は、上述の要求および応答の例に限定されるものではなく、むしろこれらはＨＴＴＰ上のＸＭＬ要求／応答表現の単なる例であると理解されるべきである。上述したように、多くのサポートされた言語（．ＮＥＴ、Ｊａｖａ（登録商標）等）、ＳＤＫオブジェクトモデル及びＸＭＬと互換性のある上述したような公開されたソフトウェア開発キット（ＳＤＫ）オブジェクトモデル等、アプリケーション３０２がＡＰＩ１０４と通信する方法は多くある。
【００３４】
図６を参照すると、本明細書に記載された本発明の実施形態による健康統合ネットワークからのデータにアクセスするためのシステム６００が示されている。健康統合ネットワーク３０４にアクセス可能なアプリケーションであるアプリケーション３０２に、ソフトウェア開発キット（ＳＤＫ）６０２が提供される。ＳＤＫ６０２は、当該アプリケーションが、健康統合ネットワーク３０４内に保存されたデータに要求、保存、変更または他の方法でアクセスするためのコールを行うことを可能にする。ＡＰＩ１０４は、健康統合ネットワーク３０４との通信を促進するために提供される。
【００３５】
アプリケーション３０２は、ＳＤＫ６０２を使用してＡＰＩ１０４にコールを行うことができる。ＳＤＫ６０２は、ＡＰＩ１０４に含まれる機能の少なくとも一部を提供するために実行される。例えば、当該アプリケーションは、健康統合ネットワーク３０４内のデータの読み出し、保存および変更をするためにはＳＤＫ６０２と通信することのみが必要である。アプリケーション３０２は、ＳＤＫ６０２を初期化することができ、この時点でＳＤＫ６０２を使用することができる。通常は一度初期化されると、アプリケーション３０２は、以下の疑似コードで表わされるようなドット表記形式でＳＤＫ６０２にファンクションコールを行うことができる。
【００３６】
【表３】
2010508610.tif 000005
【００３７】
上記の疑似コードは、ＳＤＫを伴う本発明の実施形態の使用の単なる例であり、本発明はこのように限定されないことが理解されるべきである。アプリケーション３０２がＳＤＫ６０２に、たとえばrecord.GetThingsByType…とコールをした場合、ＳＤＫ６０２が実行され、（健康統合ネットワークがリモートに保存されていた場合）インターネット５０２を介してデータを取得、保存または変更するためのコールがＡＰＩ１０４に行われる。ＳＤＫ６０２は、この情報のやりとり（ｉｎｔｅｒａｃｔｉｏｎ）をアプリケーション３０２にとってシームレスに見えるようにする。ＡＰＩに対する適切な要求の際、ＡＰＩ１０４及び／又は可能なソフトウェア層は、関連するデータを健康統合ネットワークに要求する。当該要求は、上述のように、異なる環境に又はローカルに保存された１つ又は複数のデータベースに対する１つ又は複数の要求を含むことができる。関連する情報が収集されると、ＡＰＩ１０４及び／又は可能なソフトウェア層は、インターネット５０２を介してＳＤＫ６０２にデータを返送する前に、データに変換、スタイル及び／又はスキーマを適用することができる。
【００３８】
図５及び図６の両方に関して、健康統合ネットワーク３０４及び／又はＡＰＩ１０４へのアクセスはインターネット通信に限られず、むしろ、同一のローカルエリアネットワーク（ＬＡＮ）にそれらのコンポーネントが位置する場合は、ＬＡＮ通信に加えて、ＷＡＮ、ＷＬＡＮ等も使用することができる。２つのシステム間でデータを通信する任意のモードが使用され得る。さらに、インターネット等における任意の種類のデータ通信／規格も使用され得る。加えて、ＡＰＩ１０４は、アプリケーション３０２によってなされたコールから、（上述のサンプルＸＭＬにおいて示されているような）少なくとも１つの状態コードを返送するだろう。このコードは、以下の状態コードのリストのようなものとすることができる。
【００３９】
【表４】
2010508610.tif 000006
【００４０】
【表５】
2010508610.tif 000007
【００４１】
【表６】
2010508610.tif 000008
【００４２】
【表７】
2010508610.tif 000009
【００４３】
図７を参照すると、様々なルーチンのグループを含むＡＰＩ７００が示されていて、これらは種々のデータへアクセスの種々の方法を提供する。レコードデータルーチン７０２は複数のルーチンを含み、これらはアプリケーション３０２（図４）に、健康統合ネットワーク３０４（図４）に保存されたレコードデータの要求、保存、変更または他の方法によるアクセスを許容する。このようなデータは、３つのデータベース４０４、４０６及び４０８（図４）内のデータ、データ自体および当該データを記述するデータ、関連するバイナリデータ（画像、レントゲン等）等を含むことができる。レコードに関連し、タイプによって定義されたデータが、本明細書において、実施例およびルーチンネームにおいて「シング（ｔｈｉｎｇ）」と呼ばれる。レコードデータルーチン７０２は、健康統合ネットワーク内に保存された健康レコードからのデータにクエリーを行うようなルーチンを含むことができる。シングは、構築されたデータ（ＸＭＬ）、バイナリデータ（画像）等の形式であり得る。これらは、健康統合ネットワークにおいて単一のインスタンスデータを表し、通常はタイプやメタデータ（これは、値のタイプ、測定単位、コメント、データの開始点等を有し得る）に関連する。例えば、GetThingsルーチンは、上述の例に示された様にこの情報を読み出すために提供される。例えばＨＴＴＰ上のＸＭＬを使用してコール可能なルーチンは、コールされるルーチンを特定し、さらにデータクエリーのフィルターを特定する「info」セクションを含むＸＭＬ入力を要求し得る。当該フィルターは、以下のいずれかを含むことができる。
【００４４】
【表８】
2010508610.tif 000010
【００４５】
加えて、当該「info」セクションは、１つ又は複数のフォーマットセクションを特定して、特定されたフィルターに適合するシングに対して返送されるデータ及び適用される任意の変換、スタイルまたはスキーマをさらに判定することができる。要求がＡＰＩに送信され、ソフトウェア層が当該要求を処理してデータを収集したとき、応答が当該要求エンティティに返送される。当該応答は、適合するシングの結果、状態コード等のグループ化を伴う、上述したようなＸＭＬ応答であり得る。当該応答は、当該応答のレイアウトを定義することのできるＸＭＬスキーマに従い、かつ、それと共に送信することができ、特に、GetThingsルーチン応答は、シングに対して定義されたスキーマに従うことができ、これらは複数のセクションを有し得る。ＡＰＩは、当該要求において特定されたセクションを収集する。当該セクションは、レコードの有効日およびメンバシステムセット（シングが所属可能な高レベルなグループ）を定義可能なコアセクションと、将来のクエリーのためにレコードの生成および更新情報を定義可能な監査セクションと、シングに関するデータを表すＸＭＬを含むＸＭＬセクション（タイプがスキーマを定義する場合、当該データは当該スキーマに従うべきである。）と、バイナリデータ（画像／レントゲン等）のためのＢＬＯＢセクションと、監査に関するノート（ｎｏｔｅ）を含み得る１つ又は複数の注釈を定義可能な注釈セクションと、当該データが所属する１つ又は複数のユーザ定義セットを定義するセットセクション（ｓｅｔｓ  ｓｅｃｔｉｏｎ）と、当該シングに対する種々の権利付与許可の概要を記述する許可セクションとを含む。同様に、レコードデータルーチン７０２は、新しいシングを形成するための、かつ／または現存のシングを更新するためのPutThingsルーチンを提供することができる。当該要求は、上述したようにＸＭＬ形式でもよく、加えるべきシングは上述のシングのスキーマに従うように要求されてもよい。このルーチンは、結果コード及び生成された／更新されたシングのＩＤを返信することができる。加えて、シングを削除するためにRemoveThingsルーチンを提供することができ、ここにおいて、当該要求はGetThings要求と同様の要素を含むことができる。しかし、当該特定されたシングは削除され、返信されない。さらに、GetAuthorizedRecordsルーチンが、要求エンティティが許可を有する既知のレコードＩＤにクエリーを行うために提供されてもよい（例えば、当該要求エンティティは当該データが所属するユーザではない。）。このルーチンは、スキーマに従って、かつ／またはそれを伴って当該レコードに返送され得る。
【００４６】
ＡＰＩ７００は、一組のアカウントルーチン７０４を提供して、健康統合ネットワークにおけるユーザ及びグループを管理することができる。例えば、特定されたフィルタ基準に適合するユーザーのアカウント情報の減少された一組（ａ  ｒｅｄｕｃｅｄ  ｓｅｔ）を収集することを要求アプリケーションに許容するQueryPersonsルーチンを提供することができる。この目的を達成するために、要求は要求スキーマに従うことを必要とされてもよい。利用可能なフィルターには、読み出される個人の名前、ＩＤ、電子メールアドレス等を含んでいてもよく、これらの要素が特定された特徴のいずれかを含んでいる場合に肯定的な結果の返送をチェック可能である。当該結果は、スキーマ（ＸＭＬ等）に従っていることが必要とされ得る。さらに、GetPersonInfoルーチンが提供されて、名前、電子メールアドレス、電子メールアドレスの検証状態、アプリケーション設定、権利付与レコード等を含む要求ユーザのアカウント情報を要求することができる。加えて、同様のグループルーチンを提供して、ユーザに論理グループに属することを許容することができる。従って、例えば、GetGroupルーチンのようなルーチンを提供して、たとえばメンバＩＤを含むグループに関する情報の読み出しを行うことができる。要求および応答の両方は、データを解釈するためにＸＭＬに従うことを必要とされてもよい。
【００４７】
加えて、ＡＰＩ７００は、アプリケーションルーチン７０６を提供して、ＡＰＩ７００及び健康統合ネットワークを使用した登録及び配置（ｌｏｃａｔｉｏｎ）を許容することができる。例えば、GetApplicationルーチンを提供して、健康統合ネットワークに登録された１つ又は複数のアプリケーションに関連した情報を収集することができる。特定されたパラメータは、アプリケーション名前及び／又は既知であればＩＤを含むことができる。当該ルーチンは、配置された１つ又は複数のアプリケーション（名前およびＩＤ）に加えて、当該アプリケーションが権限付与及び／又は受諾を必要とするか否か等を返信することができる。さらに、AddApplicationルーチンも提供して、健康統合ネットワークにアプリケーションを登録することができる。当該要求は、当該アプリケーションに関するＩＤ（証明書を使用して生成されたもの）、当該アプリケーションの名前、すべての要求を検証するために使用される公開暗号化キー、レコードレベル権限付与、ルーチンレベル権限付与、アプリケーション設定（ＸＭＬ形式等）、当該アプリケーションを使用するために権限付与が必要か否か、及び当該アプリケーションを使用するのに受諾が必要か否かに対応したパラメータを伴ったＸＭＬとして送信することができる。受諾は、エンドユーサー用の使用許諾契約書（ＥＵＬＡ）の許諾等のステップを含むことができる。例えば、当該ルーチンは、当該アプリケーションのＩＤ及び状態コードを返信することができる。
【００４８】
さらに、ＡＰＩ７００は、例えば所与のシング及び／又はレコードに関するセキュリティを管理するセキュリティルーチン７０８を含むことができる。これらのルーチンは、所定のレコードに関して権限付与されたユーザに関連した許可を取得するためのGetPermissionsルーチンを含むことができ、この許可は、当該ユーザのＩＤ及び許可情報が要求されているレコードのＩＤを必要としてもよい。その後、当該ルーチンは、ユーザまたはグループに関するレコードＩＤ、当該レコードに関して存在する許可、当該許可が適用されるレコード内のシング、及び。当該許可が適用されない任意の除外されたシングに関連する一組のルールを返信することができる。同様に、GetAuthorizationsルーチンを提供して、特定のシングにアクセスを有するユーザまたはグループのＩＤを取得することができる。この目的を達成するために、シングＩＤが入力の許可規格を伴って提供され、当該ルーチンは、要求されたシングに対するアクセスのレベルを有するユーザ及び／又はグループのリストを返信する。加えて、AddPermissions及びRemovePermissionsルーチンを提供して、所与のレコードに対する新しい許可の設定および取消を行うことができる。セキュリティルーチン７０８は、GetEffectivePermissionsルーチンを含み、様々な許可を有するグループの一部でもあるユーザに関するレコード上の許可情報を収集することができる。このルーチンは、グループメンバシップまたはユーザレベルに与えられた許可に起因してもしなくても、最良の許可情報を当該ユーザに提供する試行が可能である。例えば、さらなるルーチンを提供することができ、これらのルーチンは健康統合ネットワーク内でのみ使用されるものでもよい（管理システム及び／又は当該ネットワークに加わる他のタイプのシステムによって）。さらに、ユーザに関する認可機能を提供するルーチンが提供されて、他のアプリケーション及び会社等の代わりに健康統合ネットワークによって提供されたサービスを承認し得る。これらは、例えば、システムの使用に対するインセンティブ、異なるアプリケーション供給者からのプロモーション、サービスの使用に対するクーポン等を提供するルーチンも含み得る。
【００４９】
上述したように、先に説明された実施形態は例を通してＸＭＬの文脈で言及されているが、このようなルーチンを提供する他の方法を用いることができ、例えば、ＳＤＫが．ＮＥＴを使用して公開（ｅｘｐｏｓｅ）することができ、ＨＴＴＰ上のＸＭＬよりもむしろフォーマットを特定するドット表記／パラメータのコール（ｃａｌｌｓ  ｉｎ  ａ  ｄｏｔ  ｎｏｔａｔｉｏｎ／ｐａｒａｍｅｔｅｒ）を解釈することができる。当該パラメータは、ＸＭＬまたは他のタイプのパラメータであり得るが、ＨＴＴＰ上のＸＭＬが前述の例において使用された様に、送信され受信される実質的なデータは同一である。
【００５０】
ＡＰＩ７００は、健康統合ネットワークを保守する権限を付与された者、例えばカスタマーサービス担当者によってのみアクセス可能な一組の管理ルーチン７１０をさらに含むことができる。これらのルーチンは、健康統合ネットワークにおけるほぼ任意のシング及び／又はレコードを変更するためのスーパーユーザレベルの権限付与を許容することができる。これらのルーチンは、上述と同様または個別のアーキテクチャ内で実施して、潜在的なハッキング等からの保護を行うことができる。
【００５１】
ＡＰＩ７００は、一組のインテリジェンスルーチン７１２も公開し得る。インテリジェントルーチン７１２を生成して特定のアプリケーション又はパッケージに合わせて調整し、サードパーティのアプリケーション開発におけるＡＰＩの使用を補佐する。例示のルーチンは、アプリケーションが使用を予定するデータに対するＸＭＬスキーマを開発者が生成することを助ける。このことは、新しい可能なデータ値、タイプ及びコンテナ（ｃｏｎｔａｉｎｅｒ）を開発者が迅速に追加することを可能とし得る。このことは、バッチモードにおいて実施することができ、当該ルーチンは当該情報と当該アプリケーションとを関連付けることができる。これらのルーチンは、サードパーティによってＡＰＩ７００のアドオンとして生成され、リッチデータへの単純なアクセスを容易にすることができる。例えば、企業は、ルーチンコール名においてその商号（trade name）を使用してその専有データにアクセスできるようにパブリックルーチンを公開して、有益なデータを公開する開発の促進のための金銭的インセンティブを追加的に生成することができる。ＡＰＩ７００及びいくつかのルーチンは、他のものがアクセスアプリケーションに近接して、その上に、またはその内部に存在している一方で、リモートに存在し得ることが理解されるべきである。実際、いくつかのルーチンは、拡張された機能および使用容易なより効率的なルーチンを許容するために、デバイスにダウンロード可能としてもよい。これらは、パッケージされた状態または個別にダウンロード可能であると同時に、自動更新としても可能であり、またソフトウェア開発キットの一部にもなり得る。
【００５２】
インテリジェントルーチン７１２の他の実施例は警告システム機能としてもよく、警告システム機能は、システム内の特定のイベントに続いて、かつ／または何らかの閾値の超過が起こると、ＡＰＩはその情報に精通した適切な当事者に通知を行う。例えば、血糖値レベル測定器が多数の低測定値または１つの致命的な低測定値を受信した場合、測定値は、ＡＰＩ７００へ送信されるとインテリジェントルーチン７１２をトリガして、健康統合ネットワーク内に列挙されたＥＭＳ及び／又は緊急連絡先に通知することができる。専らこの機能に基づいて生成されたデバイスを思い浮かべることができるだろう。多くの人が常に身に付けていられる自動パルス検出装置は、低パルスまたは無パルス（または速いパルス）を検出して専門家及び／又は緊急連絡先に通知しても良い。加えて、当該デバイスは、ＧＰＳ（Global Positioning System）であっても良く、ＡＰＩ７００は当該デバイスのＧＰＳ座標を取得して警告されたシステム／関係者（ｐａｒｔｙ）に当該座標を提示することができる。従って、別のインテリジェントルーチン７１２は、ＧＰＳ座標を住所に解読して、さらに通知されたシステムまたはユーザの現在位置からの道順を提供することができる。ＡＰＩ７００は、データ機能に加えてこのようなサービスを提供できるが限定はされないことが理解されるべきである。
【００５３】
さらに、通信ルーチン７１４を提供して、例えば、健康統合ネットワーク内のユーザ、デバイス、アプリケーション及び他のエンティティに自動的に情報を通信することを容易にすることができる。このような通信は、ネットワークの内部及び／又は外部で起こり得る。内部通信には、イベント、警告等を含めることができる。例えば、放射線科医はユーザのレントゲンをかかりつけの医師のアプリケーションに送信可能である。他の例は、病歴の告知、処方箋またはそれに関連する情報の変更、予約のリマインダー等のような健康警告を含む。外部通信には、たとえば電子メール（ｅメール）、ファクシミリ、インスタントメッセージ等を含めることができる。以前の例において、レントゲンは電子メールでかかりつけの医者に送信することができた（例えば添付ファイルで）。加えて、同期ルーチン７１６を供給して、記載された本発明の分散型の健康統合ネットワーク間の通信を容易にすることができる。特に、２以上の健康統合ネットワークが存在してもよく、ユーザは異なる健康統合ネットワーク内に保存された情報を要求することができる。従って、同期ルーチン７１６は、システム間の通信を容易としてこの目的を達成し得る。複数のリモートに位置する健康統合ネットワークを有することは、世界の各地で効率的なアクセスを提供し、同期ルーチン７１６は、セキュリティ及び／又はプライバシーの層を提供し得ることが理解されるべきである。加えて、同期ルーチン７１６は、複数の健康統合ネットワーク内の冗長性を提供して、データのアクセス性の向上を促進する。
【００５４】
上述したシステム、アーキテクチャ等は、いくつかのコンポーネント間のインタラクションに関して説明されてきた。このようなシステム及びコンポーネントは、記載されたコンポーネントまたはサブコンポーネント、記載されたコンポーネントまたはサブコンポーネントのうちのいくつか、及び／又は追加のコンポーネントを含むことできることを理解されたい。サブコンポーネントは、親コンポーネントに含まれるコンポーネントというよりもむしろ他のコンポーネントと通信可能に接続されたコンポーネントとして実装することもできる。さらに、１つ又は複数のコンポーネント及び／又はサブコンポーネントは、単一コンポーネントとして一体化して、統合された機能を提供してもよい。システム、コンポーネント及び／又はサブコンポーネントの間の通信は、プッシュモデル及び／又はプルモデルのいずれかに従って遂行され得る。当該コンポーネントは、簡潔さのために本明細書中に具体的に記載されていないが当業者には知られている１つ又は複数の他のコンポーネントと情報をやりとりすることもできる。
【００５５】
さらに、理解されるように、開示されたシステム及び方法の様々な部分が、人工知能、マシンラーニング、知識ベースもしくはルールベースのコンポーネント、サブコンポーネント、プロセス、手段、手順またはメカニズム（例えば、サポートベクターマシン、ニューラルネットワーク、エキスパートシステム、ベイジアンネットワーク、ファジー理論、データ融合エンジン、分類子等）を含みか又はそれらからなっていてもよい。とりわけ、このようなコンポーネントは、特定のメカニズムまたはそれによって実行されるプロセスを自動化して、システム及び方法の一部を、例えばコンテクスト情報に基づいた推測行動によって、さらに適応性があり効率的で高知能にすることができる。例示であって限定するものではないが、このようなメカニズムはマテリアライズドビュー（ｍａｔｅｒｉａｌｉｚｅｄ  ｖｉｅｗ）等の生成に関連して使用され得る。
【００５６】
上述された例示的システムを考慮すると、開示された本発明に従って実施される手順は、図８及び９のフローチャートを参考にしてより理解されるだろう。説明を簡単にするために手順は一連のブロックで示され説明されるが、請求される発明は、当該ブロックの順番に限定されないことが理解されるべきである。それは、いくつかのブロックは本明細書に説明されるのと異なる順番で、かつ／または他のブロックと同時に生じ得るからである。さらに、以下に説明される手順の実施に全てのブロックが必要でなくともよい。
【００５７】
図８は、ＡＰＩを介して健康統合ネットワークからのデータを要求するアプリケーションのための手順をしている。当該要求は、当該要求されたデータまたは他のデータを含む健康統合ネットワーク内に存在する任意のデータに対するものであり得る。当該要求は、ＨＴＴＰ上のＸＭＬ、ＳＤＫ及び／又はこれらのアーキテクチャの両方もしくは組み合わせに加えて、任意の要求／応答タイプのアーキテクチャを含む複数のアーキテクチャで特定され得る。当該要求は、要求／応答タイプでも、及び／又は、要求を受けるとデータチャンネルが開いた状態を維持し、更新が当該チャンネルに向けて自動的に送信されて要求アプリケーションによって受信されるサブスクリプションベース（ｓｕｂｓｃｒｉｐｔｉｏｎ  ｂａｓｅｄ）でもよい。後者の形式は、警告／警報、自動更新および上述されたようなものに対して有用であり得る。例えば、非常に低いインシュリンレベルの測定値によって、インシュリン測定器は当該情報を健康統合ネットワークへ送信することができる（これが要求／応答である。）。その後、当該健康統合ネットワークは、開いたチャンネルを通じて医院のアプリケーション及び／又は緊急連絡先のアプリケーション（ページ及び／又はテキストメッセージを送信可能なアプリケーション等）へ、ユーザの低インシュリンレベルの警告を送信して、この情報を要求することの必要性を軽減する（これはサブスクリプションベースのシステムの例である。）。この特定の手順８００は要求／応答を示すが、サブスクリプションベースの方法も記載された本発明に従って使用できることを理解されたい。
【００５８】
参照番号８０２を参照すると、アプリケーションは、本明細書に記載されたように、健康統合ネットワークのＡＰＩからのデータに対する要求を開始する。前述したように、当該アプリケーションは、まずＡＰＩを介して健康統合ネットワークに登録するように要求されてもよく、それは別の形式の要求であってもよい。さらに、要求は、健康統合ネットワーク内のデータのクエリーに加えてデータを保存することあってもよい。また、当該要求アプリケーションは、ＡＰＩとの通信能力を有する多数のデバイス、アプリケーション等であってもよい。例えば、当該アプリケーションは、外部の個人的なフィットネスデバイスと伝統的に動作可能なサードバーティアプリケーション（心拍数モニター時計等）であってもよく、このサードバーティアプリケーションは、健康統合ネットワークＡＰＩと情報をやりとりして、外部の個人的なフィットネスデバイスにより収集されたデータを保存および読み出すように適合されている。加えて、個人フィットネスデバイスは、ＡＰＩ自体を介して健康統合ネットワークと通信する技術を備えてもよい。さらに、要求がデータに対するものであった場合、当該アプリケーションは、クエリータイプ機能のフィルタ及び読み出されるデータのセクションを特定してもよい。例えば、レントゲン情報を要求した場合、当該アプリケーションは管理情報のみを必要とする（そして実際に管理情報のみの受信の権限付与を受ける）場合がある。従って、当該要求はこのことを指定して、健康統合ネットワークからの応答の際にレントゲン画像（これはおそらく他の関連データに比べて大きい。）を送信することの必要を軽減することができる。
【００５９】
当該要求が為された後、当該アプリケーションは、８０４において当該ＡＰＩからの応答の受信のために待機する。当該要求は、当該アプリケーションに関して同期的でもよく、これは、当該要求の返送を待つ間、当該アプリケーションは他のタスクを遅らせることを意味する。しかし、当該アプリケーションは、非同期的状況で要求を行い、応答を待つ間に当該アプリケーションが処理を継続することもできる。通常、当該機能はコールバック機能、複数の生成スレッド（ｍｕｌｔｉｐｌｅ  ｓｐａｗｎｅｄ  ｔｈｒｅａｄｓ）等により実装することができる。加えて、当該アプリケーションは、現在のコールの返信待ちの間にＡＰＩに他のコールを行うことができる。
【００６０】
参照番号８０６において、当該ＡＰＩ応答が当該アプリケーションによって受信される。当該データは、例えば、特定された状態コードを伴ってＸＭＬ形式で届いてもよい。当該ＸＭＬは、データに対する要求から結果として得られるデータも含み得る。当該データは、変換、スタイル及び／又はスキーマ情報を伴う単純な形式（ｐｌａｉｎ  ｆｏｒｍ）であるか又は既にこれらが適用されたストリングであってもよい。当該アプリケーションは、受信した情報のレンダリング及び／又は他の方法による処理を如何に行うかを知っているので、当該アプリケーションのユーザは当該情報を最適に閲覧することができ、参照番号８０８においてＸＭＬスキーマに従ってそうすることが可能である。
【００６１】
図９は、ＡＰＩを介して健康統合ネットワークからのデータを要求することを促進する手順９００を示している。当該データは、健康統合ネットワーク内に存在するものとして上述された任意のデータであってもよく、これらの情報はネットワーク及び／又はデータベースにわたって分散していてもよい。当該要求は、データのみ、データ及びタイプ情報、データ及び変換、スタイル、並びに／又はスキーマ情報等に対するものであり得る。さらに、上述したように、当該要求はＨＴＴＰ上のＸＭＬ、ＳＤＫ及び／又はそれらの組み合わせ並びに任意の要求／応答プラットフォームを使用して生成され得る。
【００６２】
参照番号９０２において、データに対する要求がアプリケーションから受信される。当該要求は、ＡＰＩ、ソフトウェア層及び／又は組み合わせによって受信され得る。上述したように、当該要求は、健康統合ネットワークで入手可能な任意のレコードに対するもの（及び、エラーがおそらく生じるが利用不可能なレコードに対するもの）であり得る。当該ＡＰＩ及び／又はソフトウェア層は、キャッシュ、監査等の要求により追加の処理を実行することが可能である。加えて、受信エンティティは、健康統合ネットワークからのデータの要求の継続前に、なんらかの認証／権限付与ルーチンを実行してもよい。あるいは又は追加的に、認証及び／又は権限付与が健康統合ネットワークによって実行されてもよい。
【００６３】
参照番号９０４において、関連する情報が健康統合ネットワークから読み出される。この情報は、要求されたデータ、及び／又は、権限付与、生成（ｆｏｒｍｕｌａｔｅ）、変換、スタイリングまたは当該要求されたデータに実行される他の動作を助ける追加のデータであり得る。当該データは、１つ又は複数のローカル又はリモートに保存されるデータベースから取得され得る。加えて、当該データベースは、互いに動作して当該データへのシームレスなアクセスを提供することができる。例えば、求められる情報がどこに存在し、読み出すことができるのかに関するインジケータを有するマスタデータベースが提供され得る。従って、一実施形態において、情報は、マスタデータベース又はそのインタフェースにのみ要求されればよく、マスタデータベースが情報をどこで検索するかを知っており、要求者にその情報を返信することができる。あるいは、当該ＡＰＩ及び／又はソフトウェア層はこの保存情報を知っているか又は取得することが可能である。
【００６４】
当該要求されたデータが適切な情報と共に返される場合、参照番号９０６において、変換スタイル及び／又はスキーマが当該データに適用される。例えば、変換は、キログラムからポンドのようなメートル法から米国単位への変換等を含む。変換は、たとえばストリングまたは２つの整数値を、収縮期及び拡張期血圧の血圧データ構造へ変換することを含む。同様に、スタイルは、７３（インチを表す整数）として保存された高さを６’１”の形式にレンダリングするような参照符号または特性の追加を含む。加えて、スキーマに、より複雑なデータ構造のデータレイアウトを記述するデータを与えることができる。当該ＡＰＩ及びソフトウェア層は、このスキーマを利用して特定の関連データを抽出するか、又は当該データの表示を生成するためにそのスキーマを適用することができる。例えば、上述の手順において、当該アプリケーションが、画像自体は含まないレントゲンに関する管理情報等のデータの一部のみを必要とする場合、当該スキーマを適用して要求された管理データのみを返信することができる。
【００６５】
その後、９０８において、当該データは当該要求アプリケーションに返送される。当該返送されたデータは、データのみ、上述された適用される変換、スタイル及び／若しくはスキーマを伴うデータ、またはその両方であり得る。従って、当該アプリケーションは、変換、スタイル及び／若しくはスキーマの全て、組み合わせ、又はその一部を使用することによって、当該要求エンティティの要求に応えるデータを形成することができる。データに無関係な（ｅｘｔｒａｎｅｏｕｓ）変換、スタイル及び／又はスキーマ情報を別に要求し、かつ／または、後の使用のために当該アプリケーションのローカルキャッシュ内に保存してもよい。
【００６６】
本明細書で使用される用語「コンポーネント」、「システム」等は、コンピュータ関連エンティティを指すことが意図されており、ハードウェア、ハードウェア及びソフトウェアの組み合わせ、ソフトウェア、または実行されているソフトウェアのいずれかである。例えばコンポーネントは、これらに限定されないが、プロセッサーで実行されているプロセス、プロセッサー、オブジェクト、インスタンス、実行ファイル（ｅｘｅｃｕｔａｂｌｅ）、実行スレッド、プログラム、及び／又は、コンピュータとすることができる。例として、コンピュータ上で実行されているアプリケーション及び当該コンピュータが共にコンポーネントでありうる。１つ又は複数のコンポーネントがプロセス及び／又は実行スレッド内に存在してもよく、コンポーネントが１つのコンピュータ上に位置しても、２つ又はそれ以上のコンピュータ間に分散されていてもよい。
【００６７】
「例示的」という語は、例、事例または実例としての役割を果たすという意味で本明細書において使用されている。「例示的」として本明細書に記載されているどのような態様または設計も、他の態様または設計よりも好ましい又は有利なものとして必ずしも解釈されるべきではない。さらに、例は、単に明瞭性および理解のために提供されており、本発明またはそれに関連する部分をいかなる形でも限定することを意味しない。無数の追加的または代替的な例を示すことができたが、簡潔性のために省略されたことが理解されるべきである。
【００６８】
さらに、本発明全体または一部は、基本的なプログラミング技術および／または工学技術を使用した方法、装置または製品として実装して、開示された発明を実施するようにコンピュータを制御するソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組み合わせを生産することができる。本明細書で使用される用語「製品（ａｒｔｉｃｌｅ  ｏｆ  ｍａｎｉｆａｃｔｕｒｅ）」は、任意のコンピュータ読み取り可能なデバイス又は媒体からアクセス可能なコンピュータプログラムを包含することを意図されている。例えば、コンピュータ読み取り可能な媒体は、これらに限定されないが、磁気記憶デバイス（例えばハードディスク、フロッピー（登録商標）ディスク、磁気ストライプ等）、光学ディスク（例えば、ＣＤ（ｃｏｍｐａｃｔ  ｄｉｓｋ）、ＤＶＤ（ｄｉｇｉｔａｌ  ｖｅｒｓａｔｉｌｅ  ｄｉｓｋ）等）、スマートカード及びフラッシュメモリーデバイス（例えば、カード、スティック、キードライブ等）を含む。加えて、搬送波を使用して、電子メールの送受信において又はインターネット若しくはＬＡＮ（ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）等のネットワークへのアクセスにおいて使用されるようなコンピュータ読み取り可能ま電子データの伝送が行われてもよいことが理解されるべきである。もちろん、当業者は、請求される本発明の範囲または精神から逸脱することなく、本構成に多くの変更を加えることができることを認識するだろう。
【００６９】
開示される本発明の様々な態様に関する状況を提供するために、図１０及び図１１並びに以下の議論は、開示される本発明の様々な態様を実施可能な適切な環境の簡潔で、一般的な説明を提供することを意図している。１つ又は複数のコンピュータ上で実行されるプログラムのコンピュータ実行可能命令の一般的状況において本発明が説明されてきたが、当業者は、本発明が他のプログラムモジュールとともに実施可能であることを認識するだろう。プログラムモジュールには一般的に、特定のタスクを実行し、かつ／または、特定のアブストラクトデータタイプを実装するルーチン、プログラム、コンポーネント、データ構造等が含まれる。さらに、当業者は、当該システム／方法が、シングルプロセッサ、マルチプロセッサまたはマルチコアプロセッサコンピュータシステム、ミニコンピューティングデバイス、メインフレームコンピュータ、パーソナルコンピュータ、ハンドヘルドコンピューティングデバイス（例えば、ＰＤＡ（personal digital assistant）、電話、時計等）、家庭用または産業用のマイクロプロセッサベースまたはプログラム可能な電子機器等を含む他のコンピュータシステム構成により実施可能であることを認識するだろう。説明された態様は、通信ネットワークを介してリンクされたリモート演算処理デバイスによってタスクが実行される分散型コンピューティング環境においても実施することができる。しかしながら、請求される本発明の態様の全てではなくともそのいくつかは、スタンドアローン型コンピュータにおいて実施することができる。分散型コンピューティング環境において、プログラムモジュールは、ローカルおよびリモートのメモリ記憶デバイスの両方に存在してもよい。
【００７０】
図１０を参照すると、本明細書で開示された様々な態様を実施するための例示的環境１０１０は、コンピュータ１０１２（例えば、デスクトップ、ラップトップ、サーバー、ハンドヘルド・パソコン、家庭用または産業用のプログラム可能な電子機器等）を備える。コンピュータ１０１２は、処理ユニット１０１４と、システムメモリ１０１６と、システムバス１０１８とを備える。システムバス１０１８は、これに限定されないが、システムメモリ１０１６を含むコンポーネントを処理ユニット１０１４に接続する。処理ユニット１０１４は、任意の利用可能な様々なマイクロプロセッサとすることができる。デュアルマイクロプロセッサ、マルチコア及び他のマルチプロセッサアーキテクチャが処理ユニット１０１４として使用され得ることが理解されるべきである。
【００７１】
システムメモリ１０１６には、揮発性及び不揮発性メモリが含まれる。例えば起動中におけるコンピュータ１０１２内の要素間の情報伝送のための基本ルーチンを含むＢＩＯＳ（basic input/output system）が、不揮発性メモリ内に保存される。例として、これに限定されないが、不揮発性メモリにはＲＯＭ（read only memory）が含まれる。揮発性メモリには、ＲＡＭ（random access memory）が含まれ、これは外部キャッシュとして動作して処理を容易にすることができる。
【００７２】
コンピュータ１０１２には、リムーバブル／ノンリムーバブル、揮発性／不揮発性コンピュータ記憶媒体が含まれる。例えば、図１０は、大容量記憶装置１０２４を示している。大容量記憶装置１０２４には、これらに限定されないが、磁気または光学ディスクドライブ、フロッピー（登録商標）ディスクドライブ、フラッシュメモリまたはメモリスティック等のデバイスが含まれる。加えて、大容量記憶装置１０２４は、別個の記憶媒体または他の記憶媒体と組み合わされた記憶媒体を含み得る。
【００７３】
図１０には、１つ又は複数のソフトウェアアプリケーション１０２８が示されていて、これはユーザ及び／又は他のコンピュータと適切なコンピュータ動作環境１０１０に示された基本的なコンピュータリソースとの間の媒介として動作する。このようなソフトウェアアプリケーション１０２８は、システムソフトウェア及びアプリケーションソフトウェアの一方または両方を含む。システムソフトウェアは、大容量記憶装置に保存することのできるオペレーティングシステムを含み、これはコンピュータシステム１０１２のリソースの制御および割り当てを行うように動作する。アプリケーションソフトウェアは、システムソフトウェアによるリソースの管理を、システムメモリ１０１６及び大容量記憶装置１０２４の一方または両方に保存されているプログラムモジュール及びデータを介して活用する。
【００７４】
コンピュータ１０１２は、１つ又は複数のインタフェースコンポーネント１０２６も含み、これらはバス１０１８に通信可能に接続されてコンピュータ１０１２との情報のやりとりを容易にする。例として、インタフェースコンポーネント１０２６は、ポート（例えば、シリアル、パラレル、ＰＣＭＣＩＡ、ＵＳＢ、ＦｉｒｅＷｉｒｅ等）、インタフェースカード（例えば、サウンド、ビデオ、ネットワーク等）等とすることができる。インタフェースコンポーネント１０２６は、（有線または無線によって）入力を受信し、出力を供給することができる。例えば、これらには限定されないが、マウスのようなポインティングデバイス、トラックボール、スタイラスペン、タッチパッド、キーボード、マイクロフォン、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナ、カメラ、他のコンピュータ等のデバイスから入力を受信することができる。出力は、インタフェースコンポーネント１０２６を介して、コンピュータ１０１２によって出力デバイスへ供給することができる。出力デバイスには、他にもあるが、ディスプレイ（例えば、ＣＲＴ、ＬＣＤ、プラズマ等）、スピーカー、プリンタ及び他のコンピュータが含まれる。
【００７５】
図１１は、本発明が情報をやりとり可能な例示的なコンピューティング環境１１００の概略ブロック図である。システム１１００は、１つ又は複数のクライアント１１１０を備える。クライアント１１１０は、ハードウェア及び／又はソフトウェア（たとえば、スレッド、プロセス、コンピュータデバイス）であり得る。システム１１００は、１つ又は複数のサーバ１１３０も備える。従って、システム１１００は、他にもあるが、２層（ｔｗｏ−ｔｉｅｒ）クライアントサーバモデルまたは多層（ｍｕｌｔｉ−ｔｉｅｒ）モデル（例えば、クライアント、中間層サーバ、データサーバ）に対応し得る。サーバ１１３０は、ハードウェア及び／又はソフトウェアでもあり得る（例えば、スレッド、プロセス、コンピュータデバイス）。例えば、サーバ１１３０は、スレッドを内包して本発明の態様を利用することによって変換を実行し得る。クライアント１１１０とサーバ１１３０との間で可能な１つの通信は、２又はそれ以上のコンピュータプロセス間の伝送されるデータパケットの形式であってもよい。
【００７６】
システム１１００は、通信フレームワーク１１５０を備え、これはクライアント１１１０とサーバ１１３０との間の通信を容易にするために使用することができる。ここにおいて、上述したように、クライアント１１１０は、プログラムアプリケーションコンポーネントに対応し、サーバ１１３０は、インタフェース機能及び追加的に記憶システムの機能を提供することができる。クライアント１１１０は、１又は複数のクライアントデータ記憶デバイス１１６０と動作可能に接続されていて、当該クライアントデータ記憶デバイスは、情報をクライアント１１１０にローカルに保存するために使用することができる。同様に、サーバ１１３０は、１つ又は複数のサーバデータ記憶デバイスに動作可能に接続されていて、当該サーバデータ記憶デバイスは、情報をサーバ１１３０にローカルに保存するために使用することができる。
【００７７】
例として、プログラムアプリケーションコンポーネントは、クライアント１１１０を介して、１つ又は複数のサーバ１１３０（および、たとえば、サーバ１１３０に保存された又はサーバ１１３０からアクセス可能なＡＰＩ）に個人健康情報を要求することができる。サーバ１１３０は、データ記憶デバイス１１４０または複数のデータ記憶デバイスから所望のデータを取得して、例えば変換、スタイル及び／又はスキーマを適用することができる。続いて、他のプログラムアプリケーションコンポーネントが、データサーバ１１３０からの同一または異なるデータへのアクセスを要求することができる。
【００７８】
上述してきた内容は、請求される本発明の態様の例を含む。もちろん、請求される本ク発明を説明する目的のために考え得るすべてのコンポーネント又は手順の組み合わせを記載することは不可能であるが、当業者は、開示された本発明の多くの他の組み合わせ及び並び替えが可能であることを認識するだろう。従って、開示された本発明は、添付の特許請求の範囲の精神および範囲内にある代替形態、変形形態、変更形態等のすべてを包含することが意図されている。さらに、詳細な説明または特許請求の範囲のいずれかにおいて使用されている限りにおいて、用語「含む」、「備える」、「有する」（“ｉｎｃｌｕｄｅｓ，”“ｈａｓ，”ｏｒ“ｈａｖｉｎｇ”）またはそれらの変形は、用語「含む」、「備える」（“ｃｏｍｐｒｉｓｉｎｇ”）がクレーム内で移行語（ｔｒａｎｓｉｔｉｏｎａｌ  ｗｏｒｄ）として用いられるときに解釈されるのと同様に、包含的であることが意図されている。
【図１】
2010508610.tif 000011
【図２】
2010508610.tif 000012
【図３】
2010508610.tif 000013
【図４】
2010508610.tif 000014
【図５】
2010508610.tif 000015
【図６】
2010508610.tif 000016
【図７】
2010508610.tif 000017
【図８】
2010508610.tif 000018
【図９】
2010508610.tif 000019
【図１０】
2010508610.tif 000020
【図１１】
2010508610.tif 000021
【国際調査報告】
2010508610.tif 000022
2010508610.tif 000023
2010508610.tif 000024