JP2014179070A - 情報管理のためのヘルスケアアプリケーションの連結 - Google Patents

Abstract

【課題】医療ケアアプリケーションと分析インフラとの間の情報交換を管理するコンピュータ実装方法、ソフトウェア及びシステムを提供する。
【解決手段】ユーザの医療状態に関連する第１医療アプリケーションへのアクセスをユーザへ提供する工程と、医療データを受信する工程であって、医療データの少なくとも一部は、第１医療アプリケーションを介してユーザから受信され、医療データは医療状態に関連するプライベート情報を含む工程と、医療データを、ユーザの医療状態に関する結論の生成するためのその後の使用のためにセキュア情報リポジトリへ送信する工程と、ユーザの医療状態に関連する第２医療アプリケーションを識別する工程と、ユーザの医療状態に関する結論を生成するために第２医療アプリケーションによって医療データを使用する工程とを有する。
【選択図】図１

Description

関連出願との相互参照
本願は、２０１３年２月２７日に出願された米国仮出願第６１／７７０，０４２号への優先権を主張し、この仮出願は参照により全体が本明細書に組み込まれる。

無線電話は消費者に非常に人気のあるデバイスになってきた。無線電話はアプリケーションストアから無線電話へ１以上のアプリケーションをダウンロードし、１以上のアプリケーションを呼び出してもよい。アプリケーションの例は、ゲーム、写真編集ソフトウェア及びソーシャルネットワークアプリケーションを含む。時として、モバイルオペレーティングシステム上のモバイルデプロイのために特別に設計されたアプリケーションは、「アプリ（apps）」と呼ばれる。しかし、アプリケーションという用語は一般に、所与のタスクを実現するための一連の命令を含む、計算デバイスが実行しうる任意のプログラムを指す。時として、ユーザが実現したいタスクは、ヘルスケア及び医学的治療に関するタスクである。一部のアプリケーションは、患者が状態を監視することを支援したり、医師が患者を治療するための情報をより効率的に収集・分析することを可能にしたり、データを集約し、製薬会社のようなヘルスケア会社が自身の業務を支持する結論を引き出すことを可能にしたりするような、ヘルスケアタスクに関する情報を管理する際に様々な当事者によって用いられるように特別に開発されてもよい。

本開示は、分析インフラと相互作用する医療ケアアプリケーションの流通を制御するためのコンピュータに実装される方法、ソフトウェア及びシステムに関する。本開示は、医療ケアアプリケーションと分析インフラによる医療情報処理との間のセキュアな情報交換を容易にする実装にも関する。

１つのコンピュータ実装方法は、モバイルデバイス上にあり、ユーザの医療状態に関連する第１医療アプリケーションへのアクセスを前記ユーザへ提供する工程と、医療データを受信する工程であって、前記医療データの少なくとも一部は、前記モバイルデバイスによって提供される情報ゲートウェイにおいて前記第１医療アプリケーションを介して前記ユーザから受信され、前記医療データは前記医療状態に関連するプライベート情報を含む、工程と、前記医療データを、前記ユーザの前記医療状態に関する結論の生成するためのその後の使用のためにセキュア情報リポジトリへ送信する工程と、
前記ユーザの前記医療状態に関連する第２医療アプリケーションを識別する工程と、前記セキュア情報リポジトリにおいて前記医療データへのアクセスを前記第２医療アプリケーションに提供するために前記第２医療アプリケーションを認証する工程と、前記認証された第２医療アプリケーションと前記医療データを共有する工程と、前記ユーザの前記医療状態に関する結論を生成するために前記第２医療アプリケーションによって前記医療データを使用する工程とを有する。

他の実装は、対応するコンピュータシステム、装置及び１以上のコンピュータストレージデバイスに記録されたコンピュータプログラムを含み、それぞれは方法の動作を実行するように構成される。１以上のコンピュータのシステムは、システムにインストールされたソフトウェア、ファームウェア、ハードウェア又はソフトウェア、ファームウェア若しくはハードウェアの組合せのおかげで動作時にシステムに動作を実行させる特定の演算又は動作を実行するように構成されうる。１以上のコンピュータプログラムは、データ処理装置によって実行された場合に、装置に動作を実行させる命令を含むおかげで、特定の演算又は動作を実行するように構成されうる。

前述の実装及び他の実装はそれぞれ、オプションとして以下の機能の１以上を含んでもよい。一部の実装では、前記結論は、前記ユーザの前記医療状態の治療を支援する。このような実装では、前記結論は、診断と、ユーザが特定の治療法を開始すべきであるという判定と、ユーザが特定の治療法を中止すべきであるという判定と、ユーザがケアプランを変更すべきであるという判定と、医療状態を治療するためにユーザが医療ケアアプリケーションにアクセスすべきであるという判定と、ユーザが医療専門家との予約をスケジュールすべきであるという判定とのうちの１つであってもよい。他の実装では、前記結論は、健康上の意思決定を行うためのヘルスケアプロセスの参加者を助ける情報であってもよい。一部の実装では、前記結論は、前記ユーザについての前記医療データを、他のユーザについて取得された識別不能な集約医療データに対して比較することに少なくとも部分的に基づく。

一部の実装では、前記第１医療ケアアプリケーションは、特定の製薬化合物、特定の医療状態、特定の製薬製造者又は特定のヘルスケア専門家に関連してもよい。他の実装では、前記医療情報の少なくとも一部は、電子医療記録システムと、医療請求記録システムと、小売薬局記録システムと、ヘルスケア専門家記録システムと、製薬会社記録システムと、モバイル計算デバイスに通信可能に結合されたセンサとのうちの少なくとも１つから受信されたデータから取得される。

この明細書に記載される主題は、以下の有用な特徴の１以上を実現するために特定の実装において実装されうる。第１に、医療アプリケーションは、医師、無線デバイス提供者、キャリア、病院若しくは薬剤師又は互いに関連して動作するこれらのエンティティの１以上によってユーザに提供されてもよい。これに代えて、ユーザは、自身が直面している健康上の心配事に関連すると考える医療アプリケーションにアクセスできてもよい。これらのアプリケーションは、他では行えないかもしれない有意な結論を導出するために様々なソースからの医療情報の使用を促進し容易にしてもよい。第２に、アプリケーションが流通される制限の側面は、患者が医療状態を管理することを助けるアプリケーションのデプロイを支援しうる。第３に、情報は、不注意による情報の開放を防ぐ方法で提供されてもよい。

他の実装は、他の有用な特徴を提供してもよい。例えば、一部の実装は、医療ケアアプリケーションポータルへのアクセスを提供してもよい。このような医療ケアアプリケーションポータルは、医療ケアアプリケーションポータルによってユーザが１つのアプリケーションへのアクセスが提供され、その後に当該アプリケーションと相互作用することによってユーザがポータルへ情報を提供するように、アプリケーション間でのセキュアな情報交換を容易にするような有用な特徴が提供されてもよい。その後、ポータルは、アプリケーション間でヘルスケア情報を収集し供給するためのセキュアな集中型インフラを提供してもよい。この共有プロセスの一部として、第２アプリケーションがヘルスケア情報にアクセスするために認証されるように、第２アプリケーションがユーザに提供されてもよい。その後に、第２アプリケーションは、有用な方法でヘルスケア情報を使用できてもよい。第２アプリケーションがヘルスケア情報を利用しうる１つの方法は、元のユーザの治療を支援することである。しかし、元のユーザ以外の他の当事者が、ヘルスケア情報から有意な結論を導出するために第２アプリケーションへのアクセスを与えられてもよいことが認識されるだろう。例えば、他の当事者は、業務上の意思決定又は診断・治療の意思決定を行うことを助けるようにヘルスケア情報を使用するために第２アプリケーションを使用できてもよい。ヘルスケア情報が用いられうる多くの方法が以下に詳細に議論されるが、一般に、ヘルスケア情報はまた、ヘルスケアプロセスの他の参加者が経済的目的又は他の目的を達成することを可能にしてもよい。例えば、製薬会社はマーケティングを支援するために情報を使用してもよいし、保険業者は費用節約対策を支援するために情報を使用してもよいし、政府機関は法律行使用途を支援するために情報を使用してもよい。

この明細書の主題の１以上の実装の詳細が添付の図面及び詳細な説明において以下に説明される。当該主題の他の特徴、側面及び利点は詳細な説明、図面及び特許請求の範囲から明らかになるだろう。

分析目的のための識別不能データを統合するように構成された計算システム１００に実装される例示の医療ケアアプリケーション流通システムを説明する図である。 無線デバイスに存在する医療ケアアプリケーションからのスクリーンショットである。 患者がどのようにして喘息症状を管理しうるかを示す一連のビューを説明する図である。 医療ケアアプリケーションがヘルスケア情報の交換を連携するためのインタフェースを確立しうるように、医療ケアアプリケーションがどのように下位アプリケーションと相互作用しうるかを示す図である。 医療ケアアプリケーションポータルがモバイル計算デバイスと情報を交換するプロセスのフローチャートである。 モバイルデバイスでアプリケーション間でのセキュアな情報交換を管理するための例示のシステムを説明するブロック図である。 医療ケアアプリケーションポータルが、複数の医療ケアアプリケーションへのアクセスと、複数の医療ケアアプリケーション間のセキュアな情報交換とを管理するプロセスのフローチャートである。

この開示は一般に、ヘルスケア関連アプリケーションを流通し、当該ヘルスケア関連アプリケーションが互いに、そして分析・報告インフラと相互作用できるようにするためのコンピュータに実装される方法、ソフトウェア及びシステムを記載する。ヘルスケア関連アプリケーションは一般に、モバイル計算デバイスで実行されることが意図される。これらの動作の一部として、アプリケーションはデータを収集する。アプリケーションが続いて分析・報告インフラと相互作用する場合に、当該データは、ケアの提供において患者が治療及び介護者を得ることを支援できる医学的意義のある結論を当該アプリケーションが導出することを可能にする。１つのセットの実装において、この開示の主題は、ヘルスケア関連アプリケーションへのアクセスを管理する医療ケアアプリケーションポータルを伴ってもよい。ポータルは、ヘルスケア関連アプリケーションにアクセスする際のセキュリティを提供してもよい。ポータルはさらに、ヘルスケア関連アプリケーション間の情報交換を管理する。例えば、このような情報交換は、第１アプリケーションでデータを収集することと、その後に第２アプリケーションで当該データにアクセスして第１アプリケーションからのデータに基づいて結論を導出することとを伴ってもよい。

あるモバイル環境において、アプリケーションが互いに直接に相互作用することはできない。実装は、この問題に対処するための方法を提供してもよく、この方法ではポータルによってアクセスが提供される第１アプリケーションから情報を収集し、ポータルを用いて当該情報を集中型ストレージへ送信し、続いて別のアプリケーションによる使用のために集中型ストレージにアクセスすることが可能になる。このアクセスプロセスの一部として、アプリケーションが互いに情報を共有できるにもかかわらず、情報共有がセキュアな方法で行われることを保証するセキュリティ対策を統合することが可能である。

アプリケーションは、一般に、機能を提供する計算デバイスによって実行される命令セットを含む。しかし、アプリケーションは様々な形態をとりうる。一部のアプリケーションは、計算デバイスによって実行され、デスクトップオペレーティングシステムからのリソースを要求する排他的なローカルアプリケーションであってもよい。しかし、他のアプリケーションは、モバイルオペレーティングシステムによって実行されてもよい。さらに他のアプリケーションは、ブラウザがアプリケーションにホスティング機能を提供することを可能にするスクリプト、プラグイン又は他のブラウザ拡張及びアドオンなどのよって、ウェブブラウザを通じて提供されてもよい。時として、アプリケーションの機能が複数の機械によって、例えばクライアント・サーバ分散アーキテクチャ又はピア・ツー・ピア分散アーキテクチャにおいて提供されるように、アプリケーションが分散される。分散された機能は、クライアントが、１以上のサーバで実行される分析プラットフォームと相互作用するために個別のユーザが採用するモバイルデバイスである実装において特に重要であってもよい。

無線電話及び同様のモバイル計算デバイスに利用可能なアプリケーションの多くは、医療関連アプリケーション又はヘルス関連アプリケーションである。このようなアプリケーションは、医療関連問題又はヘルス関連問題に対処する多くのタイプの機能を有してもよい。医療関連アプリケーション及びヘルス関連アプリケーションの使用は、ユーザにとって多様な利点を有しうる。ユーザはヘルスケア展開プロセスに関与する人又はエンティティを含んでもよく、異なるアプリケーションは異なるユーザグループを対象としてもよい。医者は、医薬品相互作用のデータベースを記憶するアプリケーションを用いて薬物を管理してもよいし、患者は当該患者の血糖レベルに関する情報を記録・整理するアプリケーションを用いてもよい。製薬製造者は自身の販売する薬物に関するアプリケーションを流通してもよい。血圧降下剤を販売する製薬会社は、血圧測定結果を追跡するアプリケーションを提供してもよい。

さらに、情報を互いに供給する能力を有するアプリケーションを提供することが望ましい。情報共有は、複数の診断、特に治療が相互に関連する診断を有する患者の治療を支援しうる。例えば、肥満の患者は、糖尿病に苦しむだけでなく、高血圧にも苦しむかもしれない。当該患者に血糖追跡アプリケーションへのアプリケーションへのアクセスを与え、当該アプリケーションによって提供される情報を、血圧追跡アプリケーションによって提供される情報と連携することは有利でありうる。このような関連情報は、患者だけでなく、治療提供者にも使用されるものでありうる。例えば、医師は、どの血糖薬物が患者にとって最良の選択であるかを判定するために、当該患者がアプリケーションを用いて測った血糖測定結果にアクセスできることを望んでもよい。しかし、他の当事者は、共有情報から様々な方法で利益を受けてもよい。例えば、保険会社は、様々なユーザからの集約情報を検査し、当該集約情報に基づいて金銭を節約する方法を判定できてもよい。例えば、保険会社は、異なるスタチンを摂取する個人のうちの何人がその後に心筋梗塞によって入院したかを追跡し、この分析を実行することによって、最良の診療結果が何であるかだけでなく、どの医薬品が患者へ処方するのに最も費用効率が高いかを判定できてもよい。よって、情報共有は、実装が、患者ヘルス結果を向上し、又は業務意思決定を助けるためのような結論を生成することを可能にできる。

このようなアプリケーションは自身の機能を実行するために必要な情報を収集する。例えば、アプリケーションは血糖レベルを監視し、ユーザがいつインスリンを摂取する必要があるかをユーザに警告するために当該情報を用いてもよい。しかし、ユーザの血糖レベルに関する情報は、血糖薬物を処方することを望む医者、又は血糖薬物を市販しようとしている製薬会社にも関連しうる。

例示のために、本明細書に記載される様々な実装は、患者、処方者及び製薬小売業者に関するデータを受信し、１以上の医療ケアアプリケーションの販売／流通に関してこれらの利害関係者を評価する医療ケアアプリケーション流通システムに関して記載される。上述のように、このような医療ケアアプリケーション流通システムは、医療ケアアプリケーションによって受信された情報から結論を導出するための情報共有を容易にするために、医療ケアアプリケーションを流通する医療ケアアプリケーションポータルシステムに統合されてもよい。このようなシステムはまた、このような情報がどのようにアクセスされるかを制御することによって、このような情報の機密性、プライバシー及び秘密性を維持するように設計される。以下により詳細に記載されるように、システムは、規制物質を含みうる１以上の薬物の卸売業者、小売業者及び処方者に、局所レベル及び全国レベルの両方において１以上の医療ケアアプリケーションの市場の広い視点を提供する。このような情報エコシステムは、ヘルスケアプロセスの参加者によって有意義な方法で医療情報を統合することを支援する。なぜなら、情報エコシステムは、意思決定及びヘルスケア勧告のための基礎として一般にまとめて利用可能ではない複数のデータを分析することによって結論を導出するためのデータを収集するからである。よって、本明細書で検討される実装は、アプリケーション間のセキュアな情報交換を容易にすることによって、個別の患者及びヘルスケア提供者が小規模なヘルスケア意思決定をよりよく行えるようにするが、当該実装は、市場参加者がヘルスケアシステムの参加者の大きな集団に関する挙動及びデータに基づいてパターンを把握できるように、大規模な情報の集約をも容易にする。

アプリケーション環境は、インテリジェントデータベース及びコレクションシステムをモバイルアプリケーション（及びアプリケーションマーケット）にリンクするように構成されてもよく、モバイルアプリケーションにおいて、アプリケーションマーケット内のアプリケーションはデータベース及びそのコレクションシステムへ情報を報告し送信するように構成される。アプリケーションは、ｉＰａｄ（登録商標）、ｉＰｈｏｎｅ（登録商標）又はＡｎｄｒｏｉｄ（登録商標）ハンドセットのようなものを含む無線デバイス又は無線タブレットで動作するように構成されたアプリケーションを含む。しかし、これらはアプリケーションを実行しうるデバイスの単なる例であり、一般に幅広い範囲の計算デバイスが、モバイルデバイスのユーザが集中型アプリケーションマーケット及び分析インフラと相互作用する様々な実装での使用に適する。上記のように、このようなモバイルデバイスの側面は、情報を互いに共有するためのこれらのアプリケーションの能力に関して制約が存在するかもしれないことである。よって、実装は、第１アプリケーションを通じてデータを収集し、当該データをセキュアな集中型ロケーションへ送信し、続いて当該データに基づいて分析結論を導出できる別のアプリケーションに対して当該データへのアクセスを許可することによって、アプリケーション間での情報共有を容易にすることを助ける方法を提供する。

これらのアプリケーションは医者によって処方されてもよく、顧客が特定のアプリケーションにアクセスするために必要となる許可又は信任システムが存在してもよい。医者は、患者の疼痛管理を支援するアプリケーションを処方してもよく、ついで、これは医師に当該情報を提供して、当該医師が疼痛管理製薬をよりよく処方できるようにする。このような例では、別の関連情報は、疼痛管理製薬の一部が、例えば乱用の可能性のために、重度に規制されているか、大幅に規制された物質でありうることである。実装のこれらの側面は、以下に詳細に説明される。さらに、アプリケーションは、どのアプリケーションがユーザに密接な関係があるかを認識している、プロセスにおける別の当事者によって処方されてもよい。例えば、ユーザに癲癇の薬物を提供する薬剤師も、別の神経的問題のためのアプリケーションについての示唆を有してもよいし、保険業者が、高価な有名ブランド薬物からジェネリック医薬品へユーザが移行することを促進したいことの示唆を有してもよい。これに代えて、製薬会社は、自身が生産する医薬品の投与を補完するように設計されたアプリを提供してもよく、これは以下に詳細に説明される。

一般に、アプリケーション環境は、顧客又はユーザによって使用されうる無線デバイス又は無線タブレットを含む。さらに、デスクトップコンポーネント又はラップトップコンポーネントも有するアプリケーションが存在してもよい。実装における計算デバイスの「無線」側面は限定であることを意図しておらず、簡単に持ち運ぶことができない計算デバイスが用いられてもよく、持ち運ぶことができる適切なデバイスが、有線接続を用いて実装の他の部分の一部と通信してもよいことが留意されうる。一般に、設計のこの側面の関与は、ポータルがユーザのためのデバイスでホスティングされ、その後の使用及び分析のために情報を記憶し管理する集中型インフラとデバイスが通信することである。

ユーザデバイスをまたがる機能はこれらの大きさと共に変わりうる。モバイル計算デバイスにデータの限られた部分集合が存在してもよいが、より広大な部分集合がデスクトップ環境にまたがって利用可能である。このような機能の分割は、モバイル計算デバイスの空間、物理インタフェース及び電力制限に起因してモバイル計算デバイスよりもデスクトップマシンにおいて多くの計算リソースがあることに起因しうる。さらに、アプリケーションは、無線デバイスを通じて利用可能である所定の認証、信用及び／又はセキュリティ対策を利用可能であってもよい。例えば、無線デバイスは、特定のユーザに属するものとして指定されてもよい。しかし、個別のユーザは、プライバシー設定にさらに関連する特定のアカウントに関連してもよい。

特定の国内無線キャリアとのアカウントを有する無線ハンドセット顧客は信用限度額を有しうることを開発者が知っていてもよいので、当該判定は、デスクトップのような他のプラットフォームにまたがって必ずしも利用可能でない保証水準を提供するために用いられてもよい。これらの信用対策は、製品及びサービスの広大な配置を提供するために用いられてもよい。しかし、医療アプリケーションの購入を行う能力のようなアクセス権を与えられる前に、ユーザの本人確認を確立するために、ワンタイムパスワード、生体情報、パターンなどであってもよい、パスワードのような他の従来のセキュリティ手段が実装において要求されてもよい。医療データが非常にセンシティブであり、ヘルスケアプロセスの参加者のプライバシー及び機密性を保護することが重要でありうるので、これらのセキュリティ対策は特に重要でありうる。必要な場合にプライベート情報が利用可能となることが必須であるが、法律基準に準拠するため、そして、プライベート情報にアクセスできるべきでない当事者が患者又は個人情報の他の保有者の不利益に関する情報を悪用できないようにするために、プライベート情報にアクセスする資格を有する当事者だけがそれにアクセスできることが最も重要である。

無線デバイスは、中間物と相互作用するように構成されてもよい。中間物は、ヘルスケアアプリケーションストアを実行する１以上のサーバを含んでもよい。アプリケーションへのアクセスを提供する場合に、医療アプリケーションポータルは、アプリケーションの流通を支援するためにこのようなヘルスケアアプリケーションストアと相互作用してもよい。多くのモバイルオペレーティングシステムは、当該オペレーティングシステムに利用可能なアプリケーションに関連するアプリケーションストアを有し、アプリケーションストアはオペレーティングストアの作者によって保守される。ポータルは、アプリケーションを流通する際にこのようなアプリケーションへのアクセスの提供を助けるように、このようなアプリケーションストアと相互作用してもよい。これらのアプリケーションストアは、ユーザデバイスがこれらのアプリケーションの１以上へアクセスすることを可能にするために、薬剤師、医師のオフィス及び医療ケア提供者とともに動作してもよい。

アプリケーション及び当該アプリケーションに関する情報へのアクセスは、患者の状態に依存して保護されてもよい。上述のように、無線デバイス及び中間物は、特に不名誉な状態及び問題を伴う環境において、個人識別可能情報を安全にし、個人識別可能でセンシティブな情報の不慮の開示を防ぐように設計された他の技術を提供してもよい。アプリケーションは、制約化合物又は治療計画のような、特定の状態又は医療計画に向けられてもよい。これに代えて、アプリケーションは、診断的コンポーネントを含んでもよいし、血糖及び他のパラメータのような診断測定情報を生成しうるＢｌｕｅｔｏｏｔｈ（登録商標）診断的コンポーネントと相互作用してもよい。Ｂｌｕｅｔｏｏｔｈは診断的コンポーネントのためのインタフェースの単なる１つのタイプであり、他のアプローチも可能であることが留意されうる。さらに、アプリケーションマーケットは、医師システム、支払人システム（例えば、保険業者や政府の規制システムのようなもの）と相互作用してもよく、さらに、ヘルスケア情報会社のような他の代理人へ情報を提供してもよく、他の代理人は製薬の有効性のようなデータを解明するためにこの情報を処理する。例えば、ユーザがスタチンを処方された場合に、ユーザの治療計画が適切に機能しているかを評価するために血液コレステロールレベルが用いられうる。

アプリケーションストア及びアプリケーションは、製薬会社及び共に働く医師が、よりタイムリーな又は更新された治療計画を流通し、製薬の有効性を解明できるように、分析エンジンに結合されてもよい。さらに、アプリケーション及びそのサーバ側コンポーネントはまた、治療計画を識別するために、医師意思決定支援システムと相互作用してもよい。アプリケーション及びそのサーバコンポーネントはまた、保険業者計画と相互作用してもよく、保険業者計画は費用節約対策を実行して、より高価な有名ブランド製薬が処方される前にジェネリック製薬が探索され、費用の低い治療計画が追及されたならば、顧客は、ブランド形態でのみ利用可能である製薬のような、利用可能でありうる次のレベルの製薬恩恵に自動的にアップグレードされてもよい。交換される製薬情報はまた、状態管理においてもユーザを支援する情報を含んでもよい。情報は、有効性データ又は副作用事例のような、ユーザが過去の治療にどのように反応したかの側面に関する情報を含んでもよい。

１つの構成では、セキュアモバイルアプリケーションプラットフォーム及びアプリケーションストアは医師関連サーバによって提供される。別の構成では、プラットフォームは製薬会社サーバによって提供されるが、さらに別の環境では、プラットフォームは信頼された中間物及び／又は政府の規制機関によって運営される。さらに、アプリケーションストアは、様々なソースから提供されるアプリケーションへのアクセスを管理する集約部として動作してもよい。プラットフォームの構成に関する様々な追加の情報は以下で図７に関連して説明される。

アプリケーションサーバは、有効性を解明するため、及び／又は状態をよりよく治療するために医師に示唆を提供するために、分析サービスと関連して動作してもよい。このようなフィードバック及び分析は、付加価値サービスとして提供されてもよく、及び／又はプライバシー及び選択制御の対象となってもよいし、データが処理される際に治療勧告を受け取ることを選択する医師を含んでもよい。アプリケーション及びそのデータは、１以上のプライバシー対策によって保護されてもよい。データがシステムを通じて処理される際に鍵情報と結合されるように、データが暗号化されてもよいし、及び／又は匿名化フィルタにかけられてもよい。しかし、データがユーザのハンドセットから離れると、個人識別可能な情報が利用できないようにデータが処理されてもよい。このような処理は、データのサニタイズとしても知られており、ユーザのプライバシーを危険にさらすことなく、集約データから有意な結論を得るのに十分な情報を保持することを可能にする。これらのラインでは、データの通信は、情報がＨＩＰＡＡ及び他のプライバシー要件に準拠したままとなるように、データネットワークを通じた様々な暗号化通信を要求し、採用してもよい。よって、個別の勧告のためにプライベートベースでデータが処理されてもよいし、集団についてのデータ分析が可能となるようにデータが集約されサニタイズされてもよい。

インフラが中央に位置してもよいし、部分集合情報が分散して存在するように構成されてもよい。システムはまた、アプリケーションが意図したように動作しないか、及び／又は扱われている製品が意図したように動作していないため、アプリケーション及び／又は行っている治療計画が市場規模のリコールの対象となりうるならば、患者にリスクを提示するための食品医薬品局（ＦＤＡ）信任サーバとともに構成されてもよい。

アプリケーションは、顧客が別の治療計画に切り替えるのではなく特定の治療計画に留まるように説得するためのロイヤリティプログラムを製薬会社が提供しうるように、ロイヤリティ計画に結合されてもよい。例えば、製薬会社は、顧客ベースを維持するために、医薬品のジェネリック製剤又は別の安価な医薬品の代替である有名ブランド医薬品のためのクーポンを提供してもよい。ロイヤリティ計画又はユーザ情報に基づいて行われる他のマーケティングステップの文脈では、プライバシーを維持することが重要である。ユーザがマーケティング通信を受け入れることを肯定的に選択するか、少なくともユーザが見合わせることを可能にするかが必須であってもよい。しかし、ユーザがこのような通信を受けることを受け入れるならば、症状及び治療の特性に基づいて医薬品会社がユーザに売り込むことを可能にすることは、ユーザと医薬品会社とにとって相互に有益でありうる。

アプリケーションは、製薬医薬品情報、医薬品相互作用情報、順守リマインダ、どの治療計画が行われ、及び所定の状態を検査し診断するように設計された１以上の周辺センサに結合しうるかを文書化し、患者が記録することを可能にする情報を含んでもよい。データは、センサカメラ及び／又は無線又は有線の１以上の物理アタッチメントによってアプリケーションのために収集されてもよい。アプリケーションはまた、医薬品安全性警告を流通してもよいし、特定の処方が看護師又は他のライセンスを有するヘルスケア専門家によって投与されなければならないならば、出張支援を提供してもよい。一部の場合に、アプリケーションはまた、特定の状態をフォローするために人が自身の直近の機会に医師に予約できるように、利用可能な医療機会を調整し識別してもよい。分析的観点から、識別されたデータは、患者識別子、医師識別子、診断、ペア識別子、特定の処方のような１以上の記述的情報を含んでもよいし、分析サービス提供者が大規模な集団にわたってデータを監視しうるように統合されてもよい。この統合は、ついで、医師、製薬会社及び保険業者のような、プロセスにおける様々な利害関係人が、患者報告の結果、コスト及び節約効率性、自宅診断データ及び追跡結果をよりよく識別することを可能にしてもよい。統合はまた、薬剤師が、顧客が医薬品をリフィルする範囲を知覚し、ロイヤリティデータを解明し、視力検査予約及び予防接種のような充実した薬局サービスを提供することを可能にする。

システムはまた、保険業者又は他の支払人が、統合ケア管理を提供し、一部の予防治療対策を提供し、会員福祉管理を実行し、病気予防を実行することを可能にしてもよい。アプリケーションは、電子医療記録システムにも結合されてもよく、その結果として、インターネットを通じて流通されうる情報は、１以上の電子医療記録に自動的に投入される。分析及び／又はアプリケーションストアはまた、セキュアクラウドリポジトリを含んでもよく、その結果として、無線デバイスが紛失されるか置き忘れられたならば、ユーザはその代わりに新しい無線デバイスを起動した際にその構成を複製できる。注記したように、無線デバイスは、電子医療記録提供者からのデータの双方向送信に関与してもよい。

１つの構成では、アプリケーション環境は、医薬品又は予約のリマインダを設定し、次の予約を確保し、リフィルを自動的に開始し、リフィルを要求し、医師との予約をスケジュールするために使用されてもよく、その結果として、センシティブな処方が自動的にリフィルされうる。よって、環境は、患者のためにケアするようにヘルスケア提供者によって特定の投与動作が行われる機能を含んでもよい。アプリケーションは、薬剤師が１以上のコンポーネントを有効にすることを可能にするために、アプリケーション内に選択的に呼び出し可能な薬剤師リンクを含んでもよい。アプリケーションは様々な状態を管理するために用いられてもよい。喘息を管理するための構成アプリケーションが存在してもよく、他の状態を管理するための別のアプリケーションも存在してもよい。さらに、アプリケーションは、疼痛を管理するためにユーザがアプリケーションにロードできるように、より大きなアプリケーション内の他のモジュールのカタログを含んでもよく、これらの問題に対処するために一緒になって動作するモジュールをさらに伴ってもよい。例えば、アプリケーションの一部は薬物用法を追跡してもよいし、別のアプリケーションはユーザが呼吸練習を行うのを助けてもよい。

アプリケーションは、無線電話のようなユーザデバイス上の他のアプリケーションにリンクされてもよい。例えば、カレンダ又はスケジューリングアプリケーションにカレンダリマインダを設定してもよいし、リマインダエンジンにリマインダを設定してもよいし、オーディオ信号の再生又は振動などによってユーザに通知する警告を起動してもよいし、ＧＰＳ又は他の位置センサなどから位置情報をマッピングデータベースにロードしてもよい。アプリケーションはまた、リマインダの編集可能リストを含んでもよい。

図１は、分析目的のための識別不能データを統合するように構成された計算システム１００に実装される例示の医療ケアアプリケーション流通システムを説明する。計算システムは、本明細書で説明される機能を提供可能なデータ処理装置として実装されてもよいし、プロセッサ、メモリ、並びに適切な医療データを受信し、後述のように当該データを処理できる他のハードウェア及びソフトウェアの任意の適切な組合せを含んでもよい。ハイレベルでは、説明される例示の計算システム１００は、ヘルスケアプロセスの参加者であるソースから様々なデータを受信する。ソースは、小売薬局１０２、患者１０４、処方者１０６及び製薬流通者１０８を含んでもよい。データは、小売処方データ１１０、長期患者データ１１２、参照処方者データ１１４及び製薬購入データ１１６を含んでもよい。

図１は、分析インフラが、患者１０４から又は処方者１０６として動作しうるヘルスケア提供者からモバイルアプリケーションを介して受信された個人に関するデータを、薬局１０２や製薬流通者１０８のような、ＩＭＳで利用可能な他のデータソースと統合することができるプロセスを説明する。患者１０４からのデータは、長期患者データ１１２に制限されず、彼らのデバイスを通じて記録された任意のヘルスメトリックを含んでもよく、処方者１０６からのデータは彼らのＥＭＲシステムを通じて記録された同様の範囲の測定結果だけでなく、ラボ結果又は画像を含みうる。システムは集約データベースに記名データを記憶するのではなく、識別不能データのみを記録することを理解することが重要である。個人についての記名データは関連する集約データに対して比較されうるが、これは、単一のデータベース内の複数の患者についての記名レコードを維持することによってではなく、個別の患者アプリケーション内の集約値を用いることによって達成される。また、ユーザ及び彼らの医療専門家以外のソースからのデータの統合は、薬局からの製薬購入データ１１６のような別のソースからの情報を提供する目的のために個人が自身の本人情報（氏名、位置、性別及び年齢）を用いることを許可する例を除いて、識別不能ベースにおいてのみ実現されうる。

小売処方データ１１０は、小売薬局１０２によるような、小売セクタにおいて調剤された処方に関するデータを含んでもよい。小売処方データ１１０は、１以上の小売薬局１０２から直接に受信されてもよく、製品を取得するために用いられる処方のタイプに関する情報や製品を購入するために用いられる支払い方法を含む、１以上の販路１０２によって調剤されるすべての製薬製品を反映するデータを表してもよい。上述のように、この情報は、患者のプライバシーを保護するためにサニタイズされ集約されてもよい。薬局チェーン、独立薬局、長期ケア施設及び／又はメールサービスを含んでもよい１以上の小売薬局１０２は、周期的に（例えば、毎週又は毎月）小売処方データ１１０を提供してもよい。図１は小売処方データ１１０が１以上の小売薬局１０２から計算システム１００へ直接に提供されることを示すが、小売処方データ１１０は１以上の他の中間システムによって収集され、その後に計算システム１００へ提供されてもよい。中間システムが用いられるならば、小売処方データ１１０の集約及びサニタイズは、場合によっては中間システムによって実行されてもよい。

長期患者データ１１２は、１以上の患者１０４についてのサニタイズされた小売患者レベルデータを含んでもよい。例えば、長期患者データ１１２は、小売薬局ソースの処方保険請求に関する情報、小売製薬処方箋及び／又は患者プロファイルデータを含んでもよい。長期患者データ１１２は、１以上の患者１０４についてのケアの側面に関する情報を含む。図１は長期患者データ１１２が１以上の患者１０４から直接に計算システム１００によって受信されるように説明するが、長期患者データ１１２は、小売処方データ１１０について説明された同様のアプローチに類似する方法で、１以上の他のシステムによって収集され、その後に計算システム１００へ提供されてもよい。さらに、長期患者データ１１２は、１以上の患者１０４に由来するのではなく、患者が相互作用する１以上の処方者／医師によって、患者が保険請求を提出する保険会社によって、及び／又は患者が製薬製品を購入する小売業者によって提供されてもよい。

参照処方者データ１１４は、１以上の処方者１０６の背景情報を含んでもよい。例えば、参照処方者データ１１４は、処方者のデモグラフィック情報、住所、提携先、認可データ（例えば、ＤＥＡ、ＡＯＡ、ＳＬＮ及び／又はＮＰＩ番号）、団体及び／又は専門を含んでもよい。殆どの処方者は医者であるが、医師アシスタント又は看護師研修生のような他のヘルスケア専門家が処方者１０６であってもよい。図１は参照処方者データ１１４が１以上の処方者１０６から直接に計算システム１００によって受信されるように説明するが、参照処方者データ１１４は、小売処方データ１１０について説明された同様のアプローチに類似する方法で、１以上の他のシステムによって収集され、その後に計算システム１００へ提供されてもよい。さらに、参照処方者データ１１４は、１以上の処方者１０６に由来するのではなく、処方者１０６の処方挙動に関する情報を追跡する１以上の他のエンティティ（例えば、政府機関又は専門医療組織）によって作成及び／又は保守されてもよい。

製薬購入データ１１６は、流通者１０８（例えば、製薬卸売業者又は製造者）から行われた製薬購入に関する情報を含んでもよい。例えば、製薬購入データ１１６は、製薬製品が購入された販路に関する情報、購入された製薬製品のタイプ、購入が行われた際の製薬製品の購入者と販売者との両方の位置、及び／又は購入された製薬製品の量を含んでもよい。図１は製薬購入データ１１６が１以上の流通者１０８から直接に計算システム１００によって受信されるように説明するが、製薬購入データ１１６は、小売処方データ１１０について説明された同様のアプローチに類似する方法で、１以上の他のシステムによって収集され、その後に計算システム１００に提供されてもよい。さらに、製薬購入データ１１６は、１以上の流通者１０８に由来するのではなく、製薬製品の購入者（例えば、小売販路）によって提供されてもよい。

小売処方データ１１０、長期処方データ１１２、参照処方者データ１１４及び製薬購入データ１１６を含んでもよい上述された様々なタイプのデータは、当該データに基づく結論を導出するために、計算システム１００によって受信される。上述のように、データが計算システム１００によって受信されるまでに、計算システム１００がアクセスできるべきではないプライベート情報又は機密情報を当該データが含まないように、サニタイズされているべきである。

説明のために、計算システム１００は、データ処理モジュール１１８、統計ランキングモジュール１２０、報告モジュール１２２及びストレージデバイス１２４を含むものとして説明される。しかし、計算システム１００は、記載される機能を実行可能な任意の計算プラットフォームであってもよい。計算システム１００は、記載される機能を実行するためのハードウェア、ソフトウェア又は両者の組合せを含んでもよい１以上のサーバを含んでもよい。さらに、データ処理モジュール１１８、統計ランキングモジュール１２０及び報告モジュール１２２は、ハードウェア及び／又はソフトウェアにおいて一緒に実装されてもよいし、別々に実装されてもよい。データ処理モジュール１１８、統計ランキングモジュール１２０及び報告モジュール１２２はそれぞれ所定の機能を実行するものとして説明されるが、これらのモジュールのそれぞれの記載される機能は、記載されるモジュールと連携する、又は記載されるモジュールに置き換わる１以上の他のモジュールによって実行されてもよい。

データ処理モジュール１１８は、小売処方データ１１０、長期患者データ１１２、参照処方者データ１１４及び製薬購入データ１１６のうちの１以上を受信し処理する。受信したデータの処理において、データ処理モジュール１１８は、特定の情報について、小売処方データ１１０、長期患者データ１１２、参照処方者データ１１４及び製薬購入データ１１６をフィルタリング及び／又はマイニングしてもよい。データ処理モジュール１１８は、特定の製薬について、受信した小売処方データ１１０、長期患者データ１１２、参照処方者データ１１４及び製薬購入データ１１６をフィルタリング及び／又はマイニングしてもよい。よって、追跡される化合物又は処方に関連するものとして分類されない製薬製品に関する任意の受信した小売処方データ１１０、長期患者データ１１２、参照処方者データ１１４及び製薬購入データ１１６は無視されてもよい。例えば、受信したデータは、特定の抗生物質又は一般的な抗生物質の使用を追跡するためにデータ処理モジュール１１８によって処理されてもよい。

受信した小売処方データ１１０、長期患者データ１１２、参照処方者データ１１４及び製薬購入データ１１６を処理した後に、データ処理モジュール１１８は処理後のデータを患者データ１２６、処方者データ１２８及び販路データ１３０に集約する。これらのデータグループは、ストレージデバイス１２４に記憶されてもよい。一部の実装では、データ処理モジュール１１８は、データが受信された各患者、各処方者及び各小売薬局販路についてプロファイルを作成してもよい。

小売処方データ１１０は、１以上の製薬製品を調剤する小売薬局販路に関する情報、製薬製品を購入した１以上の患者に関する情報、及び製薬製品を取得するために患者によって用いられる処方箋を記載した１以上の処方者に関する情報を含んでもよい。この例では、データ処理モジュール１１８は、受信した小売処方データ１１０に含まれる情報を、小売販路、１以上の患者及び１以上の処方者に関連するプロファイルに追加するだろう。別の例では、長期患者データ１１２は、製薬製品についての処方を受信した患者に関する情報及び患者が処方を受けた１以上の処方者に関する情報を含んでもよい。この例では、データ処理モジュール１１８は、受信した長期患者データ１１２に含まれる情報を、患者及び１以上の処方者に関連するプロファイルに追加するだろう。

他の実装では、データ処理モジュール１１８は、他のモジュールによるその後の使用のために、処理後の小売処方データ１１０、長期患者データ１１２、参照処方者データ１１４及び製薬購入データ１１６を単にソートし、ストレージデバイス１２４に記憶してもよい。

データが受信された対象の各患者１０４について、患者データ１２６は、処方及び／又は１以上のタイプの製薬製品の販売に関する任意の情報を含んでもよい。患者データ１２６は、患者が購入した各タイプの製薬製品の量と、患者がなおも有しているべき製薬製品の日々の累積供給と、製薬製品の累積投与量と、薬物所有率と、患者が処方箋を受けた医者の人数及び／又は名前と、患者が製薬製品を購入した小売販路の個数及び／又は名前と、及び／又は製薬製品を購入した際に患者によって用いられた支払い方法（群）に関する情報（例えば、現金又は保険）とを含んでもよい。

データが受信された対象の各処方者１０６について、処方者データ１２８は、１以上のタイプの製薬製品について処方者によって記載された処方と、処方が記載された患者とに関する任意の情報を含んでもよい。処方者データ１２８は、処方者が処方を記載した１以上のタイプの製薬製品の量と、処方者によって記載された総処方数に対する当該処方者によって記載された１以上のタイプの製薬製品についての処方のパーセンテージと、現金で支払われた１以上のタイプの製薬製品についての処方のパーセンテージと、及び／又は１以上のタイプの製薬製品について処方者が処方を書き、閾値を超える１以上のタイプの処方製品の供給を現在有している患者の人数とを含んでもよい。

データが受信された対象の各小売薬局販路１０２について、販路データ１３０は、１以上の製薬製品の販売と、１以上のタイプの製薬製品の販売が行われた患者と、及び／又は１以上のタイプの製薬製品の販売が基づく処方箋を書いた処方者とに関する任意の情報を含んでもよい。例えば、販路データ１３０は、販路によって販売された１以上のタイプの製薬製品の量と、小売販路による総販売に対する１以上のタイプの製薬製品の販売のパーセンテージと、現金で支払われた１以上のタイプの製薬製品の販売のパーセンテージとを含んでもよい。

統計ランキングモジュール１２０は、個別の患者、処方者及び小売販路を評価しランク付けするために、患者データ１２６、処方者データ１２８及び／又は販路データ１３０を用いる。一部の実装では、統計ランキングモジュール１２０は、患者集合にわたる患者データ１２６の１以上の要素の平均に対して、患者に対応する患者データ１２６の１以上の要素を比較してもよい。患者データ１２６の１以上の要素の比較に基づいて、統計ランキングモジュール１２０は、１以上の評価を患者に割り当ててもよい。言い換えると、患者データ１２６の各要素（例えば、患者が購入した各タイプの製薬製品の量と、現金で行われた購入のパーセンテージ）について、統計ランキングモジュール１２０は、患者データ１２６の要素が、これらの計算された統計に関する集合における他の患者の同じ要素とどのように匹敵するかを反映する評価を患者に割り当ててもよい。比較に用いられる集合内の患者は、同じ位置（例えば、国、州、市又は郵便番号）にいる患者、同様の患者データ（例えば、医療診断又はデモグラフィック情報）を共有する患者、及び／又は他の何らかの関係を共有する患者であってもよい。

第１患者に対応する患者データ１２６は、先月にわたって、第１患者が所定の血糖読み取り値の集合を有したことを示してもよい。患者データ１２６はまた、同じ期間にわたって、平均的患者に典型的な血糖読み取り値を示してもよい。この情報に基づいて、統計ランキングモジュール１２０は、第１患者の血糖読み取り値が異常に高いことを解明してもよい。この結論は、血糖情報へのアクセスが許可されているならば、ユーザ又はユーザの医者が、ユーザの血糖が異常であり、治療応答を必要としうることが助言されるべきであることの示唆につながってもよい。

同様に、統計ランキングモジュール１２０は、関連する処方者の集合にわたる処方者データ１２８の１以上の要素の平均に対して、処方者に対応する処方者データ１２８の１以上の要素を比較してもよい。処方者データ１２８の１以上の要素の比較に基づいて、統計ランキングモジュール１２０は、１以上の評価を処方者に割り当ててもよい。比較に用いられる集合内の処方者は、同じ位置（例えば、国、州、市又は郵便番号）にいる処方者、同様の専門データ（例えば、開業エリア又はデモグラフィック情報）を共有する処方者、及び／又は他の何らかの関係を共有する処方者であってもよい。統計ランキングモジュール１２０は、患者データに用いられたのと同様にして、処方者データ１２８から処方者についての結論を導出できてもよい。例えば、ある国の一般開業医は癲癇を有する患者にジェネリック医薬品を処方する傾向にあるが、神経科医は同様の診断を有する自身の患者に有名ブランド医薬品を用いる可能性が高いことが判定されてもよい。これらの判定は、例えば、製薬会社が、新たな抗痙攣薬を一般開業医よりも神経科医に重きを置いて営業活動すべきであることを示唆するために用いられてもよい。

統計ランキングモジュール１２０はまた、関連する小売販路の集合にわたる販路データ１３０の１以上の要素の平均に対して、小売販路に対応する販路データ１３０の１以上の要素を比較してもよい。販路データ１３０の１以上の要素の比較に基づいて、統計ランキングモジュール１２０は、１以上の評価を販路に割り当ててもよい。比較に用いられる集合内の小売販路は、同じ位置（例えば、国、州、市又は郵便番号）にいる小売販路、同様の商業データ（例えば、小売販路の規模）を共有する処方者、及び／又は他の何らかの関係を共有する処方者であってもよい。例えば、データは、所定の医薬品が地方の薬局で、より頻繁に購入され、他の医薬品は都市部の薬局で購入されることを示してもよい。例えば、これらの判定は、薬局が、自身の地方の支店で花粉アレルギーの抗ヒスタミン剤を多く備蓄すべきであることを示唆してもよい。

統計ランキングモジュール１２０によって患者、処方者及び／又は小売販路に割り当てられた評価は、患者データ１２６、処方者データ１２８及び／又は販路データ１３０の要素に関して実行された分析を反映する正規化された数値であってもよい。一部の実装では、統計ランキングモジュール１２０によって判定された評価は、定期的に（例えば、週ごと又は月ごとに）更新されてもよいし、コンピュータシステム１００によって評価に対応する要素に関する新たなデータが受信された任意の時点で更新されてもよい。これに代えて、一部の実装では、統計ランキングモジュール１２０によって判定される評価は、統計ランキングモジュール１２０が評価のクエリを受信するごとに算出されてもよい。

統計ランキングモジュール１２０はまた、コンピュータシステム１００によってデータが受信された各患者、各処方者及び／又は各小売販路について合成評価を算出してもよい。一部の実装では、統計ランキングモジュール１２０は、患者、処方者又は小売販路に関連する個別要素の評価のそれぞれに重み付けし、個別要素の評価の合成を算出するために式を適用してもよい。これに代えて、一部の実装では、統計ランキングモジュール１２０は、利用可能な個別要素の評価の適切な部分集合を選択し、選択した個別要素の評価に基づいて合成評価を算出してもよい。

一部の実装では、統計ランキングモジュール１２０は、判定された評価に基づいて、患者、処方者及び／又は小売販路を互いにランク付けしてもよい。例えば、統計ランキングモジュール１２０は、各患者の合成評価に基づいて、所与の位置（例えば、郵便番号）にいる患者のすべてをランク付けしてもよい。このようなアプローチは、特定の位置にいる集団についての患者情報の検討を可能にし、これは、対象の患者の挙動が、局所化された集団についてのものとなりうるので有用である。別の例では、統計ランキングモジュール１２０は、処方者が処方を書いた１以上のタイプの製薬製品の量（すなわち、処方者データ１２８の要素）に関する各処方者評価に基づいて、所与の州にいる癌専門医である処方者のすべてをランク付けしてもよい。このようなアプローチは有用でありうる。なぜなら、専門医は一般医とは異なるように処方するかも知れず、上述のように、処方者の異なるグループによって用いられるケア戦略を比較することに関心があるかもしれないからである。

報告モジュール１２２は、統計ランキングモジュール１２０によって算出された評価及び／又はランキングに基づいて報告を準備する。報告モジュール１２２によって準備される報告は、統計ランキングモジュール１２０によって算出された評価のうちの１以上だけでなく、患者データ１２６、処方者データ１２８及び／又は販路データ１３０に含まれる他の任意のデータを含んでもよい。例えば、報告システムによって生成される報告は、特定の製薬製品（例えば、オキシコドン‐規制物質）について所与の州におけるすべての処方者についての合成評価を含んでもよい。

示されるシステムは、患者、処方者及び／又は小売販路に関連する任意の１以上の基準に基づいてフィルタリング及び／又はマイニングされてもよい。報告は、位置、製薬製品タイプ、処方者の医療専門、小売販路のカテゴリ（例えば、大規模チェーン小売販路）、及び／又は統計ランキングモジュール１２０によって算出された１以上の評価に基づいてフィルタリング及び／又はマイニングされてもよい。言い換えると、データ処理モジュール１１８によって受信され処理された任意のデータ又は統計ランキングモジュール１２０によって算出された任意の評価又はランキングは、報告に含まれてもよいし、報告に含まれるデータをフィルタリング及び／又はマイニングするために用いられてもよい。

さらに、一部の実装では、生成された報告は、動的であってもよし、静的であってもよい。報告モジュール１２２は、フォーマットを変更するための及び／又は報告に提示されたデータを操作するための仕組みを何も提供せずに、１以上の静的なフォーマット（例えば、チャート、グラフ又は表）に提示されるデータを含む報告を生成してもよい。このような実装では、データ提示を更新するための機能を組み込むことなく、データ提示が生成され、保存される。一部の実装では、報告モジュール１２２は、ＰＤＦ、スプレッドシート又はＸＭＬフォーマットにおいて静的な報告を提供する。このようなフォーマットは一般的に、テキストデータ又は可視物として報告モジュール１２２の理解を提供するが、報告モジュール１２２の取りうる結果として、オーディオ、ビデオ又はアニメーションのような、結論を提示する他のフォーマットが排除されない。

これに加えて又はこれに代えて、報告モジュール１２２は、ユーザが報告自体をインタラクティブに変更及び／又は操作することを可能にするコントロールを含む報告を生成してもよい。例えば、報告システムは、報告に表示されたデータをフィルタリング、操作及び／又は整列するためのコントロールをそれ自体が含むＨＴＭＬ文書の形態の動的な報告を提供してもよい。さらに、動的な報告は、動的な報告に含まれる情報の多数の視覚表現間を切り替える能力を含んでもよい。一部の実装では、動的な報告は、報告自体に含まれるデータ及び／又は評価のみにアクセスを可能にするのとは対照的に、データ処理モジュール１１８及び／又は統計ランキングモジュール１２０によって準備される患者データ１２６、処方者データ１２８及び／又は販路データ１３０の一部又は全部への直接アクセスをユーザによって選択されたように提供してもよい。

１以上のクライアント１４０は、報告システムによって作成される報告を要求し、受信するために、計算システム１００と相互作用してもよい。一部の実装では、１以上のクライアント１４０は、計算システム１００へのインターネットベースのアクセスを提供するウェブブラウザを含んでもよい。ウェブブラウザを通じて、クライアント１４０のユーザ（例えば、卸業業者、小売販路又は処方者）は、上述のように報告システムから静的又は動的な報告を要求してもよい。

一部の実装では、計算システム１００へのアクセスは、計算システム１００に記憶された任意の機密データを保護するために制御されてもよい。一部の実装では、計算システム１００からの報告を要求しようとするクライアント１４０の各ユーザは、ユーザカウントを作成し、ログインすることを要求されてもよい。ユーザアカウントは、特定のタイプのデータ、報告及び／又は他の機能へのユーザのアクセスを制限するために用いられうる、ユーザに関する識別情報を含んでもよい。処方者に関連するユーザアカウントは、自身のエリア内の処方者についての処方者評価データ及び／又は処方者が専門的関係を有する患者についての患者評価データのみを閲覧できるように処方者を制限してもよい。さらに、処方者に関連するユーザアカウントは、処方者が別の処方者のプライベートデータにアクセスすることを防ぐために、報告に含まれるデータの詳細レベルを制限してもよい。アクセスに関する更なる側面は、図７を参照して以下に説明される。

例示の計算システム１００に関連して、又はこの外部に、任意の個数のクライアント１４０が存在してもよい。説明される例示の計算システム１００は１つのクライアント１４０と通信するように示されるが、例示の計算システム１００の代替の実装は、例示の計算システム１００の目的に適する任意の個数のクライアント１４０と通信してもよい。さらに、「クライアント」及び「ユーザ」という用語は、この開示の範囲から逸脱することなく、必要に応じて交換可能に用いられうる。さらに、クライアント１４０は単一のユーザによって用いられる観点で記載されるが、この開示は、多くのユーザが１つのコンピュータの使用を共有してもよいし、１人のユーザが複数のコンピュータを使用してもよいことを意図する。

説明されるクライアント１４０は、デスクトップコンピュータ、ラップトップ／ノートブックコンピュータ、無線データポート、スマートフォン、携帯情報端末（ＰＤＡ）、タブレット計算デバイス、これらのデバイス内の１以上のプロセッサ又は他の任意の適切な処理デバイスのような、任意の計算デバイスを包含することが意図される。例えば、クライアント１４０は、キーパッド、タッチスクリーン、又はユーザ情報を受け取ることができる他のデバイスのような入力デバイスと、計算システム１００の動作に関連する情報を伝達する出力デバイスとを含むコンピュータを備えてもよい。入力デバイスは、計算システム１００へ命令を提供するためにクライアント１４０によって用いられてもよく、計算システム１００は、計算システム１００が受信する様々なデータからクライアント１４０によって要求された情報を提供するために当該命令を実行できる。

一部の実装では、計算システム１００によって実行されるものとして記載された機能は、クライアント１４０によって実行されてもよい。例えば、計算システム１００は、統計ランキングモジュール１２０によって算出された評価及びランキングへの直接アクセスをクライアント１４０に提供してもよい。結果として、報告モジュール１２２によって実行されるものとして記載された機能の一部又は全部は、クライアント１４０によってローカルに実行されてもよい。

図２は、無線デバイスに存在する医療ケアアプリケーションのスクリーンショットである。医療ケアアプリケーションは、ユーザがヘルスケア情報及びサービスを管理し、要求することを可能にするコマンドへのアクセスをユーザに提供するポータルである。図２では、医療ケアアプリケーションは、ＩＭＳ医療アプリケーションポータル２００として識別される。スクリーンショットは、「何をしたいですか？」とユーザに問うユーザプロンプト２１０を示す。ＩＭＳ医療アプリケーションポータルは、ヘルスケア情報及びサービスを取得するためにユーザが選択してもよいいくつかのコマンドを提供する。第１コマンドセットは、ヘルスツール２２０の集合である。これらのコマンドは、殆どのユーザに使用される基本機能を提供する。これらのコマンドは、薬剤管理２３０Ａ、リマインダ設定２３０Ｂ、医薬品相互作用チェック２３０Ｃ、警告＆メッセージチェック２３０Ｄ及び処方リフィル注文２３０Ｅを含んでもよい。しかし、医療ケアアプリケーション（ＩＭＳ医療アプリケーションポータル２００）は、特定のユーザに固有のアプリケーション、すなわちユーザアプリ２４０と相互作用するようにさらに構成される。図２では、これらの他のアプリケーションは、喘息トラッカ２５０Ａと、ＭＳマネージャ２５０Ｂとを含む。これらの例示のアプリケーションは、特定の製薬製造者から受け取られるもののように、アプリケーションがブランド付きのものであってもよいことを説明する。ＩＭＳ医療アプリケーションポータル２００は、図１に関して説明されたように、これらの他のアプリケーションから情報を受信し、この情報の分析のために計算デバイス１００へ報告してもよい。図２はまた、図４の説明で詳細に検討されるマイアプリ管理２６０というオプションを説明する。図２は、医療アプリケーションポータルと相互作用する際にモバイルデバイスのユーザへ提供されるインタフェースの例であり、この動作は図７に関して説明される。

図３は、患者がどのように喘息症状を管理しうるかを示す一連のビューを説明する。図３は、喘息管理アプリの３つのビューを提示する。患者ダッシュボードビュー３１０は、気温、汚染、花粉数及び天候を含む、喘息に影響しうる環境要因に関する情報を提示する。ユーザは、所与の時刻における喘息に応答して患者の「状態」を入力することが可能である。ここで提供される状態は、ユーザが自身の喘息の重症度をどのように判断したかを示す嬉しい感情、普通の感情又は悲しい感情である。結果は、患者が進行を評価しうる「転帰」追跡セクションを示す。１つの取りうる「転帰」追跡セクション３２０Ａでは、患者が自身の転帰を評価しうるように、又は医師が患者の転帰及び／又は汚染（又は、デモグラフィック、状態、治療計画、年齢、性別、位置又はプロファイルによって分類された集団の部分集合）を認識しうるように、結果はカレンダ上に表示される。別の取りうる「転帰」追跡セクション３２０Ｂでは、喘息の重症度が時間と共にどのように変化したかを追跡するために、時間に関する線グラフとして結果がプロットされる。

図４は、医療ケアアプリケーションがヘルスケア情報の交換を連携するためのインタフェースを確立するように医療ケアアプリケーションがどのように下位アプリケーションと相互作用しうるかを示す。アプリ管理４００は、図２のマイアプリ管理２６０からアクセスされうる。１つの構成では、下位アプリケーションは、患者が無線デバイスで処方製薬化合物を受け取り、関連する下位アプリケーションにアクセスすることも許可するために、医師によって処方される。アプリ管理４００は、現在のマイアプリ４１０を列挙する。喘息トラッカ４２０Ａ及びＭＳマネージャ４２０Ｂが再び例である。これらのアプリケーションを選択することによって、これらのアプリケーションは始まりうる。これらのアプリケーションは、ブランド付きの治療に連動して提供されてもよいことに留意されたい。例えば、喘息トラッカ４２０Ａはブランド付きの喘息薬に関連して提供されてもよいし、ＭＳマネージャ４２０Ｂはブランド付きのＭＳ薬に関連して提供されてもよい。これに代えて、図４に示されるように、ユーザは、マスタアプリケーションと相互作用する追加の下位アプリケーションを閲覧してもよい。ユーザは、新たなアプリを検索するためにキーワード４３０を入力してもよい。これに代えて、ユーザは、選択階層構造から新たなアプリ４４０を閲覧してもよい。選択階層構造は、治療エリア別４５０Ａ、アプリケーション発行者別４５０Ｂ，人気別４５０Ｃ又はアルファベット順４５０Ｄによって整理されてもよい。ユーザが下位アプリケーション及び／又は下位アプリケーションの一部にアクセスするために、医師、薬剤師及び／又は他のライセンス保有専門家からの許可が要求されてもよい。

マイアプリ管理２６０は、オプションとして、アプリの単なる追加又は削除のほかに、設定変更や、アプリケーションの購入やアプリの月額使用料を支払うために必要ならばアプリに関する金融取引の管理などの他の機能を含んでもよい。

しかし、図４は、アプリケーションの相互作用及び流通がどのように扱われるかに関するユーザの観点を単に説明する。アプリケーションの流通に関する追加情報、アプリ間の情報交換及びデータ収集・解析は、図７に関連して後述される。

図５は、医療ケアアプリケーションポータルがモバイル計算デバイスと情報を交換するプロセスのフローチャートである。

ブロック５１０で、モバイル計算デバイスのユーザについて医療ケアアプリケーションポータルで医療ケアアプリケーションへのアクセスの要求が受信される。クライアント１４０は、「アプリケーションストア」へのアクセスを要求してもよいし、アプリケーションへのアクセスを容易にするウェブサイトをロードするために医師又は薬剤師からのＱＲコード（登録商標）を受信してもよい。よって、患者は、関心のある医療ケアアプリケーションへのアクセスを要求してもよいし、医療ケアアプリケーションへのアクセス要求は、医師、薬剤師、製薬会社、保険提供者、又はアプリケーションが患者に関連すると信じる理由を有する別の当事者のようなものに代わって行われてもよい。このようなアプリケーションストアは、計算システム１００によってホスティングされてもよいし、これに代えて、１以上の適切に構成されたウェブサーバのような他の適切なインフラによってホスティングされてもよい。

ブロック５２０で、医療ケアアプリケーションポータルによってモバイル計算デバイスのユーザために医療ケアアプリケーションへのアクセスが提供される。例えば、医療ケアアプリケーションポータルは、モバイル計算デバイスが、特定の製薬化合物に関連する医療ケアアプリケーションをダウンロードすること、又は特定の医療状態を監視することを許可してもよい。ポータルはまた、ウェブブラウザのウェブページによるような、医療ケアアプリケーションオンラインへのアクセスを提供してもよい。一般に、上述のように、アプリケーションはモバイルデバイスに存在してもよいし、サーバに存在してもよいし、医療ケアアプリケーションポータルが医療ケアアプリケーションへのユーザによるアクセスを可能にする様々な方法が存在するように、分散されてもよい。

ブロック５３０で、医療情報の少なくとも一部が医療ケアアプリケーションを介してユーザからの入力として受信されるように、ユーザに関する医療情報が取得される。クライアント１４０は、アプリケーションに情報を入力することによって計算システム１００に情報を提供してもよい。このような情報は、図３で説明したように、喘息重症度に関する情報を含んでもよい。しかし、情報はまた、気温又は汚染情報のようなセンサからの情報や、図１に関して説明した小売処方データ１１０、長期処方データ１１２、参照処方者データ１１４及び製薬購入データ１１６のような他のエンティティからの情報を含んでもよい。

ブロック５４０で、ユーザに関する医療決定を行うために医療情報が分析される。分析プロセスは上述され、データ処理モジュール１１０と、場合によってはデータを処理するための統計ランキングモジュール１２０とを用いて医療情報を処理することを伴う。上述のように、クライアント１４０に関する情報は、平均値のような、他の医療データからの集約された測定結果に対して比較されてもよい。

ブロック５５０で、医療決定は、医療ケアアプリケーションを介して、更なる動作のために医療意思決定者へ報告される。この文脈で、医療意思決定者は、ユーザの治療計画に関する意思決定を行いうる様々な取りうる当事者を含みうる。しかし、医療決定は、行われうる決定の単なる一タイプであり、行われうる代替のタイプの決定は、図７に関して説明される代替の実装に関連して説明される。患者は医療決定に基づいてヘルスケア選択を行いうるので、患者自身は大抵の場合に医療意思決定者であると考えられる。しかし、他の当事者が医療意思決定者の役割を果たしてもよい。例えば、子どもである患者について、子どもの親又は保護者が医療意思決定者であってもよい。さらに、医療意思決定者は、医者、看護師、薬剤師、及び他のヘルスケア専門家並びに場合によっては保険提供者も含んでもよい。医療決定を医療意思決定者へ報告することによって、医療意思決定者は患者の医療ケアを進めるために適切な動作をとりうる。報告は、報告モジュール１２２によって実行されてもよい。例えば、医療決定は、患者が医療予約を行うこと又はケアプランを変更することの示唆であってもよい。医療決定はまた、医療状態を治療するためにユーザが医療ケアアプリケーションにアクセスすべきであることの決定を含んでもよい。例えば、実装は、医者への血圧追跡アプリケーションに、高血圧である患者へ示唆することを勧告してもよい。

図６は、モバイルデバイスでアプリケーション間のセキュアな情報交換を管理するための例示のシステムを説明するブロック図である。例えば、このようなシステムは、モバイルデバイスでアプリケーション間のセキュアな情報交換を管理するモジュールであるＩＭＳ医療アプリケーションポータル６１０を含んでもよい。ＩＭＳ医療アプリケーションポータル６１０自体は、ある実装において、モバイルデバイスでホスティングされてもよいし、ウェブポータルによってアクセスされてもよい。ＩＭＳ医療アプリケーションポータル６１０は、組込み機能を有するアプリケーションであるが、単なる単一アプリケーションではない。ＩＭＳ医療アプリケーションポータル６１０は、安全かつセキュアな環境でサードパーティアプリケーションを統合するセキュアモバイル環境である。これは、センシティブなヘルス情報をアプリケーション間でセキュアに共有することを可能にする。さらに、これは、情報交換を促進するために、電子メール経由ではなく、電子医療記録（ＥＭＲ）システムに直接に接続する。さらに、ＩＭＳ医療アプリケーションポータル６１０は、医療データを受信し、当該データをアプリ間でルーティングする情報ゲートウェイとして機能できる。

ルーティングされた医療データは、１以上のアプリ６２０Ａ、６２０Ｂ、…、６２０Ｎから取得されてもよい。ＩＭＳ医療アプリケーションポータル６１０は、情報交換の容易化を助ける様々なコンポーネントを有してもよい。これらのコンポーネントは、指定された機能を実行するための適切なソフトウェア及び／又はハードウェアからなるモジュールを含んでもよい。ＩＭＳ医療アプリケーションポータル６１０は、アプリ統合部６３０、ポータルセキュリティモジュール６４０、ポータル機能モジュール６６０及びポータル共有モジュール６７０を含んでもよい。ポータルセキュリティモジュール６４０は、情報匿名化部６５０をさらに含んでもよい。ＩＭＳ医療アプリケーションポータル６１０はさらに、図１に記載されたコンピュータシステム１００と通信してもよい。ＩＭＳ医療アプリケーションポータル６１０はまた、医療情報への効率的なアクセスを可能にするためにＥＭＲシステム６８０と直接に相互作用する能力を有してもよい。

アプリ統合部６３０は、１以上のアプリ６２０Ａ、６２０Ｂ、…、６２０ＮをＩＭＳ医療アプリケーションポータル６１０に統合することを管理する。アプリ統合部６３０は、ユーザが自身の要求に合う適切なアプリにアクセスし相互作用できることを保証する。さらに、ポータルセキュリティモジュール６４０は、ＩＭＳ医療アプリケーションポータル６１０により動作された医療データがセキュアなままであることを保証する。上述のように、ポータルセキュリティモジュール６４０は、プライバシー要件及びセキュリティ要件が尊重されることを保証し、その結果として、個別のアプリはこれらがアクセスすべきではない情報にアクセスできず、アプリが互いに共有する際にデータはセキュアのままである。ポータルセキュリティモジュール６４０の動作の一部は、オプションとして、情報匿名化部６５０によって実行されてもよく、情報匿名化部６５０は、受信する資格を有しない情報をアプリが受信すべきでないことを保証するためにアプリ６２０Ａ、６２０Ｂ、…、６２０Ｎによって提供される情報をフィルタリングしてもよい。

ＩＭＳ医療アプリケーションポータル６１０はまた、ポータル機能モジュール６６０を含んでもよい。ポータル機能モジュール６６０は、図のアイテム２２０、２３０Ａ−Ｅに描かれるヘルスツールのようなＩＭＳ医療アプリケーションポータル６１０の基本機能を提供する。さらに、ＩＭＳ医療アプリケーションポータル６１０は、ポータル共有モジュール６７０を含んでもよい。ポータル共有モジュール６７０は、アプリ間のデータ交換を管理する。例えば、アプリ６２０Ａから受信する情報を集中型として収集、記憶することによってデータ交換を管理し、ポータルセキュリティモジュール６４０がそうすることが適切であると示すならば、その後に別のアプリ６２０Ｂと情報を共有する。

図７は、医療ケアアプリケーションポータルが複数の医療ケアアプリケーションにアクセスし、複数の医療ケアアプリケーション間の情報交換を保護するプロセスのフローチャートである。

ブロック７１０で、実装は、第１医療アプリケーションへのアクセスを提供する。具体的に、ユーザは、モバイルデバイスの第１医療アプリケーションへのアクセスを提供され、アプリケーションはユーザの医療状態に関する。第１医療アプリケーションは、肝炎又は嚢胞性線維症のようなユーザの特定の医療状態や、ユーザの健康全体を含みうるユーザの一般的な医療状態に関するものとして選択されてもよい。このステップがどのように生じるかの例は図２、図３で説明される。医療アプリケーションポータルは、ユーザに医療アプリケーションへのアクセスを提供してもよい。例えば、ＩＭＳ医療アプリケーションポータル２００は、喘息トラッカ２５０Ａのような特定のアプリケーションへのユーザによるアクセスを容易にしてもよい。ユーザによる喘息トラッカ２５０Ａへのアクセスは、図３の一部のサンプルスクリーンショットによって説明される。ポータルは、様々な方法で第１医療アプリケーションへのアクセスを提供してもよい。ポータルは、クライアントデバイスへ医療アプリケーションをダウンロードしてもよい。これに代えて、医療アプリケーションは、例えばプラグイン又はスクリプト技術を通じて、ウェブブラウザにおいて提供されてもよい。実装のプロセスのこの部分の追加の側面は、一般に、ユーザの医療状態に関するものとしてヘルスヘア専門家によってアプリケーションがユーザのために選択されることである。例えば、ユーザの神経科医は、ユーザによる使用のためにＭＳマネージャ２５０Ｂを処方してもよい。しかし、ヘルスケアアプリケーションは、他のヘルスケア提供者だけでなく、ヘルスケアプロセスに関与する他の専門家によって処方されてもよい。これらの方法の実装の変形において、診断される医療状態に対処するためにユーザが自身で医療アプリケーションを選択することも確かに可能であることにも留意されうる。例えば、図４は、「新しいアプリを閲覧」４４０、「治療エリア別」４５０Ａ、「アプリ発行者別」４５０Ｂ、「人気別」４５０Ｃ、「アルファベット順」４５０Ｄをユーザに可能にするＩＭＳ医療アプリケーションポータルのユーザインタフェースの一部を示す。よって、図４は、ユーザがアプリケーションを選択し、ヘルスケア専門家によって単に割り当てられたものではない実装を示す。

ブロック７２０で、実装は医療データを受信する。具体的に、医療データはユーザから受信され、医療データの少なくとも一部はモバイルデバイスによって提供される情報ゲートウェイにおいて第１医療アプリケーションを介してユーザから受信され、医療データは医療状態に関するプライベート情報を有する。医療データが受信される方法は、アプリケーションごと、および実装ごとに変わってもよい。医療データの少なくとも一部はアプリケーションを介してユーザから受信されてもよい。このようなデータは一般にユーザとモバイルデバイスとの間の情報交換によって受信される。例えば、ユーザは、アプリケーションによって提供されるインタフェースに入力を与えるために、キーボード、タッチスクリーン、マイク、コントロールボタンなどのような様々な入力デバイスを用いてもよい。しかし、アプリケーションはまた、他の手段によって医療データを十分に受信できてもよい。例えば、ユーザが医療アプリケーションに、ユーザのための医療ケアに関する情報を含む、電子医療記録のようなファイルにアクセスすることを命令することが可能であってもよい。他の医療情報は、小売薬局、医者又は製薬会社によって提供されてもよい。さらに、医療情報は、ユーザの身体状態に関する情報を収集するセンサから導出されてもよい。これらのセンサは、血圧、体温、血液酸素などのようなユーザに関する診断データを提供してもよい。医療情報はまた、血液サンプル又は尿サンプルの分析のような検査法からの情報や、薬物レベル又は感染症の存在についての検査テストに関する情報を含んでもよい。また、医療情報は、実装がプライベートデータを保護するように設計されている際に、一部のこのようなデータを少なくとも含むべきである。プライベートデータのみ又は非プライベートデータのみを含む実装を想像することは確かに可能であるが、どのデータが誰からもアクセス可能であるべきかを実装が認識し、どのデータが制限されたアクセスを有し、誰が当該データにアクセスできるかを管理することが重要である。

ブロック７３０で、実装は医療データを送信する。具体的に、ユーザの医療状態に関する結論を生成するために後で使用するためのセキュア情報リポジトリへの医療データ。上述のように、医療データは、ブロック７２０で第１医療アプリケーションを介してユーザから受信された。図１の文脈で、このステップは、医療データをストレージデバイス１２４へ送信するＩＭＳ医療アプリケーションポータル２００をホスティングするクライアント１４０によって実装されうる。しかし、医療データがどのように記憶されるかの詳細は、実装ごとに変わってもよい。必要なストレージの側面は、ストレージがデータのプライベート部分のプライバシーを保護できなければならないことである。よって、データへのアクセスがその後に要求された場合に、セキュア情報リポジトリは、任意の要求者へ任意のパブリックデータを提供すべきだが、適切に許可された部分のみがプライベートデータへアクセスできるべきである。

ブロック７４０で、実装は第２医療アプリケーションを識別する。具体的に、ユーザの医療状態に関連する第２医療アプリケーションが識別される。第２医療アプリケーションは、ブロック７１０に関して上述したように、患者自身のような様々な当事者によって識別されてもよい。１つの実装では、アプリケーションは、ユーザの医療状態に関するものとして識別される。しかし、変形が可能である。例えば、アプリケーションは、ユーザが摂取する薬物、ユーザが使用する医療デバイス又はユーザが相手にする開業医のタイプのような、ユーザのヘルスケアに密接な関係がある他の情報に基づいて識別されてもよい。これに代えて、第２医療アプリケーションの選択は、第１医療アプリケーションの識別に基づいてもよいし、第１医療アプリケーションから収集された情報に基づいてもよい。例えば、第１医療アプリケーションは、糖尿病管理スイートであってもよいし、当該アプリケーションによって収集された検査結果は、高血圧薬の投与を追跡するアプリケーションの必要性を示唆してもよい。

ブロック７５０で、実装は、第２医療アプリケーションを認証する。具体的に、第２医療アプリケーションは、セキュア情報リポジトリにおいて医療データへのアクセスを第２医療アプリケーションに提供するために認証される。この段階で、第２医療アプリケーションは、ユーザの代わりにプライベート情報にアクセスする資格を合法的に有するという情報を受信し、使用する。これは、ユーザアカウントへのログイン及びパスワードのような情報、ＳＳＮ又は誕生日のような識別情報、又はスワイプパターン又は指紋、声門又は虹彩スキャン識別情報のような生体認証を含んでもよい。認証はまた、公開鍵暗号又は秘密鍵暗号のような、第２医療アプリケーションによってアクセスされる情報についてセキュアな接続を確立できる暗号化を伴ってもよい。認証は、一般的に、第２医療アプリケーションに、ユーザのパブリック情報だけでなく、プライベート情報の少なくとも一部へのアクセスを提供する。

ブロック７６０で、実装は医療データを共有する。具体的に、医療データは、認証された第２医療アプリケーションと共有される。説明したように、この段階までの第２医療アプリケーションは、ユーザの医療データの所定の部分への資格を有し、医療データが共有される場合に、当該データにアクセスする資格を有しない第三者が当該データを傍受し不適切にアクセスできないことを保証することを助けるための暗号化のようなステップが取られてもよい。一般に、このステップは、第２医療アプリケーションが、動作の一部としてセキュア情報リポジトリからの医療データを要求するように動作する。したがって、第１医療アプリケーションが、ユーザが測定した血糖レベルの読み取り値を記憶したならば、第２医療アプリケーションは、その後に、当該情報にアクセスし、これを別のアプリケーションの文脈で使用できる。

ブロック７７０で、実装は医療データを使用する。具体的に、医療データは、ユーザの医療状態に関する結論を生成するために、第２医療アプリケーションによって使用される。結論は、事実的結論であってもよいし、勧告であってもよい。結論は、ユーザの医療状態の治療を支援する結論であってもよい。例えば、結論は、診断と、ユーザが特定の治療法を開始すべきであるという判定と、ユーザが特定の治療を中止すべきであるという判定と、ユーザがケアプランを変更すべきであるという判定と、医療状態を治療するためにユーザが医療ケアアプリケーションへアクセスすべきであるという判定と、ユーザが医療専門家との予約をスケジュールすべきであるという判定とのうちの１つであってもよい。例えば、結論は、ユーザの医療状態の治療を支援するための情報を提供してもよい。別の例として、アプリケーションは、医薬品又は医療デバイスの使用、食習慣の変更、検査手順、医療予約、手術などのような様々な医療介入を示唆してもよい。

しかし、実装は、幅広い目的のために医療データを使用してもよく、医療データの使用は、単に診断又は治療勧告を提供することに排他的に制限される必要はない。実際に、本出願を通じて広範に説明されてきたように、特定のユーザに関し、かつユーザが属する大きな集団に関して、医療データから導出されうる多くの有用な結論を利用するための第２医療アプリケーションのようなアプリケーションによって医療データが使用されてもよい。例えば、このような結論は、業務上の意思決定を助けるために用いられてもよい。

よって、プライバシーの心配が尊重される必要がある間に、個別のユーザに関する医療データは、治療のためだけでなく、医療及び製薬の研究を含む他の目的や、法律行使からマーケティングへの範囲に及ぶ他のアプリケーションで用いられうる。さらに、個別のユーザについての医療データを、ユーザのグループで集約された医療データに対して比較することも可能である。このアプローチは上述されたが、ユーザの集団についてデータを集約し、様々な平均値又は集団に関する他のメトリックのような統計情報を取得し、この比較に基づいて結論を導出することが可能である。データのこのような使用の例は上述された。一般に、実装は、医療データを使用し、この文脈で医療ケア勧告及び結果を向上するためであるが、これは医療データの唯一の使用ではなく、実装は、医療データに関する第２医療アプリケーションの動作によって提供されうるヘルスケアプロセスの参加者に有用な医療データの任意の使用を含むことが理解されるべきである。

本明細書に記載された主題及び機能動作の実装は、デジタル電子回路に実装されうるし、有体に実装されるコンピュータソフトウェア又はファームウェアに実装されうるし、本明細書に開示された構造及びこれらの構造的均等物を含むコンピュータハードウェアに実装されるし、これらの１以上の組合せに実装されうる。本明細書に記載された主題の実装は、１以上のコンピュータプログラムとして、すなわち、データ処理装置による実行のため又はデータ処理装置の動作を制御するために有体の非一時的なプログラムキャリアに符号化されたコンピュータプログラム命令の１以上のモジュールとして実装されうる。コンピュータ記憶媒体は、機械可読記憶デバイス、機械可読記憶基板、ランダムアクセスメモリデバイス又はシリアルアクセスメモリデバイス、又はこれらの１以上の組合せでありうる。

「データ処理装置」という用語はデータ処理ハードウェアを指し、データを処理するためのすべての種類の装置、デバイス及び機械を包含し、例えば、プログラム可能プロセッサ、コンピュータ、又は複数のプロセッサ又はコンピュータを含む。装置はまた、特定用途ロジック回路、例えば中央処理ユニット（ＣＰＵ）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）又はＡＳＩＣ（特定用途向け集積回路）であるか、これらをさらに含みうる。一部の実装では、データ処理装置及び／又は特定用途ロジック回路は、ハードウェアベースであってもよし、ソフトウェアベースであってもよい。装置は、オプションとして、コンピュータプログラムのための実行環境を作成するコード、例えばプロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、又はこれらの１以上の組合せを構成するコードを含みうる。本開示は、従来のオペレーティングシステム、例えば、Ｌｉｎｕｘ（登録商標）、ＵＮＩＸ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、ＭａｃＯＳ（登録商標）、Ａｎｄｒｏｉｄ（登録商標）、ｉＯＳ（登録商標）又は他の任意の適切な従来のオペレーティングシステムを用いた又は用いないデータ処理装置の使用を意図する。

プログラム、ソフトウェア、ソフトウェアアプリケーション、モジュール、ソフトウェアモジュール、スクリプト又はコードとも参照されうるか、このように記載されることもありうるコンピュータプログラムは、コンパイルされた又は解釈された言語若しくは宣言型又は手続き型言語を含む任意の形式のプログラミング言語で書かれてもよく、スタンドアロンプログラム、若しくはモジュール、コンポーネント、サブルーチン又は計算環境での使用に適した他のユニットを含む任意の形式で展開されてもよい。コンピュータプログラムはファイルシステム内のファイルに対応してもよいが、対応していなくてもよい。プログラムは、他のプログラム又はデータ、例えばマーク付け言語文書、対象のプログラムに専用の単一ファイル、又は複数の連携したファイル、例えば１以上のモジュール、サブプログラム、又はコードの一部に格納される１以上のスクリプトを保持するファイルの一部に格納されうる。コンピュータプログラムは、１つの場所に位置する１つのコンピュータ又は複数の場所にまたがって分散され、通信ネットワークによって相互接続された複数のコンピュータで実行されるように展開されうる。様々な図で説明されたプログラムの一部は様々なオブジェクト、メソッド又は他のプロセスを通じて様々な特徴及び機能を実装する個別のモジュールとして示されるが、その代わりにプログラムは必要に応じて複数のサブモジュール、サードパーティサービス、コンポーネント、ライブラリ、及びこのようなものを含んでもよい。反対に、様々なコンポーネントの特徴及び機能は、必要に応じて単一のコンポーネントに組み込まれてもよい。

本明細書に記載されるプロセス及びロジックフローは、入力データで動作し出力を生成することによって機能を実行するための１以上のコンピュータプログラムを実行する１以上のプログラム可能コンピュータによって実行されうる。プロセス及びロジックフローはまた、特定用途ロジック回路、例えば中央処理ユニット（ＣＰＵ）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）又はＡＳＩＣ（特定用途向け集積回路）によって実行されてもよいし、装置はまた、これらとして実装されてもよい。

コンピュータプログラムの実行に適したコンピュータは、例として、汎用マイクロプロセッサ若しくは特殊用途マイクロプロセッサ又はこの両方又は他の任意の種類の中央処理ユニットに基づきうる。一般に、中央処理ユニットは、リードオンリメモリ若しくはランダムアクセスメモリ又はこの両方から命令及びデータを受信する。コンピュータの必須要素は、命令を実行するための中央処理ユニットと、命令及びデータを記憶するための１以上のメモリデバイスとである。一般に、コンピュータはまた、データを記憶するための１以上の大容量記憶デバイス、例えば磁気ディスク、光磁気ディスク又は光ディスクを含むか、これらからデータを受信し、これらにデータを送信するように動作可能に結合されるか、これらの両方である。しかし、コンピュータはこれらのデバイスを有していなくてもよい。さらに、コンピュータは、別のデバイス、例えば、モバイル電話、携帯情報端末（ＰＤＡ）、モバイルオーディオ／ビデオプレーヤ、ゲーム機、全地球測位システム（ＧＰＳ）受信機、又はポータブル記憶デバイス、例えば少しだけ名前を挙げるとユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブに組み込まれてもよい。

コンピュータプログラム命令及びデータを記憶するのに適したコンピュータ可読媒体（必要に応じて一時的又は非一時的）は、すべての形式の不揮発性メモリ、媒体及びメモリデバイスを含み、例として半導体メモリデバイス、例えばＥＰＲＯＭ、ＥＥＰＲＯＭ及びフラッシュメモリデバイス、磁気ディスク、例えば内部ハードディスク又はリムーバブルディスク、光磁気ディスク、並びにＣＤ−ＲＯＭディスク及びＤＶＤ−ＲＯＭディスクを含む。メモリは、キャッシュ、クラス、フレームワーク、アプリケーション、バックアップデータ、ジョブ、ウェブページ、ウェブページテンプレート、データベーステーブル、業務情報及び／又は動的情報を記憶するリポジトリ、並びに任意のパラメータ、変数、アルゴリズム、命令、規則、制約又はこれらへの参照を含む他の任意の適切な情報を含む様々なオブジェクト又はデータを記憶してもよい。さらに、メモリは、ログ、ポリシー、セキュリティデータ又はアクセスデータ、報告ファイルなどのような他の任意の適切なデータを含んでもよい。プロセッサ及びメモリは、特定目的ロジック回路によって補完されてもよく、これと統合されてもよい。

ユーザとの相互作用を提供するために、本明細書に記載される主題の実装は、ユーザへの情報を表示するためのディスプレイデバイス、例えばＣＲＴ（ブラウン管）、ＬＣＤ（液晶ディスプレイ）又はプラズマモニタ、並びにユーザがコンピュータへ入力を提供できるキーボード及びポインティングデバイス、例えばマウス又はトラックボールを有するコンピュータに実装されうる。他の種類のデバイスもユーザとの相互作用を提供するために用いられうる。例えば、ユーザへ提供されるフィードバックは、任意の形式の感覚フィードバック、例えば視覚フィードバック、聴覚フィードバック又は触覚フィードバックであってもよく、ユーザからの入力は、音響入力、音声入力又は触覚入力を含む任意の形式で受信されうる。さらに、コンピュータは、ユーザによって用いられるデバイスへ文書を送信し、当該デバイスから文書を受信することによって、例えばウェブブラウザから受信された要求に応答してユーザのクライアントデバイスのウェブブラウザへウェブページを送信することによって、ユーザと相互作用できる。

「グラフィカルユーザインタフェース」すなわちＧＵＩという用語は、１以上のグラフィカルユーザインタフェースと、特定のグラフィカルユーザインタフェースの表示のそれぞれとを説明するために単数形又は複数形で用いられてもよい。従って、ＧＵＩは、ウェブブラウザ、タッチスクリーン、又は情報を処理し、情報の結果をユーザへ効率的に提示するコマンドラインインタフェース（ＣＬＩ）を含むがこれらに限定されない任意のグラフィカルユーザインタフェースを表してもよい。一般に、ＧＵＩは、業務スイートのユーザにより動作可能なインタラクティブフィールド、プルダウンリスト、及びボタンのような、複数のユーザインタフェース（ＵＩ）要素を含んでもよく、これらの一部又は全部はウェブブラウザに関連する。これらのＵＩ要素及び他のＵＩ要素は、ウェブブラウザの機能に関連してもよく、当該機能を表してもよい。

本明細書に記載される主題の実装は、例えばデータサーバのようなバックエンドコンポーネントを含む計算システムか、例えばアプリケーションサーバのようなミドルウェアコンポーネントを含む計算システムか、例えば本明細書に記載される主題の実装にユーザが相互作用できるグラフィカルユーザインタフェース又はウェブブラウザを有するクライアントコンピュータのようなフロントエンドコンポーネントを含む計算システムか、１以上のこのようなバックエンドコンポーネント、ミドルウェアコンポーネント又はフロントエンドコンポーネントの任意の組合せで実装されうる。システムのコンポーネントは、任意の形式の又は媒体のデジタルデータ通信、例えば通信ネットワークによって相互接続されうる。通信ネットワークの例は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、例えばインターネット、及び無線ローカルエリアネットワーク（ＷＬＡＮ）を含む。

計算システムは、クライアント及びサーバを含みうる。クライアント及びサーバは一般に互いにリモートにあり、典型的に通信ネットワークを通じて相互作用する。クライアントとサーバとの関係は、各コンピュータで実行され、互いにクライアント‐サーバ関係を有するコンピュータプログラムのおかげで生じる。

様々な実装の調合薬は、必ずしも重度に制御される必要はなく、本明細書に提示される方法は店頭薬に等しく当てはまり、場合によっては医学的治療に影響を有する可能性のある漢方薬又は栄養剤にさえも当てはまる。臨床的鬱病の患者を治療するためのセイヨウオトギリソウの使用が実装によって考慮されてもよく、魚油のような栄養剤又は処方抗欝剤でありうる。

この明細書は多くの特定の実装の詳細を含むが、これらは任意の発明の範囲又は主張されうるものの範囲に関する制限とみなされるべきではなく、特定の発明の特定の実装に固有でありうる特徴の記載としてみなされるべきである。別個の実装の文脈においてこの明細書で記載される何らかの特徴はまた、単一の実装において組み合わせて実装されうる。反対に、単一の実装の文脈において記載される様々な機能はまた、複数の実装で別々に又は任意の適切なサブコンビネーションで実装されうる。さらに、何らかの組合せで動作し、このようなものとして最初に主張されるように特徴が上述されるが、主張される組合せからの１以上の特徴は、一部の場合に組合せから除去されてもよいし、主張される組合せはサブコンビネーション又はサブコンビネーションの変形を対象としてもよい。

同様に、図面において特定の順序で動作が描かれるが、これは、所望の結果を達成するために、このような動作が、示される特定の順番で又は直列の順番で実行されること、又は説明される全ての動作が実行されることを要求するものとして理解されるべきではない。何らかの環境では、マルチタスク処理及び並列処理が有用でありうる。さらに、上述の実装における様々なシステムモジュール及びコンポーネントの分離は、すべての実装においてこのような分離が要求されるものとして理解されるべきではなく、記載されるプログラムコンポーネント及びシステムは一般に単一のソフトウェア製品にまとめて統合されうるか、複数のソフトウェア製品にパッケージされうることが理解されるべきである。

主題の特定の実装が記載されてきた。当業者に明らかなように、記載された実装の他の実装、変形及び並び替えが以下の特許請求の範囲に含まれる。例えば、特許請求の範囲に記載される動作は、異なる順番で実行されてもよく、なおも所望の結果を達成できる。

従って、例示の実装の上記の記載は、この開示を規定又は限定しない。この開示の精神及び範囲から逸脱することなく他の変化、置換又は変形も可能である。

Claims (21)

1. 医療ケアアプリケーションポータルによって実行されるコンピュータ実装方法であって、
   モバイルデバイス上にあり、ユーザの医療状態に関連する第１医療アプリケーションへのアクセスを前記ユーザへ提供する工程と、
   医療データを受信する工程であって、前記医療データの少なくとも一部は、前記モバイルデバイスによって提供される情報ゲートウェイにおいて前記第１医療アプリケーションを介して前記ユーザから受信され、前記医療データは前記医療状態に関連するプライベート情報を含む、工程と、
   前記医療データを、前記ユーザの前記医療状態に関する結論の生成するためのその後の使用のためにセキュア情報リポジトリへ送信する工程と、
   前記ユーザの前記医療状態に関連する第２医療アプリケーションを識別する工程と、
   前記セキュア情報リポジトリにおいて前記医療データへのアクセスを前記第２医療アプリケーションに提供するために前記第２医療アプリケーションを認証する工程と、
   前記認証された第２医療アプリケーションと前記医療データを共有する工程と、
   前記ユーザの前記医療状態に関する結論を生成するために前記第２医療アプリケーションによって前記医療データを使用する工程とを有することを特徴とするコンピュータ実装方法。
2. 前記結論は、前記ユーザの前記医療状態の治療を支援する結論であることを特徴とする請求項１に記載のコンピュータ実装方法。
3. 前記結論は、診断と、ユーザが特定の治療法を開始すべきであるという判定と、ユーザが特定の治療法を中止すべきであるという判定と、ユーザがケアプランを変更すべきであるという判定と、医療状態を治療するためにユーザが医療ケアアプリケーションにアクセスすべきであるという判定と、ユーザが医療専門家との予約をスケジュールすべきであるという判定とのうちの１つであることを特徴とする請求項２に記載のコンピュータ実装方法。
4. 前記結論は、業務上の意思決定を行うためのヘルスケアプロセスの参加者を助ける情報であることを特徴とする請求項１に記載のコンピュータ実装方法。
5. 前記結論は、前記ユーザについての前記医療データを、他のユーザについて取得された識別不能な集約医療データに対して比較することに少なくとも部分的に基づくことを特徴とする請求項１に記載のコンピュータ実装方法。
6. 前記第１医療ケアアプリケーションは、特定の製薬化合物、特定の医療状態、特定の製薬製造者又は特定のヘルスケア専門家に関連することを特徴とする請求項１に記載のコンピュータ実装方法。
7. 前記医療情報の少なくとも一部は、電子医療記録システムと、医療請求記録システムと、小売薬局記録システムと、ヘルスケア専門家記録システムと、製薬会社記録システムと、モバイル計算デバイスに通信可能に結合されたセンサとのうちの少なくとも１つから受信されたデータから取得されることを特徴とする請求項１に記載のコンピュータ実装方法。
8. １以上のコンピュータと命令を記憶する１以上のストレージデバイスとを備えるシステムであって、
   前記命令は、前記１以上のコンピュータによって実行された場合に、前記１以上のコンピュータに、
   モバイルデバイス上にあり、ユーザの医療状態に関連する第１医療アプリケーションへのアクセスを前記ユーザへ提供する動作と、
   医療データを受信する動作であって、前記医療データの少なくとも一部は、前記モバイルデバイスによって提供される情報ゲートウェイにおいて前記第１医療アプリケーションを介して前記ユーザから受信され、前記医療データは前記医療状態に関連するプライベート情報を含む、動作と、
   前記医療データを、前記ユーザの前記医療状態に関する結論の生成するためのその後の使用のためにセキュア情報リポジトリへ送信する動作と、
   前記ユーザの前記医療状態に関連する第２医療アプリケーションを識別する動作と、
   前記セキュア情報リポジトリにおいて前記医療データへのアクセスを前記第２医療アプリケーションに提供するために前記第２医療アプリケーションを認証する動作と、
   前記認証された第２医療アプリケーションと前記医療データを共有する動作と、
   前記ユーザの前記医療状態に関する結論を生成するために前記第２医療アプリケーションによって前記医療データを使用する動作とを実行させるように動作可能であることを特徴とするシステム。
9. 前記結論は、前記ユーザの前記医療状態の治療を支援する結論であることを特徴とする請求項８に記載のシステム。
10. 前記結論は、診断と、ユーザが特定の治療法を開始すべきであるという判定と、ユーザが特定の治療法を中止すべきであるという判定と、ユーザがケアプランを変更すべきであるという判定と、医療状態を治療するためにユーザが医療ケアアプリケーションにアクセスすべきであるという判定と、ユーザが医療専門家との予約をスケジュールすべきであるという判定とのうちの１つであることを特徴とする請求項９に記載のシステム。
11. 前記結論は、業務上の意思決定を行うためのヘルスケアプロセスの参加者を助ける情報であることを特徴とする請求項８に記載のシステム。
12. 前記結論は、前記ユーザについての前記医療データを、他のユーザについて取得された識別不能な集約医療データに対して比較することに少なくとも部分的に基づくことを特徴とする請求項８に記載のシステム。
13. 前記第１医療ケアアプリケーションは、特定の製薬化合物、特定の医療状態、特定の製薬製造者又は特定のヘルスケア専門家に関連することを特徴とする請求項８に記載のシステム。
14. 前記医療情報の少なくとも一部は、電子医療記録システムと、医療請求記録システムと、小売薬局記録システムと、ヘルスケア専門家記録システムと、製薬会社記録システムと、モバイル計算デバイスに通信可能に結合されたセンサとのうちの少なくとも１つから受信されたデータから取得されることを特徴とする請求項８に記載のシステム。
15. １以上のコンピュータによって実行可能な命令を含むソフトウェアを記憶する非一時的なコンピュータ可読な記憶媒体であって、
    前記命令は、実行された場合に、前記１以上のコンピュータに、
    モバイルデバイス上にあり、ユーザの医療状態に関連する第１医療アプリケーションへのアクセスを前記ユーザへ提供する動作と、
    医療データを受信する動作であって、前記医療データの少なくとも一部は、前記モバイルデバイスによって提供される情報ゲートウェイにおいて前記第１医療アプリケーションを介して前記ユーザから受信され、前記医療データは前記医療状態に関連するプライベート情報を含む、動作と、
    前記医療データを、前記ユーザの前記医療状態に関する結論の生成するためのその後の使用のためにセキュア情報リポジトリへ送信する動作と、
    前記ユーザの前記医療状態に関連する第２医療アプリケーションを識別する動作と、
    前記セキュア情報リポジトリにおいて前記医療データへのアクセスを前記第２医療アプリケーションに提供するために前記第２医療アプリケーションを認証する動作と、
    前記認証された第２医療アプリケーションと前記医療データを共有する動作と、
    前記ユーザの前記医療状態に関する結論を生成するために前記第２医療アプリケーションによって前記医療データを使用する動作とを実行させるように動作可能であることを特徴とする記憶媒体。
16. 前記結論は、前記ユーザの前記医療状態の治療を支援する結論であることを特徴とする請求項１５に記載の記憶媒体。
17. 前記結論は、診断と、ユーザが特定の治療法を開始すべきであるという判定と、ユーザが特定の治療法を中止すべきであるという判定と、ユーザがケアプランを変更すべきであるという判定と、医療状態を治療するためにユーザが医療ケアアプリケーションにアクセスすべきであるという判定と、ユーザが医療専門家との予約をスケジュールすべきであるという判定とのうちの１つであることを特徴とする請求項１６に記載の記憶媒体。
18. 前記結論は、業務上の意思決定を行うためのヘルスケアプロセスの参加者を助ける情報であることを特徴とする請求項１５に記載の記憶媒体。
19. 前記結論は、前記ユーザについての前記医療データを、他のユーザについて取得された識別不能な集約医療データに対して比較することに少なくとも部分的に基づくことを特徴とする請求項１５に記載の記憶媒体。
20. 前記第１医療ケアアプリケーションは、特定の製薬化合物、特定の医療状態、特定の製薬製造者又は特定のヘルスケア専門家に関連することを特徴とする請求項１５に記載の記憶媒体。
21. 前記医療情報の少なくとも一部は、電子医療記録システムと、医療請求記録システムと、小売薬局記録システムと、ヘルスケア専門家記録システムと、製薬会社記録システムと、モバイル計算デバイスに通信可能に結合されたセンサとのうちの少なくとも１つから受信されたデータから取得されることを特徴とする請求項１５に記載の記憶媒体。

Images